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
