On Tue, Sep 24, 2013 at 9:52 PM, Garth N. Wells <gn...@cam.ac.uk> wrote:
> 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! :-) What design? A class that hold the mapping between 1-N,N-1,1-1 dofmaps? If so I agree. But it is not clear to me what you think the syntax for the assignment statement should be. I do not think: dmtdmm = DofMapToDofMapMapping([V,V,V], VV) assign([u0,u1,u2],u, dmtdmm) is better than for example: dmtdmm = DofMapToDofMapMapping([V,V,V], VV) dmtdmm.assign([u0,u1,u2],u) The first is similar to what Martin suggested and the latter is basically what I first suggested with a different naming. We can still support a more general free function: assign([u0,u1,u2],u) where a DofMapToDofMapMapping is created inside the assign function and then discarded. > 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. > Agree. No dofmaps are transformed. 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). Sounds good. I suppose a general mapping class between dofmaps could be useful for different cases. However, I am not sure what these cases are, and I have therefor difficulties envision how such class should be looking. I have one particular task in mind, and for that I need a mapping between 1-N,N-1,1-1 dofmaps. > > 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). > > > And what is the difference? Couldn't an assign method be implemented as part of a DofMapToDofMapMapping class? > 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; > I think this example is just stupid. It has nothing to do with what I suggested. As I said we can hide the instantiation of the class within a free function for people who wants to solve a problem with a small script with nice syntax. I suggest adding a useful class that solves a problem many has requested in an elegant way. > Adding FunctionAssigner is just one class but it's a slippery > > slope... :-) > The slope is as slippery as adding DOLFIN_EPS_LARGE, which easily could lead to the addition of DOLFIN_EPS_NOT_SO_LARGE ;) Johan > > -- > > 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 >
_______________________________________________ fenics mailing list fenics@fenicsproject.org http://fenicsproject.org/mailman/listinfo/fenics
