create MeshFunction from MeshValueCollection

Try

    mf = MeshFunction('sizet', mesh, mesh.domains().markers(1))

(note the 'sizet').

Garth

On Tue, Nov 20, 2012 at 3:15 AM, Jan Blechta
<email address hidden> wrote:
> New question #214692 on DOLFIN:
> https://answers.launchpad.net/dolfin/+question/214692
>
> I'm currently improving mesh converter from Triangle format in order to support edge boundary markers. It now outputs single XML file with mesh and MeshValueCollection on edges. But I can't find the way how to create MeshFunction from it to be written to VTK file. Documented way fails:
> mesh = Mesh('A.1.xml')
> mf = MeshFunction('uint', mesh, mesh.domains().markers(1))
>
> Traceback (most recent call last):
> File "testTriangle2xml_2.py", line 12, in <module>
> mf = MeshFunction('uint', mesh, mesh.domains().markers(1))
> File "/usr/local/pkg/fenics-dev/1.0.0/gnu/lib/python2.7/site-packages/dolfin/cpp.py", line 14504, in __new__
> return MeshFunctionUInt(*args)
> File "/usr/local/pkg/fenics-dev/1.0.0/gnu/lib/python2.7/site-packages/dolfin/cpp.py", line 13387, in __init__
> _cpp.MeshFunctionUInt_swiginit(self,_cpp.new_MeshFunctionUInt(*args))
> TypeError: in method 'new_MeshFunctionUInt', argument 2 of type 'std::string const'
>
> Would somebody try to reproduce it on development version for example with aneurysm mesh in data/meshes dir
> mesh = Mesh('aneurysm.xml.gz')
> mf = MeshFunction('uint', mesh, mesh.domains().markers(2)) #now let marker dim=2
>
>
> --
> You received this question notification because you are a member of
> DOLFIN Team, which is an answer contact for DOLFIN.

> mf = MeshFunction('sizet', mesh, mesh.domains().markers(1))
This does not work. What is 'sizet'?

First problem stays - how to 'cast' MeshValueCollection to
MeshFunction? Maybe it was fixed since 1.0.0. I will try compiling
trunk in a few days.

But in this case I realized that through
  mesh.domains().facet_domains(mesh)
you can directly access MeshFunction which is written in mesh XML like

<dolfin ...>
  <mesh ...>
    <vertices ...>...</vertices>
    <cells ...>...</cells>
    <domains ...>
      <mesh_value_collection ...>
        <value cell_index="0" local_entity="2" value="1"/>
        <value cell_index="0" local_entity="0" value="1"/>
        <value cell_index="0" local_entity="1" value="0"/>
        ...
      </mesh_value_collection>
    </domains>
</dolfin>

Problem is that when dolfin renumbers local vertices of cells, it does
not fixes this facet_domains() (and probably anything stored in
mesh.domains()). You can reproduce it by this code

mesh = Mesh()
File('mesh_with_domains.xml') >> mesh
File('mesh_with_domains_ordered.xml') << mesh

And what about mesh functions which user load from some separate file
which has ordering corresponding to some unordered mesh file? I
think that user should be generaly able to:

  1. load separate xml files (which are consistent with unordered mesh)
to initialize MeshFunctions or MeshValueColletions before mesh.order()
is called.

  2. have possibility to fix ordering of underlying local entities in
MeshFunctions, MeshValueColletions and MeshDomains when mesh is
ordered.

And one little question: why MeshDomains.facet_domains(mesh) has an
argument mesh? It operates on underlying mesh of MeshDomains, doesn't
it?

Best regards,
Jan

I think this is a bug in the mesh converter for Triangle. The vertices
in the generated mesh need to comply with the dolfin mesh numbering. It
is easier to solve this problem than to let mesh ordering algorithm fix
any stored MeshValueCollections. To solve that you just make sure that
the vertex indices for each element are ordered from lowet to highest
value.

Your mileage might vary, but I had the exact same problem in a related
software, and I found it easier to fix the mesh converter than fiddling
with mesh ordering algorithm.

