Would you agree that that the BoundingBoxTree represents data associations, not an operation, similar to my just-now suggestion DofMapToDofMapMapping instead of FunctionAssigner? An object that represents the mapping could conceivably be useful for operations other than assign as well.
Martin On 24 September 2013 10:39, Johan Hake <[email protected]> wrote: > Well, we have the BoundingBoxTree, which similarly caches data that speed > up certain operations. We also have a Solver class and a free function > solve, an Assembler class and a free function assemble. Similarly we could > have a free function assign, which construct a FunctionAssign object. > However there is a lot of data which could be reused in the FunctionAssign > object. If a user want to utelize that he should instantiate the object and > use that in his code. > > Johan > > > > On Tue, Sep 24, 2013 at 10:27 AM, Anders Logg <[email protected]> wrote: > >> Is it possible to solve this without introducing the design pattern >> with a class FunctionAssigner? We have been careful to avoid this in >> other places. >> >> -- >> Anders >> >> >> >> On Mon, Sep 23, 2013 at 07:20:03PM +0200, Johan Hake wrote: >> > I am working on sub-function assignment. To facilitate caching of dof >> indices >> > for a particular assignment combination I suggest introducing a >> > FunctionAssigner class which caches the necessary indices (dofs) for >> the whole >> > domain. >> > >> > Something like: >> > >> > mesh = UnitSquareMesh(10,10) >> > V = FunctionSpace(mesh, "CG", 1) >> > VV = V*V >> > >> > # Assign two scalar functions to the components of a mixed function >> > assigner0 = FunctionAssigner([V, V], VV) >> > >> > # Assign components of a mixed function to scalar Functions >> > assigner1 = FunctionAssigner(VV, [V, V]) >> > >> > # Assign a scalar function to a component of a mixed function >> > assigner2 = FunctionAssigner(V, VV.sub(1)) >> > >> > u0, u1 = Function(V), Function(V) >> > U = Function(VV) >> > >> > Then in some time loop: >> > >> > while t < tstop: >> > ... >> > assigner0.assign([u0, u1], U) >> > ... >> > assigner1.assign(U, [u0, u1]) >> > ... >> > assigner2.assign(u0, U.sub(1)) >> > >> > In C++ the equivalent to a list of Foo will be a std::vector of shared >> Foos. >> > >> > Comments? >> > >> > By using sub spaces and sub functions we avoid using indices in the >> interface, >> > which I think is neat. However, there are some limitations with the >> present >> > interface: >> > >> > 1) The FunctionAssigner needs to have access to the local ownership >> range of a >> > sub dofmap, but that is not possible as it is set to 0,0 during >> construction. >> > Could we add a proper local ownership range to a sub dofmap? >> > 2) The FunctionAssigner need to be able to access the private _vector >> of a >> > parent Function during the assignment, as calling subfunc.vector() >> raises an >> > error. This can be fixed by a friend statement. Is that acceptable? >> > >> > Johan >> >> > _______________________________________________ >> > 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
