SQP: Error in DES_UNPACK_PARCROSS

MFiX
1

Hello Team,

I am running the heat transfer simulation with SQP particles. Earlier the simulation (without the energy equation) was okay, while the same case included the energy equation for the heat transfer case, showing DESMPI_UNPACK_PARCROSS: Unable to match particles crossing processor boundaries. Initially the simulation was converging, and after a few seconds, the simulation crashed and got this error. I have attached my case file along with the particles input file here. Kindly look at the case and suggest the possible cause of the error.

particle_input.csv (389.3 KB)

ar4sqp.mfx (16.4 KB)

2

Hi Gunjan @chz238191

Thanks for the report and your files. This case reveals several problems with the SQP and DMP code.

The first thing I’d like you to do is upgrade to the latest release (26.1.2). In this version, the PARCROSS error is gone, but there’s a new problem - when I ran your case I got

Error from check_convergence.f:266
Error 1000: NaN detected in residual:Energy equation, phase (0)

Tracking this down I found the following:

The parallel error message is a symptom. In serial the same case stops with NaN detected in residual: Energy equation. A particle temperature becomes NaN, and in a DMP run that surfaces as particles that cannot be matched across processor boundaries.

Cause. Your case sets e_young_actual, v_poisson_actual, ew_young_actual and vw_poisson_actual. These turn on the contact-area correction for particle-particle and particle-wall conduction. With the Hertzian collision model that correction is computed incorrectly: it inflates the overlap by a factor of 5 to 7 for particles of your size, even when the “actual” values equal the simulation values, as they do in your file. For SQP particles the conduction model also works on the bounding sphere (12.5 mm for your rods) rather than the particle surface. Together, the inflated overlap can exceed the sphere diameter, and the contact radius becomes the square root of a negative number.
There are also some bookkeeping issues with the DMP code (neighbor list and tangential history).

Fix. The attached patches are against the current (26.1) source. So upgrade to 26.1.2 before you do anything else. Then download the tarball, then do

   $ mv ~/Downloads/patches.tgz /tmp
   $ cd /tmp
   $ tar xfz patches.tgz
   $ cd $CONDA_PREFIX/share/mfix/src
   $ for p in /tmp/patches/000*.patch; do patch -p1 < $p; done

If you have trouble applying the patches, let me know.

After doing this you can rebuild the default solvers:

  $ cd $CONDA_PREFIX/bin
  $ build_mfixsolver -j; build_mfixsolver -j --dmp; build_mfixsolver -j --smp

Alternately you can build a custom solver in the project dir, but you will have to do this for each project

Here’s a breakdown of the patches:

  • 0001, 0002: the area correction and the invalid contact radius. These two stop the crash.
  • 0003, 0004, 0009: heat transfer for non-spherical SQP particles. Conduction now uses the contact geometry instead of the bounding sphere. Convection and radiation use the particle surface area, which is 127 mm² for your rods; the bounding sphere gave 492 mm².
  • 0007, 0008: contact forces and contact history for particles that cross a processor or periodic boundary. These affect any DMP run.
  • 0005, 0006: SQP with the linear spring-dashpot model, and GSP convection. Your case does not use either.

Workaround without patching. Delete the four *_actual keywords. Since they match your simulation values, the correction should have had no effect anyway. The run will then complete, but particle heating and cooling rates will be too high, because heat transfer is still based on the bounding sphere.

Please let us know how it goes with this!

– Charles

patches.tgz (23.1 KB)

3

just for fun:

4

Thank you for your suggestions. I will apply the patches and let you know if I encounter any issues.

5

In this case particles are going out of the domain at the top (BC: Pressure outflow), How can I get the particles back in the domain? As per an earlier suggestion, I have applied “bc_po_apply_to_des(2) = .True.” but it is not working at higher velocities (less than 3 Umf). The height of the domain is very large, almost 8-9 times the fixed bed height and the superficial gas velocity is less than 3Umf.

6

Once the particles leave the domain through a pressure outlet BC, you cannot get them back in the system without applying another mass inlet BC somewhere else. You can prevent them from leaving by setting bc_po_apply_to_des(2) = .False. (bc_po_apply_to_des(2) = .True. will le particles exit the domain). Since you start with a packed bed, you can also ramp up the bottom inlet velocity from zero to the 3Umf value to avoid lifting the bed as a plug, or start with a less dense bed.

7

Thanks @jeff.dietiker for the useful suggestion. To use the ramp bottom inlet, do I need to use the UDF function?

8

No, you can setup the ramp directly from the BC pane:

image
image863×693 75.2 KB

Click on the icon highlighted above and set the start and end values (time and velocity). Adjust to fit your needs.

9

Okay, thank you very much for the quick reply and valuable suggestions.

10

I have applied the patches and built the solver on my PC, and as of now, the simulation is running. How can I verify that the implementation is correct? How can I apply these patches to the HPC machine where I just load the modules and extract the source code and build the solver. This step is missing there: “cd $CONDA_PREFIX/share/mfix/src”.

11

You’d have to check with whoever set up the modules on your HPC. They are the ones who built the default modules there. In the meanwhile you can build a custom solver in your project dir and use that. You will have to do this for each project but this isn’t too bad.
As far as verifying, as long as the patch command didn’t produce any error messages or .rej files you should be OK.

12

Okay, got it. Thank you for the reply

13

Hello Team,

I have applied, bc_po_apply_to_des(2) = .False. This condition prevents the particles from leaving the domain. I have set the ramp velocity Umf at 0 s and after 1 s = 2.1 m/s . In a few seconds particles stick to the top, and after 12 s of simulation, they do not fall; eventually they should fall. What I should do to get the particles down.

12s
12s741×627 38.7 KB

14

Maybe the velocity is too large and it keeps pushing particles up, or the particles are too soft and they wedged themself at the top. What happens if you turn off the gas inlet, do they fall down?

15

Yes, after turning off the gas inlet, particles fall down but sometimes get an error, DT < DT_MIN. Recovery not possible! at low /0 gas velocity.