import meshes from OpenFOAM
Forum rules
Please read the forum usage recommendations before posting.
Please read the forum usage recommendations before posting.
Re: import meshes from OpenFOAM
Hello Yvan,
As far as I see, snappyHexMesh makes polyhedral cells close to the boundry which generates some polygonal boundry faces at some locations. The decompose polyhedra doesn't do a good job at certain such locations.
I was just taking the easy way out and haven't tried the foamMeshToMed tool. I'll try that next. Thank you,
Kumar
As far as I see, snappyHexMesh makes polyhedral cells close to the boundry which generates some polygonal boundry faces at some locations. The decompose polyhedra doesn't do a good job at certain such locations.
I was just taking the easy way out and haven't tried the foamMeshToMed tool. I'll try that next. Thank you,
Kumar
Re: import meshes from OpenFOAM
Hello Kumar,
When you get the cgns format mesh, I think you can import it into Code_Saturne directly, instead of transfer cgns to med and then import it into Saturne. I use cgns format mesh, which works well.
Best regards,
Ruonan
When you get the cgns format mesh, I think you can import it into Code_Saturne directly, instead of transfer cgns to med and then import it into Saturne. I use cgns format mesh, which works well.
Best regards,
Ruonan
Re: import meshes from OpenFOAM
Hello Ruonan,
Thanks for your input! I tried that first but cs was not able to recognize the cgns mesh saved by Paraview. It always results in read errors and applying adf2hdf or hdf2adf converters doesn't resolve the problems. I think the problem comes from the Paraview cgns writer. However I suppose this may not be a problem for cgns meshes generated by other commercial software.
Kumar
Thanks for your input! I tried that first but cs was not able to recognize the cgns mesh saved by Paraview. It always results in read errors and applying adf2hdf or hdf2adf converters doesn't resolve the problems. I think the problem comes from the Paraview cgns writer. However I suppose this may not be a problem for cgns meshes generated by other commercial software.
Kumar
Re: import meshes from OpenFOAM
Hi Kumar,
Thanks for your explanation! Sorry I didn't realize this problem. Yes, I use ICEM to generate mesh and have no problem. Hope you can fix it soon!
Best regards,
Ruonan
Thanks for your explanation! Sorry I didn't realize this problem. Yes, I use ICEM to generate mesh and have no problem. Hope you can fix it soon!
Best regards,
Ruonan
Re: import meshes from OpenFOAM
Hi Ruonan,
I tried to compile foamMeshToMED utility using OpenFOAM versions 7 and 8 - it is really amazing that it compiles with both versions 7 and 8 with some minor changes in the code. However there is a glitch while linking with the library and I'm not able to resolve the issue.
I have code_saturne 7.0.0 with med-4.1.0 installed and I am trying to link the foamMedToMED application with the libmedC library from code_saturne, as required. My OF Make/options are as follows:
EXE_INC = \
/*-DFULLDEBUG -g -O0 -DNDEBUG \*/\
-std=c++11 \
-I/home/kumar/Code_Saturne/7.0.0/hdf5-1.10.6/arch/Linux_x86_64/include \
-I/home/kumar/Code_Saturne/7.0.0/med-4.1.0/arch/Linux_x86_64/include \
-I$(LIB_SRC)/finiteVolume/lnInclude \
-I$(LIB_SRC)/meshTools/lnInclude \
-I$(LIB_SRC)/dynamicMesh/lnInclude
EXE_LIBS = \
-L/home/kumar/Code_Saturne/7.0.0/med-4.1.0/arch/Linux_x86_64/lib/libmedC.so \
-lfiniteVolume \
-lmeshTools \
-ldynamicMesh
During the linking stage, I get the error:
g++ -std=c++11 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3 -DNoRepository -ftemplate-depth-100 -std=c++11 -I/home/kumar/Code_Saturne/7.0.0/hdf5-1.10.6/arch/Linux_x86_64/include -I/home/kumar/Code_Saturne/7.0.0/med-4.1.0/arch/Linux_x86_64/include -I/opt/openfoam8/src/finiteVolume/lnInclude -I/opt/openfoam8/src/meshTools/lnInclude -I/opt/openfoam8/src/dynamicMesh/lnInclude -IlnInclude -I. -I/opt/openfoam8/src/OpenFOAM/lnInclude -I/opt/openfoam8/src/OSspecific/POSIX/lnInclude -fPIC -fuse-ld=bfd -Xlinker --add-needed -Xlinker --no-as-needed Make/linux64GccDPInt32Opt/foamToMED.o -L/opt/openfoam8/platforms/linux64GccDPInt32Opt/lib \
-L/home/kumar/Code_Saturne/7.0.0/med-4.1.0/arch/Linux_x86_64/lib/libmedC.so -lfiniteVolume -lmeshTools -ldynamicMesh -lOpenFOAM -ldl \
-lm -o /home/kumar/OpenFOAM/kumar-8/platforms/linux64GccDPInt32Opt/bin/foamMeshToMED
/usr/bin/ld.bfd: Make/linux64GccDPInt32Opt/foamToMED.o: in function `main':
foamToMED.C:(.text.startup+0x568): undefined reference to `MEDfileOpen'
collect2: error: ld returned 1 exit status
make: *** [/opt/openfoam8/wmake/makefiles/general:142: /home/kumar/OpenFOAM/kumar-8/platforms/linux64GccDPInt32Opt/bin/foamMeshToMED] Error 1
The error says there is an undefined reference to MEDfileOpen. But this C function is available in <medfile.h> as:
#ifdef __cplusplus
extern "C" {
#endif
/* File */
MEDC_EXPORT med_idt
MEDfileOpen(const char* const filename,
const med_access_mode accessmode);
I suppose that the linker is not able to find the function in the library libmedC. I am not able to understand why this happens. Can anyone who compiled it successfully please help me out?
Thanks
Kumar
I tried to compile foamMeshToMED utility using OpenFOAM versions 7 and 8 - it is really amazing that it compiles with both versions 7 and 8 with some minor changes in the code. However there is a glitch while linking with the library and I'm not able to resolve the issue.
I have code_saturne 7.0.0 with med-4.1.0 installed and I am trying to link the foamMedToMED application with the libmedC library from code_saturne, as required. My OF Make/options are as follows:
EXE_INC = \
/*-DFULLDEBUG -g -O0 -DNDEBUG \*/\
-std=c++11 \
-I/home/kumar/Code_Saturne/7.0.0/hdf5-1.10.6/arch/Linux_x86_64/include \
-I/home/kumar/Code_Saturne/7.0.0/med-4.1.0/arch/Linux_x86_64/include \
-I$(LIB_SRC)/finiteVolume/lnInclude \
-I$(LIB_SRC)/meshTools/lnInclude \
-I$(LIB_SRC)/dynamicMesh/lnInclude
EXE_LIBS = \
-L/home/kumar/Code_Saturne/7.0.0/med-4.1.0/arch/Linux_x86_64/lib/libmedC.so \
-lfiniteVolume \
-lmeshTools \
-ldynamicMesh
During the linking stage, I get the error:
g++ -std=c++11 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3 -DNoRepository -ftemplate-depth-100 -std=c++11 -I/home/kumar/Code_Saturne/7.0.0/hdf5-1.10.6/arch/Linux_x86_64/include -I/home/kumar/Code_Saturne/7.0.0/med-4.1.0/arch/Linux_x86_64/include -I/opt/openfoam8/src/finiteVolume/lnInclude -I/opt/openfoam8/src/meshTools/lnInclude -I/opt/openfoam8/src/dynamicMesh/lnInclude -IlnInclude -I. -I/opt/openfoam8/src/OpenFOAM/lnInclude -I/opt/openfoam8/src/OSspecific/POSIX/lnInclude -fPIC -fuse-ld=bfd -Xlinker --add-needed -Xlinker --no-as-needed Make/linux64GccDPInt32Opt/foamToMED.o -L/opt/openfoam8/platforms/linux64GccDPInt32Opt/lib \
-L/home/kumar/Code_Saturne/7.0.0/med-4.1.0/arch/Linux_x86_64/lib/libmedC.so -lfiniteVolume -lmeshTools -ldynamicMesh -lOpenFOAM -ldl \
-lm -o /home/kumar/OpenFOAM/kumar-8/platforms/linux64GccDPInt32Opt/bin/foamMeshToMED
/usr/bin/ld.bfd: Make/linux64GccDPInt32Opt/foamToMED.o: in function `main':
foamToMED.C:(.text.startup+0x568): undefined reference to `MEDfileOpen'
collect2: error: ld returned 1 exit status
make: *** [/opt/openfoam8/wmake/makefiles/general:142: /home/kumar/OpenFOAM/kumar-8/platforms/linux64GccDPInt32Opt/bin/foamMeshToMED] Error 1
The error says there is an undefined reference to MEDfileOpen. But this C function is available in <medfile.h> as:
#ifdef __cplusplus
extern "C" {
#endif
/* File */
MEDC_EXPORT med_idt
MEDfileOpen(const char* const filename,
const med_access_mode accessmode);
I suppose that the linker is not able to find the function in the library libmedC. I am not able to understand why this happens. Can anyone who compiled it successfully please help me out?
Thanks
Kumar
-
- Posts: 4207
- Joined: Mon Feb 20, 2012 3:25 pm
Re: import meshes from OpenFOAM
Hello,
Just in case, you can run "nm" on /home/kumar/Code_Saturne/7.0.0/med-4.1.0/arch/Linux_x86_64/lib/libmedC.so to make sure the MEDfileOpen function is present in MED.
Not sure whether your link is static or dynamic, but in some cases, when building a stic executable/library, order of library appearance may be important.
But what really seems strange in your link line is this:
Where I would expect:
Or possibly
(without -L or -l if you are passing the full path explicitely)
Best regards,
Yvan
Just in case, you can run "nm" on /home/kumar/Code_Saturne/7.0.0/med-4.1.0/arch/Linux_x86_64/lib/libmedC.so to make sure the MEDfileOpen function is present in MED.
Not sure whether your link is static or dynamic, but in some cases, when building a stic executable/library, order of library appearance may be important.
But what really seems strange in your link line is this:
Code: Select all
-L/home/kumar/Code_Saturne/7.0.0/med-4.1.0/arch/Linux_x86_64/lib/libmedC.so
Code: Select all
-L/home/kumar/Code_Saturne/7.0.0/med-4.1.0/arch/Linux_x86_64/lib -lmedC
Code: Select all
/home/kumar/Code_Saturne/7.0.0/med-4.1.0/arch/Linux_x86_64/lib/libmedC.so
Best regards,
Yvan
Re: import meshes from OpenFOAM
Hello Yvan,
Thanks for your comments! I changed the order of library appearance as you suggested to:
EXE_LIBS = \
-lfiniteVolume \
-lmeshTools \
-ldynamicMesh \
-L/home/kumar/Code_Saturne/7.0.0/med-4.1.0/arch/Linux_x86_64/lib -lmedC
Now the compilation works without errors:
g++ -std=c++11 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3 -DNoRepository -ftemplate-depth-100 -std=c++11 -I/home/kumar/Code_Saturne/7.0.0/hdf5-1.10.6/arch/Linux_x86_64/include -I/home/kumar/Code_Saturne/7.0.0/med-4.1.0/arch/Linux_x86_64/include -I/opt/openfoam8/src/finiteVolume/lnInclude -I/opt/openfoam8/src/meshTools/lnInclude -I/opt/openfoam8/src/dynamicMesh/lnInclude -IlnInclude -I. -I/opt/openfoam8/src/OpenFOAM/lnInclude -I/opt/openfoam8/src/OSspecific/POSIX/lnInclude -fPIC -fuse-ld=bfd -Xlinker --add-needed -Xlinker --no-as-needed Make/linux64GccDPInt32Opt/foamMeshToMED.o -L/opt/openfoam8/platforms/linux64GccDPInt32Opt/lib \
-lfiniteVolume -lmeshTools -ldynamicMesh -L/home/kumar/Code_Saturne/7.0.0/med-4.1.0/arch/Linux_x86_64/lib -lmedC -lOpenFOAM -ldl \
-lm -o /home/kumar/OpenFOAM/kumar-8/platforms/linux64GccDPInt32Opt/bin/foamMeshToMED
However, when I execute the application I get the message:
$ foamMeshToMED
foamMeshToMED: error while loading shared libraries: libmedC.so.11: cannot open shared object file: No such file or directory
Perhaps some path issue?
Thanks for your comments! I changed the order of library appearance as you suggested to:
EXE_LIBS = \
-lfiniteVolume \
-lmeshTools \
-ldynamicMesh \
-L/home/kumar/Code_Saturne/7.0.0/med-4.1.0/arch/Linux_x86_64/lib -lmedC
Now the compilation works without errors:
g++ -std=c++11 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3 -DNoRepository -ftemplate-depth-100 -std=c++11 -I/home/kumar/Code_Saturne/7.0.0/hdf5-1.10.6/arch/Linux_x86_64/include -I/home/kumar/Code_Saturne/7.0.0/med-4.1.0/arch/Linux_x86_64/include -I/opt/openfoam8/src/finiteVolume/lnInclude -I/opt/openfoam8/src/meshTools/lnInclude -I/opt/openfoam8/src/dynamicMesh/lnInclude -IlnInclude -I. -I/opt/openfoam8/src/OpenFOAM/lnInclude -I/opt/openfoam8/src/OSspecific/POSIX/lnInclude -fPIC -fuse-ld=bfd -Xlinker --add-needed -Xlinker --no-as-needed Make/linux64GccDPInt32Opt/foamMeshToMED.o -L/opt/openfoam8/platforms/linux64GccDPInt32Opt/lib \
-lfiniteVolume -lmeshTools -ldynamicMesh -L/home/kumar/Code_Saturne/7.0.0/med-4.1.0/arch/Linux_x86_64/lib -lmedC -lOpenFOAM -ldl \
-lm -o /home/kumar/OpenFOAM/kumar-8/platforms/linux64GccDPInt32Opt/bin/foamMeshToMED
However, when I execute the application I get the message:
$ foamMeshToMED
foamMeshToMED: error while loading shared libraries: libmedC.so.11: cannot open shared object file: No such file or directory
Perhaps some path issue?
-
- Posts: 4207
- Joined: Mon Feb 20, 2012 3:25 pm
Re: import meshes from OpenFOAM
Hello,
Yes. You can try adding path information to the compilation/link command
Or otherwise, add the path to your environment
Before running the executable.
Best regards,
Yvan
Yes. You can try adding path information to the compilation/link command
Code: Select all
-Wl,,-rpath -Wl,/home/kumar/Code_Saturne/7.0.0/med-4.1.0/arch/Linux_x86_64/lib
Code: Select all
export LD_LIBRARY_PATH=/home/kumar/Code_Saturne/7.0.0/med-4.1.0/arch/Linux_x86_64/lib:$LD_LIBRARY_PATH
Best regards,
Yvan
Re: import meshes from OpenFOAM
Hello everyone,
I'm using this topic because the encountered problem is quite close, but don't hesitate to precise to me if it's recommended to begin a new one.
So I would like to use meshes generated by OpenFoam utilities (snappyHexMesh, CfMesh) with Code_Saturne. I'm trying to use the existing tool foamMeshToMED mentionned in this topic and available on https://github.com/mortbauer/foamMeshToMED.
Here are the versions I'm currently using :
- Code_Saturne 7.0
- Openfoam 9
- MED 4.0.1 (from CS installation)
- hdf5-1.10.6 (from CS installation)
With some minor modifications, the compilation of the foamMeshToMED tool seems to remain globally OK (just some warnings), even with OpenFoam 9. But then, when I try to convert a mesh (a very simple cube meshed with blockMesh), I get the following output (and error) :
The error seems to suggest the generated MED file is not accepted by my MED libraries. Is there a possibility the mentionned tool foamMeshToMED is too old (8 years) compared to my currently MED version? What does this error suggest to you? kkumar20 was using same MED versions in the previous posts, but I don't know if he finally succeeded to use the tool.
Thank you for your help,
Best regards,
Matthieu
I'm using this topic because the encountered problem is quite close, but don't hesitate to precise to me if it's recommended to begin a new one.
So I would like to use meshes generated by OpenFoam utilities (snappyHexMesh, CfMesh) with Code_Saturne. I'm trying to use the existing tool foamMeshToMED mentionned in this topic and available on https://github.com/mortbauer/foamMeshToMED.
Here are the versions I'm currently using :
- Code_Saturne 7.0
- Openfoam 9
- MED 4.0.1 (from CS installation)
- hdf5-1.10.6 (from CS installation)
With some minor modifications, the compilation of the foamMeshToMED tool seems to remain globally OK (just some warnings), even with OpenFoam 9. But then, when I try to convert a mesh (a very simple cube meshed with blockMesh), I get the following output (and error) :
Code: Select all
Create time
--> FOAM Warning :
From function static Foam::instantList Foam::timeSelector::select0(Foam::Time&, const Foam::argList&)
in file db/Time/timeSelector.C at line 269
No time specified or available, selecting 'constant'
Read the mesh
Creating MEDfile
Writing Comment
Creating Mesh
Translating time = constant
~/Programmes/Code_Saturne/saturne_build/prod_7.0.2/med-4.1.0/src/hdfi/MEDfichierNo.c [39] : Impossible d'identifier un numéro de fichier correct à partir de l'identifiant :
~/Programmes/Code_Saturne/saturne_build/prod_7.0.2/med-4.1.0/src/hdfi/MEDfichierNo.c [40] : id = 0
~/Programmes/Code_Saturne/saturne_build/prod_7.0.2/med-4.1.0/src/misc/_MEDcheckVersion30.c [32] : Erreur d'appel de l'API
~/Programmes/Code_Saturne/saturne_build/prod_7.0.2/med-4.1.0/src/misc/_MEDcheckVersion30.c [32] : MEDfileNumVersionRd
~/Programmes/Code_Saturne/saturne_build/prod_7.0.2/med-4.1.0/src/misc/_MEDcheckVersion30.c [33] : majeur = 0
~/Programmes/Code_Saturne/saturne_build/prod_7.0.2/med-4.1.0/src/misc/_MEDcheckVersion30.c [33] : mineur = 0
~/Programmes/Code_Saturne/saturne_build/prod_7.0.2/med-4.1.0/src/misc/_MEDcheckVersion30.c [33] : release = 0
~/Programmes/Code_Saturne/saturne_build/prod_7.0.2/med-4.1.0/src/hdfi/MEDfichierNo.c [39] : Impossible d'identifier un numéro de fichier correct à partir de l'identifiant :
~/Programmes/Code_Saturne/saturne_build/prod_7.0.2/med-4.1.0/src/hdfi/MEDfichierNo.c [40] : id = 0
~/Programmes/Code_Saturne/saturne_build/prod_7.0.2/med-4.1.0/src/misc/_MEDcheckVersion30.c [32] : Erreur d'appel de l'API
~/Programmes/Code_Saturne/saturne_build/prod_7.0.2/med-4.1.0/src/misc/_MEDcheckVersion30.c [32] : MEDfileNumVersionRd
~/Programmes/Code_Saturne/saturne_build/prod_7.0.2/med-4.1.0/src/misc/_MEDcheckVersion30.c [33] : majeur = 0
~/Programmes/Code_Saturne/saturne_build/prod_7.0.2/med-4.1.0/src/misc/_MEDcheckVersion30.c [33] : mineur = 0
~/Programmes/Code_Saturne/saturne_build/prod_7.0.2/med-4.1.0/src/misc/_MEDcheckVersion30.c [33] : release = 0
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigSegv::sigHandler(int) at ??:?
#2 ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3 MEDfilterClose in "/home/morelm/Programmes/Code_Saturne/saturne_build/prod_7.0.2/med-4.1.0/arch/Linux_x86_64/lib/libmedC.so.11"
#4 _MEDmeshAdvancedWr in "/home/morelm/Programmes/Code_Saturne/saturne_build/prod_7.0.2/med-4.1.0/arch/Linux_x86_64/lib/libmedC.so.11"
#5 MEDmeshElementConnectivityWr in "/home/morelm/Programmes/Code_Saturne/saturne_build/prod_7.0.2/med-4.1.0/arch/Linux_x86_64/lib/libmedC.so.11"
#6 ? in "/media/disque2/ProjPerso_d2/OpenFoam_v9/PROJECT_USER/foamMeshtoMED/foamMeshToMED"
#7 ? in "/media/disque2/ProjPerso_d2/OpenFoam_v9/PROJECT_USER/foamMeshtoMED/foamMeshToMED"
#8 ? in "/media/disque2/ProjPerso_d2/OpenFoam_v9/PROJECT_USER/foamMeshtoMED/foamMeshToMED"
#9 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#10 ? in "/media/disque2/ProjPerso_d2/OpenFoam_v9/PROJECT_USER/foamMeshtoMED/foamMeshToMED"
Erreur de segmentation (core dumped)
Thank you for your help,
Best regards,
Matthieu
-
- Posts: 4207
- Joined: Mon Feb 20, 2012 3:25 pm
Re: import meshes from OpenFOAM
Hello,
The best solution here would probably be to compile Foam2Med in debug mode and run it under a debugger to understand what is wrong. You may also experiment with using a MED library build with 32-bit or 64-bit integer sizes, but this is just a guess.
Best regards,
Yvan
The best solution here would probably be to compile Foam2Med in debug mode and run it under a debugger to understand what is wrong. You may also experiment with using a MED library build with 32-bit or 64-bit integer sizes, but this is just a guess.
Best regards,
Yvan