Pure granular flow diverging with Erroneous arithmetic operation

MFiX
#1

mfix_log.dat (779.8 KB)
Dear community,

I am running the attached case, a TFM (granular phase only) discharge from a hopper in 2D using cartesian grid with poly.dat.
With particle diameter of 0.01 m it runs fine, however if I decrease to 0.001 m or less the simulation crashes, specifically the problem occurs in the linear matrix solver subroutines (see attached log file). I have tried playing with the linear solvers, tolerances and/or internal iterations, discretization schemes, different degree of cartesian grid tolerances but nothing helped so far.
Does anyone have suggestions?

Thanks!
Fabio
poly.dat (134 Bytes)
unical_hopper_2D_poly.mfx (16.7 KB)

#2 
Warning: Could not find unical_hopper_pseudo_2D.stl.

Please attach the STL files for this case.

Note that if you use “Submit bug report” from the main menu, the ZIP file will automatically include all needed STL files.

#3

Please attach the correct poly.dat. The one you attached does not have the required header. Did you set this up in the GUI? Polygon geometry input is not supported in the GUI. It should still work at the command line.

#4

Hi,

The attached poly.dat is the correct one, I manage to run the case with mfix-23.1.1 in batch mode (I am not using the GUI version because it does not support poly.dat and I want to run a 2D simulation). I use 23.1.1 because I could not find the source code of the latest version (see https://mfix.netl.doe.gov/forum/t/where-to-find-the-source-code/5283.

I have an update. Activating the gas phase I managed to complete the simulation. So the issue seems to occur when disabling the gas phase.

Thanks
Fabio
Fabio

#5

Ok. I was trying to load this case in the current MFiX GUI and it failed because there are references to unical_hopper_pseudo_2d.stl in the .mfx file - you must have adapted this from a different case. MFiX source tarballs will be restored to the website, but note that if you install the mfix conda package, it includes the full mfix sources. If you don’t want to download and install the gui components and their dependencies, you can modify the download command to only include the mfix-gui=23.4.1 part.

– Charles

#6

Running in batch mode:

 **********************************************************************
 From: GET_POLY_DATA
 Message: Error while reading poly.dat file 
**********************************************************************
#7

Not sure why you get the error, it runs fine (a part from the error mentioned above), at least with v23.1.1

Fabio

#8

Yes I originally used a pseudo-2D simulation using a STL with GUI, but I then switched to a pure 2D simulation with poly.dat.

I try attaching the poly.dat again.

Fabio
poly.dat (134 Bytes)

#9

A valid poly.dat has a header like this:

image
image1078Ă—326 61.2 KB

Actual data starts at line 14. I don’t understand how it runs for you, it should trigger an error message as Charles is showing.

#10

Ah yes, now I recall (it’s been a while since I last used this option).
Anyway for some reason it runs with my version of mfix (I did not modify it a part for some debugging). But it may be that actually the geometry is not read properly.
I try again tomorrow with the proper header.

Thanks
Fabio

#11

Even though the MFiX GUI doesn’t have full support for poly.dat you can certainly setu up run such cases in the GUI, using the “Advanced” pane:
shot-2024-02-15_15-50-24

#12

Hi all,

I have to apologize.
For some reason I found out that actually a while ago I modified the source code to avoid reading the first 13 lines of the poly.dat file (maybe because I could not find an original poly.dat with the header). Anyway this does not change the issue whatsoever, it is just a matter of skipping lines… I attach the correct version of the poly.dat just in case.

Fabio
poly.dat (749 Bytes)

#13

Hi Fabio -

The file headers can be a bit of a pain - IMO it would be better if the header lines started with a comment character like # and all other lines were treated as data, rather than using a fixed line-count for the header. (The header contents doesn’t matter, of course, it just has to be the right # of lines.) I might make this change in a future version, but this is of course a pretty low priority.

#14

It doesn’t change the issue, but it saves time and energy trying to figure out if we are using the right file to reproduce the core issue.

You have conflicting Boundary Conditions because you define regular BCs along the MFiX box edges and you also use the poly data boundaries. Would be better to not have overlapping BCs but it still crashed when I took them out.

However, I can get it to run to completion if I turn of the pre-conditioner. I added

leq_pc(1:9) = 9*'NONE'

in the .mfx file.

1 Like
#15

Yes I am aware, which is why I apologized…

Anyway thanks for your help, indeed it works now.
I had other simulations of pure granular flows (but no cartesian grid) that showed similar convergence issues, now solved thanks to your suggestion.

Fabio