Making the entity (facet, vertex) an array dimension in the psi tables would make some code simpler
Being able to access e.g. element value tables without a switch:
v = FE0_C0_
instead of
switch (facet)
{
case 0:
v = FE0_F0_
...
}
Is this a lot of work? It would make my life easier in uflacs, so I can do it if it's feasible but would like to know how hard it will be...
Blueprint information
- Status:
- Started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Approved
- Assignee:
- None
- Definition:
- Approved
- Series goal:
- None
- Implementation:
-
Started
- Milestone target:
- None
- Started by
- Martin Sandve Alnæs
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
JH:
- Me like concept! Also, (should maybe be discussed elsewhere) when tabulating sub entities like facets and vertices we never tabulate the whole tensor. Passing a reduced tensor would then make sense.
KBO: It depends on how deep in you will go (I suppose you will get rid of the switch completely?).
Apart from making your life simpler, it could also reduce the size of the generated code particularly for dg in three dimensions.
On the downside, it will be more difficult to find all zeros in the tables, the nzcs arrays will have to be two dimensional (depend on facets).
But if you ingnore that part of the optimisation anyway, it will be OK.
The following is based on memory, I did not look at the code.
Two approaches as I see it.
1) In the code where psi values are tabulated (a loop over facets) as rank two tensors, you just create a rank three which is easy in Python. Then you just modify the code where the tensor (C++) is generated.
2) Generate the rank three C++ tensor directly from the rank two tensors by a simple loop over facets.
So, not that difficult as I see it, but could be that I overlooked something.
MSA: After looking a bit at the code, I find it hard to see the total scope of such changes. There's a lot of code in ffc that involves tables and nzcs that only runs under particular circumstances with certain choices of elements and certain options set, which is really hard to modify. So instead I'm working on doing what I need for uflacs only instead of changing existing ffc code. Instead of full sparsity tables (nzcs) I discover only all-zero columns, which removes the bulk of the zeros and avoids indirect array indexing in the generated code.
KBO: That's more or less what I wrote. If you ignore the nzcs and only remove the zeros arising from vector elements, then you can use approach 1) or 2) as outlined above. But depending on how you plan on hooking that particular part of ffc into uflacs, it might be easier for you to generate your own tables.
