internal faces in mesh (med-file)
internal faces in mesh (med-file)Posted by Roman Voronov at March 26. 2013
I want to create a program that can convert mesh from med-file to OpenFOAM. And I have problem with reading data of internal faces.
This function returns a number of only boundary faces:
ntria3 = MEDmeshnEntity(fid, meshname, MED_NO_DT, MED_NO_IT, MED_CELL, MED_TRIA3, MED_CONNECTIVITY,
MED_NODAL, &coordinatechangement, &geotransformation)) < 0);
And this function returns connectivities of only boundary faces too:
MEDmeshElementConnectivityRd(fid, meshname, MED_NO_DT, MED_NO_IT, MED_CELL, MED_TRIA3, MED_NODAL,
But the number of nodes (points) and their's coordinates is ok.
Please tell me how to read a number of internal faces?
It seems that you are trying to do what is already done. Look at this site http://pythonflu.wikidot.com/.
I know this project, but I want to create C/C++ application without python and without need to any programming.
Oh, I forgot to ask! Can pythonFlu help to save complicated mesh from Salome to disk in OpenFOAM format?
Unfortunately, I don't know any details about pythonFlu. I only suggest that med2foam conversion is to be implemented in hybridFlu.
As about med-file API, it returns only what is stored. I mean, if it returns only boundary faces, then there are no any other faces in a stored mesh.
Why do you think there are internal faces?
I made a mesh and exported it to I-DEAS and MED. Then I converted I-DEAS to OpenFOAM. The chekMesh utility shows a bigger number of faces than Salome's Mesh info or MED API. Sum of only boundary faces from checkMesh is equal to number of faces from MED API.
Probably I-DEAS to OpenFOAM conversion computes (generates) faces bounding every volume.
I don't have the solution to what you are trying to do, but according to my experience, the use of internal boundary conditions (or internal faces, patches, or whatever) is not possible with OpenFOAM. Only external ones are allowed.
So, maybe trying to export internal faces to OpenFOAM format is not necessary...
OK, I was wrong in my last comment.
Indeed internal faces have to be present in the OpenFOAM mesh.
Actually, "internal faces" in OpenFOAM are face elements between each cell. And without internal faces, it would be impossible to define any cell... Because cells are defined according to their faces (and not according to their nodes) in OpenFOAM.
And Saint-Michael is probably right (as usual...)
Hi William Tougeron
It's necessary to read internal faces not for solution. I want to read only connectivities of internal nodes to build same connectivities in OpenFOAM's mesh. But unfortunately I can't read connectivities of internal nodes.
My geometry is very complicated and has pyramids with quad bases. They appeared when tet-mesh "glues" with hex-mesh (see sample picture below). Unfortunately I-DEAS UNV doesn't support this pyramids. As far as I understand, pythonFlu doesn't support them too.
I see a simple solution, maybe it's OK for you. If you converts your complex mesh to a tetrahedral one (using "Split into Tetrahedra" operation), you'll be able to pass all your mesh via UNV format.
As I know, tet elements is not good for cfd. But, if I'll not find solution of this problem, I'll try your method. Thank you!
- Load you mesh from your med file using MEDLoader. Here you get MEDCoulplingUMesh including volumes only.
- Create a MEDCoulplingUMesh including internal faces only using MEDCoulplingUMesh::buildDescendingConnectivity()
- Append the mesh including internal faces to your med file. Names of the volumic mesh and of the mesh being appended must be same.
Activate by Roman Voronov on Mar 26, 2013 10:32 AM