error in coupling code_saturne and code_aster using Yacs

[lzhang]

Hello,

Yes, I updated the config file. I think they are some configuration issues with salome_meca 2017.

Thanks a lot, I am waiting for your results.

Best regards,

Lei

[Yvan Fournier]

Hello,

I updated the script generation for recent versions of Salome, which use the "salome" command but not runSession and runAppli scripts anymore.

I won't be able to upload it before Jan 2, so I attach the updated patch file for bin/case_case.py (as well as the current updated version, as of the "trunk" development version. Updating this file in your install (rerunning the Code_Saturne install or also copying the file in <install_prefix>/lib/python<version>/site-packages/code_saturne over the previous version will do.

I also attach the latest example that worked for me.

In my case, on my home machine (running Arch Linux), I stll have issues, but those seem related to installation and os/libary compatibility issues (code_aster seems to want openblas, which I have not installed, and which is not in the Salome-Meca tree, and I have another compatibility issue on the Code_Satune side, with an undefined symbol which is probably related to using another gcc version than Salome, leading to different C++ name mangling rules: I am missing ZN19Engines_Component_i20configureSalome_fileENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_P13Salome_file_i, while the closest symbol in Salome-Meca is _ZN19Engines_Component_i20configureSalome_fileESsSsP13Salome_file_i in libSalomeContainer.so).

