Floating point exception while using parallel-explicit coupling scheme for two different interfaces

Official adapters and tutorials
,
1

Dear All,

I am attempting to couple three regions for heat conduction using the preCICE adapter. For each region, I am solving the heat conduction equation in OpenFOAM. However, during the simulation, I encounter a floating-point exception error with the parallel explicit scheme. I have also tried using the parallel implicit scheme, but without success. Using the multi-coupling scheme, the system was running with the following conductivities: 1 for the bottom region, 10 for the middle region, and 100 for the top region, and the simulation was converging. Once the conductivities of the middle and top regions were exchanged, the system did not converge and showed a floating-point exception. Can anyone please help me rectify this?
precice-config.xml (7.4 KB)

Thank you.
precice-config.xml (3.7 KB)

precice-config.xml (4.6 KB)
explicitparallel.zip (4.1 MB)
implicitParallel.zip (951.2 KB)

2

For such a scenario, a multi coupling scheme is the right way to go.
Read more here why combining several bi-coupling schemes might not work: A plug-and-play coupling approach for parallel multi-field simulations | Computational Mechanics

To get your failing case to work, I would try to swap the boundary conditions from Dirichlet-Neumann to Neumann-Dirichlet.

More on these coupling conditions: Verstraete and Scholl 2016

A student thesis that used a similar multi-field CHT setup: Numerical Coupling between the Finite Volume Method and the Finite Element Method for Modeling the Turbulent Heat Transfer in an AFPM Machine — Eindhoven University of Technology research portal

Hope that helps already :crossed_fingers:

3

Dear Uekerman,

Thank you for your kind response. I have attached the converging test case. The convergence criteria should not depend on the conductivities of the materials, and a converging solution is desired for any combination of conductivities. The problem is equivalent to heat conduction in an inhomogeneous medium, which is known to be one of the simplest problems. Can you suggest the necessary adjustments in timestep or grid size for a converging solution? I have tried various boundary conditions (by interchanging Dirichlet and Neumann), but the system seems to be non-conserving for all combinations of different conductivities.
fluxTemperature.zip (483.9 KB)

4

Hi @dibyendu,

Can you elaborate? How do you observe that?

Note that you are using a nearest-neighbor mapping, which is the most simplistic one, and which could be generating significant error depending on the meshes you use.

5

Dear Makis,

Thank you for your response. The system I am studying consists of three regions: upper-solid, lower-solid, and fluid. Each region is assumed to be a two-dimensional sheet, perpendicular to the z-axis. The fluid region shares boundaries with both the upper-solid and lower-solid regions.

I have experimented with various combinations of read-data and write-data settings. For instance, when the fluid-mesh reads Temperature and writes Heat-Flux, the solid regions read Heat-Flux and write Temperature, and vice versa. Initially, I used heat conduction (laplacianFoam) for the fluid region in the simplest case.

However, I am encountering convergence issues when using different combinations of conductivities in these three regions. Although the system converges for certain conductivity combinations, it fails to converge for others. One case where convergence was achieved was previously uploaded to this discussion forum.

Could you please provide guidance on how to address these issues? Systems with only two regions have converged successfully, even in three dimensions and with various conductivity combinations. However, I am experiencing convergence challenges when dealing with more than one boundary.

Note: By “combination of conductivities,” I mean the different conductivity values used in the three different regions for each simulation.

6

The question is still a bit vague. Let me ask a different question, maybe it helps:

How does your case and (most importantly) the preCICE configuration differ from the one in the simplified heat exchanger tutorial? We also use multi-coupling there, but we couple one fluid with two solids, not three solids:

7

Dear Makis,

Thank you for your kind response. The problem I am attempting to address is analogous to the Heat Exchanger (Simplified) tutorial, with the distinction that, in my case, the intermediary fluid is also a solid. I have employed the basic type of Conjugate Heat Transfer (CHT) coupling at the interfaces. The issue I am encountering is that the system fails to converge for various combinations of thermal conductivities. I have initiated a discussion on this matter in a separate thread, which can be accessed via the following link: Convergence Issues in Multi-Coupling Scheme.

