My model run time is set to 900 seconds, creating .vtp files every 0.001 seconds. Most of the time MFIX generates all 900,000 .vtp files, but sometimes only 899,958 files are created. Is there a reason it will be doing this?
I can think of two reasons:
- There are no particle in the vtk region at the time of writing the vtp file.
- The time step gets larger than the vtk time interval (DT>vtk_dt).
It’s a model where particles enter a container and leave again. There are 400 particles pre assigned into the container so there are always particles in the model.
If your second point is the issue how do I fix this?
I am currently running a sensitivity analysis changing friction coefficient and coefficient of restitution and if only occurs with some combinations of these parameters and not others.
Try either setting vtk_dt to a value larger than dt_max, or else set dt_max less than vtk_dt
To be sure, try either logging or plotting DT so you can see if this is the reason.
Logging Dt to a file:
Plotting Dt at runtime:
So my saving increments (vtk_dt) are 0.001s.
My time step (dT) is 1.0e-03
You have vtk_dt = dt but dt can change dynamically. What are your settings for dt_max and dt_min (in the Run panel).
Can you upload your input file?
Also, since dt and vtk_dt are equal, and numbers like 0.001 cannot be represented perfecty accurately in binary floating point, it’s possible that you are seeing the effect of some round-off error.
Thanks. In the future please also include any other needed inputs (particle_input.dat, etc) - you can use “Submit bug report” from the main application menu to create a zip file containing everything needed to run the case.
Upon loading the case, first thing I noticed was:
your starting dt is not between dt_min and dt_max, I’m not quite sure if this is causing your problem but it doesn’t seem right, we should probably add a check to the program to disallow this.
Without the particle input, I can’t fully replicate your results. If you send that file I’ll try again. One suggestion I do have is to check the logs and program output for messages of the form
WRITING VTP FILE : RP_DATA_0023.vtp ..
VTP file not written (zero particle in vtk region).
or any other mentions of VTP … this may help track it down.
– Charles
Apologies, I forgot I had pre-assigned the input.
It wont let me upload it in its standard form as it says the file type is not supported, but here is a link to it:
You can always create a zipfile and upload that (“Submit bug report” from main menu)
OK, I ran this and got 900000 vtp files.
x280:) ls|grep -c 'RP_DATA.*vtp'
900000
What parameters were you using when you saw fewer than 90000?
I will create a zip file and send over.
Like I said, sometimes it works and sometimes it doesn’t, but that doesn’t make sense to me hence the post on the forum.
2 of the combinations that definitely did not work are:
Friction 0.2, Restitution coefficient 0.3
Friction 0.2, Restitution coefficient 0.4
When the model finishes running there will only be 899,500ish files in the folder.
OK, I changed the friction and restitution coefficients to 0.2/0.3 as you suggested, and I can confirm that only 899835 VTP files are written.
In the future, please supply a complete and reproducible case when submitting problem reports - this will help us get to the solution faster.
With 0.2/0.3 for parameters, RP.LOG is showing
RP.LOG: VTP file not written (zero particles in vtk region).
which accounts for the lower number of VTP files, as Jeff suggested above.
I suggest you make more use of the log files and program output since they contain a lot of useful info. The RP.LOG for this run is 267M, so it’s too far too much to go through but using commands like
$ grep -i vtp RP.LOG | less
I found things like this:
WRITING VTP FILE : RP_DATA_519466.vtp .
VTP file not written (zero particles in vtk region).
WRITING VTP FILE : RP_DATA_519467.vtp .
VTP file not written (zero particles in vtk region).
WRITING VTP FILE : RP_DATA_519468.vtp .
VTP file not written (zero particles in vtk region).
WRITING VTP FILE : RP_DATA_519469.vtp .
VTP file not written (zero particles in vtk region).
We could elevate “VTP file not written” to a warning message so it’s harder to miss, although this may become annoying. I will discuss this with Jeff.
If you are absolutely certain that there are particles in the system at this time, then this may be an MFiX bug, but you have to look at your simulation and verify this. I think the message is probably correct.
Finally, I’ve also noticed that the MFiX GUI does not work well with hundreds of thousands of VTP files in the project directory. I’ll see what we can do to improve performance, but I think you are generating too many files. Is it necessary to write the VTU files at such short time intervals?
– Charles
rp.zip (11.9 KB)
I have attached the zip file containing my initial input file. Apologies this was not done sooner.
There is no reason there should be no particles in the region.
I am not running through the GUI, I am running through command prompt on my PC. I may be able to increase the data sampling rate up to 0.01 from 0.001, which you think may help the issue?
I think that’s the central assumption that needs to be interrogated.
The solver is printing messages that say zero particles in region (this is in the log file, which you should always examine when there are issues), and you have an outlet, so particles can leave the system. If the friction is lower, they can leave the system more easily. What prevents the particle count from reaching zero?
I created a monitor for total particle mass (AFAIK, there’s no simple way to track total particle number, but total mass is a reasonable proxy) and plotted it:
With the lower coefficient of friction, particles are falling out of the system.
Investigating further, I modified lines 820 of vtp_mod.f as follows
IF(GLOBAL_CNT>=0.AND.MODE==0) THEN
WRITE(ERR_MSG,*) global_cnt, ' DONE.'
ELSE
WRITE(ERR_MSG,20)' VTP file not written (zero particle in vtk region).'
ENDIF
to print the number of particles, and this confirms that the particle count is very low and eventually reaches zero. Here’s a small piece of the plot:
I believe this is a feature of your model when running with low friction, and is not a bug or problem with MFiX. The only problem is that the log files are huge and hard to deal with, I’m working on ‘trimming the fat’ a bit.
Also please note, I did not suggest increasing vtk_dt as a way of working around the reported issue but simply to reduce the amount of data written. Having nearly a million files in a directory is cumbersome, it causes the OS to respond very slowly, the GUI hangs up completely, commands like ‘rm RP*’ fail with Command line too long, etc. And what to do with all that data? An animation with that many frames running at 60FPS will be 4 hours long. Plots don’t need a million points on the x-axis. In general, I suggest not collecting more data than you really need, it just consumes resources. If you do need to collect data at a more fine-grained time interval, try using monitors - thay way the data gets appended to the same file, instead of creating a new file at every time step.
– Charles
PS. here’s a little script that shows # of particles in each file, I’m leaving it here in case it’s useful:
#!/usr/bin/env python
import vtk, glob
r = vtk.vtkXMLPolyDataReader()
for f in sorted(glob.glob("*vtp")):
r.SetFileName(f)
r.Update()
print(f, r.GetNumberOfPoints())I believe Charles has the right approach. The issue here is that your domain empties out due to the side outlet. Now since you also have an inlet at the top you end up with a few particles trickling in and out of the domain.
Here you are running a granular flow (no fluid phase) so the relevant time step is the solids time setp:
Info: At time = 0.000000E+00 sec., setting DEM solids time step, DTSOLID (sec) = 0.191259E-04
Your file output frequency is to high, so overwhelming that we cannot visualize the data for troubleshooting. Outputting data at a much lower frequency shows you end up with zero particles from time to time.