On 05/28/2013 09:48 AM, Garth N. Wells wrote: > 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.
Sure, but none of that relates to MeshValueCollections stored in a mesh file, read in via MeshDomains, only MeshValueCollection stored in its own file. > If you rely on functionality, add tests. True. I thought we had tests for extracting MeshFunctions from MeshDomains, but it seems like we do not had too many of those. But we had it in one place, testing functionality relating SubMesh. test/unit/mesh/python/SubMesh.py So to your comment I would add: "If you break functionality do not just out-comment tests." Johan >> 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 > _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