To streamline our discourse, I suggest we consolidate our conversation into a single thread.

8

Are you sure you set the initial condition under the ‘0’ file correctly? Especially your ‘type’ and ‘internalField’.

9

Thank you for your response. The necessary files are attached to this thread. I kindly request you to review them to identify the issues and guide me in resolving them. Your assistance would be greatly appreciated.

10

@dibyendu Not sure what the issue is, but I am trying to bring some relevant information to the surface. Maybe the issue becomes apparent to someone else.

This is how your preCICE configuration currently looks like, visualized:

precice-config
precice-config653×691 84.7 KB

Acceleration configuration:

      <max-iterations value="40" />
      <relative-convergence-measure limit="1.0e-5" data="Temperature" mesh="Fluid-lowerSolid-Mesh" />
      <relative-convergence-measure limit="1.0e-5" data="Heat-Flux" mesh="lowerSolid-Mesh" />
      <relative-convergence-measure data="Heat-Flux" mesh="Fluid-upperSolid-Mesh" limit="1e-5" />
      <relative-convergence-measure
        data="Temperature"
        mesh="upperSolid-Mesh"
        limit="1e-5" />
      <acceleration:IQN-ILS>
        <data mesh="Fluid-lowerSolid-Mesh" name="Temperature" />
        <data mesh="lowerSolid-Mesh" name="Heat-Flux" />
        <data name="Temperature" mesh="upperSolid-Mesh" />
        <data name="Heat-Flux" mesh="Fluid-upperSolid-Mesh" />
        <initial-relaxation value="0.01" />
        <max-used-iterations value="50" />
        <time-windows-reused value="8" />
        <filter type="QR2" limit="1e-3" />
      </acceleration:IQN-ILS>

Looking at the fluid-openfoam/precice-Fluid-iterations.log:

TimeWindow  TotalIterations  Iterations  Convergence  QNColumns  DeletedQNColumns  DroppedQNColumns  
     1      11      11       1      10       0       0  
     2      42      31       1      20      20       0  
     3      43       1       1      20      20       0  
     4      44       1       1      20      20       0  
     5      45       1       1      20      20       0  
     6      46       1       1      20      20       0  
...
  5194    5234       1       1      20      20       0  
  5195    5235       1       1      20      20       0

I think it is suspicious that after the second time window, it always takes one iteration. It also seems like every time window is converging.

Looking at the convergence log:

TimeWindow  Iteration  ResRel(Temperature)  ResRel(Heat-Flux)  ResRel(Heat-Flux)  ResRel(Temperature)  
     1       1              inf   1.00000000e+00              inf              inf  
     1       2   1.00000000e+00   9.90000000e-01   1.00000000e+00              inf  
     1       3   4.65484637e-01   6.39474296e-02   4.65484637e-01   1.00000000e+00  
     1       4   8.36829374e-02   6.16634129e-05   5.91097005e-02   6.54257136e-04  
     1       5   6.94841058e-02   1.71483305e-03   4.90230842e-02   4.82989472e-03  
     1       6   2.62703431e-03   8.67889403e-05   4.08458512e-03   2.01203375e-04  
     1       7   7.88433309e-05   9.14203344e-04   1.31189746e-04   1.91521046e-04  
     1       8   1.84460302e-04   1.60743230e-05   2.59511491e-04   8.70440890e-06  
     1       9   2.26766342e-05   5.85727836e-05   2.69340868e-05   1.24876849e-05  
     1      10   1.16792474e-05   7.12866156e-07   1.39805558e-05   1.34874121e-07

@dibyendu @uekerman Do you see something I don’t see?
My gut feeling tells me something is wrong with the acceleration (which data is accelerated on which mesh) or the convergence measures.

By the way, I am still a bit confused: you define upperSolid-Fluid-lowerSolid, but at the same time you write above:

You could also look into the partitioned heat conduction tutorials: Partitioned heat conduction | preCICE - The Coupling Library

