precice / calculix-adapter

preCICE-adapter for the CSM code CalculiX

CalculiX-preCICE adapter

The adapter was initially developed for conjugate heat transfer (CHT) simulations via preCICE by Lucia Cheung in the scope of her master’s thesis [1] in cooperation with SimScale. For running the adapter for CHT simulations refer to this thesis. The adapter was extended to fluid-structure interaction by Alexander Rusch [2].

The latest version of the adapter is based on CalculiX version 2.20. Legacy versions of the adapter for older versions of CalculiX are supported on various branches. Branches for CalculiX version older than 2.15 require preCICE v1.x, whereas newer versions rely on preCICE v2.x. The release v2.20.1 relies on preCICE v3.0.x.

Start here

Go to the adapter documentation

References

[1] Lucia Cheung Yau. Conjugate heat transfer with the multiphysics coupling library precice. Master’s thesis, Department of Informatics, Technical University of Munich, 2016.

[2] Benjamin Uekermann, Hans-Joachim Bungartz, Lucia Cheung Yau, Gerasimos Chourdakis and Alexander Rusch. Official preCICE Adapters for Standard Open-Source Solvers. In Proceedings of the 7th GACM Colloquium on Computational Mechanics for Young Scientists from Academia, 2017.

License

This project contains modified CalculiX files (licensed under GPLv2 or later) and additional adapter-specific files (GPLv3). As a whole, this project is licensed under GPLv3.

calculix-adapter's Issues

Segmentation fault at the end of simulation

I opened this issue originally here, since it is an error occuring with the calculix adapter, I am opening an issue here, too.

Hi @arusch

I am trying to use this system test in a docker (link). I am building a docker image with all needed software and than simulate, but the simulation fails:

Output of Allrun script:

Setting up the preCICE configuration file for a serial simulation
Preparing the Inner-Fluid participant...
Starting the Inner-Fluid participant...
Preparing the Outer-Fluid participant...
Starting the Outer-Fluid participant...
Starting the Solid participant...
Waiting for the participants to exit...
(you may run 'tail -f Inner-Fluid.log' in another terminal to check the progress)
./Allrun: line 62:   176 Segmentation fault      (core dumped) ${Solver3} -i ${Participant3}/solid -precice-participant ${Participant3} > ${Participant3}.log 2>&1

Something went wrong... See the log files for more.

Than i look in the Solid.log I find following message (dots denote more Output, to be exactly a table with the summary):

Run finished at Tue May 15 14:11:00 2018
Global runtime       = 159264ms / 159s
Number of processors = 1
# Rank: 0

....

[3ac372e390fb:00176] *** Process received signal ***
[3ac372e390fb:00176] Signal: Segmentation fault (11)
[3ac372e390fb:00176] Signal code: Address not mapped (1)
[3ac372e390fb:00176] Failing at address: (nil)
[3ac372e390fb:00176] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x354b0)[0x7f92306644b0]
[3ac372e390fb:00176] [ 1] /precice/build/last/libprecice.so(_ZN7precice4impl19SolverInterfaceImpl8finalizeEv+0x5ab)[0x7f922fd104ab]
[3ac372e390fb:00176] [ 2] /precice/build/last/libprecice.so(precicec_finalize+0x199)[0x7f922fd9f176]
[3ac372e390fb:00176] [ 3] ccx_preCICE[0x6052ce]
[3ac372e390fb:00176] [ 4] ccx_preCICE[0x6041b1]
[3ac372e390fb:00176] [ 5] ccx_preCICE[0x602de4]
[3ac372e390fb:00176] [ 6] ccx_preCICE[0x40fee8]
[3ac372e390fb:00176] [ 7] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f923064f830]
[3ac372e390fb:00176] [ 8] ccx_preCICE[0x408499]
[3ac372e390fb:00176] *** End of error message ***

Used flags in Makefile for CalculiX adapter:

CFLAGS = -g -Wall -std=c++11 -O0 -fopenmp $(INCLUDES) -DARCH="Linux" -DSPOOLES -DARPACK -DMATRIXSTORAGE
FFLAGS = -g -Wall -O0 -fopenmp $(INCLUDES)

Versions of the used software:

OpenFOAM-adapter Version: 890ae8c834d59d9ea459fabc08ea23252dbf0bcf refs/heads/v2.12
CalculiX-adapter Version: 890ae8c834d59d9ea459fabc08ea23252dbf0bcf refs/heads/v2.12
tutorials Version: f19a8a563215320b570237c593e0c2a74d7dc356 refs/pull/1/head
preCICE Version: c957f625350bbdfcda497c4288e286884064861c refs/tags/v1.1.1
OpenFOAM version: 4.1
CalculiX version: 2.12
Ubuntu version: 16.04

What is wrong? How can I debug this? Looking forward to your reply.

Also same error with Calculix version 2.13 and adapter version 2.13.

Best regards,
Yakup

Formatter configuration needed