Not sure what kind of tool you use to convert from Triangle. It doesn't
seems like the dolfin-convert support extraction of facet markers for
storage as MeshValueCollection in the mesh.

Johan

On 11/21/2012 02:55 AM, Jan Blechta wrote:
> Question #214692 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/214692
>
> Status: Answered => Open
>
> Jan Blechta is still having a problem:
>> mf = MeshFunction('sizet', mesh, mesh.domains().markers(1))
> This does not work. What is 'sizet'?
>
> First problem stays - how to 'cast' MeshValueCollection to
> MeshFunction? Maybe it was fixed since 1.0.0. I will try compiling
> trunk in a few days.
>
> But in this case I realized that through
> mesh.domains().facet_domains(mesh)
> you can directly access MeshFunction which is written in mesh XML like
>
> <dolfin ...>
> <mesh ...>
> <vertices ...>...</vertices>
> <cells ...>...</cells>
> <domains ...>
> <mesh_value_collection ...>
> <value cell_index="0" local_entity="2" value="1"/>
> <value cell_index="0" local_entity="0" value="1"/>
> <value cell_index="0" local_entity="1" value="0"/>
> ...
> </mesh_value_collection>
> </domains>
> </dolfin>
>
> Problem is that when dolfin renumbers local vertices of cells, it does
> not fixes this facet_domains() (and probably anything stored in
> mesh.domains()). You can reproduce it by this code
>
> mesh = Mesh()
> File('mesh_with_domains.xml') >> mesh
> File('mesh_with_domains_ordered.xml') << mesh
>
> And what about mesh functions which user load from some separate file
> which has ordering corresponding to some unordered mesh file? I
> think that user should be generaly able to:
>
> 1. load separate xml files (which are consistent with unordered mesh)
> to initialize MeshFunctions or MeshValueColletions before mesh.order()
> is called.
>
> 2. have possibility to fix ordering of underlying local entities in
> MeshFunctions, MeshValueColletions and MeshDomains when mesh is
> ordered.
>
> And one little question: why MeshDomains.facet_domains(mesh) has an
> argument mesh? It operates on underlying mesh of MeshDomains, doesn't
> it?
>
> Best regards,
> Jan
>

> I think this is a bug in the mesh converter for Triangle. The vertices
> in the generated mesh need to comply with the dolfin mesh numbering.
Unless it is part of xml mesh specification: "If you specify
some MeshValueCollection it must be in right ordering.", it is bug in
mesh.order().

> It is easier to solve this problem than to let mesh ordering
> algorithm fix any stored MeshValueCollections. To solve that you just
> make sure that the vertex indices for each element are ordered from
> lowet to highest value.
ok, I would do it this way.

> Not sure what kind of tool you use to convert from Triangle. It
> doesn't seems like the dolfin-convert support extraction of facet
> markers for storage as MeshValueCollection in the mesh.
I'm currently adding support for markers on edges to dolfin-convert.

Jan

On 11/21/2012 03:01 PM, Jan Blechta wrote:
> Question #214692 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/214692
>
> Status: Answered => Open
>
> Jan Blechta is still having a problem:
>> I think this is a bug in the mesh converter for Triangle. The vertices
>> in the generated mesh need to comply with the dolfin mesh numbering.
> Unless it is part of xml mesh specification: "If you specify
> some MeshValueCollection it must be in right ordering.", it is bug in
> mesh.order().

Sure, it is most probably not part of the xml specification. So it is a
bug in the mesh order method. Please feel free to report! :)

>> It is easier to solve this problem than to let mesh ordering
>> algorithm fix any stored MeshValueCollections. To solve that you just
>> make sure that the vertex indices for each element are ordered from
>> lowet to highest value.
> ok, I would do it this way.
>
>> Not sure what kind of tool you use to convert from Triangle. It
>> doesn't seems like the dolfin-convert support extraction of facet
>> markers for storage as MeshValueCollection in the mesh.
> I'm currently adding support for markers on edges to dolfin-convert.

Nice!

Johan