Debug info for cases which were run (or failed) may be found in /tmp/*FSI*.log files (it's quite helpful to know where to look).

I assume those issues should not occur an a system more similar to the one Salome-Meca is built on (Debian 8 I beleive, though am not 100% certain), so I'll let you check.

For reference for others reading this thread, my code_saturne.cfg file contains the following path for code_aster (adapt to your Salome-Meca install path):
aster = /home/yvan/opt/salome_meca/V2017.0.2/tools/Code_aster_stable-v134_smeca

Best regards,

Yvan

[Yvan Fournier]

Hello,

Update: I have not tried this yet, but to avoid the symbol issues related to C++ described above, you can test the following addition to the "configure" command line for the Code_Saturne installation:

CXXFLAGS=-D_GLIBCXX_USE_CXX11_ABI=0

Best regards,

Yvan

[Xepls]

Hello,

I updated the script generation for recent versions of Salome, which use the "salome" command but not runSession and runAppli scripts anymore.

I won't be able to upload it before Jan 2, so I attach the updated patch file for bin/case_case.py (as well as the current updated version, as of the "trunk" development version. Updating this file in your install (rerunning the Code_Saturne install or also copying the file in <install_prefix>/lib/python<version>/site-packages/code_saturne over the previous version will do.

I also attach the latest example that worked for me.

In my case, on my home machine (running Arch Linux), I stll have issues, but those seem related to installation and os/libary compatibility issues (code_aster seems to want openblas, which I have not installed, and which is not in the Salome-Meca tree, and I have another compatibility issue on the Code_Satune side, with an undefined symbol which is probably related to using another gcc version than Salome, leading to different C++ name mangling rules: I am missing ZN19Engines_Component_i20configureSalome_fileENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_P13Salome_file_i, while the closest symbol in Salome-Meca is _ZN19Engines_Component_i20configureSalome_fileESsSsP13Salome_file_i in libSalomeContainer.so).

Debug info for cases which were run (or failed) may be found in /tmp/*FSI*.log files (it's quite helpful to know where to look).

I assume those issues should not occur an a system more similar to the one Salome-Meca is built on (Debian 8 I beleive, though am not 100% certain), so I'll let you check.

For reference for others reading this thread, my code_saturne.cfg file contains the following path for code_aster (adapt to your Salome-Meca install path):
aster = /home/yvan/opt/salome_meca/V2017.0.2/tools/Code_aster_stable-v134_smeca

Best regards,

Yvan

HI Yvan

I resolved that problems.

I change my default mpi to:
- mpi 2.1.2 (change)
- open MPI 1.5.5 (change)
- API MPI 3.1.0 (default)

and the first problem is clear on ubuntu 16.04, or download caelinux 2013 and install normal salome_meca 2016 and saturne 4.2.3 coupled without add any config extra.

I hope that is usefull for you.

But I reach other problem related to other lib in the two distros:

Code: Select all

 [...] ./cs_solver: symbol lookup error: /opt/Code_Saturne/4.2.3/code_saturne-4.2.3/arch/Linux_x86_64/lib/salome/libSalomeIDLFSI.so.0: undefined symbol: _ZN4omni18proxyObjectFactoryD2Ev

I try with patch on your post, and post my results.

[Yvan Fournier]

Hello,

The missing symbol seems different from the one I encountered. Let's hope it disappears with the patch...

I'll be happy to have your feedback in any case.

Best regards,

Yvan

[Xepls]

Hello,

The missing symbol seems different from the one I encountered. Let's hope it disappears with the patch...

I'll be happy to have your feedback in any case.

Best regards,

Yvan

I have to say that that problem with:

_ZN19Engines_Component_i20configureSalome_fileESsSsP13Salome_file_i in libSalomeContainer.so).

I resolved with old MPI. but I have new problem with libs.

----------------------------

With new patch for saturne coupling I can to resolve the many problem (Saturne 5.0.5 & Salome_Meca 2017) but in the test that you post, I have one error on aster (tmp) related with modules.

Code: Select all

[...] File "/opt/salome_meca/V2017.0.2/tools/Code_aster_stable-v134_smeca/lib/aster/code_aster/Cata/Commands/diffusion_H2.py", line 25, in <module>
    from code_aster.Cata.Commands import (AFFE_CHAR_THER, AFFE_MATERIAU, CALC_CHAMP, CALC_CHAM_ELEM, CREA_CHAMP, DEFI_MATERIAU, PROJ_CHAMP)
ImportError: cannot import name AFFE_CHAR_THER 

first iteration done, but this error came for two iteration.

I have this modules in my folder, don't undertand because this error, but seem problem that Aster-Salome_meca exclusively.

------------------------------------

I hope Izhang post his results for new answer

[Yvan Fournier]

Hello,

Good to know it now starts. The last issue might be due to an obsolete or deprecated function in code_aster. I'm not sure about this, but I can try to check with the code_aster team next week. Otherwise you might find info before that in code_aster release notes or on code_aster forums
(I have only minimal training in code_aster, so am not too sure about this).

If you get a solution before I do, please inform me so I can update the test case.

Best regards,

Yvan Fournier

[lzhang]

Hello,

I began to test salome_meca2017 with the patch. And I encounter a different problem from yours :
/home/lzhang/salome_meca2017/V2017.0.2/tools/Code_aster_stable-v134_smeca/bin/aster: symbol lookup error: /home/lzhang/salome_meca2017/V2017.0.2/tools/Code_aster_stable-v134_smeca/bin/aster: undefined symbol: dgesv_
EXECUTION_CODE_ASTER_EXIT_16420=127

+++ STANDARD ERROR:

+++ END

And I tried to solve this problem by installing manually openblas following
https://code-aster.org/forum2/viewtopic ... 678#p55678

Then running an Aster test case using <salome_meca shell 'as_run solid.export'> works well without error. However when running a fsi coupling test by ./runcase, the same error with "undefined symbol dgesv_" reappears.

So Aster alone can correctly locate the installation directory of openblas, but not when launching with Saturne. Maybe I need to tell saturne where to find the openblas library.

Do you have any ideas to solve this problem?

Regards,
Lei

[Yvan Fournier]

Hello,

Since you get an "undefined symbol" rather than "library not found" type error, I would assume that in the coupling case, code_aster finds a BLAS library, but not the one you want (OpenBlas). But I am not sure why.

If you are not using other BLAS functions for other applications, you may wantto check (and if possible uninstall) for other BLAS libraries. If you cannot change the installation, you would need to insert the "ldd" command in the script which runs the code_aster executable to see which one it finds (I don't remember which one it is, but you can start from scripts called by the "run_solver" script in the execution directory in which the coupling failed.

Best regards,

Yvan

[lzhang]

Hello,

Indeed, in the file "run_solver", generated automatically by code_saturne, the location of the openblas library is redirected to the wrong place. And the suppression of the corresponding line in "run_solver" solves the problem.

For your information, I did not encounter problems of undefined symbol, and my simulation seems to work. I need to do more tests to confirm. My system is ubuntu 14.04, and I work with code_saturne 5.0.4 and salome_meca 2017.0.2.

Regards,
Lei