Lets go for all in flat packed arrays then. UFC can easily provide the expected offsets into packed input arrays:
vector<size_t> coefficient_dof_offsets(); // indexed by coefficient id vector<size_t> coordinate_dof_offsets(); // indexed by domain id Martin On 6 March 2015 at 13:39, Garth N. Wells <[email protected]> wrote: > 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
