Laminar flow over a sphere case: "Minimum sized time step rejected"

Cases
1

Hello everyone,
As a newcomer to pyFR, I am currently trying to compute a Laminar flow over a sphere case to learn and understand pyFR.
In this case, the hemisphere is set with a no-slp-adia-wall boundary condition, the hemispherical symmetry surface is set with a slp-adia-wall boundary condition, the outlet is set as sup-out-fn, and the far field is set as sup-in-fa. The initial conditions for rho, u, v, w, and p are the same as the far field conditions.
The Riemann solver is set as Rusanov, and the solution points and flux points are properly set.

The simulation starts off well, but later on, I keep encountering “Minimum sized time step rejected.”
My time integrator is initially set as follows.

[solver-time-integrator]
formulation = std
scheme = rk34
controller = pi
tstart = 0.0
tend = 0.04
dt = 1E-3
atol = 1E-5
rtol = 1E-3
errest-norm = l2
safety-fact = 0.9
min-fact = 0.3
max-fact = 2.5

The simulation always terminates around 0.02~0.04 seconds.

I modified dt from 1E-3 to 1E-4, atol from 1E-5 to 1E-7, and rtol from 1E-3 to 1E-7. They are all small enough, but the simulation still reports errors.
When observing the last few rows of dtstats.csv, I noticed that during stable running, the step size was around 6.7e-8. However, without any warning, the step size suddenly drops to around 3e-10, and then “Minimum sized time step rejected,” causing the simulation to terminate.

Could you provide some suggestions on why my simulation is terminating midway? Where can I find more information?
I checked residual.csv, and it seems to show a steady decrease without any issues.
VTU files also seem to have no major problems (BUT I’m not an expert in this field).
Perhaps I should adjust the options with the “-fact” suffix in the time-integrator? But I have no experience with it.
I would be greatly appreciative of any advice you could offer.

Best regards.

2

I think you might need to change your inlet and outlet boundary conditions. Given that you are after a laminar flow I presume that you want a subsonic but compressible fluid, and so you probably want to set sub-in-frv and sub-out-fp, or potentially you could use the char-riem-inv boundary conditions. Either way, it is likely that your current boundary condition set up is unphysical as you are overconstraining the input and underconstraining the output.

3

You are wonderful!!!
But I collapsed.
Last week, I still used it well, and suddenly there was an error related to h5py.
When I want to submit my example for calculation, pyfr run xxx gives an error.

...
  File "pyfr/lib/python3.10/site-packages/h5py/_hl/files.py", line 226, in make_fid
    fid = h5f.open(name, flags, fapl=fapl)
  File "h5py/_objects.pyx", line 54, in h5py._objects.with_phil.wrapper
  File "h5py/_objects.pyx", line 55, in h5py._objects.with_phil.wrapper
  File "h5py/h5f.pyx", line 106, in h5py.h5f.open
OSError: Unable to open file (file signature not found)

I was shocked because I had no idea why this happened.
Google’s result is that the file is probably not in hdf5 format or the file is corrupted.
This is impossible, because I resubmitted my calculation results last week, and it was still the same error. Last week, it was still operational, and the result file of last week could not be suddenly damaged.

I suspected that something was wrong, but I was completely at a loss. I uninstalled h5py and reinstalled it, but it still didn’t help. The key point is that I was running well last week!

There is no error in import, no error in partition, and an error in run.
When I use pyfr export, a new error occurs:

...
  File "pyfr/lib/python3.10/site-packages/h5py/_hl/group.py", line 328, in __getitem__
    oid = h5o.open(self.id, self._e(name), lapl=self._lapl)
  File "h5py/_objects.pyx", line 54, in h5py._objects.with_phil.wrapper
  File "h5py/_objects.pyx", line 55, in h5py._objects.with_phil.wrapper
  File "h5py/h5o.pyx", line 190, in h5py.h5o.open
KeyError: 'Unable to open object (bad version number for datatype message)'

I feel really bad because of this sudden mistake. Can you give me some advice? Maybe it’s the software version? I’m at a loss.
Grateful …

4

It could be something like that, it could be that hdf5 has updated and you need to reinstall h5py. Try: pip install --force-reinstall h5py

It can also sometimes be that hdf5 has updated since you wrote that file and for whatever reason it won’t open. Try using h5dump -n pyfr_file.pyfrs. You can then try checking that h5py can open the file with something like:

import h5py
from pyfr.inifile import Inifile

with h5py.File(filename, 'r') as f:
    cfg = Inifile(f['config'][()].decode())
5

Your advice was absolutely right, and just as I was about to reinstall my pyFR, I found the root of the problem.

Although I’m not sure how this issue occurred, a few days ago, I used an outdated version of GCC, but it doesn’t seem to be the cause of the problem.

In any case, with your inspiration, I managed to identify and resolve the issue. Before using pyFR, I had been managing my Python environment using conda, but I installed pyFR using pip, which might have caused the problem due to the mixing of pip and conda.

I noticed that “pip install h5py” installed h5py version 3.9.0, while “conda install h5py” installed version 3.7.0. Although I’m not sure how this relates to the problem or how the issue arose, uninstalling h5py and its dependencies completely and then reinstalling h5py using pip resolved the problem!

Thank you for your assistance; it was truly, incredibly helpful to me.