Ok, make sense. Johan
On 05/28/2013 09:55 AM, Garth N. Wells wrote: > On 28 May 2013 08:42, Johan Hake <[email protected]> wrote: >> 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? >> > > MeshValueCollection is a class just like MeshFunction and can still be > used. MeshValueCollection uses much less memory in common cases, e.g.. > when marking boundary facets only. > > The whole point was to remove the circular dependency - (Mesh - > MeshDomains/MeshValueCollection - Mesh - . . . . ) - which is why > MeshDomains uses plain data types and not types that require a Mesh. > MeshFunction and MeshValueCollection are both templated, which was > marking finding an include order for header files that the compiler > would swallow difficult. > > Garth > >> Johan >> >>> Martin >>> >>> >>> >>> On 28 May 2013 08:38, Garth N. Wells <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> On 28 May 2013 06:15, Martin Sandve Alnæs <[email protected] >>> <mailto:[email protected]>> 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" <[email protected] <mailto:[email protected]>> wrote: >>> >> > On Monday, 27 May 2013, Jan Blechta wrote: >>> >> > >>> >> > > On Mon, 27 May 2013 23:10:47 +0100 >>> >> > > "Garth N. Wells" <[email protected] <mailto:[email protected]> >>> <javascript:;>> wrote: >>> >> > > > On 27 May 2013 22:06, Jan Blechta >>> >> > > > <[email protected] >>> <mailto:[email protected]><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 >>> >> > > > > [email protected] >>> <mailto:[email protected]> <javascript:;> >>> >> > > > > http://fenicsproject.org/mailman/listinfo/fenics >>> >> > > > _______________________________________________ >>> >> > > > fenics mailing list >>> >> > > > [email protected] <mailto:[email protected]> >>> <javascript:;> >>> >> > > > http://fenicsproject.org/mailman/listinfo/fenics >>> >> > > >>> >> > > _______________________________________________ >>> >> > > fenics mailing list >>> >> > > [email protected] <mailto:[email protected]> >>> <javascript:;> >>> >> > > http://fenicsproject.org/mailman/listinfo/fenics >>> >> > > >>> >> > >>> >> > >>> >> >>> >> _______________________________________________ >>> >> fenics mailing list >>> >> [email protected] <mailto:[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
