On 24 September 2013 21:24, Johan Hake <hake....@gmail.com> wrote: > 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.
Yes. The simple C++ approach is to just use a map class, but this is hard wrap in Python. > 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 former is better because if 'DofMapToDofMapMapping' is just about the relationship between dofmaps, in clean design it shouldn't know about Functions. Garth > 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 -- Garth N. Wells Department of Engineering, University of Cambridge http://www.eng.cam.ac.uk/~gnw20 _______________________________________________ fenics mailing list fenics@fenicsproject.org http://fenicsproject.org/mailman/listinfo/fenics
