Closed RemDelaporteMathurin closed 5 years ago
In MED (also gmsh in fact) we can give the same name to different sets corresponding to different manifold dimensions (so Top can be used to group all 2d elements on the top, and some 1d elements on the top), internally MED will just assign another unique set id.
So this motivates me to use the unique element set id's as keys in the mesh.tags
(aka your field_data
).
Reading the gmsh-converted .msh
file containing two different sets with a same name leads to one being eaten by the other. So maybe we also need to redesign your field_data
?
Reading the gmsh-converted .msh file containing two different sets with a same name leads to one being eaten by the other. So maybe we also need to redesign your field_data?
Yes that does sound like a shortcoming in the Gmsh reader, especially if that failing file is actually output by Gmsh itself. Is that MSH2.2? Could you launch an issue and attach a minimal failing example?
On the other hand, just because a format permits something doesn't mean it's likely to arise in practice. Is there much chance of a sensible MED or Gmsh user presenting such a file?
I reckon it will always be possible to do whatever you want by assigning 1 cell to 1 group (no overlapping). If you want to apply a BC to 2 surfaces (top and bottom let's say) in FEniCS for example, you can apply to BCs to 1 surface each easily ... Don't you agree @tianyikillua ?
Yes of course, technically we don't need overlapping groups, but sometimes for modeling purposes we could need them, see https://github.com/nschloe/meshio/issues/347#issuecomment-474252859. If we had used the non-intersecting Top
and Down
, then on Top
, the engineer would have to manually superpose himself the two pressure loads.
Well, let's take the commercial software COMSOL for example: when you need to apply a BC to several surfaces, you have to select each surface one by one. It's not that time consuming in the end, except if you have plenty of surfaces, but even in this case, the user would have to select them in SALOME (or any meshing software) one by one in order to group them into 'Top and Down'.
Yes I see your point. So an experienced engineer has to choose
We should allow these two possibilities...
That's true. But one bird in the hand is worth two in the bush. Currently the user can't do either of the two possibilities 😉
Yes better an egg today than a hen tomorrow, and take the cash and let the credit go.
In https://github.com/nschloe/meshio/pull/352#issuecomment-475204271, it may be now possible to take your egg and cash.
Hi all, finally got time to test all the work you've done @tianyikillua. I ran into some issues:
xdmf
:when I try to import the mesh in FEniCS, I get an error caused by the "mixed" value - but that was expected.
doflin-convert
to xml or xdmf:I get the following error:
Converting from Gmsh format (.msh, .gmsh) to DOLFIN XML format
Traceback (most recent call last):
File "/usr/local/bin/dolfin-convert", line 132, in <module>
main(sys.argv[1:])
File "/usr/local/bin/dolfin-convert", line 79, in main
meshconvert.convert2xml(ifilename, ofilename, iformat=iformat)
File "/usr/local/lib/python3.6/dist-packages/dolfin_utils/meshconvert/meshconvert.py", line 1301, in convert2xml
convert(ifilename, XmlHandler(ofilename), iformat=iformat)
File "/usr/local/lib/python3.6/dist-packages/dolfin_utils/meshconvert/meshconvert.py", line 1322, in convert
gmsh2xml(ifilename, handler)
File "/usr/local/lib/python3.6/dist-packages/dolfin_utils/meshconvert/meshconvert.py", line 261, in gmsh2xml
line = ifile.readline()
File "/usr/lib/python3.6/codecs.py", line 321, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb8 in position 57: invalid start byte
Don't know if it's a fenics-related issue or again caused by the "mixed" value. med_to_msh.zip
xml
:
Creates 2 files: mesh.xml and mesh_cell_tags.xml
When I try to import mesh.xml : no problem at all.
When I try to import mesh_cell_tags.xml I get the following error:
Traceback (most recent call last):
File "meshfunction.py", line 30, in <module>
subdomains = MeshFunction("size_t", mesh, "test_cell_tags.xml")
File "/usr/local/lib/python3.6/dist-packages/dolfin/mesh/meshfunction.py", line 18, in __new__
return fn(mesh, dim)
RuntimeError:
------------------------------------------------------------------------- DOLFIN encountered an error. If you are not able to resolve this issue *** using the information listed below, you can ask for help at
*** fenics-support@googlegroups.com
Remember to include the error message listed below and, if possible, include a minimal running example to reproduce the error.
------------------------------------------------------------------------- Error: Unable to read mesh function from XML file. Reason: Type mismatch reading XML MeshFunction. MeshFunction type is "uint", but file type is "int". Where: This error was encountered inside XMLMeshFunction.h. *** Process: 0
DOLFIN version: 2018.1.0 Git changeset: 948dc42cc4e06ed9227d0201ad50f94ac94cbf9f *** -------------------------------------------------------------------------
[med_to_xml.zip](https://github.com/nschloe/meshio/files/3029583/med_to_xml.zip)
Could you please try https://github.com/nschloe/meshio/pull/352#issuecomment-475204271? You need to manually separate and export line and face elements, with appropriate tags.
Also, don't forget to take the absolute values of cell_tags
as FEniCS prefers natural numbers size_t
.
Ah really sorry about that, missed that one. Do you know if it'd work in 2D as well ? I should just replace tetra
by triangle
and triangle
by line
, am I right ?
Yes, and for triangular meshes include also cell_tags
if you want to define different material behaviors for instance.
@tianyikillua, it couldn't work better. Thanks for all the work guys!
Hi, i'm using gmesh and meshio for FEM and I'd like to get the node coordinates etc of my physical groups to apply BC's . I thought mesh.field_data could be used but from reading this thread it seems I am wrong. Are you saying that there is no way I can do this and that the named regions are essentially useless?
@smickleborough Look at point_data, cell_data.
Thanks, i think I've got it now.
Hi all,
Just to say that I found a workaround using for converting .med to .xml using MED 3.2:
- Convert from .med to .msh by opening it in GMSH
- Convert from .msh to .xml with
dolfin-convert
Note that 2) creates as expected 3 .xml files (mesh.xml alongside mesh_facet_region.xml and mesh_physical_region.xml) whereas
meshio-convert
doesn't and returns this warning: WARNING:root:DOLFIN XML can only handle one cell type at a time. Using tetra, discarding triangle.Here are the files. MED 3.2 generated with SALOME 8.3.0
i would like to know how can i get the facet_region information?
Hi all,
I wish to convert a mesh from SALOME (MED 4.0) to .msh or .xml alongside with cell attributes.
Here's an exemple of a mesh from SALOME with 1 volume marked. MED.zip
Meshio seems to read it without issues. But, when converting to .msh and after opening it in GMSH, here's the mesh file I get. gmsh.zip
No sign of the entity "tungsten".
Thanks guys for your help!
Rem
PS: Screenshot of the med file re-imported in SALOME, the group is there as expected.