# Error while running - NaN

**URL:** <https://pyfr.discourse.group/t/error-while-running-nan/1274>\
**Category:** Errors\
**Created:** [28 June 2025 17:57 UTC](https://pyfr.discourse.group/t/error-while-running-nan/1274 "2025-06-28T17:57:22Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Amirshau](https://avatars.discourse-cdn.com/v4/letter/a/c89c15/32.png) [@Amirshau](https://pyfr.discourse.group/u/Amirshau)\
**Post date:** [28 June 2025 17:57 UTC](https://pyfr.discourse.group/t/error-while-running-nan/1274/1 "2025-06-28T17:57:22Z")

</div>

Hello everyone,

I’m trying to run a simulation with PyFR, and I’m gettig error for NaN as the runtime is geting to the delta time which was specified.

Here’s the ini file:

[backend]  
precision = single  
rank-allocator = linear

[backend-cuda]  
device-id = local-rank  
;devide-id = round-robin  
mpi-type = cuda-aware

[constants]  
ac-zeta=50  
;ac-zeta = 0.4  
gamma = 1.4  
Uin = 4.6  
Vin = 0  
Win = 0  
Pc = 101325  
Pr = 0.72  
nu = 0.000015

[solver]  
system = ac-navier-stokes  
order = 3  
anti-alias = flux, surf-flux

[solver-time-integrator]  
formulation = dual  
scheme = backward-euler  
pseudo-scheme = rk45  
controller = none  
tstart = 0.0  
tend = 24  
dt = 5e-5  
;dt = 0.0016  
atol = 0.00001  
rtol = 0.00001  
pseudo-dt = 1e-6  
;pseudo-dt = 4e-5  
pseudo-niters-max = 20  
pseudo-niters-min = 3  
pseudo-resid-tol = 1e-4  
pseudo-resid-tol-p = 1e-4  
pseudo-resid-norm = l2  
pseudo-controller = local-pi  
safety-fact = 0.8  
min-fact = 0.98  
max-fact = 1.01  
pseudo-dt-max-mult = 2.5

[solver-interfaces]  
riemann-solver = rusanov  
ldg-beta = 0.5  
ldg-tau = 0.1

[solver-dual-time-integrator-multip]  
pseudo-dt-fact = 1.75  
cycle = [(3, 1), (2, 1), (1, 1), (0, 3), (1, 1), (2, 1), (3, 3)]

[solver-interfaces-line]  
flux-pts = gauss-legendre  
quad-deg = 9  
quad-pts = gauss-legendre  
[solver-interfaces-line-mg-p2]  
flux-pts = gauss-legendre  
quad-deg = 7  
quad-pts = gauss-legendre  
[solver-interfaces-line-mg-p1]  
flux-pts = gauss-legendre  
quad-deg = 5  
quad-pts = gauss-legendre  
[solver-interfaces-line-mg-p0]  
flux-pts = gauss-legendre  
quad-deg = 3  
quad-pts = gauss-legendre

[solver-elements-tri]  
soln-pts = williams-shunn  
quad-deg = 9  
quad-pts = williams-shunn  
[solver-elements-tri-mg-p2]  
soln-pts = williams-shunn  
quad-deg = 7  
quad-pts = williams-shunn  
[solver-elements-tri-mg-p1]  
soln-pts = williams-shunn  
quad-deg = 5  
quad-pts = williams-shunn  
[solver-elements-tri-mg-p0]  
soln-pts = williams-shunn  
quad-deg = 3  
quad-pts = williams-shunn

[solver-elements-quad]  
soln-pts = gauss-legendre  
quad-deg = 9  
quad-pts = gauss-legendre  
[solver-elements-quad-mg-p2]  
soln-pts = gauss-legendre  
quad-deg = 7  
quad-pts = gauss-legendre  
[solver-elements-quad-mg-p1]  
soln-pts = gauss-legendre  
quad-deg = 5  
quad-pts = gauss-legendre  
[solver-elements-quad-mg-p0]  
soln-pts = gauss-legendre  
quad-deg = 3  
quad-pts = gauss-legendre

[solver-elements-hex]  
soln-pts = gauss-legendre  
quad-deg = 9  
quad-pts = gauss-legendre  
[solver-elements-hex-mg-p2]  
soln-pts = gauss-legendre  
quad-deg = 7  
quad-pts = gauss-legendre  
[solver-elements-hex-mg-p1]  
soln-pts = gauss-legendre  
quad-deg = 5  
quad-pts = gauss-legendre  
[solver-elements-hex-mg-p0]  
soln-pts = gauss-legendre  
quad-deg = 3  
quad-pts = gauss-legendre

[solver-elements-pri]  
soln-pts = williams-shunn~gauss-legendre  
quad-deg = 9  
quad-pts = williams-shunn~gauss-legendre  
[solver-elements-pri-mg-p2]  
soln-pts = williams-shunn~gauss-legendre  
quad-deg = 7  
quad-pts = williams-shunn~gauss-legendre  
[solver-elements-pri-mg-p1]  
soln-pts = williams-shunn~gauss-legendre  
quad-deg = 5  
quad-pts = williams-shunn~gauss-legendre  
[solver-elements-pri-mg-p0]  
soln-pts = williams-shunn~gauss-legendre  
quad-deg = 3  
quad-pts = williams-shunn~gauss-legendre

[solver-interfaces-tri]  
flux-pts = williams-shunn  
quad-deg = 9  
quad-pts = williams-shunn  
[solver-interfaces-tri-mg-p2]  
flux-pts = williams-shunn  
quad-deg = 7  
quad-pts = williams-shunn  
[solver-interfaces-tri-mg-p1]  
flux-pts = williams-shunn  
quad-deg = 5  
quad-pts = williams-shunn  
[solver-interfaces-tri-mg-p0]  
flux-pts = williams-shunn  
quad-deg = 3  
quad-pts = williams-shunn

[solver-interfaces-quad]  
flux-pts = gauss-legendre  
quad-deg = 9  
quad-pts = gauss-legendre  
[solver-interfaces-quad-mg-p2]  
flux-pts = gauss-legendre  
quad-deg = 7  
quad-pts = gauss-legendre  
[solver-interfaces-quad-mg-p1]  
flux-pts = gauss-legendre  
quad-deg = 5  
quad-pts = gauss-legendre  
[solver-interfaces-quad-mg-p0]  
flux-pts = gauss-legendre  
quad-deg = 3  
quad-pts = gauss-legendre

[soln-plugin-pseudostats]  
flushsteps = 10  
file = pseudostats.csv  
header = true

[soln-plugin-nancheck]  
nsteps = 1

[soln-plugin-writer]  
tstart = 12.0  
dt-out = 0.05  
basedir = /home/amir/  
#basedir = .  
basename = Urban2-{t:.4f}

[soln-ics]  
u = 4.6  
v = 0.0  
w = 0.0  
p = Pc

[soln-bcs-walls]  
type = no-slp-wall  
u = 0  
v = 0  
w = 0

[soln-bcs-inlet]  
type = ac-char-riem-inv  
ac-zeta = 50  
;ac-zeta = 5  
rho=1.185  
p = Pc  
u = Uin  
v = Vin  
w = Win

[soln-bcs-outlet]  
type = ac-char-riem-inv  
ac-zeta=50  
;ac-zeta = 5  
rho=1.185  
p = Pc  
u = Uin  
v = Vin  
w = Win

[soln-bcs-farfield]  
type = ac-char-riem-inv  
ac-zeta=50  
;ac-zeta = 5  
p = Pc  
u = Uin  
v = Vin  
w = Win

Please advice how to solve the problem.

---

<div class="post-metadata">

**Author:** ![fdw](https://avatars.discourse-cdn.com/v4/letter/f/a587f6/32.png) [@fdw](https://pyfr.discourse.group/u/fdw)\
**Post date:** [29 June 2025 03:55 UTC](https://pyfr.discourse.group/t/error-while-running-nan/1274/2 "2025-06-29T03:55:28Z")

</div>

In the majority of cases this is caused by:

1. An incorrect start-up procedure (starting a simulation directly at a high-order rather than gradually increasing it).
2. A mesh which is too coarse.
3. A time step which is too larger.

Without knowing more about your simulation it is difficult to say what is going on.

Regards, Freddie.

---

<div class="post-metadata">

**Author:** ![Amirshau](https://avatars.discourse-cdn.com/v4/letter/a/c89c15/32.png) [@Amirshau](https://pyfr.discourse.group/u/Amirshau)\
**Post date:** [1 July 2025 05:23 UTC](https://pyfr.discourse.group/t/error-while-running-nan/1274/3 "2025-07-01T05:23:18Z")

</div>

Hi Freddie,

how do you suggest to rewrite the ini file for gradually increased startup?

Thanks.

---

<div class="post-metadata">

**Author:** ![fdw](https://avatars.discourse-cdn.com/v4/letter/f/a587f6/32.png) [@fdw](https://pyfr.discourse.group/u/fdw)\
**Post date:** [1 July 2025 07:01 UTC](https://pyfr.discourse.group/t/error-while-running-nan/1274/4 "2025-07-01T07:01:29Z")

</div>

PyFR allows you to restart a simulation with a different ini file. So you start with an initial file say, at `order = 1`. Then, run the simulation for some period of time, then restart from the final solution with a new ini file with `order = 2`. This will typically be more robust.

Regards, Freddie.

---

<div class="post-metadata">

**Author:** ![Amirshau](https://avatars.discourse-cdn.com/v4/letter/a/c89c15/32.png) [@Amirshau](https://pyfr.discourse.group/u/Amirshau)\
**Post date:** [11 July 2025 17:03 UTC](https://pyfr.discourse.group/t/error-while-running-nan/1274/5 "2025-07-11T17:03:28Z")

</div>

Thanks Freddie.

I tried your method and it was running ok on p=1 & p=2 with restarting. However, when I restarted the simulation with p=3 , there was no convergence i.e. NaN.  
To be honest, I’ve conducted the simulation first with pressure P = 1.013 by mistake and the simulation worked properly, so I don’t think there is any coarse meshing issues.  
I don’t know how to proceed on this, maybe you can help me.

Best regards,  
Amir

---

<div class="post-metadata">

**Author:** ![fdw](https://avatars.discourse-cdn.com/v4/letter/f/a587f6/32.png) [@fdw](https://pyfr.discourse.group/u/fdw)\
**Post date:** [11 July 2025 21:06 UTC](https://pyfr.discourse.group/t/error-while-running-nan/1274/6 "2025-07-11T21:06:46Z")

</div>

How does the flow look at p = 2? Is it well developed? When you restart at p = 3 how does the flow look before it NaNs? Usually, this will give you an idea of where you are under-resolved.

Regards, Freddie.

---

<div class="post-metadata">

**Author:** ![Amirshau](https://avatars.discourse-cdn.com/v4/letter/a/c89c15/32.png) [@Amirshau](https://pyfr.discourse.group/u/Amirshau)\
**Post date:** [12 July 2025 07:32 UTC](https://pyfr.discourse.group/t/error-while-running-nan/1274/7 "2025-07-12T07:32:19Z")

</div>

I apologize, the simulation didn’t restarted at p=2, not at p=3. However, I ran the simulation with p = 1 for quite long time, so it should converege.

Also, I tried to restart from the simulation with BC P = 1.013 (where it worked propely with p = 3) and replace the pressure value to 1.013e5, but it also didn’t convereged. Does changing the pressure value is vital for convergence?

---

<div class="post-metadata">

**Author:** ![fdw](https://avatars.discourse-cdn.com/v4/letter/f/a587f6/32.png) [@fdw](https://pyfr.discourse.group/u/fdw)\
**Post date:** [12 July 2025 07:50 UTC](https://pyfr.discourse.group/t/error-while-running-nan/1274/8 "2025-07-12T07:50:56Z")

</div>

If you want to make any progress you need to actually start looking at the flow. As I mentioned before the issue is almost certainly with your mesh; the fact a mesh works at a low polynomial order but not a higher one does not in itself mean much. Lower polynomial orders have more dissipation which can allow under-resolved simulations to remain stable. This goes away as the order is increase.

Arbitrarily changing the pressure is also unlikely to result in a meaningful outcome. The pressure should be fixed by the physics you are trying to replicate and your chosen set of units.

Regards, Freddie.