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<https://spam.ic.ac.uk/SpamConsole/Senders.aspx> 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<https://proton.me/mail/home>.