ASPECT can't access all of solver history data from solver_control.cc in dealII?

[naliboff]

I just started trying to track the origin of this issue, but I wanted to put it up quickly in case anyone is thinking updating deal.II.

After updating the master branch of deal.II yesterday all of the ASPECT tests I ran failed. The tests are failing due to an incorrect number of stokes solver steps. For example, the output from the test quick_mpi is

Number of active cells: 16 (on 3 levels)
Number of degrees of freedom: 268 (162+25+81)

*** Timestep 0:  t=0 years
   Rebuilding Stokes preconditioner...
   Solving Stokes system... 17+4294967295 iterations.
      Relative Stokes residual after nonlinear iteration 1: 1
   Solving Stokes system... 0+4294967295 iterations.
      Relative Stokes residual after nonlinear iteration 2: 6.60395e-08

   Postprocessing:

Termination requested by criterion: end time

The issue appears to be related to solver_control.cc in deal.II or how ASPECT accesses that data. The test stokes_residual gives the error

Number of active cells: 256 (on 5 levels)
Number of degrees of freedom: 3,556 (2,178+289+1,089)

*** Timestep 0:  t=0 seconds
   Solving temperature system... 0 iterations.
   Rebuilding Stokes preconditioner...
   Solving Stokes system...
--------------------------------------------------------
An error occurred in line <166> of file </data1/Software/dealii/master/dealii/source/lac/solver_control.cc> in function
    const std::vector<double>& dealii::SolverControl::get_history_data() const
The violated condition was:
    history_data.size() > 0
Additional information:
    The SolverControl object was asked for the solver history data, but there is no data. Possibly you requested the data before the solver was run.

Stacktrace:
-----------
#0  /data1/Software/dealii/master/install/lib/libdeal_II.g.so.9.0.0-pre: dealii::SolverControl::get_history_data() const
#1  /data1/Software/aspect/master/aspect/aspect: aspect::Postprocess::StokesResidual<2>::stokes_solver_callback(dealii::SolverControl const&, dealii::SolverControl const&)
#2  /data1/Software/aspect/master/aspect/aspect: boost::detail::function::void_function_obj_invoker5<std::_Bind<std::_Mem_fn<void (aspect::Postprocess::StokesResidual<2>::*)(dealii::SolverControl const&, dealii::SolverControl const&)> (aspect::Postprocess::StokesResidual<2>*, std::_Placeholder<4>, std::_Placeholder<5>)>, void, aspect::SimulatorAccess<2> const&, unsigned int, unsigned int, dealii::SolverControl const&, dealii::SolverControl const&>::invoke(boost::detail::function::function_buffer&, aspect::SimulatorAccess<2> const&, unsigned int, unsigned int, dealii::SolverControl const&, dealii::SolverControl const&)
#3  /data1/Software/aspect/master/aspect/aspect: boost::signals2::detail::signal_impl<void (aspect::SimulatorAccess<2> const&, unsigned int, unsigned int, dealii::SolverControl const&, dealii::SolverControl const&), boost::signals2::optional_last_value<void>, int, std::less<int>, boost::function<void (aspect::SimulatorAccess<2> const&, unsigned int, unsigned int, dealii::SolverControl const&, dealii::SolverControl const&)>, boost::function<void (boost::signals2::connection const&, aspect::SimulatorAccess<2> const&, unsigned int, unsigned int, dealii::SolverControl const&, dealii::SolverControl const&)>, boost::signals2::mutex>::operator()(aspect::SimulatorAccess<2> const&, unsigned int, unsigned int, dealii::SolverControl const&, dealii::SolverControl const&)
#4  /data1/Software/aspect/master/aspect/aspect: aspect::Simulator<2>::solve_stokes()
#5  /data1/Software/aspect/master/aspect/aspect: aspect::Simulator<2>::solve_timestep()
#6  /data1/Software/aspect/master/aspect/aspect: aspect::Simulator<2>::run()
#7  /data1/Software/aspect/master/aspect/aspect: main

Notably, deal.II step-32 does not appear to be affected.

[bangerth]

The differences in the output are almost certainly due to this patch: dealii/dealii#4870
Therein, SolverControl initializes the number of iterations it has run as numbers::invalid_unsigned_int instead of zero, and only starts to count once it actually starts the iteration. We may want to work around this by printing a zero if the returned number of iterations is numbers::invalid_unsigned_int.

The second error (with the exception) I don't know about.

[naliboff]

Printing a zero for either solver_control_cheap.last_step() or solver_control_expensive.last_step() when the number of iterations is numbers::invalid_unsigned_int does the trick. I'll do a pull request for this fix and handle the other issue separately.

[gassmoeller]

Was this issue fixed by #1914?

[naliboff]

#1914 fixed one of the issues, but there is still another error(s) left to resolve. Shall we close this as soon as the remaining errors are fixed?

[gassmoeller]

This is still happening, I will take another look next week.

[gassmoeller]

@naliboff could you check if this solves the problems for you?

[naliboff]

@gassmoeller - I just tried compiling with the current deal.II master and I'm getting a compiler error related to the spherical manifold. Is there a specific aspect or deal.II commit I should revert back to for testing the issue? Sorry, I still need to go through all of the commits that have come through the last few days.

[gassmoeller]

No problem, but could you specify the error you get? I thought we had everything sorted out over the last week. In particular which error message do you get, which deal.II commit, which ASPECT commit?

[naliboff]

The error is

In file included from /home/naliboff/software/aspect/master_dealii_dev/aspect/source/boundary_composition/spherical_constant.cc:23:0:
/home/naliboff/software/aspect/master_dealii_dev/aspect/include/aspect/geometry_model/sphere.h:136:15: error: ‘SphericalManifold’ does not name a type
         const SphericalManifold<dim> spherical_manifold;
               ^

I'm currently at commit at deal.II commit dealii/dealii@43453ba, but it looks there have been additional commits related to the Spherical manifold added since then (e.g., dealii/dealii@7b3a3e7). I'll update deal.II and see if this resolves the issue. No issues compiling with deal.II 8.5.0 on the same machine. Sorry, this is getting the issue way of track.

[bangerth]

Are we just forgetting to #include <deal.II/grid/manifold_lib.h> in that file? Can you try whether that makes the error go away for you?

[naliboff]

Yep, adding #include <deal.II/grid/manifold_lib.h> to sphere.h did the trick 👍 I'll submit a patch tomorrow for the compiler error and close this issue (tests look correct now) after adding links to the relevant pull requests.

[bangerth]

Excellent, thanks for checking!

[naliboff]

#1995 fixes the sphere.h compiler issue outlined above.

[naliboff]

The second of the two original issues has now been fixed #1988. Thanks @gassmoeller!