Hi Alexander,

 

Thanks for your email.

 

When you run your case without the local p-Refinement do you get the same error?

 

Regarding the Variable P capability, I have not seen your mesh, but it is generally beneficial to ensure a smooth transition between the polynomial orders (or mesh). If you jump from P=3 to P=7, it is quite a drastic change in the mesh refinement for the solver to handle.

 

Best regards,

Joćo.

 

From: nektar-users-bounces@imperial.ac.uk <nektar-users-bounces@imperial.ac.uk> on behalf of Alexander Schukmann <alexander.schukmann@protonmail.com>
Date: Monday, 18 November 2024 at 09:37
To: nektar-users <nektar-users@imperial.ac.uk>
Subject: [Nektar-users] Element u_11 is 0 from dsptrf

This email from alexander.schukmann@protonmail.com originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list to disable email stamping for this address.

 

Hello all,

 

when I run a 2.5D simulation using the incompressible NS solver the following error message appears with e.g. 480 CPUs after reading the initial state file, so the run immediately crashes:

 

Fatal   : Level 0 assertion violation
ERROR: Element u_11 is 0 from dsptrf

 

However, when switching to a lower CPU count such as 128 CPUs, it works. 

I have a region of local P-refinement in my domain, where the polynomial order is 7. Outside this region I coarsened the spatial resolution to P = 3 and suspect that it has something to do with this. 

Why does this happen?

 

All the best

Alex

 

Sicher versendet mit Proton Mail.