error (divergence) solving for Pressure

[Ruonan]

Dear Code_Saturne Team,

Could you please help me with this error?

I am running a new case using the new feature version 7.1. But one error occurred at the first time step: Flexible Conjugate Gradient: error (divergence) solving for Pressure

Code: Select all

Conjugate Gradient [Pressure:coarse:10]: divergence after 142 iterations:
  initial residual:  8.3927e+00; current residual:  1.0299e+05

Flexible Conjugate Gradient [Pressure]: divergence after 205 iterations:
  initial residual:  2.9481e-04; current residual:  1.3534e+02

Flexible Conjugate Gradient [Pressure]: divergence
  fallback from Multigrid to Jacobi (diagonal) preconditioning
  for re-try and subsequent solves.

Flexible Conjugate Gradient [Pressure]: divergence after 656 iterations:
  initial residual:  2.9481e-04; current residual:  1.0228e+02

/home/ruonanwang/code_saturne_7.1.0/code_saturne-7.1.0/src/alge/cs_sles_it.c:4874: Fatal error.

Flexible Conjugate Gradient: error (divergence) solving for Pressure

In the forum I can only find one same error, reported in a recent post, viewtopic.php?f=2&t=2863. Following the sggestions in that post, I checked my mesh quality in run_solver.log, which is good.

I tried all 4 different "Gradient reconstruction type", I also tried to initialize with the inlet velocity and temperature, but all ended up with this same error.

I wonder if you know what might cause this error and the possible solutions?

The log, xml and subroutines used are attached. The mesh is too large to upload but here is a link to download it. Thank you very much!

https://drive.google.com/file/d/10fPEZg ... sp=sharing

Best regards,
Ruonan

[Yvan Fournier]

Hello,

At least from the logs, the mesh quality seems mostly OK (I did not download it), I would suspect either a too large time step, a too strong explicit momentum source term, or perhaps some incompatible boundary conditions (such as a wall inside the domain, or any combination of boundary conditions making the incompressibility hypothesis impossible to follow).

Did you try running the case without user-defined sources ? And adding those sources step by step ?

Regards,

Yvan

[Ruonan]

Hello Yvan,

Thank you very much. Following your kind comments, I did some experiments:

1. First, I removed the source term subroutine, but ended up with the same error: divergence pressure.

2. Then, I decreased the timestep by a factor of 1000, from 1.9E-4s to 1.9E-7s, but again ended up with the same error.

I'm not sure if there is something wrong with the boundary condition. I tried the same BC using the same mesh in ANSYS CFX, it can run.

Now I set mass flow rate at inlet and pressure at outlet. I tried to set inlet velocity instead of mass flow rate, but end up with the same error.

Do you think it is worth trying to set pressure boundary condition at inlet? Or are there any other possible reasons for this divergence?

Best regards,
Ruonan

[Yvan Fournier]

Hello,

Using such a small time step should not be necessary. I suspect a difference in handling of boundary conditions.

As I mentioned in my previous answer, you seem to have interior boundary faces.

Did you visualize the mesh (using cuts or tranparencies) when checking it ? Did you check the preprocessor.log file ?
It contains the explanation to your crash :

Warning
=======
The CGNS mesh read contains multizone ("one to one")
vertex equivalences which are not automatically handled
by the Preprocessor.
-> Use an appropriate joining option

Simply looking at the run_solver.log ,you can also probably see that some groups which should be interior faces are still boundary faces. So you need to add joining.

Regards,

Yvan

[Ruonan]

Hello Yvan,

Thank you very much for pointing out the mesh problem. At first I thought it was a warning, not an error, so I ignored it.

Now I solved it. The original mesh was structured with multiple zones. I used Pointwise to join all the zones into one unstructured zone, then exported it. Then the mesh warning disappeared, and the case can run smoothly.

Thank you for your great help, Yvan.

Best regards,
Ruonan

[Yvan Fournier]

Hello,

in a sense, it is a warning, since you can also do the joining directly in code_saturne. But if you do nothing, it can lead to an error.

This is difficult to automate, because CGNS allows many different ways of storing mesh adjacency information, and supporting them all would require extra resources, which might be better used for other development work. Though as usual all feedback is welcome, as it helps prioritize things.

Best regards,

Yvan

[Ruonan]

Thank you Yvan! This is new knowledge for me.

Best regards,
Ruonan