Yes, I like DofMapToDofMapMapping much better. My suggestion for a short name would be
DofMapTransformation Yes, BoundingBoxTree has a lot of methods but it is an implementation detail that the methods are actually implemented as part of the BoundingBoxTree class hierarchy (and not outsourced to algorithm classes as we do in other places). I just want to stay away from the horror in dolfin/common/unittest.h: CppUnit::TestResult result; CppUnit::TestResultCollector collected_results; result.addListener(&collected_results); CppUnit::TestRunner runner; runner.addTest(CppUnit::TestFactoryRegistry::getRegistry().makeTest()); runner.run(result); CppUnit::CompilerOutputter outputter(&collected_results, std::cerr); outputter.write (); return collected_results.wasSuccessful () ? 0 : 1; Adding FunctionAssigner is just one class but it's a slippery slope... :-) -- Anders On Tue, Sep 24, 2013 at 10:44:05AM +0200, Martin Sandve Alnæs 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 <[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. > > > > > 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