As the project grows in developers, we will have more and more inconsistencies in formatting, making pull requests more difficult to review (see, e.g., #68). So, let's add a formatter!

Adding a .clang-format is quite easy, but it needs some time to fine-tune it to a style that is close to the original/intented.

Examples:

• preCICE
• OpenFOAM adapter (with some comments on how we try to fit the OpenFOAM style guidelines) - see also precice/openfoam-adapter#173
• deal.II adapter

If needed, I can prepare something to discuss.

write iteration checkpoint include velocity and acceleration

Hi:

I wonder if we would need to store the inital velocity and acceleration when write iteration checkpoint and reload them when read_iteration_checkpoint? Since when calculix step before synchronization time, it may update the velocity and acceleration, which should be restored when sub-iteration is needed. Currently the adapter seems only restore the displacement

Tutorial heat_exchanger CalculiX 2.15 error "There is no Data with ID 66231168"

Hello Team,

I'm working on Centos 7 with shared OpenMPI 4.0.2 library.
Using devtoolset-8

Installed from sources :
yaml-cpp 0.6.2, petcs 3.12.3, boost 1.69, spooles 2.2, arpack 9.6, preCICE 1.6.1, CalculiX 2.15 & OpenFoam 6.
and eigen3-devel-3.3.4-7.el7.noarch from repo

Now, major parts of tutorials FSI are running but not for heat_echanger.

When launching in serial, an error appears in Solid.log :

Initializing coupling data
Adapter writing coupling data...
---[precice] �[31mERROR: �[0m There is no Data with ID 66231168

When launching in parallel, another error appears in Solid.log : 
Initializing coupling data
Adapter writing coupling data...
ASSERTION FAILED
  Location:          void precice::impl::SolverInterfaceImpl::writeBlockScalarData(int, int, const int*, const double*)
  File:              /cm/shared/software/precice/precice-1.6.1/src/precice-1.6.1/src/precice/impl/SolverInterfaceImpl.cpp:1066
  Rank:              0
  Failed expression: valueIndices != nullptr
 0# getStacktrace() in /cm/shared/software/precice/precice-1.6.1/lib/libprecice.so.1.6.1
 1# precice::impl::SolverInterfaceImpl::writeBlockScalarData(int, int, int const*, double const*) in /cm/shared/software/precice/precice-1.6.1/lib/libprecice.so.1.6.1
 2# precicec_writeBlockScalarData in /cm/shared/software/precice/precice-1.6.1/lib/libprecice.so.1.6.1
 3# 0x00000000005C71DD in ccx_preCICE
 4# 0x00000000005C7EE6 in ccx_preCICE
 5# 0x00000000005B40C2 in ccx_preCICE
 6# 0x0000000000412EDA in ccx_preCICE
 7# __libc_start_main in /lib64/libc.so.6
 8# 0x000000000041AEE5 in ccx_preCICE

Thanks for answer.
Karim

Inner-Fluid.log
Inner-Fluid_decomposePar.log
Outer-Fluid.log
Outer-Fluid_decomposePar.log
Solid.log
env.log
Inner-Fluid-serial.log
Outer-Fluid-serial.log
Solid-serial.log

precice-config.txt
precice-config_parallel.txt
precice-config_serial.txt
config.txt

Segmentation vialiolation in CalculiX when running OpenFOAM - CCX tutorials

Hello everybody! Yesterday I installed preCICE, OpenFOAM 7, CalculiX 2.15 and their adapters on Ubuntu 18.04. Then I tried to run the tutorial case: FSI/flap-perp/OpenFOAM-CalculiX Unfortunately, I'm constantly reaching this error:

Starting FSI analysis via preCICE using the geometrically non-linear CalculiX solver...
Using up to 1 cpu(s) for the stress calculation.

Using up to 1 cpu(s) for the symmetric stiffness/mass contributions.

Factoring the system of equations using the symmetric spooles solver
Using 1 cpu for spooles.

Using up to 1 cpu(s) for the stress calculation.

About to enter preCICE setup in Calculix with names Calculix and config.yml
Setting up preCICE participant Calculix, using config file: config.yml
./runSolid: line 19: 3892 Segmentation fault (core dumped) ccx_preCICE -i Solid/flap -precice-participant Calculix

Then I tried to run any other tutorial case and they all end the same way. The OpenFOAM adapter seems to be working correctly and there were no issues with making CCX_preCICE or its dependencies. It also seems to run fine given a standalone .inp file. Any ideas how to find the cause of that? Thank you very much for help. It's my first post in GitHub issues so if I posted this in the wrong place feel free to move it or direct me somewhere else.
Kind regards,
Marek Lubieniecki

Undocumented naming requirement for surfaces

As @FWey noticed, it looks like surfaces defined in the CalculiX adapter need to start with an S. One example is our heat-exchanger tutorial (here Sinner-interface, in the file inner-interface.sur):

** Surfaces based on inner-interface
*SURFACE, NAME=Sinner-interface

@boris-martin @KyleDavisSA any idea where this requirement originates from? I could not find something in Lucia's thesis, nor in the adapter config docs. Apparently, this is not a requirement for CalculiX itself.

If we cannot drop this requirement, we should at least document it.

Automatic adjustment of compiler flags based on compiler/version

We currently have the quick-and-dirty solution for GCC 10 or newer:

FFLAGS = -Wall -O3 -fopenmp $(INCLUDES)
# Note for GCC 10 or newer: add -fallow-argument-mismatch in the above flags

With Ubuntu 22.04 LTS, this will become a more pressing issue, as people will stumble upon it more often without reading the documentation.

We could easily make a condition in the Makefile to check if this is GCC and if it is >=10. Not necessarily now, just documenting the need. We have more pressing issues.

Maybe there is already some fix in the vanilla CalculiX Makefile?

Linking to OpenMPI fails

gfortran -fopenmp -Wall -O3 -o bin/ccx_preCICE bin/ccx_2.12.o bin/ccx_2.12.a /home/florian/software/calculix/SPOOLES.2.2/spooles.a /home/florian/software/calculix/ARPACK/libarpack_INTEL.a -lpthread -lm -lc -L/home/florian/precice/build/last -lprecice -lboost_regex -lboost_log -lboost_log_setup -lboost_thread -lboost_program_options -lboost_system -lboost_filesystem -lpython2.7 -lstdc++ -lmpi_cxx -lm -lmpi -L/build -lyaml-cpp
/usr/bin/ld: cannot find -lmpi_cxx
collect2: error: ld returned 1 exit status
make: *** [Makefile:87: bin/ccx_preCICE] Error 1

Setting FC=mpifort in the Makefile makes it link successfull.

Using the MPI compiler wraper should be the default, as it is also recommeded by the MPI vendors.

ccx_preCICE just crashes with segmentation fault

If I run ccx_preCICE -i somenonsenseinput it just crashes with the following error:

$ ccx_preCICE -i somenonsenseinput

************************************************************

CalculiX Version 2.16, Copyright(C) 1998-2019 Guido Dhondt
CalculiX comes with ABSOLUTELY NO WARRANTY. This is free
software, and you are welcome to redistribute it under
certain conditions, see gpl.htm

************************************************************

You are using an executable made on Mo 25. Nov 18:56:47 CET 2019
ccx_preCICE: malloc.c:4036: _int_malloc: Assertion `(unsigned long) (size) >= (unsigned long) (nb)' failed.
Aborted (core dumped)

Note that the vanilla CalculiX (I used the version installed via apt) gives me a different error which is for a user much easier to understand:

$ ccx -i somenonsenseinput

************************************************************

CalculiX Version 2.11, Copyright(C) 1998-2015 Guido Dhondt
CalculiX comes with ABSOLUTELY NO WARRANTY. This is free
software, and you are welcome to redistribute it under
certain conditions, see gpl.htm

************************************************************

You are using an executable made on So 31. Jul 13:26:31 CEST 2016
*ERROR in readinput: cannot open file somenonsenseinput.inp

Check for memory leaks

During tests for FSI with CalculiX and OpenFOAM, @derekrisseeuw noticed unreasonably high memory usage for CalculiX after a while, so there may be some memory leak in the adapter (or maybe in CalculiX itself).

At first, I would manually check if we delete every pointer we create. If this does not help, I would try to use Valgrind or a similar tool, although I would expect this to be a bit tricky in our case.

RBF mapping: Polynomial QR linear system has not converged. (specific to v2.16)

As I wrote on #33, which is now merged to master:

This time I tried on a clean install on Ubuntu 20.04, preCICE 2.0.1 from master built in Debug mode, PETSc 3.12 from APT (3.12.4+dfsg1-1), CalculiX 2.16 and the adapter from the v2.16 branch.

Running the tutorials/FSI/flap_perp/OpenFOAM-CalculiX tutorial without any changes, with OpenFOAM v1912, returns on the Fluid side:

---[preciceAdapter] [DEBUG] Writing coupling data...
---[preciceAdapter] [DEBUG] Advancing preCICE...
---[precice]  Mapping Forces0 conservative from Fluid-Mesh-Faces (ID 0) to Solid (ID 2) for dimension 0) with polynomial set to separate
---[precice]  Mapping Forces0 conservative from Fluid-Mesh-Faces (ID 0) to Solid (ID 2) for dimension 1) with polynomial set to separate
---[precice]  Mapping Forces0 conservative from Fluid-Mesh-Faces (ID 0) to Solid (ID 2) for dimension 2) with polynomial set to separate
---[precice]  Compute read mapping from mesh "Solid" to mesh "Fluid-Mesh-Nodes".
---[precice]  Using tree-based preallocation for matrix C
---[precice]  Using tree-based preallocation for matrix A
---[precice]  Mapping Displacements0 consistent from Solid (ID 2) to Fluid-Mesh-Nodes (ID 1) for dimension 0) with polynomial set to separate
KSP Object: QR Solver 1 MPI processes
  type: lsqr
    standard error not computed
    using inexact matrix norm
  maximum iterations=10000, initial guess is zero
  tolerances:  relative=1e-05, absolute=1e-50, divergence=10000.
  left preconditioning
  using UNPRECONDITIONED norm type for convergence test
PC Object: 1 MPI processes
  type: none
  linear system matrix = precond matrix:
  Mat Object: Q 1 MPI processes
    type: seqdense
    rows=86, cols=4
    total: nonzeros=344, allocated nonzeros=344
    total number of mallocs used during MatSetValues calls=0
---[precice] ERROR:  Polynomial QR linear system has not converged. Try to fix axis-aligned mapping setups by marking perpendicular axis as dead.

Again, running the same exact tutorial on the v2.15 is perfectly fine.

I got the same issue with the FSI/3DTube/OpenFOAM-CalculiX tutorial (switching to rbf-thin-plate-splines mapping). I also observed it on Ubuntu 16.04 with PETSc 3.9.1 built from source.

It looks to me that this is specific to the CalculiX adapter for v2.16, but I have no clue why.

elastic-tube-3d tutorial results are incorrect

Running our elastic-tube-3d tutorial using OpenFOAM and Calculix (master branch) looks as follows:

This is quite different from a result @KyleDavisSA sent me for the same time step:

I am using gcc 10.2 (and the argument-mismatch flag as introduced in #48 ). @KyleDavisSA which version of the adaper are you using and which compiler are you using? I think @IshaanDesai reported similar results.

EDIT: Maybe there is another way around the argument mismatch. To cite from the gcc docs:

Using this option is strongly discouraged. It is possible to provide standard-conforming code which allows different types of arguments by using an explicit interface and TYPE(*).

make readData and writeData array

We are iterating over numReadData.

calculix-adapter/adapter/PreciceInterface.c

Line 467 in 10938d8

for( i = 0 ; i < config->numReadData ; i++ )

But, readData is not an array.

calculix-adapter/adapter/PreciceInterface.h

Line 71 in 10938d8

enum CouplingDataType readData;

Same goes for writeData. If we have a config like this,

participants:

    Calculix:
        interfaces:
        - nodes-mesh: Calculix_Mesh
          patch: interface
          read-data: [Read0,AnotherRead0]
          write-data: [Write0,AnotherWrite0]

precice-config-file: ../precice-config.xml

numRead/WriteData will be 2.

CalculiX + precice with PaStiX solver (pastix.c and pastix.h)

Attempting to compile CalculiX + precice adapter with PaStiX solver ends with an error:

C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:18:35: error: unknown type name 'ITG'
   18 |          double *sigma,double *b, ITG *icol, ITG *irow,
      |                                   ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:18:46: error: unknown type name 'ITG'
   18 |          double *sigma,double *b, ITG *icol, ITG *irow,
      |                                              ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:19:3: error: unknown type name 'ITG'
   19 |   ITG *neq, ITG *nzs,ITG *symmetryflag,ITG *inputformat,ITG *jq,
      |   ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:19:13: error: unknown type name 'ITG'
   19 |   ITG *neq, ITG *nzs,ITG *symmetryflag,ITG *inputformat,ITG *jq,
      |             ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:19:22: error: unknown type name 'ITG'
   19 |   ITG *neq, ITG *nzs,ITG *symmetryflag,ITG *inputformat,ITG *jq,
      |                      ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:19:40: error: unknown type name 'ITG'
   19 |   ITG *neq, ITG *nzs,ITG *symmetryflag,ITG *inputformat,ITG *jq,
      |                                        ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:19:57: error: unknown type name 'ITG'
   19 |   ITG *neq, ITG *nzs,ITG *symmetryflag,ITG *inputformat,ITG *jq,
      |                                                         ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:20:3: error: unknown type name 'ITG'
   20 |   ITG *nzs3,ITG *nrhs);
      |   ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:20:13: error: unknown type name 'ITG'
   20 |   ITG *nzs3,ITG *nrhs);
      |             ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:23:31: error: unknown type name 'ITG'
   23 |                 double *sigma,ITG *icol, ITG *irow,
      |                               ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:23:42: error: unknown type name 'ITG'
   23 |                 double *sigma,ITG *icol, ITG *irow,
      |                                          ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:24:3: error: unknown type name 'ITG'
   24 |   ITG *neq, ITG *nzs,ITG *symmetryflag,ITG *inputformat,
      |   ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:24:13: error: unknown type name 'ITG'
   24 |   ITG *neq, ITG *nzs,ITG *symmetryflag,ITG *inputformat,
      |             ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:24:22: error: unknown type name 'ITG'
   24 |   ITG *neq, ITG *nzs,ITG *symmetryflag,ITG *inputformat,
      |                      ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:24:40: error: unknown type name 'ITG'
   24 |   ITG *neq, ITG *nzs,ITG *symmetryflag,ITG *inputformat,
      |                                        ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:25:3: error: unknown type name 'ITG'
   25 |   ITG *jq,ITG *nzs3);
      |   ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:25:11: error: unknown type name 'ITG'
   25 |   ITG *jq,ITG *nzs3);
      |           ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:28:31: error: unknown type name 'ITG'
   28 |                 double *sigma,ITG *icol, ITG *irow,
      |                               ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:28:42: error: unknown type name 'ITG'
   28 |                 double *sigma,ITG *icol, ITG *irow,
      |                                          ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:29:3: error: unknown type name 'ITG'
   29 |   ITG *neq, ITG *nzs,ITG *symmetryflag,ITG *inputformat,
      |   ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:29:13: error: unknown type name 'ITG'
   29 |   ITG *neq, ITG *nzs,ITG *symmetryflag,ITG *inputformat,
      |             ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:29:22: error: unknown type name 'ITG'
   29 |   ITG *neq, ITG *nzs,ITG *symmetryflag,ITG *inputformat,
      |                      ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:29:40: error: unknown type name 'ITG'
   29 |   ITG *neq, ITG *nzs,ITG *symmetryflag,ITG *inputformat,
      |                                        ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:30:3: error: unknown type name 'ITG'
   30 |   ITG *jq,ITG *nzs3);
      |   ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:30:11: error: unknown type name 'ITG'
   30 |   ITG *jq,ITG *nzs3);
      |           ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:35:31: error: unknown type name 'ITG'
   35 |                 double *sigma,ITG *icol, ITG *irow,
      |                               ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:35:42: error: unknown type name 'ITG'
   35 |                 double *sigma,ITG *icol, ITG *irow,
      |                                          ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:36:3: error: unknown type name 'ITG'
   36 |   ITG *neq, ITG *nzs,ITG *symmetryflag,ITG *inputformat,
      |   ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:36:13: error: unknown type name 'ITG'
   36 |   ITG *neq, ITG *nzs,ITG *symmetryflag,ITG *inputformat,
      |             ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:36:22: error: unknown type name 'ITG'
   36 |   ITG *neq, ITG *nzs,ITG *symmetryflag,ITG *inputformat,
      |                      ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:36:40: error: unknown type name 'ITG'
   36 |   ITG *neq, ITG *nzs,ITG *symmetryflag,ITG *inputformat,
      |                                        ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:37:3: error: unknown type name 'ITG'
   37 |   ITG *jq,ITG *nzs3);
      |   ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:37:11: error: unknown type name 'ITG'
   37 |   ITG *jq,ITG *nzs3);
      |           ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:39:1: error: unknown type name 'ITG'
   39 | ITG pastix_solve(double *b,ITG *neq,ITG *symmetryflag,ITG *nrhs);
      | ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:39:28: error: unknown type name 'ITG'
   39 | ITG pastix_solve(double *b,ITG *neq,ITG *symmetryflag,ITG *nrhs);
      |                            ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:39:37: error: unknown type name 'ITG'
   39 | ITG pastix_solve(double *b,ITG *neq,ITG *symmetryflag,ITG *nrhs);
      |                                     ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:39:55: error: unknown type name 'ITG'
   39 | ITG pastix_solve(double *b,ITG *neq,ITG *symmetryflag,ITG *nrhs);
      |                                                       ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:41:21: error: unknown type name 'ITG'
   41 | void pastix_cleanup(ITG *neq,ITG *symmetryflag);
      |                     ^~~
C:/msys64/usr/local/CalculiX/ccx_2.17_precice2/src/pastix.h:41:30: error: unknown type name 'ITG'
   41 | void pastix_cleanup(ITG *neq,ITG *symmetryflag);
      |                              ^~~
pastix.c:63:23: error: 'IPARM_SIZE' undeclared here (not in a function)
   63 | spm_int_t iparm_basic[IPARM_SIZE];
      |                       ^~~~~~~~~~
pastix.c:65:20: error: 'DPARM_SIZE' undeclared here (not in a function)
   65 | double dparm_basic[DPARM_SIZE];
      |                    ^~~~~~~~~~
pastix.c:69:1: error: unknown type name 'pastix_data_t'
   69 | pastix_data_t* pastix_data = NULL;
      | ^~~~~~~~~~~~~
pastix.c:135:5: error: unknown type name 'pastix_data_t'
  135 |     pastix_data_t* pastix_data;
      |     ^~~~~~~~~~~~~
pastix.c: In function 'pastix_init':
pastix.c:161:6: warning: implicit declaration of function 'pastixResetSteps' [-Wimplicit-function-declaration]
  161 |      pastixResetSteps(pastix_data);
      |      ^~~~~~~~~~~~~~~~
pastix.c:195:2: warning: implicit declaration of function 'pastixInitParam' [-Wimplicit-function-declaration]
  195 |  pastixInitParam( iparm, dparm );
      |  ^~~~~~~~~~~~~~~
pastix.c:198:11: error: 'IPARM_ORDERING' undeclared (first use in this function)
  198 |     iparm[IPARM_ORDERING]      = PastixOrderScotch;
      |           ^~~~~~~~~~~~~~
pastix.c:198:11: note: each undeclared identifier is reported only once for each function it appears in
pastix.c:198:34: error: 'PastixOrderScotch' undeclared (first use in this function)
  198 |     iparm[IPARM_ORDERING]      = PastixOrderScotch;
      |                                  ^~~~~~~~~~~~~~~~~
pastix.c:200:12: error: 'IPARM_SCHEDULER' undeclared (first use in this function)
  200 |      iparm[IPARM_SCHEDULER]    = PastixSchedStatic;
      |            ^~~~~~~~~~~~~~~
pastix.c:200:34: error: 'PastixSchedStatic' undeclared (first use in this function)
  200 |      iparm[IPARM_SCHEDULER]    = PastixSchedStatic;
      |                                  ^~~~~~~~~~~~~~~~~
pastix.c:203:34: error: 'PastixSchedParsec' undeclared (first use in this function)
  203 |      iparm[IPARM_SCHEDULER]    = PastixSchedParsec;
      |                                  ^~~~~~~~~~~~~~~~~
pastix.c:205:8: error: 'IPARM_THREAD_NBR' undeclared (first use in this function)
  205 |  iparm[IPARM_THREAD_NBR]    = nthread_mkl;
      |        ^~~~~~~~~~~~~~~~
pastix.c:206:8: error: 'IPARM_GPU_NBR' undeclared (first use in this function)
  206 |  iparm[IPARM_GPU_NBR]       = (int) gpu;
      |        ^~~~~~~~~~~~~
pastix.c:207:8: error: 'IPARM_FLOAT' undeclared (first use in this function)
  207 |  iparm[IPARM_FLOAT]      = globDoublePrecision ? 3 : 2;
      |        ^~~~~~~~~~~
pastix.c:208:8: error: 'IPARM_MIN_BLOCKSIZE' undeclared (first use in this function)
  208 |  iparm[IPARM_MIN_BLOCKSIZE]    = 1024;
      |        ^~~~~~~~~~~~~~~~~~~
pastix.c:209:8: error: 'IPARM_MAX_BLOCKSIZE' undeclared (first use in this function)
  209 |  iparm[IPARM_MAX_BLOCKSIZE]    = 2048;
      |        ^~~~~~~~~~~~~~~~~~~
pastix.c:210:8: error: 'IPARM_FACTORIZATION' undeclared (first use in this function)
  210 |  iparm[IPARM_FACTORIZATION]    = PastixFactLU;
      |        ^~~~~~~~~~~~~~~~~~~
pastix.c:210:34: error: 'PastixFactLU' undeclared (first use in this function)
  210 |  iparm[IPARM_FACTORIZATION]    = PastixFactLU;
      |                                  ^~~~~~~~~~~~
pastix.c:211:8: error: 'IPARM_TASKS2D_WIDTH' undeclared (first use in this function)
  211 |  iparm[IPARM_TASKS2D_WIDTH]    = globDoublePrecision ? 256 : 128;
      |        ^~~~~~~~~~~~~~~~~~~
pastix.c:213:8: error: 'IPARM_REUSE_LU' undeclared (first use in this function)
  213 |  iparm[IPARM_REUSE_LU]     = firstIter ? 0 : 1;
      |        ^~~~~~~~~~~~~~
pastix.c:216:11: error: 'IPARM_GPU_MEMORY_PERCENTAGE' undeclared (first use in this function)
  216 |     iparm[IPARM_GPU_MEMORY_PERCENTAGE]  = 95;
      |           ^~~~~~~~~~~~~~~~~~~~~~~~~~~
pastix.c:217:11: error: 'IPARM_GPU_MEMORY_BLOCK_SIZE' undeclared (first use in this function)
  217 |     iparm[IPARM_GPU_MEMORY_BLOCK_SIZE]  = 64 * 1024;
      |           ^~~~~~~~~~~~~~~~~~~~~~~~~~~
pastix.c:220:11: error: 'DPARM_EPSILON_REFINEMENT' undeclared (first use in this function)
  220 |     dparm[DPARM_EPSILON_REFINEMENT]  = 1e-12;
      |           ^~~~~~~~~~~~~~~~~~~~~~~~
pastix.c:221:11: error: 'IPARM_ITERMAX' undeclared (first use in this function)
  221 |     iparm[IPARM_ITERMAX]             = 50;
      |           ^~~~~~~~~~~~~
pastix.c:222:11: error: 'IPARM_GMRES_IM' undeclared (first use in this function)
  222 |     iparm[IPARM_GMRES_IM]             = 50;
      |           ^~~~~~~~~~~~~~
pastix.c:249:2: warning: implicit declaration of function 'pastixInit'; did you mean 'pastix_init'? [-Wimplicit-function-declaration]
  249 |  pastixInit( &pastix_data, MPI_COMM_WORLD, iparm, dparm );
      |  ^~~~~~~~~~
      |  pastix_init
pastix.c:249:28: error: 'MPI_COMM_WORLD' undeclared (first use in this function)
  249 |  pastixInit( &pastix_data, MPI_COMM_WORLD, iparm, dparm );
      |                            ^~~~~~~~~~~~~~
pastix.c:256:2: warning: implicit declaration of function 'pastix_task_analyze'; did you mean 'pastix_analyze'? [-Wimplicit-function-declaration]
  256 |  pastix_task_analyze( pastix_data, spm );

while the same version just not using PaStiX (removed from makefile -DPASTIX) compiles without any problem.

Checkpointing does not work for subcycling

For implicit coupling the writeCheckpoint is called by the function:
Precice_WriteIterationCheckPoint

This function takes the values of the last timestep as checkpoint values. However, for implicit coupled simulations where the calculix is subcycling, the last calculix timestep is not the same as the last coupling timestep. Therefore, the wrong checkpoint is written.

Inconsistencies of type in CCXHelpers with 8 bytes integers mode

In CCXHelpers.h, functions setFaceFluxes, setFaceHeatTransferCoefficient and setFaceSinkTemperature take an "ITG" argument numface, whereas that argument is an int in CCXHelpers.c.
This is not a problem, unless you compile with -DLONGLONG, as seen in adapter's Calculix.h :

ifdef LONGLONG
#define ITG long long
#define ITGFORMAT "lld"
#else
#define ITG int
#define ITGFORMAT "d"
#endif

(Then, you get an error message because headers and implementation don't match)

In practice, this flag is required for building the adapter with PaStiX. I found this while investigating #57 and simply replacing the 3 occurences of "int" by ITG should do the job. It'll be part of my future PR for fixing PaStiX integration, but some opinions would be appreciated to check that I'm not missing a good reason for this difference.

EDIT : There are a few other functions in the same file with the same issue, I only mentioned the 3 first ones because compilation stopped at that point)

Implement mesh connectivity for e.g. nearest-projection mapping

Define edges and triangles. Any guess how complicated that would be in CalculiX?

Null essential (Dirichlet) boundary condition imposed on node 1

Hey,

I have experienced a problem with the adapter for CalculiX 2.16 where node number 1 of the CalculiX mesh has a null Dirichlet BC imposed on it for every increment/time step of a simulation. This happens even when there are no BCs specified for that node. In the case of an FSI simulation this means node 1 stays fixed; it's displacement is always zero.

Others have reported this issue as well:

• CalculiX single node stagnation problem (Specially, check out post number 3).
• FSI SU2/CalculiX (flap_perp): CalculiX node ID#1 is fixed
• How can I create a Solid mesh for working with the nearest neighbor mapping? (See post number 4 by Kyle Davis)
• Temperature anomaly/ Calculix OpenFoam CHT Coupling

The last one seems to indicate this problem also happens for CHT simulations. In that case, for node number 1 T = 0 K.

An easy way to reproduce it is by modifying the perpendicular-flap tutorial. Just exchange nodes 1 and 738 in the *NODE and *ELEMENT keywords. Also, change node 1 to 738 in node set Nfix1 (fix1_beam.nam file). You should get something like this:

That fixed vertex is node 1. This is for t=0.3 s; CalculiX (adapter for 2.16) coupled with OpenFOAM (v7 .org, version 1.0 of the adapter), preCICE 2.3.0, Ubuntu 20.04 LTS.

I have not tested the adapter for CalculiX 2.19 and cannot say wether this shows up with it.

Best regards,
Andrés

Makefile: Hard-coded compiler

See:

calculix-adapter/Makefile

Lines 82 to 84 in 7aff819

	$(OBJDIR)/%.o : adapter/%.cpp
	g++ -std=c++11 -I$(YAML)/include -c $< -o $@ $(LIBS)
	#$(CC) $(CFLAGS) $(INCLUDES) -c $< -o $@ $(LIBS)

Split the adapter config file to one file per participant

For the OpenFOAM adapter we decided to have one adapter configuration file per participant, as shown here. This was done so that we don't need to modify the solver to accept an extra command-line argument (we want to keep the solvers intact).

If there is no problem with the current setup, I propose that we also change the CalculiX adapter to look for one YAML file per participant, instead of accessing a common file for all the participants. We already discussed this with @uekerman.

(as the links may break in the future, they refer to the precice-adapter-config.yml and config.yml of the heat exchanger tutorial for OpenFOAM and CalculiX)

Difference between faces-mesh and mesh ?

I'm slightly confused by the different kinds of interfaces available.
From what I understand, we propose three different things:

• Nodal mesh without connectivity, for e.g. FSI with nearest neighbor or RBF mapping. Configuration is nodes-mesh
• Nodal mesh with connectivity, for same context but when nearest projection is used. Configuration is nodes-mesh-with-connectivity
• Face centers mesh for CHT. Configuration is either mesh or faces-mesh.

In the config reader code mesh and faces-mesh seem to have a different treatment. I think it's just a matter of style, but shouldn't it be a "if(mesh) else if (faces-mesh) else" instead of this "if-else-if" ?
I'm working on some refactoring but I'd rather have confirmation they're equivalent to be sure.

calculix-adapter/adapter/ConfigReader.cpp

Lines 36 to 55 in 4496e8f

	if (config["participants"][participantName]["interfaces"][i]["nodes-mesh"]) {
	interface.nodesMeshName = strdup(config["participants"][participantName]["interfaces"][i]["nodes-mesh"].as<std::string>().c_str());
	interface.map = 0;
	} else if (config["participants"][participantName]["interfaces"][i]["nodes-mesh-with-connectivity"]) {
	interface.nodesMeshName = strdup(config["participants"][participantName]["interfaces"][i]["nodes-mesh-with-connectivity"].as<std::string>().c_str());
	interface.map = 1;
	} else {
	interface.nodesMeshName = NULL;
	}
	if (config["participants"][participantName]["interfaces"][i]["faces-mesh"]) {
	interface.facesMeshName = strdup(config["participants"][participantName]["interfaces"][i]["faces-mesh"].as<std::string>().c_str());
	} else {
	interface.facesMeshName = NULL;
	}
	if (config["participants"][participantName]["interfaces"][i]["mesh"]) {
	interface.facesMeshName = strdup(config["participants"][participantName]["interfaces"][i]["mesh"].as<std::string>().c_str());
	}

Also, documentation on the website seems quite lacking. I'll work on it once I'm sure I don't have a major misunderstanding :)

Calculix error in simulation restart after version 2.10

Hi everyone

To perform a simulation restart in Calculix, a restart file (file ending in .rin) is read at the beginning of the new simulation. However, after version 2.10 Calculix gives me an error and fails. Has anyone else had this problem with v2.11 and onwards? For now, I use version 2.10 for any simulation that requires a restart. This is not an adapter issue but a problem in Calculix.

The second problem with the restart is that if a coupled simulation fails, Calculix does not write a restart output file (file ending in .rout). That means a simulation must be re-run with the end time being before where the simulation crashed the first time to generate an output file.

For now, the Calculix adapter is available for version 2.10 as well. The adapters are built in the same way so if someone is able to perform restarts with version 2.15 then that is great, otherwise I know version 2.10 works.

CalculiX and exo output

I suggest to implement CalculiX Extras Exodus written by Peter A. Gustafson to get results readable by Paraview from CalculiX.

https://www.openaircraft.com/calculix-extras/

More CalculiX extras:
https://sites.google.com/site/kodanda/research/calculix-addons
http://tfel.sourceforge.net/calculix.html
https://gitlab.lrz.de/flayerbein/calculix
https://arc.aiaa.org/doi/abs/10.2514/6.2019-0775

Add support for MODAL DYNAMIC Modus of CalculiX

Information:

Target: Enable the use of MODAL DYNAMIC Cards within CalculiX in a preCICE-coupled simulation.

Implementation: done

Pull request: will hopefully follow soon

2D cases fail when out-of-plane axis is not the z-axis

As discussed here.

Running it looks as follows:

---[precice]  I am participant "Calculix"
Using quasi 2D-3D coupling
Set ID Found 
ccx_preCICE: adapter/PreciceInterface.c:559: PreciceInterface_ConfigureNodesMesh: Assertion `count == interface->num2DNodes' failed.
[lapus303:696058] *** Process received signal ***
[lapus303:696058] Signal: Aborted (6)
[lapus303:696058] Signal code:  (-6)
[lapus303:696058] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7f19c5f223c0]
[lapus303:696058] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcb)[0x7f19c591e18b]
[lapus303:696058] [ 2] /lib/x86_64-linux-gnu/libc.so.6(abort+0x12b)[0x7f19c58fd859]
[lapus303:696058] [ 3] /lib/x86_64-linux-gnu/libc.so.6(+0x25729)[0x7f19c58fd729]
[lapus303:696058] [ 4] /lib/x86_64-linux-gnu/libc.so.6(+0x36f36)[0x7f19c590ef36]
[lapus303:696058] [ 5] ccx_preCICE(+0x1da28e)[0x56203bcd228e]
[lapus303:696058] [ 6] ccx_preCICE(+0x1dad73)[0x56203bcd2d73]
[lapus303:696058] [ 7] ccx_preCICE(+0x1c3bca)[0x56203bcbbbca]
[lapus303:696058] [ 8] ccx_preCICE(+0xa66d)[0x56203bb0266d]
[lapus303:696058] [ 9] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7f19c58ff0b3]
[lapus303:696058] [10] ccx_preCICE(+0x1556e)[0x56203bb0d56e]
[lapus303:696058] *** End of error message ***
./runSolid.sh: line 1: 696058 Aborted                 (core dumped) ccx_preCICE -i Solid/test -precice-participant Calculix

