Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    ajaust
    @ajaust

    For the more recent versions of preCICE the FindPETSC script has been updated. For these versions I had to extend PKG_CONFIG_PATH as well

    You could try extending that by

    export PKG_CONFIG_PATH={$PETSC_DIR}/lib/pkgconfig/:${PKG_CONFIG_PATH}
    wait
    There is a type
    export PKG_CONFIG_PATH=${PETSC_DIR}/lib/pkgconfig/:${PKG_CONFIG_PATH}
    *typo
    So, for me extending the PKG_CONFIG_PATH the following way worked:
    export PKG_CONFIG_PATH=${PETSC_DIR}/lib/pkgconfig/:${PKG_CONFIG_PATH}
    Could you try that?
    Just be sure that the PETSC_DIR variable is set before using that command. ;)
    guifon1000
    @guifon1000

    I had to run

    export PKG_CONFIG_PATH=${PETSC_DIR}/arch-linux2-c-debug/lib/pkgconfig/:${PKG_CONFIG_PATH}

    but it worked ;)
    Thank you @ajaust !

    guifon1000
    @guifon1000

    maybe a

    export PKG_CONFIG_PATH=${PETSC_DIR}/${PETSC_ARCH}/lib/pkgconfig/:${PKG_CONFIG_PATH}

    would be better to remember...

    ajaust
    @ajaust
    Ah... That makes sense :)
    I have set up my paths a little bit messy. I will open an issue so that information will net be lost.
    Martin Saravia
    @martinsaravia
    Thanks @MakisH . With the modifications in the directory structure that I posted above the adapter compiled succesfully in Centos 7 (Actually Rocks 7). I still have no tested it since I am having troubles with the Calculix adapter and YAML. I 'll keep you posted. Thanks, Martin.
    Gerasimos Chourdakis
    @MakisH
    by the way, any feedback on Centos (and Rocks ;-) ) is very welcome, especially if there is anything we can add/fix on the wiki
    do the preCICE tests work for you?
    Martin Saravia
    @martinsaravia
    I am having a had a hard time to adjust the required libraries, mainly because some of them are installed several times with different versions, when you install Rocks rolls you need different versions of the same library. I have tried several configurations of cmake flags when compiling precice and finally almost all test worked, except for solverDummy, I had to enter the solver dymmy directory and execute cmake there, I dont know how but the test passed apparently. I am pretty sure that whith the proper libraries it works. The main problem I am having is that I a mechanical engineer, so some problems that for me are hard to solve are probably trivial for a software engineer.
    I still have not compiled the calculix adapter since the YAML version that I download from the link that is posted on the calculix adapter page is not working, it appears that there is an incompatibiliy issue with some YAML function or that it is not correctly linked, I tried a hundred configuration and it could not get it work. Today I will be testing a YAML instelled with yum from the centos 7 repositories.
    Gerasimos Chourdakis
    @MakisH
    @martinsaravia I see several issues here:
    • preCICE: Since you are using Rocks, I guess you are on a cluster. Have you tried getting preCICE from Spack?
    • CalculiX adapter: This yaml-cpp version should work. However, there is an issue with old compilers. I once tried to understand this and documented my observations here.
    Martin Saravia
    @martinsaravia
    I was not aware of Spack, I am going to give it a try @MakisH . I was aware of your comment in #83, in a few minutes we are going to give the adapter a second try. I think preCICE is working...
    Martin Saravia
    @martinsaravia
    Well guys, I manged to install everything on Centos 7, preCICE and the Calculix and OpenFOAM adpters, the problem starts to run and I get a floating point exception while running, I think because there is a communication failure. I have compiled precice without Python Actions since I get an error in the 19 test base: PythonAction.cpp:36:25: error: PyUnicode_AsWideCharString not declared in this scope (I tried pointing to the python executable but it does not help). The simulation logs are above, do you have an idea of what can be happening?
    Martin Saravia
    @martinsaravia
    Note: the logs correspond a a copilation with Python actions disabled and the solverdummy test not passed due to an error saying: only initial declaration of f loops in mode C99 are allowed.
    Gerasimos Chourdakis
    @MakisH
    @martinsaravia the error seems to originate from inside OpenFOAM. Do OpenFOAM-only cases run?
    also, do the preCICE tests (make test) succeed? (not related, but just wondering)
    With OpenFOAM 8, the heated plate tutorial is running for me, but at the very end I get:
    Inconsistency detected by ld.so: dl-close.c: 811: _dl_close: Assertion `map->l_init_called' failed!
    Martin Saravia
    @martinsaravia

    @MakisH OpenFOAM alone is running well, It appears as if Calculix passed Nan in the displacement field to OpenFOAM, this is probably why laplacianFoam solver tries to solve the displacement equation for the mesh motion but crushes. Line 132 says:

    ---[precice]  initializeData is skipped since no data has to be initialized. In my machine this does not appears.

    I installed preCICE with OpenFOAM 8 and Calculix in my machine (Ubuntu) and all test passed and everything runs properly (at least flap perp). However, in the cluster with Rocks test number 19 of make tests_base failed (also all related, I think 22, 23). These are all the dummySolver tests. The main problem with this tests is that it appears that the for loops are not compatible with the compiler, I tried with cmake -std=C99 but it does not help.

    Martin Saravia
    @martinsaravia
    I have just run separately the OpenFOAM and Calculix parts of flap perp (the one giving the errors above) and both work fine. I'll keep trying...precice-Calculix-convergence.log shows -Nan for the first value of ResAbs(Displacement).
    Martin Saravia
    @martinsaravia
    cylinderFlap example is running on Rocks after changing the mapping from rbf to nearest-projection.
    Gerasimos Chourdakis
    @MakisH
    then I can imagine that OpenFOAM and preCICE are built with different MPI versions and this causes some undefined behavior when OpenFOAM links to preCICE
    guifon1000
    @guifon1000
    Hello, I have the same problem as in precice/precice#45 , on a debian 10.6. No big deal, I just replugged my ethernet cable, but the problem still exists.
    Benjamin Uekermann
    @uekerman
    @guifon1000 Could you please comment there with enough information to reproduce your case and re-open the issue.
    guifon1000
    @guifon1000
    Yes I will. In fact my case is neither working when I plug the ethernet. Calculix and Openfoam wait for one another eternally. In sequential this case (OpenFoam-Calculix Cylinder Flap) runs fine. Iwill come back when I have more info
    Gerasimos Chourdakis
    @MakisH
    @guifon1000 could it be any of these issues instead?
    guifon1000
    @guifon1000
    No in fact this behaviour was due to the fact that I forgot to recompile OpenFOAM with the openmpi-from-source I had used to compile preCICE. As everything was running fine in sequential I forgot... After recompiling OpenFOAM everything is OK, even with ethernet unplugged :-)
    Gerasimos Chourdakis
    @MakisH
    I guess this is something currently missing a bit from our documentation: maybe we should include the "use the same MPI" in our communication page
    guifon1000
    @guifon1000
    Hi I am working on the tutorials, on the 3d_tube in particular. I wanted to check both meshes in paraview so I created a STL file with cgx from the all.msh mesh, which I imported with the OpenFOAM mesh in paraview
    pb.png
    In blue is the FEA mesh, in yellow the Fluid mesh. I really do not understand why there is such a scale difference in the input ?
    Amr Elsharkawy
    @AAELsharkawy

    HI everyone,
    I am trying to build the calculix adaptor, and I am getting the following error:

    CalculiX/ccx_2.16/src/spooles.h:26:10: fatal error: misc.h: No such file or directory
    26 | #include <misc.h>

    Any idea how to solve that problem? system is ubuntu 20.04
    Thanks in advance

    Ishaan Desai
    @IshaanDesai
    Hi @AAELsharkawy, can you check whether the paths to CCX, SPOOLES, ARPACK and YAML are set correctly in the Makefile of the adapter? The paths are in the first 10 lines of the Makefile
    Amr Elsharkawy
    @AAELsharkawy
    @IshaanDesai , the include paths are correct (e.g. /usr/include/spooles) but needed to change the directory name to small letters.
    Now new error:
    g++: error: /usr/include/spooles/spooles.a: No such file or directory
    g++: error: /usr/include/arpack/libarpack_INTEL.a: No such file or directory
    And I have searched using the dpkg -L libspooles-dev and dpkg -L libarpack2-dev
    and I could not find the spooles.a and libarpack_INTEL.a among the installed files.
    Ishaan Desai
    @IshaanDesai
    I have faced similar issues when installing the dependencies with sudo apt install libarpack2-dev libspooles-dev libyaml-cpp-dev. The remedy is in the calculix-adapter Wiki page sections which is to install the library from source. For a source installation the required files are available
    Gerasimos Chourdakis
    @MakisH
    btw, @AAELsharkawy, yesterday I updated the master branch of the CalculiX adapter to simplify the Makefile and allow to just install the dependencies from APT. See precice/calculix-adapter#46 and check that you have the latest state
    Amr Elsharkawy
    @AAELsharkawy

    @IshaanDesai Thanks, yes I needed to install the libraries from the source.
    @MakisH Thanks, I have already downloaded the libraries and it works.
    Now, I am running the flap_prep using OpenFOAM and Calculix and I get the error that the problem is ill-posed as follows:

    ERROR: The polynomial QR system of the RBF mapping from mesh Solid to mesh Fluid-Mesh-Nodes has not converged. This means most probably that the mapping problem is not well-posed. Please check if your coupling meshes are correct. Maybe you need to fix axis-aligned mapping setups by marking perpendicular axes as dead?

    Now, I just need to specify somehow that the problem actually is 2D and not 3D as specified in the preCICE config file, right?

    Gerasimos Chourdakis
    @MakisH
    this error is actually something that you specifically may like looking into! We don't have a 2D variant with CalculiX, but we do have both a 3D and a 2D variant with deal.II in the same repository. Better look at this.
    Amr Elsharkawy
    @AAELsharkawy

    Hi everyone,
    I am trying to test the fenics adapter and I get the following error:
    ImportError: cannot import name 'sub_forms_by_domain' from 'ufl.form' (/home/aelsharkawy/.local/lib/python3.8/site-packages/ufl/form.py)

    Some forums suggested that there are multiple versions of the package at /home/aelsharkawy/.local/lib/python3.8/site-packages
    However, I have already checked and there is only one.
    Thanks in advance.

    Benjamin RĂ¼th
    @BenjaminRueth
    Another hint: you can usually test whether FEniCS works or not by simply running python3 -c "from fenics import *. No need to go through the whole adapter pipeline.
    Amr Elsharkawy
    @AAELsharkawy
    @BenjaminRueth Unfortunately I still get the same error. Will try look into it again.