BoundingBoxTree is more than data associations. It provides a lot of methods. I see that the dofmap mapping could potentially be used by different operations, but I then suggest we then extend with some member method. Obviously the name is then a problem, and we could pick some more generic name I guess. But you suggestion is maybe a bit verbose ;)
Johan On Tue, Sep 24, 2013 at 10:44 AM, Martin Sandve Alnæs <marti...@simula.no>wrote: > 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 <hake....@gmail.com> 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 <l...@chalmers.se> 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 >>> > fenics@fenicsproject.org >>> > http://fenicsproject.org/mailman/listinfo/fenics >>> >>> >> >> _______________________________________________ >> fenics mailing list >> fenics@fenicsproject.org >> http://fenicsproject.org/mailman/listinfo/fenics >> >> >
_______________________________________________ fenics mailing list fenics@fenicsproject.org http://fenicsproject.org/mailman/listinfo/fenics