It would be nice if we can inform the user what's wrong and how to fix it.

Quasi 2D-3D coupling fails for 2D SU2 grid and 3D CalculiX grid

Hello,
System:

• Ubuntu 20.04
• Precice 2.2.0 installed using the .deb file for Ubuntu 20.04.
• CalculiX 2.16
• SU2 6.0.0
  I currently have a 2D SU2 mesh and I have a 3D CalculiX mesh which has only 1 element in the z-direction. So, I have set the following in my precice-config file.

<solver-interface dimensions="2">

But when I run CalculiX using the command

ccx_preCICE -i ramp -precice-participant Solid

I get the following error

Using quasi 2D-3D coupling
Set ID Found 
ccx_preCICE: adapter/PreciceInterface.c:559: PreciceInterface_ConfigureNodesMesh: Assertion `count == interface->num2DNodes && "Filtering of 2D nodes not done properly. Please make sure the out-of-plane axis is Z-axis"' failed.

But my CalculiX grid's out of plane axis is the z-axis. Do you have any suggestions on what I could be doing incorrectly? I have attached my case folder.
precice_25_degree_compression_ramp.zip

DisplacementDeltas not implemented for explicit coupling?

https://github.com/precice/calculix-adapter/blob/master/adapter/PreciceInterface.c

It seems like sim->coupling_init_v is only updated for implicit coupling (through Precice_WriteIterationCheckpoint), but never if only explicit coupling is used.

@arusch Are we overseeing something?

Thanks!

Use isTimeWindowComplete

See precice/precice#619

Remove appending index from readData and writeData labels

readData and writeData names are stored inside PreciceInterface.

calculix-adapter/adapter/PreciceInterface.h

Line 71 in 10938d8

enum CouplingDataType readData;

We have an array of interfaces to isolate these from getting mixed between interfaces.

calculix-adapter/adapter/PreciceInterface.c

Line 33 in 10938d8

sim->preciceInterfaces = (struct PreciceInterface**) malloc( sim->numPreciceInterfaces * sizeof( PreciceInterface* ) );

So from CalculiX itself, we don't need this index.

participants:

    ccx1:
        interfaces:
        - nodes-mesh: interface0
          patch: patch0
          read-data: [Read,AnotherRead]
          write-data: [Write,AnotherWrite]
        - nodes-mesh: interface1
          patch: patch1
          read-data: [Read,AnotherRead]
          write-data: [Write,AnotherWrite]

precice-config-file: ../precice-config.xml

And on the precice config side,

    <data:vector name="Read"  />
    <data:vector name="AnotherRead"  />
    <data:vector name="Write"  />
    <data:vector name="AnotherWrite"  />

    <mesh name="interface0">
      <use-data name="Read" />
      <use-data name="AnotherRead" />
      <use-data name="Write" />
      <use-data name="AnotherWrite" />
    </mesh>

    <mesh name="interface1">
      <use-data name="Read" />
      <use-data name="AnotherRead" />
      <use-data name="Write" />
      <use-data name="AnotherWrite" />
    </mesh>

Did I miss a case where we need the index to make things work?

Adapter does not work with CalculiX version 2.17

I tried building the adapter using CalculiX version 2.17 and it didn't work. With 2.16 everything is fine. According to the documentation I understand that the adapter should work with any version. At least there is no specific hint to a certain version in https://www.precice.org/adapter-calculix-get-calculix.html#get-the-source. However, the Makefile is specifically written for version 2.16:

calculix-adapter/Makefile

Line 5 in eadedee

CCX = $(HOME)/CalculiX/ccx_2.16/src

What's exactly the intended behavior?

• If only version 2.16 is supported, the documentation should be updated correspondingly and be more specific.
• If all versions should work, what I'm observing is a bug. I think additionally the Makefile should be designed in a more general way.

config.yml file name extension

In ccx_2.12.c the adapter default loads a precice.yml. Since precice files are XML files, it should default to precice.xml

Redesigning of CalculiX adapter which allows ''STATIC" step for FSI simulation

Hello,

I want to do a steady-state FSI simulation using CalculiX as solid solver. Currently the CalculiX adapter only allows a “DYNAMIC” step for FSI. Whereas for doing a steady-state FSI, I need to use a “STATIC” step in CalculiX. If I use the keyword “STATIC” in CalculiX input file, the following error is shown in Solid.log -
**ERROR: Only thermal coupling or FSI is available with preCICE**

So, what changes need to be made in the adapter to implement this new feature where the adapter allows a “STATIC” step as well ? Suggestions are requested to implement this feature.

facial distributed load for 2nd order element

Hi:

Just curious if I am using 2nd order element in Calculix for heat transfer, there will be three Gauss points in each face of the element, I wonder just provide the facial center value will be enough to integrate the facial flux in the Calculix adapter?

Best,
Yuxiang

Unified Makefile for non-PaStiX and PaStiX version

As of now, PaStiX is supported in a different Makefile. In the long run, we'd like to make it such that a unique Makefile (more maintainable ?) with a unique flag to decide whether or not we use the options necessary for using PaStiX.

Using a higher order finite element mesh is problematic

If the adapter is run with a case setup having higher order mesh elements, the higher order nodes get detected as physical nodes while defining the coupling boundary. For example consider the following mesh:

Here there are only four nodes along the Y axis. But if the mesh element type he20:

is defined, then the coupling boundary shows seven nodes along the Y axis. This means that in addition to the four physical nodes, additional three higher order nodes are also detected.

This is problematic and needs to be resolved by having some sort of filtering in the adapter. A similar situation arises while extracting nodes from a FEniCS mesh, and the FEniCS-Adapter handles the filtering here.

No support for missing write-data / read-data

Removing the write-data node (or defining write-data: []) seems to trigger a bad conversion:

About to enter preCICE setup in Calculix with names Calculix and config.yml 
Setting up preCICE participant Calculix, using config file: config.yml
terminate called after throwing an instance of 'YAML::TypedBadConversion<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >'
  what():  bad conversion

As a workaround, write-data: "" seems to pass, but then it fails with ERROR: There is no Mesh with ID:-1

Here is the respective code:

calculix-adapter/adapter/ConfigReader.cpp

Lines 65 to 81 in 73a9a06

	if( ( *interfaces )[i].numWriteData == 0 )
	{
	// write-data is a string
	( *interfaces )[i].numWriteData = 1;
	( *interfaces )[i].writeDataNames = (char**) malloc( sizeof( char* ) * ( *interfaces )[i].numWriteData );
	( *interfaces )[i].writeDataNames[0] = strdup( config["participants"][participantName]["interfaces"][i]["write-data"].as<std::string>().c_str() );
	}
	else
	{
	// write-data is an array
	( *interfaces )[i].writeDataNames = (char**) malloc( sizeof( char* ) * ( *interfaces )[i].numWriteData );
	for( int j = 0 ; j < ( *interfaces )[i].numWriteData ; j++ )
	{
	( *interfaces )[i].writeDataNames[j] = strdup( config["participants"][participantName]["interfaces"][i]["write-data"][j].as<std::string>().c_str() );
	}
	}

It looks like we always ask for at least one writer.

This essentially means that currently the CalculiX adapter does not support one-way coupling due to some configuration reading issue that could easily be solved.

Use markActionFulfilled

See precice/precice#631

CalculiX installation Makefile

I have installed all the dependencies using the conventional apt install method:

sudo apt install libarpack2-dev libspooles-dev libyaml-cpp-dev

Now when opening the makeFile in calculix-adaper I see this:

CCX             = $(HOME)/PathTo/CalculiX/ccx_2.16/src
# Path to SPOOLES main directory (e.g. $(HOME)/SPOOLES.2.2 )
SPOOLES         = $(HOME)/PathTo/SPOOLES
# Path to ARPACK main directory (e.g. $(HOME)/ARPACK )
ARPACK          = $(HOME)/PathTo/ARPACK
# Path to yaml-cpp prefix (e.g. $(HOME)/yaml-cpp, should contain "include" and "build")
YAML            = $(HOME)/PathTo/yaml-cpp

I did try to find the installation pathes for all these dependencies but I had problems finding arpack installation path. Any workaround to use the already-installed packages in the Makefile instead of giving them the pathes?

Extend adapter to also handle 2D interfaces

Currently the adapter only works with 3D coupling interfaces, meaning ...

calculix-adapter/adapter/PreciceInterface.c

Line 379 in ad446eb

interface->dim = precicec_getDimensions();

... is 3.

For quasi-2D cases (a 2D mesh that is only extruded by one layer in span-wise direction), it can be beneficial to make CalculiX behave as a 2D solver (from preCICE perspective): if the other solver is 2D, or for numerical reasons (precice/tutorials#112).

In that cases, read forces need to be equally distributed to both mesh layers and displacements (to be written) need to be averaged. Span-wise coordinates should be dropped.

Furthermore, there should be an error message if preCICE is 2D, but the case isn't quasi-2D, but real 3D.

Requiring "Velocity" instead of "Velocities" breaks other adapters and schemes

At the line:

calculix-adapter/adapter/PreciceInterface.c

Line 780 in d4db584

else if ( startsWith( config->writeDataNames[i], "Velocity" ) )

it says the requirement is that the tag must start with "Velocity". Formerly the requirements was "Velocities". Since we're talking about nodes, some prefer plural. Can you make the requirement to be: if ( startsWith( config->writeDataNames[i], "Velocit" ) ) so both cases are covered?

small bugs with mapping2D3D in case of mesh between 0 and H

Hello everyone,
Thanks a lot for your incredible work.

I found small bugs with mapping2D3D. In the following i consider that the 2D3D direction is z.

First, the mapping2D3D requires one side of the mesh to be z = 0. I did not find an explanation on this point in the documentation. Maybe it can be specified somewhere.
Secondly, the mapping2D3D requires the mesh to be between z = -H and z = 0. If the mesh is between z = 0 and z = H, there is a problem with the mapping. The simulation runs but the mapping is false. A workaround is to modify the preciceInterface.c :

diff --git a/adapter/PreciceInterface.c b/adapter/PreciceInterface.c
index b5d718b..7446e72 100644
--- a/adapter/PreciceInterface.c
+++ b/adapter/PreciceInterface.c
@@ -568,7 +568,7 @@ void PreciceInterface_ConfigureNodesMesh( PreciceInterface * interface, Simulati
             isDoubleEqual(interface->nodeCoordinates[ii*dimCCX + 1], interface->nodeCoordinates[i*dimCCX + 1]) &&
             !isDoubleEqual(interface->nodeCoordinates[ii*dimCCX + 2], interface->nodeCoordinates[i*dimCCX + 2]))
         {
-          if ( !isDoubleEqual(interface->nodeCoordinates[i*dimCCX + 2], 0.0) )
+          if ( !isDoubleEqual(interface->nodeCoordinates[ii*dimCCX + 2], 0.0) )
           {
             interface->mapping2D3D[i] = count;
             interface->mapping2D3D[ii] = count;

I think we can easily found a better solution to support both cases. If you want i can propose a patch to do it.

And again, I did not found an explanation on this point in the documentation. Maybe it can be specified somewhere.

Thank you again for your very nice work,

Cyrille

Inconsistent lookup for read/write data in CHT and FSI

For temperature and heat flux, we are checking whether the field name is exactly matched in the config:

calculix-adapter/adapter/PreciceInterface.c

Line 624 in 4496e8f

if (isEqual(config->readDataNames[i], "Temperature")) {

For other fields, we are checking whether the field name just starts with this prefix (similar behavior as in the OpenFOAM adapter), sometimes with a trailing -, sometimes without:

calculix-adapter/adapter/PreciceInterface.c

Line 37 in 4496e8f

precicec_createSolverInterface(participantName, adapterConfig.preciceConfigFilename, 0, 1);

calculix-adapter/adapter/PreciceInterface.c

Line 654 in 4496e8f

} else if (startsWith(config->readDataNames[i], "Displacement")) {

Additionally, data names are hard-coded for preCICE:

calculix-adapter/adapter/PreciceInterface.c

Line 628 in 4496e8f

interface->temperatureDataID = precicec_getDataID("Temperature", interface->nodesMeshID);

Finally, this error message is rather confusing:

calculix-adapter/adapter/PreciceInterface.c

Line 662 in 4496e8f

printf("ERROR: Read data '%s' does not exist!\n", config->readDataNames[i]);

"Does not exist" made me think that I still needed to specify it somewhere. However, it just means that the adapter does not know how to handle it.

Add more supported elements to CHT simulations

As of now, CHT simulations (more generally, simulations needing element face centers instead of nodes) only work with tetrahedrons. (Probably only first order tetrahedrons but I haven't tested)
Using different elements (Say brick hexaedrons elements) crashes with no explicit messages but a segfault.

This part is problematic:

calculix-adapter/adapter/PreciceInterface.c

Lines 466 to 472 in 4496e8f

	if (config->facesMeshName) {
	interface->faceCentersMeshName = strdup(config->facesMeshName);
	// Only configure a face center mesh if necesary; i.e. do not configure it for FSI simulations, also do not configure tetra faces if no face center mesh is used (as in FSI simulations)
	PreciceInterface_ConfigureFaceCentersMesh(interface, sim);
	// Triangles of the nodes mesh (needs to be called after the face centers mesh is configured!)
	PreciceInterface_ConfigureTetraFaces(interface, sim);
	}

• Function PreciceInterface_ConfigureFaceCentersMesh assumes tetrahedrons but should be adaptable +/- easily, as it calls a subroutine getTetraFaceCenters which is tetrahedron-specific
• PreciceInterface_ConfigureTetraFaces seems to be only required for connectivity but is always called (why?). This code is of course quite specific to the geometry.

I'd like to try to improve that in the near future, but I'm not 100% sure of the best approach:

• How do we detect element type ? Should we dive deeper into CalculiX code to detect each element and treat it accordingly ?
• Should we instead have only one type of elements (tetra or hexa) allowed (in the sense of "no mix") ? If so, is it detectable automatically, or should we add this as an option in the config.yml file?
• What about higher order elements ? wedge elements ? Supporting all elements could be complex.
• For connectivity, I read that supporte for quad elements on the interface is experimental. Is it safe to use ?

Fix broken implicit coupling when using modal dynamic simulations.

Since #91, the adapter supports modal dynamic simulations. (Where we use pre-computed eigenmode decomposition to speedup the computations by projecting forces into these modes and solving harmonic oscillators)
However, this functionality was designed with explicit coupling in mind and doesn't work with implicit coupling. It seems null displacements are generated. I added a warning message until we fix this.

CalculiX Restart Errors

I have found that CalculiX contains an error in dynamic mode on restart where the restarted results will not match identically to a non-restarted run. This is fundamentally a CalculiX issue due to a prediction step involving accelerations, which are not saved in the restart files.

• I have fixed this error in a fork of CalculiX: https://github.com/vollmerb/ccx
• I have updated those fixes to a fork of the calculix-adapter: vollmerb@7bc9756

With these fixes, the coupled restarts are identical to a non-restart (in my tests) to the ~14th digit, as opposed to ~5th digit. The lingering error is likely due to a final results evaluation on exit, but is sufficiently close to double precision in my estimation.

The issue here is the fixes require the updated CalculiX repository and the precice adapter. The CalculiX github repository appears unofficial, and I have mentioned my restart issue on the discourse group (https://calculix.discourse.group/t/restart-failures-dynamic/623).

Does anyone have suggestions/ideas on how to incorporate this fix more permanently?

Error solving the tutorial: flap_perp/OpenFOAM-CalculiX

I have installed both OpenFOAM and Calculix adapters without errors. Now when I run the Flap case I get the following error in the fluid terminal:

---[precice] ERROR:  The interpolation matrix of the RBF mapping from mesh Fluid-Mesh-Faces to mesh Solid is not invertable. This means 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?

OpenFOAM version is 7.0. I first run runFluid script and in another terminal I run runSolid script.

Redesign adapter to be used in all tutorial cases in new restructured format

Currently the adapter only supports certain quantities for reading and similarly for writing. Additionally certain quantities are required to be defined on the face-center vertices mesh and some quantities are required to be defined on nodes- mesh. One example is the definition of Sink-Temperature on a face-center mesh and Temperature on a nodes- mesh.
This design needs to be reviewed and reworked on in the view of the restructuring of the tutorial cases. This is brought to light by precice/tutorials#154 which shows that the existing CalculiX-Adapter cannot be used directly.

#49 added the handling of 2D cases to the adapter. This was also a quick fix for the tutorials restructuring and a proper redesigning needs to be done to clean up the adapter code and improve readability.

Issues when running make in calculix-adapter-master

Hello! I am new to GitHub, so I apologise if I am not formatting the question properly.
I am trying to build CalculiX using the make command in calculix-adapter-master, but i ran into the following error:

collect2: error: ld returned 1 exit status
Makefile:101: recipe for target 'bin/ccx_preCICE' failed
make: *** [bin/ccx_preCICE] Error 1

How should I go ahead to fix this?

Thank you!

Makefile: -lmpi_cxx should not be needed

calculix-adapter/Makefile

Line 33 in 7db6969

-lmpi_cxx \

Moreover, this line may create problems when libmpi_cxx is not installed (rare cases).

I open this issue as a hint for people that may run into this problem. Please also try building without this line and let us know if you have any problems.

I suggest that we remove this line and revert the change if anyone complains.

Prepare adapter for full integration

Goal: inline in the actual ccx code using #ifdefs

Note: I copied this issue from our internal list of todos to make it more visible. Please feel free to directly edit the header, if you can provide more details on the rationale behind this approach. I guess that one reason is that maintaining the Makefile of this adapter is painful, but I'm overview of the CalculiX adapter.