On 24 September 2013 20:18, Anders Logg <l...@chalmers.se> wrote: > Yes, I like DofMapToDofMapMapping much better. >
I like the design, much the name looks horrible! :-) > My suggestion for a short name would be > > DofMapTransformation > I don't like this name - it doesn't make clear that if defined a relationship between two domps. I don't have a good name suggestion just yet, but maybe we should raise the abstraction. A dofmap is a type of graph, and what we want is the relationship between a graph and some subgraph (related to this, I'd like to use a more graph-centric approach in DofMapBuilder to simplify it and to extend the functionality). Garth > 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 <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. >> >> >> >> >> 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 _______________________________________________ fenics mailing list fenics@fenicsproject.org http://fenicsproject.org/mailman/listinfo/fenics
