On Fri, Mar 6, 2015 at 11:13 AM, Anders Logg <[email protected]> wrote: > An additional point is that run-time performance may also be affected by > needing to copy stuff into flattened arrays on the DOLFIN side so in some > cases flattening may not be the most effecient option. >
Coefficient data generally comes from a function eval or out of a GenericVector, so there is not issue with flattening the data in this case. Garth > -- > Anders > > > fre 6 mars 2015 kl 11:52 skrev Garth N. Wells <[email protected]>: >> >> 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 _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
