On Fri, Mar 6, 2015 at 10:38 AM, Anders Logg <[email protected]> wrote: > 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...). >
I agree that at this level runtime performance should be the priority. All testing I've ever done points to flattened array being better. We can add helper code on the DOLFIN side to ease populating the arrays. Garth > -- > 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 > > > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics > _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
