When the adapter was created, it was a good idea to come up with a shared format among different adapters. Due to some technical and usability issues, we then decided to change to solver-native formats.

If possible, we should provide all the configuration for the adapter either via config.comm or via a new .comm file (e.g. precice.comm or precice-adapter-config.comm).

Extend to also clean log files, preCICE address files, and any other leftovers.
See e.g. https://github.com/precice/tutorials/blob/develop/FSI/flap_perp/OpenFOAM-CalculiX/Allclean

I am trying to rerun our code_aster case, and I am getting a cryptic AssertionError from cyprecice.pyx, line 533 from set_mesh_vertices (bindings v2.2.0.1). Is this again related to wrong type? Is this the same known issue for missing an error message (precice/python-bindings#74)? I am just wondering because this code was working around a year ago.

!  in configure                                                                     !
   !     self.setVertices()                                                            !
   !    File "/home/vagrant/code_aster/14.6/lib/aster/Execution/adapter.py", line 190, !
   !  in setVertices                                                                   !
   !     self.preciceNodeIndices =                                                     !
   ! self.precice.set_mesh_vertices(self.preciceNodesMeshID,  self.nodeCoordinates)    !
   !    File "cyprecice/cyprecice.pyx", line 533, in                                   !
   ! cyprecice.Interface.set_mesh_vertices                                             !
   !  AssertionError                                                                   !
   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

This is the line that triggers it:

https://github.com/precice/code_aster-adapter/blob/master/cht/adapter.py#L34

I am using code_aster 14.6, even though previously we were using 14.4, but this should only be related to the adapter and the bindings. @BenjaminRodenberg @IshaanDesai is there a nice way to convert the given data type to the expected one?

If the output for Code_Aster is enabled, the coupling will crash because Code_Aster is writing a result file. The Code_Aster output should be improved, such that it doesn't interfere with the coupling process.

Hardcoded paths are found in

• tutorials/buoyantSimpleFoam-aster/config.comm
• tutorials/buoyantSimpleFoam-aster/config.yml.org
• tutorials/buoyantSimpleFoam-aster/solid/solid.export

Resolve this by importing the paths from the environment. Document which paths the user must specify for example in the bashrc, and import paths from there.

The coupling works without this file, it is not necessary in any way.

For some reason that we currently don't understand, the exchange-dir is not set correctly to the same values in the respective OpenFOAM-Code_Aster tutorial, requiring us to do something like:

<!-- TODO: Give an absolute path for the exchange-directory, as Code_Aster starts in /tmp/ -->
- <m2n:sockets from="Fluid" to="Solid" exchange-directory="/path/to/tutorials/CHT/flow-over-plate/buoyantSimpleFoam-aster"/>
+ <m2n:sockets from="Fluid" to="Solid" exchange-directory="/home/tester/tutorials/CHT/flow-over-plate/buoyantSimpleFoam-aster"/>

(both . and .. don't work).

I will have a look on this issue.

The main adapter file is currently cht/adapter.py. We should:

• Rename the adapter to something that points to preCICE, for example precice.py.
• Move it to the main directory, unless we have any good reason not to. An important design decision would be if we:
  1. implement FSI in the same file as CHT (preferably, if simple)
  2. split CHT and FSI in a similar way as in the OpenFOAM adapter (preferably, if complex)
  3. provide completely different adapters for CHT and FSI
• Update the documentation respectively.

@uekerman what do you think about the name? Is there a good reason to keep this directory structure?

Hi all, great work and great incentive.

I would love to collaborate on OpenFOAM / Aster coupling. I have an in-house quick and dirty script that does FSI with Aster and OpenFOAM, but the good thing is that all the cell projection and interpolation is done. I started looking at the documentation but it is a bit complex as is. Is anyone willing to give me a little help on precice development ?

Thanks !

This is probably also valid for Ubuntu 22.04.

Building code_aster 14.6.0 (stable) is currently not possible due to a row of issues.

import imp

The setup script and some dependency python scripts use the deprecated and now removed import imp. As the dependencies are nested in archives, patching isn't easy.

Workaround for me was to add the following to the /lib/python3.12/sitecustomize.py the usercustomize.py would be less invasive though:

import importlib
import sys
sys.modules['imp'] = importlib

mumps

This dependency has a row of Error: Type mismatch in argument errors in file mpi.f.
export FCFLAGS=-fallow-argument-mismatch solves this issue

mfront

This dependency has missing type errors in C++ files.

tfel

A massive amount of no type named X and X is not member of std errors.
Also access to struct members which aren't found

There are a few hardcoded lines that are specific to the local system on which the Code_Aster adapter is run in solid/solid.export. Although the solid.export should be generated using astkl, the hardcoded lines in solid/solid.export can and should be removed.

• Figure out which lines exactly can be left out without breaking the adapter.
• Document the generation of this solid/solid.export file with astk.

See the migration guide.