One can imagine that both is possible simultaneously with templated interface:
1. function calls [resize() | asks for size by size()] if argument supports it 2. it is caller responsibility to [resize | pass in size (by std::size_t*)] respectively Jan On Mon, 09 Mar 2015 19:02:22 +0000 Anders Logg <[email protected]> wrote: > My interpretation was to template over a type that supports > operator[] and size() in which case we could send in both std::vector > and dolfin::array (which would be able to wrap a raw pointer), but > perhaps that extra wrapping could be costly. > > -- > Anders > > > mån 9 mars 2015 kl 19:57 skrev Garth N. Wells <[email protected]>: > > > On Mon, Mar 9, 2015 at 6:51 PM, Anders Logg <[email protected]> > > wrote: > > > What would that look like? > > > > Just template over the container type and use operator[] to access. > > > > Could you give an example? Could it be made to > > > support both std::vector and raw pointers? > > > > Yes, but we wouldn't have access to all the features of a > > std::vector and we'd still need to pass the array size. > > > > Or are you thinking about using > > > dolfin::Array? > > > > I hadn't considered using DOLFIN types in the interface, but > > dolfin::Array and dolfin::ArrayView could be used. > > > > If so, that might be a good idea actually to have a > > > consistent interface. > > > > > > > I think templates at this level could/would be good, but we'd have > > to check that the need to template in DOLFIN doesn't go viral. > > > > Garth > > > > > -- > > > Anders > > > > > > > > > mån 9 mars 2015 kl 19:49 skrev Garth N. Wells <[email protected]>: > > >> > > >> On Mon, Mar 9, 2015 at 6:39 PM, Anders Logg > > >> <[email protected]> > > wrote: > > >> > This was the reason we decided to use foo* in the initial > > >> > version of > > the > > >> > UFC > > >> > interface. There was likely also a suspicion that it might be > > >> > more efficient > > >> > than std::vector but even if that suspicion was wrong, the > > >> > other argument > > >> > still holds: it gives maximal flexibility for the user of the > > interface > > >> > (DOLFIN). > > >> > > > >> > Another point would be to say that DOLFIN is the only user of > > >> > the interface > > >> > so we might as well use whatever is most convenient from the > > >> > DOLFIN side, > > >> > but that would lead to a messy mix of containers. > > >> > > > >> > > >> Not necessarily if the interface is templated. There is merit to > > >> making it templated, e.g. support for std::complex or support for > > >> Eigen data structures. > > >> > > >> Garth > > >> > > >> > > >> > -- > > >> > Anders > > >> > > > >> > > > >> > mån 9 mars 2015 kl 19:26 skrev Garth N. Wells > > >> > <[email protected]>: > > >> >> > > >> >> I'm not a fan of foo*, but I think it's the better choice. > > >> >> The upside is that it places few constraints on the storage > > >> >> container on the DOLFIN side. The downsides are that it's > > >> >> less safe, the function called can't do the resizing for us, > > >> >> and we need an extra function to return the size of the array. > > >> >> > > >> >> Garth > > >> >> > > >> >> On Mon, Mar 9, 2015 at 1:34 PM, Martin Sandve Alnæs > > >> >> <[email protected]> > > >> >> wrote: > > >> >> > The overhead occurs when the caller must construct or > > >> >> > resize a vector. > > >> >> > If > > >> >> > that must happen in a function called from a loop, the > > >> >> > penalty is significant. > > >> >> > > > >> >> > 9. mar. 2015 14.05 skrev "Anders Logg" > > >> >> > <[email protected]>: > > >> >> > > > >> >> >> Another inconsistency is use of std::vector<foo> vs foo*. > > >> >> >> > > >> >> >> Did we make a decision on which to use? > > >> >> >> > > >> >> >> Here the issue is not so much speed of access (my tests > > >> >> >> indicated they > > >> >> >> are > > >> >> >> equally fast - as they should be) when compiling with > > optimization, > > >> >> >> but > > >> >> >> how > > >> >> >> easily these datastructures can be filled in from the > > >> >> >> DOLFIN side. There's > > >> >> >> now way I know of to pass raw pointer data on as a > > >> >> >> std:vector, but the > > >> >> >> opposite is possible. > > >> >> >> > > >> >> >> -- > > >> >> >> Anders > > >> >> >> > > >> >> >> > > >> >> >> fre 6 mars 2015 kl 14:51 skrev Martin Sandve Alnæs > > >> >> >> <[email protected]>: > > >> >> >>> > > >> >> >>> 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 > > >> _______________________________________________ > > >> 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
