On 28 May 2013 09:20, Johan Hake <[email protected]> wrote:
> 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.
>
Not quite true. There is a test in
test/unit/fem/python/DirichletBC.py
that tests BCs from mesh domains in the aneurysm test.
Garth
>> 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
