Covergence Error -Models with Two Comp Fields

ASPECT
1

Hello,

I’m developing 2d spherical isoviscous convection models with two compositional fields (LLVPs + Lithosphere). I’ve had previous successes running models with two comp fields, however I’ve had to increase the viscosity contrast (1e25) to prevent the deformation of the comp fields. I’ve had no issues running models with a single comp field but models with two have failed almost instantly with a convergence error.

We’ve made a few attempts to fix this:

  1. turning on adaptive mesh refinement
  2. updating the stoke’s solver
  3. increasing the number of processors used to run the models.

Attempts 2 & 3 solved the convergence issue (somewhat) but the models run to a point and then pause without failing. I would have to cancel the job once I’ve seen that no new data is being written after several hours, sometimes days, of checking back.

I’ve attached my original prm (LLSVP_Litho_stokes.prm) and the prm with the updated stokes solver (LLSVP_Litho_stokes2.prm). I have also attached the error
Debug-Error.txt (4.4 KB)
and log.txt files for a debug run of the model with the updated stokes solver.

Any help with this would be greatly appreciated! I’d be happy to provide any extra files or information you might need.

Thank you!

Hadeel

P.S. I couldn’t link more than 2 docs so I’ve attached the rest in a reply message.

LLSVP_Litho_stokes2.prm (4.3 KB)

2

log.txt (33.3 KB)
LLSVP_Litho_stokes.prm (4.3 KB)

3

Hi Hadeel,

Thanks for posting this question to the forum.

Other developers / maintainers:

  • I discussed this issue with Hadeel separately, and I’m not entirely sure why the model is hanging with this specific setup or at this specific point.
  • In short, the error is occurring during the advection solve (assemble and solve composition step) when the ParticleIterator calls dealII:CellId. The full stack trace is below.
  • Could this be due to running out of memory (I believe Hadeel is trying with more CPUs and/or memory allocated)? I don’t recall seeing this specific error before.

Hadeel - in the short term, could you try installing ASPECT with deal.II 9.6.1 (most recent release) and seeing if the issue still persists?

Cheers,
John

Full stack trace:

#0 /opt/apps/aspect/dependencies/intel/20.2/deal.II-v9.5.1/lib/libdeal_II.g.so.9.5.1: dealii::CellId::CellId(std::array<unsigned int, 4ul> const&)
#1 /opt/apps/aspect/dependencies/intel/20.2/deal.II-v9.5.1/lib/libdeal_II.g.so.9.5.1: dealii::Particles::ParticleHandler<2, 2>::send_recv_particles(std::map<unsigned int, std::vector<dealii::Particles::ParticleIterator<2, 2>, std::allocator<dealii::Particles::ParticleIterator<2, 2> > >, std::less, std::allocator<std::pair<unsigned int const, std::vector<dealii::Particles::ParticleIterator<2, 2>, std::allocator<dealii::Particles::ParticleIterator<2, 2> > > > > > const&, std::map<unsigned int, std::vector<dealii::TriaActiveIterator<dealii::CellAccessor<2, 2> >, std::allocator<dealii::TriaActiveIterator<dealii::CellAccessor<2, 2> > > >, std::less, std::allocator<std::pair<unsigned int const, std::vector<dealii::TriaActiveIterator<dealii::CellAccessor<2, 2> >, std::allocator<dealii::TriaActiveIterator<dealii::CellAccessor<2, 2> > > > > > > const&, bool)
#2 /opt/apps/aspect/dependencies/intel/20.2/deal.II-v9.5.1/lib/libdeal_II.g.so.9.5.1: dealii::Particles::ParticleHandler<2, 2>::exchange_ghost_particles(bool)
#3 /opt/apps/aspect/2.6.0_pre/intel/20.2/bin/aspect: aspect::Particle::World<2>::advance_timestep()
#4 /opt/apps/aspect/2.6.0_pre/intel/20.2/bin/aspect: aspect::Simulator<2>::assemble_and_solve_composition(std::vector<double, std::allocator > const&, std::vector<double, std::allocator >*)
#5 /opt/apps/aspect/2.6.0_pre/intel/20.2/bin/aspect: aspect::Simulator<2>::solve_single_advection_iterated_stokes()
#6 /opt/apps/aspect/2.6.0_pre/intel/20.2/bin/aspect: aspect::Simulator<2>::solve_timestep()
#7 /opt/apps/aspect/2.6.0_pre/intel/20.2/bin/aspect: aspect::Simulator<2>::run()
#8 /opt/apps/aspect/2.6.0_pre/intel/20.2/bin/aspect: void run_simulator<2>(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, bool, bool, bool)
#9 /opt/apps/aspect/2.6.0_pre/intel/20.2/bin/aspect: main
--------------------------------------------------------\

4

The error message is this:

An error occurred in line <73> of file </opt/apps/aspect/dependencies/intel/20.2/tmp/unpack/deal.II-v9.5.1/source/grid/cell_id.cc> in function\
    dealii::CellId::CellId(const std::array<unsigned int, 4UL> &)\
The violated condition was: \
    n_child_indices < child_indices.size()\
Additional information: \
    This exception -- which is used in many places in the library --\
    usually indicates that some condition which the author of the code\
    thought must be satisfied at a certain point in an algorithm, is not\
    fulfilled. An example would be that the first part of an algorithm\
    sorts elements of an array in ascending order, and a second part of\
    the algorithm later encounters an element that is not larger than the\
    previous one.\
    \
    There is usually not very much you can do if you encounter such an\
    exception since it indicates an error in deal.II, not in your own\
    program. Try to come up with the smallest possible program that still\
    demonstrates the error and contact the deal.II mailing lists with it\
    to obtain help.\
\
Stacktrace:\
-----------\
#0  /opt/apps/aspect/dependencies/intel/20.2/deal.II-v9.5.1/lib/libdeal_II.g.so.9.5.1: dealii::CellId::CellId(std::array<unsigned int, 4ul> const&)\

This is indeed concerning, but I have no idea what it means. It does not look like an out-of-memory bug to me. What is the smallest configuration in which you can reproduce this error? How many MPI processes do you need?
Best
W.