For the code generation we should pick the signature that is most efficient (from a run-time point of view) so testing is needed. When this was last brought up (Cambridge Jan two years ago) I made some rudimentary tests - see attachment that indicated flattening is good.
Regarding the custom_integral interface, we need to use one flattened array instead of two cells (as for interior_facet_integral) since there can be more than two cells (perhaps hundreds...). -- Anders tors 5 mars 2015 kl 15:38 skrev Martin Sandve Alnæs <[email protected]>: > The tabulate_tensor signatures are inconsistent in how the > different arguments are treated in the face of multiple cells. > > In the interior_facet_integral, there are explicitly named arguments > vertex_coordinates_0 and a vertex_coordinates_1, while in > custom_integral, a single flat vertex_coordinates array is used > with coordinates from two cells being packed into that array in > the MultiMeshAssembler. > > In all tabulate_tensor signatures, the dofs are passed in a single > "double**w" where the first dimension is the function id and the second > is the dof numbering with dofs from two cells in intererior_facet_integral > packed contiguously. > > I don't intend to go through everything and make it consistent in one go, > but I think that for changes that will happen in the near and far future > we > should aim for a single philisophy and move towards that when we > add something new or modify something old. > > From the code generation perspective I think it doesn't matter a lot, > it's more important to keep the dolfin side clean and easy to edit. > Packing every array flat keeps the ufc signatures flexible but moves > complexity over to documentation and conventions. The implementation > in dolfin may or may not be more complex because flat arrays are easy > to create and copy but harder to populate with more manual indexing > perhaps. > This can also be a question of performance, we should avoid > unnecessary work in the inner loops of assemblers. > > Here are the candidates with dimensions in comments (consts removed for > clarity): > > // element tensor(s) > double* A // [sum of packed element tensor size for each domain] > > // dofs of coefficient functions (num_dofs_for_this_coefficient varies) > double ** w // > [num_coefficients][num_dofs_for_this_coefficient*num_domains] > > // coordinates of cell vertices (should also be generalized to > coordinate_dofs) > double* vertex_coordinates // [num_domains*num_cell_vertices*gdim] > double* vertex_coordinates_0 // [num_cell_vertices*gdim] > double* vertex_coordinates_1 // ditto > > // quadrature rules > double* quadrature_points // [num_points] > double* quadrature_weights // [num_points*gdim] > > // geometric quantities > double* facet_normals // [num_points*gdim]? > > Martin >
main.cpp
Description: Binary data
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
