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

Reply via email to