About the shell_simple_2D model error in the manual

Hello teachers, when I run shell_simple_2D model according to the manual, the calculation stops and the following information is displayed. I want to know what the reason is and how I can solve it.

@xiyuan930809 Is this with the unmodified shell_simple_2d.prm file? If so, which version of ASPECT are you using?

It is the unmodified shell_simple_2d. PRM file. The version I use should be the 2.2.0 version with the instruction manual inside

@xiyuan930809 The error message in your picture does not show which time step the problem occurred in, nor how many processor you used. Did you run ASPECT with mpirun (and if so, with how many processors)? And can you scroll up in the output a bit so we can see where the error happened (i.e., in which time step, what the output immediately above the error was, etc)?

Dear teacher, I have re-run the shell-simple-2d. PRM file provided in the manual, and there is still an error at the 46th time step. Now I provide the screenshots of the beginning, middle and last three stages of the whole program operation. Hope can get help from you here! Thank you for your busy schedule to answer my question ~!

Dear Xiyuan,

Please see this related discussion: Problems with shell_simple_2d/3d cookbook examples · Issue #4482 · geodynamics/aspect · GitHub. It seems there is indeed a problem with this cookbook at the moment, but some other users have reported it runs fine with an additional refinement level. Can you check if that is also the case for you? If you can confirm this we can think further about potential solutions.

Thank you,
Rene Gassmoeller

Just for the record, I had this running over my lunch break today and I get the same crash:

Number of active cells: 2,556 (on 9 levels)
Number of degrees of freedom: 37,431 (22,990+2,946+11,495)

*** Timestep 46:  t=2.97782e+06 years, dt=33322.6 years
   Solving temperature system... 11 iterations.
   Rebuilding Stokes preconditioner...
   Solving Stokes system... 200+---------------------------------------------------------
TimerOutput objects finalize timed values printed to the
screen by communicating over MPI in their destructors.
Since an exception is currently uncaught, this
synchronization (and subsequent output) will be skipped
to avoid a possible deadlock.

Exception 'ExcMessage (exception_message.str())' on rank 0 on processing: 

An error occurred in line <2675> of file </home/fac/g/bangerth/p/deal.II/1/projects/aspect/source/utilities.cc> in function
    void aspect::Utilities::linear_solver_failed(const string&, const string&, const std::vector<dealii::SolverControl>&, const std::exception&, ompi_communicator_t* const&, const string&)
The violated condition was: 
Additional information: 
    The iterative Stokes solver in Simulator::solve_stokes did not
    The initial residual was: 1.019219e+13
    The final residual is: 2.866258e+07
    The required residual for convergence is: 1.721646e+07
    See output-shell_simple_2d/solver_history.txt for the full convergence
    The solver reported the following error:


Dear teacher, first of all, thank you for taking time out of your busy schedule to answer my questions. As you said, I remodified the initial temperature field in the original shell_SIMPLE_2D_SMOOTHING. PRM file by clicking the link you gave me and then ran it. But calculating at the first time step model seems to run directly to the I set the end of the time, so I changed the parameters in the source file, just set the start time, there is no set over time, it seems that he started to run, but each time step interval of time seems to be very big, is this why?

@xiyuan930809 I’m not sure I completely understand what your question is. But with your choice of initial condition, the velocity at the initial time ends up being essentially zero, and so the time step is computed as something very large. (The time step is chosen proportional to one-over-velocity.) The velocity is likely very small because you have an essentially rotationally symmetric initial temperature field for which the model cannot decide where a plume should result. You need to perturb the initial symmetry somehow.

Thank you for your answer. Let me debug it again!