By the way (again): is this case related to Configuring a Solid-Solid-Fluid CHT case in OpenFOAM?

11

Dear Makis,

I have successfully simulated the converging case for a system consisting of three regions: lower-solid, fluid, and upper-solid. Each region is modeled with heat conduction. This simple case was selected to verify the validity of the multi-coupling scheme.

In the first scenario, with conductivities set to 1 for lower-solid, 10 for fluid, and 100 for upper-solid, the system converges without issues. However, when the conductivities are swapped to 1 for lower-solid, 100 for fluid, and 10 for upper-solid, the system fails to converge.

I have attached the log files and a zip file of the test case for your review. Could you please suggest any necessary corrections?

Note: The fluid region is positioned between the lower-solid and upper-solid regions, and only heat conduction is considered for both solid and fluid regions as part of the validation test for the multi-coupling scheme.
nonConverging.zip (4.1 MB)
precice-Fluid-convergence.log (129.2 KB)
precice-Fluid-iterations.log (2.3 KB)

Could you please elaborate on what you mean by saying, “By the way, I am still a bit confused: you define upperSolid-Fluid-lowerSolid, but at the same time you write above:”? I would appreciate more details on the specific confusion you’re referring to.

12

Hello, I’m very interested in your case setup and would like to be able to discuss the issues with you, and since the two of us are using different versions of precice, I can’t directly modify and test in the file you uploaded. First of all, what I want to ask is: on what basis do you determine that the solution reaches convergence (does the temperature of each solver not change as the solution time increases?)；Then, for your problem of non-convergence of different thermal conductivity combinations, I think you can try to use type:mixed (the third type of boundary condition) at the interface of each solver, because I have encountered a situation where the interface temperature is not continuous when using the first and second boundary conditions, but I am still a novice to the setting of different boundary conditions, if you know it well, please introduce it to me in detail

13

Thanks for your message and for taking the time to engage with the case.

To clarify, I am studying heat conduction only—this is the simplest possible configuration used to validate a multi-coupling setup. The system consists of three regions:

  • Lower solid
  • Fluid (placed in the middle; although the name might be confusing, it is modeled purely with heat conduction)
  • Upper solid

The key requirement in this case is that temperature and flux continuity must be maintained at the interface between the regions.

As part of the validation, I successfully simulated a converging case with the thermal conductivities set to:

  • Lower-solid: 1
  • Fluid: 10
  • Upper-solid: 100

This setup converges without issues.

However, when I swap the conductivities to:

  • Lower-solid: 1
  • Fluid: 100
  • Upper-solid: 10

…the system fails to converge. If you check the convergence log file, you’ll see that the relative residuals oscillate instead of decaying, which indicates a non-converging behavior. This issue arises purely from interchanging the thermal conductivity values of the regions, while all other parameters and solver settings remain the same.

I have attached the relevant log files (precice-Fluid-convergence.log and precice-Fluid-iterations.log) as well as a .zip file (nonConverging.zip) containing the full test case setup for your review. If you have any insights or suggestions on how to address the convergence issue—perhaps in relation to boundary condition types or coupling settings—I would really appreciate your input.
Looking forward to your thoughts and suggestions.

Best regards,
Dibyendu

14

try to use type:mixed (the third type of boundary condition) at the interface of each solver

15

I’ve tried implementing a mixed boundary condition in my case setup. Initially, I modified only the boundary condition without changing the configuration files, but this resulted in errors that prevented the case from running.

In a second attempt, I modified both the precice-config.xml and the preciceDict files to reflect the mixed boundary setup. This configuration does run, but I’m now getting warnings during execution and the simulation still does not converge.

I’ve attached the latest version of the case files for your reference. Could you please help identify the necessary corrections to fix the errors/warnings and achieve convergence?
Uploading: mixed_nonConverging.zip…
mixed_nonConverging.zip (4.1 MB)

16

@dibyendu the last file you uploaded does not include the log files. I need these to be able to help.

I was just confused because I saw Fluid in some cases, but Solid in other cases. Maybe rename the participant to really refer to a partition heat conduction case.