On 05/28/2013 09:35 AM, Martin Sandve Alnæs wrote: > What I fundamentally want is to read the Mesh and MeshValueCollection(s) > that reside in the File. What is the purpose for storing the domains in > the Mesh object?
I think they naturally belong to the mesh. > I think the constructor is cleaner but the std::map/dict construction is > unnecessary overhead and too costly for dense mesh value collections. > > A free function can hopefully avoid this overhead by using the existing > MeshFunction constructor taking a MeshValueCollection, which is what the > mesh file reader constructs in the first place. Looking at the code it looks like MeshValueColletion is not used to store the markers. Just a std::map. Is MeshValueColletion used anymore? Johan > Martin > > > > On 28 May 2013 08:38, Garth N. Wells <gn...@cam.ac.uk > <mailto:gn...@cam.ac.uk>> wrote: > > On 28 May 2013 06:15, Martin Sandve Alnæs <marti...@simula.no > <mailto:marti...@simula.no>> wrote: > > A dict on the python side? Ouch! That is quite costly in terms of > memory. > > Each key and value object has a python overhead of about 50 bytes > each. > > > > I'm aware of this. There were essentially no unit tests or demos on > this, so it wasn't clear if MeshData was accessed outside the library > internals or not. If its used for purposes other than debugging, which > it appears to be, this can be changed. > > > In addition to breaking lots of stuff as Jan points out, this > change is not > > thought through. > > > > It has been extensively thought through - re-implementing fragile code > for the sake of fragile code is not thinking through. 'lot's' is an > exaggeration. > > > Wasn't facet_domains() there only for explicitly getting a > MeshFunction? An > > external helper function instead would be fine, I always found the > data flow > > there a bit strange. > > > > Two possibilities, both anticipated, are: > > - A free function to build a MeshFunction from a Mesh and MeshData > - A MeshFunction constructor that takes a Mesh and a std::map > > The former is better for hiding data, the latter is perhaps a bit > cleaner. Both are memory robust and explicit (the old code was > neither). Preferences? > > Garth > > > Martin > > > > tirsdag 28. mai 2013 skrev Jan Blechta følgende: > >> > >> On Mon, 27 May 2013 23:32:12 +0100 > >> "Garth N. Wells" <gn...@cam.ac.uk <mailto:gn...@cam.ac.uk>> wrote: > >> > On Monday, 27 May 2013, Jan Blechta wrote: > >> > > >> > > On Mon, 27 May 2013 23:10:47 +0100 > >> > > "Garth N. Wells" <gn...@cam.ac.uk <mailto:gn...@cam.ac.uk> > <javascript:;>> wrote: > >> > > > On 27 May 2013 22:06, Jan Blechta > >> > > > <blec...@karlin.mff.cuni.cz > <mailto:blec...@karlin.mff.cuni.cz><javascript:;>> > >> > > wrote: > >> > > > > How do I obtain FacetFunction > >> > > > > fd = mesh.domains().facet_domains() > >> > > > > with redesigned MeshDomains? > >> > > > > > >> > > > > >> > > > D = mesh.topology().dim() > >> > > > fd = mesh.domains().markers(D - 1) > >> > > > > >> > > > 'fd' is now not a MeshFunction (std::map from C++ and a dict on > >> > > > the Python side). It was necessary to change the type to > remove a > >> > > > circular dependency that was making new developments > >> > > > exponentially more complicated and to make memory management > >> > > > robust. A lot of boilerplate code was removed. > >> > > > > >> > > > If it turns out that a MeshFunction is required, we could add a > >> > > > MeshFunction constructor to make it simple to make a > MeshFunction. > >> > > > >> > > Indeed, MeshFunction is needed to feed DirichletBC or Measure. > >> > > >> > > >> > You can create Dirichlet bcs that use the domain markers without > >> > accessing the domain markers directly. See test_meshdomain_bcs in: > >> > > >> > > >> > > > https://bitbucket.org/fenics-project/dolfin/src/1247bb468d88885d57abbe74cbb82984818eacfd/test/unit/fem/python/DirichletBC.py?at=master > >> > >> You're right here. But other use cases: > >> - Measure > >> - output to file > >> - computations of other mesh functions > >> > >> The last point is easily solved but others, I think, not. Such a > >> constructor will enable users to adapt working code with 2 line > patch. > >> So I filed an issue. > >> > >> Jan > >> > >> > > >> > Garth > >> > > >> > > >> > > >> > > Jan > >> > > > >> > > > > >> > > > Garth > >> > > > > >> > > > > Jan > >> > > > > _______________________________________________ > >> > > > > fenics mailing list > >> > > > > fenics@fenicsproject.org > <mailto:fenics@fenicsproject.org> <javascript:;> > >> > > > > http://fenicsproject.org/mailman/listinfo/fenics > >> > > > _______________________________________________ > >> > > > fenics mailing list > >> > > > fenics@fenicsproject.org <mailto:fenics@fenicsproject.org> > <javascript:;> > >> > > > http://fenicsproject.org/mailman/listinfo/fenics > >> > > > >> > > _______________________________________________ > >> > > fenics mailing list > >> > > fenics@fenicsproject.org <mailto:fenics@fenicsproject.org> > <javascript:;> > >> > > http://fenicsproject.org/mailman/listinfo/fenics > >> > > > >> > > >> > > >> > >> _______________________________________________ > >> fenics mailing list > >> fenics@fenicsproject.org <mailto: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
