Use new deal.II constraints functions.

[gassmoeller]

Since a few days all of our tests and models are broken with deal.II master (see #5393), which I am pretty sure is related to dealii/dealii#16010. I have tried to use the new constraints functions that require two index sets (locally owned and locally relevant), but I am still getting the following error message which is triggered from source/simulator/initial_conditions.cc:233:

-----------------------------------------------------------------------------
-- This is ASPECT, the Advanced Solver for Problems in Earth's ConvecTion.
--     . version 2.6.0-pre (update_particle_parameters, f89b8e616)
--     . using deal.II 9.6.0-pre (master, 821af1b0c5)
--     .       with 64 bit indices and vectorization level 1 (128 bits)
--     . using Trilinos 13.2.0
--     . using p4est 2.3.2
--     . running in DEBUG mode
--     . running with 1 MPI process
-----------------------------------------------------------------------------

-----------------------------------------------------------------------------
-- For information on how to cite ASPECT, see:
--   https://aspect.geodynamics.org/citing.html?ver=2.6.0-pre&sha=f89b8e616&src=code
-----------------------------------------------------------------------------
Number of active cells: 400 (on 1 levels)
Number of degrees of freedom: 5,484 (3,362+441+1,681)


--------------------------------------------------------
An error occurred in line <2679> of file </home/renegassmoeller/software/dealii/include/deal.II/lac/affine_constraints.templates.h> in function
    void dealii::AffineConstraints<number>::distribute(VectorType&) const [with VectorType = dealii::TrilinosWrappers::MPI::BlockVector; number = double]
The violated condition was: 
    needed_elements_for_distribute != IndexSet()
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  /home/renegassmoeller/software/dealii/build/lib/libdeal_II.g.so.9.6.0-pre: void dealii::AffineConstraints<double>::distribute<dealii::TrilinosWrappers::MPI::BlockVector>(dealii::TrilinosWrappers::MPI::BlockVector&) const
#1  ../aspect: aspect::Simulator<2>::set_initial_temperature_and_compositional_fields()
#2  ../aspect: aspect::Simulator<2>::run()
#3  ../aspect: void run_simulator<2>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, bool, bool)
#4  ../aspect: main
--------------------------------------------------------

I am a bit out of ideas what I am doing wrong, and the error is a ExcInternalError, which shouldnt happen as far as I understand. @bangerth can you maybe take a look at what is wrong with my changes?

[tjhei]

I have tried to use the new constraints functions that require two index sets

Yes, that is correct. You will need to add an #ifdef guard for the developer version though. I was hoping for @vyushut to open a PR for this. :-)

I know what is going on with the error. Let me get back to you in a bit.

[tjhei]

I am a bit out of ideas what I am doing wrong, and the error is a ExcInternalError

This is a bug in deal.II fixed by dealii/dealii#16039

[bangerth]

Oh, bummer. My apologies for breaking this. You'd think the deal.II test suite is large enough to catch this sort of case, but apparently it isn't :-(

[bangerth]

As @tjhei already noted, you'll need a #if around this. Or you go with the old function signature -- it may be marginally less efficient, but it's going to stick around for a couple more versions.

[tjhei]

Let's go with #5398

[gassmoeller]

Thanks for the quick fixes 👍