On Fri, Mar 6, 2015 at 12:02 PM, Martin Sandve Alnæs <[email protected]> wrote: > Is that the case for vertex coordinates? (Or coordinate dofs in a more > generic parameterized geometry setting). > > Then using double ** coordinate_dofs, like for w, could be a good choice > allowing for an arbitrary number of cells. In particular because the cells > can have a different number of coordinate dofs so the packed array is not > rectangular, same as with w. >
I think it's still better to flatten the data and pass an integer array that points into the flat array. I expect that this would be easier to vectorise, and if necessary to pad data. > We can also easily generate ufc code for packing and unpacking. > A possible problem with this is that UFC doesn't know how the data is stored in DOLFIN so won't be able to apply certain optimisations. Garth > Martin > > 6. mar. 2015 12.13 skrev "Anders Logg" <[email protected]>: > >> 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. >> >> -- >> 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 >> > _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
