On 28 May 2013 08:35, Martin Sandve Alnæs <[email protected]> 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? >
That is the purpose and there were some unit tests for this, all of which still work. If you rely on functionality, add tests. > I think the constructor is cleaner but the std::map/dict construction is > unnecessary overhead and too costly for dense mesh value collections. > The data was previously being stored in a std::map behind the scenes. In that respect there is no change other than the improvement of now having a map (std::size_t, std::size_t) rather than a map (std::size_t, pair(std::size_t, std::size_t)). A Python dict is really only good for debugging. I agree that it should be used in production code. > 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. > This will be easy, if a free function is the preferred approach. Garth > Martin > > > > On 28 May 2013 08:38, Garth N. Wells <[email protected]> wrote: >> >> On 28 May 2013 06:15, Martin Sandve Alnæs <[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]> wrote: >> >> > On Monday, 27 May 2013, Jan Blechta wrote: >> >> > >> >> > > On Mon, 27 May 2013 23:10:47 +0100 >> >> > > "Garth N. Wells" <[email protected] <javascript:;>> wrote: >> >> > > > On 27 May 2013 22:06, Jan Blechta >> >> > > > <[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] <javascript:;> >> >> > > > > http://fenicsproject.org/mailman/listinfo/fenics >> >> > > > _______________________________________________ >> >> > > > fenics mailing list >> >> > > > [email protected] <javascript:;> >> >> > > > http://fenicsproject.org/mailman/listinfo/fenics >> >> > > >> >> > > _______________________________________________ >> >> > > fenics mailing list >> >> > > [email protected] <javascript:;> >> >> > > 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
