-
-
Notifications
You must be signed in to change notification settings - Fork 179
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flatten dofmap storage #2632
Flatten dofmap storage #2632
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general Im in favor of this change, as it would simplify libraries such as dolfinx_mpc and asimov_contact.
See comments for minor things.
This change will make it a bit more difficult for me in
in my dofmaps since I cannot assume that every cell has the same number of dofs. To help me sort this out, is there any way I can create a |
The approach to this that we're following is to have separate DofsMap for each 'element' type. But we're not quite there yet.
No, because @francesco-ballarin do you use the DOLFINx assemblers in |
@garth-wells I am reusing as much as I can from DOLFINx assembly, with a few minimal changes in matrix/vector allocation that I keep in sync with the upstream repo. The first place in which I swap out a standard dolfinx dofmap for a I guess I can still swap that out for a pair containing: as first item, the |
I confirm I have proceeded in this way, and restored |
This change stores dofmap data as flat vectors rather than AdjacencyLists, and uses
mdspan
for convenient access. This uses less memory that AdjacencyLists and data access is more performance friendly.Assumption is that all elements in a DofMap have the same number io dofs. This is presently that case, and for more complex cases in the future, e.g. mixed cell types, each element type will have its own DofMap. This follows the design that has been started for mixed topology, where cells are stored by type, and operations like assembly will be per cell type/kernel.
It's useful to make this change now as unpicking the code will be a lot harder once mixed topology support is further developed. Moreover, removing necessary use of
AdjacencyList
makes considerations dealing with #2624 simpler as the impact of any change is reduced.