> Jan
>

On Wed, Nov 21, 2012 at 2:21 PM, Johan Hake
<email address hidden> wrote:
> Question #214692 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/214692
>
> Status: Open => Answered
>
> Johan Hake proposed the following answer:
> On 11/21/2012 03:01 PM, Jan Blechta wrote:
>> Question #214692 on DOLFIN changed:
>> https://answers.launchpad.net/dolfin/+question/214692
>>
>> Status: Answered => Open
>>
>> Jan Blechta is still having a problem:
>>> I think this is a bug in the mesh converter for Triangle. The vertices
>>> in the generated mesh need to comply with the dolfin mesh numbering.
>> Unless it is part of xml mesh specification: "If you specify
>> some MeshValueCollection it must be in right ordering.", it is bug in
>> mesh.order().
>
> Sure, it is most probably not part of the xml specification. So it is a
> bug in the mesh order method. Please feel free to report! :)
>

I suggested in the past that the UFC version to which the numbering
conforms should be in the XML metadata. I recall that Anders was not
keen on this(?)

Garth

>>> It is easier to solve this problem than to let mesh ordering
>>> algorithm fix any stored MeshValueCollections. To solve that you just
>>> make sure that the vertex indices for each element are ordered from
>>> lowet to highest value.
>> ok, I would do it this way.
>>
>>> Not sure what kind of tool you use to convert from Triangle. It
>>> doesn't seems like the dolfin-convert support extraction of facet
>>> markers for storage as MeshValueCollection in the mesh.
>> I'm currently adding support for markers on edges to dolfin-convert.
>
> Nice!
>
> Johan
>
>> Jan
>>
>
> --
> You received this question notification because you are a member of
> DOLFIN Team, which is an answer contact for DOLFIN.

One technical question:
  Is it for any reason necessary to specify edge common to two triangles twice in <mesh_value_cellection ...> section?

Consider two <values ...>
      <value cell_index="0" local_entity="1" value="0"/>
      <value cell_index="1" local_entity="1" value="0"/>
with same value corresponding to the same edge. Could one of them be ommited (and do you reccomend it?) while DOLFIN would still be able to calculate all values of corresponding MeshFunction of dim=1?

And what does it mean when this two values would be different? How is mesh function constructed?

On Wed, Nov 21, 2012 at 03:31:01PM -0000, Garth Wells wrote:
> Question #214692 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/214692
>
> Garth Wells proposed the following answer:
> On Wed, Nov 21, 2012 at 2:21 PM, Johan Hake
> <email address hidden> wrote:
> > Question #214692 on DOLFIN changed:
> > https://answers.launchpad.net/dolfin/+question/214692
> >
> > Status: Open => Answered
> >
> > Johan Hake proposed the following answer:
> > On 11/21/2012 03:01 PM, Jan Blechta wrote:
> >> Question #214692 on DOLFIN changed:
> >> https://answers.launchpad.net/dolfin/+question/214692
> >>
> >> Status: Answered => Open
> >>
> >> Jan Blechta is still having a problem:
> >>> I think this is a bug in the mesh converter for Triangle. The vertices
> >>> in the generated mesh need to comply with the dolfin mesh numbering.
> >> Unless it is part of xml mesh specification: "If you specify
> >> some MeshValueCollection it must be in right ordering.", it is bug in
> >> mesh.order().
> >
> > Sure, it is most probably not part of the xml specification. So it is a
> > bug in the mesh order method. Please feel free to report! :)
> >
>
> I suggested in the past that the UFC version to which the numbering
> conforms should be in the XML metadata. I recall that Anders was not
> keen on this(?)

I don't remember that discussion. Where would we put it, and would
we make any use of the data?

--
Anders

On 11/21/2012 04:51 PM, Jan Blechta wrote:
> Question #214692 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/214692
>
> Jan Blechta posted a new comment:
> And what does it mean when this two values would be different? How is
> mesh function constructed?

It is constructed by iterating over the cells. Which means that the
final edge will get the value of the edge from the last cell value.

Johan