# Another post on restarting for FSI simulation (FASTEST/CalculiX/preCICE)

**URL:** <https://precice.discourse.group/t/another-post-on-restarting-for-fsi-simulation-fastest-calculix-precice/2945>\
**Category:** Using preCICE\
**Tags:** calculix, fsi, restart\
**Created:** [May 28, 2026, 11:27am UTC](https://precice.discourse.group/t/another-post-on-restarting-for-fsi-simulation-fastest-calculix-precice/2945 "2026-05-28T11:27:34Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![gdenayer](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/gdenayer/32/1357_2.png) [@gdenayer](https://precice.discourse.group/u/gdenayer)\
**Post date:** [May 28, 2026, 11:27am UTC](https://precice.discourse.group/t/another-post-on-restarting-for-fsi-simulation-fastest-calculix-precice/2945/1 "2026-05-28T11:27:34Z")

</div>

Dear preCICE community,

I have a running FSI simulation using our CFD solver (FASTEST-3D) coupled with the CSD solver CalculiX via preCICE. The coupled simulation is stable and the results look physically reasonable. Since the test case is large and the flow is turbulent, the simulation will run for days or even weeks. Therefore, I need to use restart functionality.

- Our CFD solver has a restart capability, which works without issues.

- I found a way ([How to use \*restart? - #5 by Phonix - Model setup - CalculiX (official versions are on www.calculix.de, the official GitHub repository is at https://github.com/Dhondtguido/CalculiX).](https://calculix.discourse.group/t/how-to-use-restart/1656/5)) to use the restart function of CalculiX using two distinct `.inp` files. A first `.inp` file is used for the initial run, and a `.rout` file is created. I copy it to a `.rin` file, and then use a second `.inp` file to restart. This seems to work.

My question concerns restart support in preCICE. I am using the `initialize` tag in the `precice-config.xml`:

```
<exchange data="Forces" mesh="Structure_Nodes" from="FASTEST" to="Calculix" initialize="yes"/>
<exchange data="Displacements" mesh="Structure_Nodes" from="Calculix" to="FASTEST" initialize="yes"/>

```

Is there a solution for the following issues?

- Since no restart information is available for preCICE, the quasi-Newton algorithm is not properly initialized at the beginning of each restarted simulation. Consequently, the FSI simulation requires more coupling iterations at the beginning.

- All results/files written by preCICE start again from time 0 after each restart.

Thanks in advance for your comments/ideas!

Best regards,

Guillaume

---

<div class="post-metadata">

**Author:** ![gdenayer](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/gdenayer/32/1357_2.png) [@gdenayer](https://precice.discourse.group/u/gdenayer)\
**Post date:** [June 1, 2026, 11:04am UTC](https://precice.discourse.group/t/another-post-on-restarting-for-fsi-simulation-fastest-calculix-precice/2945/2 "2026-06-01T11:04:10Z")

</div>

**More info:**

- FSI simulations using quasi-Newton methods are not restarting correctly, since the information from previous time steps is lost after restart. It would be great to store this information in a file and reload it when restarting.

- FSI simulations using a constant relaxation method should work, since no information from previous time steps is required. Am I wrong here? In my case, I observed a jump in the time-dependent results just after restart, so something seems to be going wrong.

**What about the mapping after a restart?**

- In a simulation without restart, the mapping is initialized based on the initial (undeformed) meshes.

- In a simulation with restart, should the mapping after restart be computed using the meshes as they are at the restart point, i.e., already deformed meshes or using the undeformed meshes. This point could explain the differences I am observing in FSI simulations using constant relaxation, couldn’t it? How is it done in the OpenFOAM adapter?

- In the CalculiX adapter it seems that the current/deformed mesh is sent after restart. See CCXHelpers.c:

```cpp
void getNodeCoordinates(ITG *nodes, ITG numNodes, int dim, double *co, double *v, int mt, double *coordinates)
{
  ITG i, j;

  for (i = 0; i < numNodes; i++) {
    int nodeIdx = nodes[i] - 1;
    // The displacements are added to the coordinates such that in case of a simulation restart the displaced coordinates are used for initializing the coupling interface instead of the initial coordinates
    for (j = 0; j < dim; j++) {
      coordinates[i * dim + j] = co[nodeIdx * 3 + j] + v[nodeIdx * mt + j + 1];
    }
  }
}

```

---

<div class="post-metadata">

**Author:** ![gdenayer](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/gdenayer/32/1357_2.png) [@gdenayer](https://precice.discourse.group/u/gdenayer)\
**Post date:** [June 4, 2026, 12:25pm UTC](https://precice.discourse.group/t/another-post-on-restarting-for-fsi-simulation-fastest-calculix-precice/2945/3 "2026-06-04T12:25:00Z")

</div>

I can confirm that the current CalculiX adapter sends the deformed mesh after a restart.

In my case, I do not want this behavior. I want both solvers to send the original undeformed meshes in order to obtain the same mapping after restart.

I slightly modified the CalculiX adapter in the following way:

I added a new function in `adapter/CCXHelpers.c`:

```cpp
void getInitialNodeCoordinates(ITG *nodes, ITG numNodes, int dim, double *co, double *coordinates)
{
  ITG i, j;

  for (i = 0; i < numNodes; i++) {
    int nodeIdx = nodes[i] - 1;

    // coordinates of the undeformed mesh
    for (j = 0; j < dim; j++) {
      coordinates[i * dim + j] = co[nodeIdx * 3 + j];
    }
  }
}

```

I replaced the call to `getNodeCoordinates` with `getInitialNodeCoordinates` in `PreciceInterface_ConfigureNodesMesh`:

```cpp
void PreciceInterface_ConfigureNodesMesh(PreciceInterface *interface, SimulationData *sim)
{
// printf(“Entering configureNodesMesh \n”);
char *nodeSetName = toNodeSetName(interface->name);
interface->nodeSetID = getSetID(nodeSetName, sim->set, sim->nset);
interface->numNodes = getNumSetElements(interface->nodeSetID, sim->istartset, sim->iendset);
interface->nodeIDs = &sim->ialset[sim->istartset[interface->nodeSetID] - 1]; // Lucia: make a copy

interface->nodeCoordinates = malloc(interface->numNodes * interface->dimCCX * sizeof(double));

getInitialNodeCoordinates(interface->nodeIDs, interface->numNodes, interface->dimCCX, sim->co, interface->nodeCoordinates);

// If 2D-3Q coupling is used (for a node mesh) delegate this to the specialized data structure.
if (interface->nodesMeshName != NULL) {

if (isQuasi2D3D(interface->quasi2D3D)) {
  interface->mappingQuasi2D3D = createMapping(interface->nodeCoordinates, interface->numNodes, interface->nodesMeshName);
} else {
  interface->preciceNodeIDs = malloc(interface->numNodes * sizeof(int));
  precicec_setMeshVertices(interface->nodesMeshName, interface->numNodes, interface->nodeCoordinates, interface->preciceNodeIDs);
}

}

if (interface->mapNPType == 1) {
assert(!interface->quasi2D3D && “Quasi 2D - 3D configuration does not work for nearest-projection mapping”);
PreciceInterface_NodeConnectivity(interface, sim);
}
}

```

This does not resolve all issues I encounter during a restart of an FSI simulation with preCICE/CalculiX, but it helps somewhat.

---

<div class="post-metadata">

**Author:** ![uekerman](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/uekerman/32/2199_2.png) [@uekerman](https://precice.discourse.group/u/uekerman)\
**Post date:** [June 5, 2026, 1:41pm UTC](https://precice.discourse.group/t/another-post-on-restarting-for-fsi-simulation-fastest-calculix-precice/2945/4 "2026-06-05T13:41:34Z")

</div>

Hi @gdenayer 👋

Interesting questions and good observations. Could you share your preCICE configuration? Restarting will depend on which participant is first and which is second, and the coupling scheme + initialization.

> [@gdenayer](#):
>
> - Since no restart information is available for preCICE, the quasi-Newton algorithm is not properly initialized at the beginning of each restarted simulation. Consequently, the FSI simulation requires more coupling iterations at the beginning.
> 
> - All results/files written by preCICE start again from time 0 after each restart.

Both features are currently not available in preCICE. They existed in an agent version and could be added again.

> [@gdenayer](#):
>
> - FSI simulations using quasi-Newton methods are not restarting correctly, since the information from previous time steps is lost after restart. It would be great to store this information in a file and reload it when restarting.
> 
> - FSI simulations using a constant relaxation method should work, since no information from previous time steps is required. Am I wrong here? In my case, I observed a jump in the time-dependent results just after restart, so something seems to be going wrong.

Quasi-Newton should likewise start with an underrelaxation step again. Sounds like sth is wrong with data initialization, either in the config or in any of the adapters.

> [@gdenayer](#):
>
> - In a simulation with restart, should the mapping after restart be computed using the meshes as they are at the restart point, i.e., already deformed meshes or using the undeformed meshes. This point could explain the differences I am observing in FSI simulations using constant relaxation, couldn’t it? How is it done in the OpenFOAM adapter?

My guess is that both are possible. I am not sure how regularly the OpenFOAM adapter is tested in setups involving restarts.

Thanks for sharing the code! Would be great if you could also open a PR. This sounds like sth, we could make configurable.

---

<div class="post-metadata">

**Author:** ![gdenayer](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/gdenayer/32/1357_2.png) [@gdenayer](https://precice.discourse.group/u/gdenayer)\
**Post date:** [June 5, 2026, 2:31pm UTC](https://precice.discourse.group/t/another-post-on-restarting-for-fsi-simulation-fastest-calculix-precice/2945/5 "2026-06-05T14:31:50Z")

</div>

* * *

Hi Benjamin,

I’ve attached two configuration files: one with constant underrelaxation and one using IQN-ILS.

[precice-config\_hangar\_test\_open\_serial-implicit\_cst-rlx\_ruk3.xml](https://precice.discourse.group/uploads/short-url/1aTIbr7BHfMwXp0u9RlTSpMCX9x.xml) (4.4 KB)

[precice-config\_hangar\_test\_open\_parallel-implicit\_IQN-ILS\_ruk3.xml](https://precice.discourse.group/uploads/short-url/w8VvxlxKxYClXqrOVBin98lPTYd.xml) (4.9 KB)

After restarting, the fluid forces sent by the CFD solver to preCICE for initialization perfectly match the fluid forces from the last time step. The displacement sent by the CSD solver (CalculiX) also matches perfectly. But the integrated fluid forces computed by the fluid solver oscillates after restart.

Do you see any issues in my preCICE configuration files?

Thanks!

---

<div class="post-metadata">

**Author:** ![uekerman](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/uekerman/32/2199_2.png) [@uekerman](https://precice.discourse.group/u/uekerman)\
**Post date:** [June 6, 2026, 9:23am UTC](https://precice.discourse.group/t/another-post-on-restarting-for-fsi-simulation-fastest-calculix-precice/2945/6 "2026-06-06T09:23:43Z")

</div>

I don’t see any obvious issues in the configuration.

What you could try (if not already done) is to further decrease the (initial) relaxation.

What I could also imagine is that there is still a fundamental issue with time stepping somewhere that only shows up during the extreme conditions of a restart, but not at the normal soft start. What time-stepping method does FASTEST use, and where do you sample the read data from preCICE? Similarly, we should look at these details in CalculiX. Which time-stepping method are you using there?

---

<div class="post-metadata">

**Author:** ![gdenayer](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/gdenayer/32/1357_2.png) [@gdenayer](https://precice.discourse.group/u/gdenayer)\
**Post date:** [June 8, 2026, 6:39am UTC](https://precice.discourse.group/t/another-post-on-restarting-for-fsi-simulation-fastest-calculix-precice/2945/7 "2026-06-08T06:39:11Z")

</div>

On the CFD solver side, I don’t think there is an issue. We have been using restarts for years without any problems. The CFD solver uses either an explicit time-stepping scheme (Runge-Kutta) or a second-order implicit backward scheme. Therefore, two previous time steps are stored, which is sufficient for a restart. Restarting pure CFD simulations works without any issues, and restarting FSI simulations (EMPIRE/Carat) also works correctly.

On the CSD side, with CalculiX, I am currently investigating the problem. The time discretization scheme used is the HHT-alpha method. If I understand correctly, the displacement, velocity, and acceleration from the previous time step are required. However, it appears that only the displacement and velocity are stored in the restart file (assuming my understanding is correct). I checked the latest version of CalculiX (2.23), and the situation seems to be the same. I am continuing to investigate this aspect, as it may explain the oscillations observed in the results. It seems that I’m not the first to find that see

> <https://github.com/precice/calculix-adapter/issues/67>
>
> I have found that CalculiX contains an error in dynamic mode on restart where th…e 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: https://github.com/vollmerb/calculix-adapter/commit/7bc9756251ed534a2f7d3f280f7f302c47dd6cfb
> 
> 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?

---

<div class="post-metadata">

**Author:** ![gdenayer](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/gdenayer/32/1357_2.png) [@gdenayer](https://precice.discourse.group/u/gdenayer)\
**Post date:** [June 8, 2026, 12:13pm UTC](https://precice.discourse.group/t/another-post-on-restarting-for-fsi-simulation-fastest-calculix-precice/2945/8 "2026-06-08T12:13:04Z")

</div>

I implemented the corrections from [vollmerb (Blaine Vollmer) · GitHub](https://github.com/vollmerb) in both CalculiX 2.20 ([GitHub - gdenayer/CalculiX-2.20: This repository contains the source files of CalculiX 2.20 · GitHub](https://github.com/gdenayer/CalculiX-2.20)) and the adapter ([GitHub - gdenayer/calculix-adapter: preCICE-adapter for the CSM code CalculiX · GitHub](https://github.com/gdenayer/calculix-adapter)). The results are significantly improved:

- The oscillations previously observed in the fluid forces integrated over the deformed structure have disappeared.
- IQN-ILS now behaves as expected. During the first few time windows after a restart, additional FSI coupling iterations are required to achieve convergence. However, from the third time window onward, the number of FSI iterations returns to the same level as before the restart.

The fact that CalculiX does not save the acceleration field in its restart file is definitely an issue when restarting an FSI simulation.

---

<div class="post-metadata">

**Author:** ![gdenayer](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/gdenayer/32/1357_2.png) [@gdenayer](https://precice.discourse.group/u/gdenayer)\
**Post date:** [June 10, 2026, 11:34am UTC](https://precice.discourse.group/t/another-post-on-restarting-for-fsi-simulation-fastest-calculix-precice/2945/9 "2026-06-10T11:34:51Z")

</div>

Next issue with restart:

After the third restart, CalculiX hangs during the solution process. By investigating further in the code and logs, I found that CalculiX terminates with `-1` due to SPOOLES failing during factorization, as it cannot handle a singular matrix.

By comparing the CalculiX output at each restart, I noticed that the value in the line

> “terms in all multiple point constraints:”

increases at every restart by a constant amount.

This suggests that the number of scalar equations in the multiple point constraint (MPC) system is not being properly reset between restarts, but instead appears to accumulate. This likely leads to an over-constrained or inconsistent system, which results in a singular matrix during factorization.

Has anyone encountered this issue before? If so, how was it resolved?

---

<div class="post-metadata">

**Author:** ![gdenayer](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/gdenayer/32/1357_2.png) [@gdenayer](https://precice.discourse.group/u/gdenayer)\
**Post date:** [June 11, 2026, 1:30pm UTC](https://precice.discourse.group/t/another-post-on-restarting-for-fsi-simulation-fastest-calculix-precice/2945/10 "2026-06-11T13:30:03Z")

</div>

By comparing the last version of CalculiX 2.23 and the version of CalculiX used in the preCICE adapter (2.20) changes were made in allocation.f. Particularly these lines are relevant:

```fortran
 if(irstrt(1).eq.0) memmpc_=memmpc_+9*3*(3*8*ne2d+8*3*ne1d)

```

```fortran
 if(irstrt(1).eq.0) memmpc_=memmpc_+2*(3*8*ne2d+8*3*ne1d)

```

```fortran
 if(irstrt(1).eq.0) memmpc_=memmpc_+3*(3*8*ne2d+8*3*ne1d)

```

“if(irstrt(1).eq.0)” was added. This limits the increase of memmpc and the previous issue disappears.

---

<div class="post-metadata">

**Author:** ![Makis](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/makis/32/25_2.png) [@Makis](https://precice.discourse.group/u/Makis)\
**Post date:** [July 19, 2026, 8:18am UTC](https://precice.discourse.group/t/another-post-on-restarting-for-fsi-simulation-fastest-calculix-precice/2945/11 "2026-07-19T08:18:29Z")

</div>

@gdenayer thank you for the detailed logging, this is very useful documentation.

Does this mean that you can now correctly restart?

I started a (premature) section in the documentation of the CalculiX adapter recently, we should expand that: [Configure the CalculiX adapter | preCICE - The Coupling Library](https://precice.org/adapter-calculix-config.html#restarting)

And it is clear that the CalculiX adapter needs updates, which should be straight forward (compare the unmodified and modified calculix 2.20, then apply the same patches on the latest). There are a couple of bigger open PRs in the adapter that would hopefully be merged before we start the version upgrade.

---

<div class="post-metadata">

**Author:** ![gdenayer](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/gdenayer/32/1357_2.png) [@gdenayer](https://precice.discourse.group/u/gdenayer)\
**Post date:** [July 20, 2026, 7:45am UTC](https://precice.discourse.group/t/another-post-on-restarting-for-fsi-simulation-fastest-calculix-precice/2945/12 "2026-07-20T07:45:33Z")

</div>

Hi @Makis ,

I first created a fork of **CalculiX 2.20** :

> **[GitHub - gdenayer/CalculiX-2.20: This repository contains the source files of...](https://github.com/gdenayer/CalculiX-2.20)**
>
> This repository contains the source files of CalculiX 2.20

I also created a fork of the **preCICE CalculiX adapter** based on CalculiX 2.20:

> **[GitHub - gdenayer/calculix-adapter: preCICE-adapter for the CSM code CalculiX](https://github.com/gdenayer/calculix-adapter)**
>
> preCICE-adapter for the CSM code CalculiX

I had already encountered several issues related to the restart capability and managed to find/steal solutions for them:

- Initializing the preCICE mapping on the **undeformed** mesh instead of the deformed one.

- Storing and restoring the acceleration array.

- Storing and restoring the `xmodal` array when Rayleigh damping is used.

The restart now seems to work correctly in several test cases. However, I have run into a new issue.

At first, I thought the crashes were caused by the restart itself because they always occurred after restarting. After further investigation, it turns out that the crashes are actually triggered when CalculiX writes the results to the **.frd** file. The restart only exposed the problem.

Interestingly, the behavior depends on the shell element type:

- **S4 (linear shell elements) and S4R:** no issues at all. I can write results, restart the simulation, and everything works as expected.

- **S8 and S8R (quadratic reduced-integration shell elements):** I observe a sudden jump in the residual in the CalculiX log immediately after writing the `.frd` file (and also in my fluid forces on the CFD side as visible in the picture below). In the present case I run those simulations with Rayleigh damping, so these non-physical oscillations are rapidly damped out and the FSI simulations survive most of the time. Since my restart frequency (every 1000 time steps) is a multiple of my output frequency (every 500 time steps), the crash always appeared to be related to the restart. In reality, it is triggered by the `.frd` output.

 ![issue_calculix_writing_frd_S8R](https://global.discourse-cdn.com/free1/uploads/precice/original/2X/5/580c2405b04084623f1e81e6a95ace1113873ef9.png)

If I disable the `.frd` output, the problem disappears completely. 😕 Has anyone seen similar behavior or has an idea what could cause writing the `.frd` file to affect the solver state?