Re: [firedrake] Nonlinear solve did not converge due to DIVERGED_FNORM_NAN
Initial thought: could you be generating a NaN in your own code as the mesh is refined? E.g. if you're interpolating some expression that leads to a 0/0 at some points in the domain. On 24 March 2017 at 10:45, Buesing, Henrik <HBuesing@eonerc.rwth-aachen.de> wrote:
Dear all,
I am doing a refinement study for two-phase flow in porous media. The first five levels of refinement succeed and I get reasonable results. On level six I get an error (see [1]). I also attached the trace.
I tried the suggestion with –snes_converged_reason and –ksp_converged_reason, but this gives no output. Since the error seems to originate from the projection on the linear output space, I removed these parts. Then I get [2].
Do you have an idea what I am doing wrong? Why does the formulation seem to be correct for coarse discretizations, but gives NAN for finer ones?
Thank you!
Henrik
[1]
firedrake.exceptions.ConvergenceError: Nonlinear solve failed to converge after 0 nonlinear iterations.
Reason:
Inner linear solve failed to converge after 0 iterations with reason: unknown reason (petsc4py enum incomplete?), try with -snes_convered_reason and -ksp_converged_reason
%s""" % (snes.getIterationNumber(), msg))
[2]
Nonlinear solve did not converge due to DIVERGED_FNORM_NAN iterations 0
--
Dipl.-Math. Henrik Büsing
Institute for Applied Geophysics and Geothermal Energy
E.ON Energy Research Center
RWTH Aachen University
------------------------------------------------------
Mathieustr. 10 | Tel +49 (0)241 80 49907 <+49%20241%208049907>
52074 Aachen, Germany | Fax +49 (0)241 80 49889 <+49%20241%208049889>
------------------------------------------------------
http://www.eonerc.rwth-aachen.de/GGE
hbuesing@eonerc.rwth-aachen.de
------------------------------------------------------
Initial thought: could you be generating a NaN in your own code as the mesh is refined? E.g. if you're interpolating some expression that leads to a 0/0 at some points in the domain. [Buesing, Henrik] I am dividing by Delta_h_facet (see [1]). So for the cell in the origin, the node should move closer to zero. But, since I am using DQ0 it should not be zero, right? I am also dividing by dt. Should I reformulate s.t. I multiply by dt? Thank you! Henrik [1] x_func_expr = Expression("x[0]") y_func_expr = Expression("x[1]") z_func_expr = Expression("x[2]") x_func = interpolate(x_func_expr, DG1) y_func = interpolate(y_func_expr, DG1) z_func = interpolate(z_func_expr, DG1) Delta_h_facet = sqrt(jump(x_func)**2 + jump(y_func)**2 + jump(z_func)**2)
Initial thought: could you be generating a NaN in your own code as the mesh is refined? E.g. if you're interpolating some expression that leads to a 0/0 at some points in the domain. [Buesing, Henrik] Ah, well. I was using int where I should have used float. Thus, my dz of the extruded mesh turned into zero.
On 24 Mar 2017, at 16:50, Buesing, Henrik <HBuesing@eonerc.rwth-aachen.de> wrote:
Ah, well. I was using int where I should have used float. Thus, my dz of the extruded mesh turned into zero.
To track these kind of things down, you can run your python program as: python -Qwarnall program.py Now you will get warnings if int division is being assumed. You can also do: from __future__ import division at the top of your file (I recommend you do this). Now a/b is floating point division, and a//b is old-style "integer" division. See https://www.python.org/dev/peps/pep-0238/ for more information. Lawrence
participants (3)
- 
                
                Andrew McRae
- 
                
                Buesing, Henrik
- 
                
                Lawrence Mitchell