Provide CoreData with a constructor.

[bangerth]

This addresses part of the discussion in #6918.

@Francyrad FYI

[bangerth]

Turns out that initializing things with invalid values shows that we're using uninitialized values:

The following tests FAILED:
	319 - dynamic_core (Failed)
	320 - dynamic_core_fully_molten (Failed)
	321 - dynamic_core_fully_solid (Failed)
Errors while running CTest

I'll have to look at that tomorrow. Too bad we didn't catch this years ago :-[

[bangerth]

@gassmoeller I think I need help here -- thank you for offering earlier today. Here's the backtrace for the dynamic_core_fully_solid test:

*** "Test dynamic_core_fully_solid failed": ***
[1/5] Generating output-dynamic_core_fully_solid/screen-output
FAILED: output-dynamic_core_fully_solid/screen-output /__w/aspect/aspect/build/tests/output-dynamic_core_fully_solid/screen-output 
cd /__w/aspect/aspect/build/tests && rm -f /__w/aspect/aspect/build/tests/output-dynamic_core_fully_solid/runs && /__w/aspect/aspect/tests/cmake/timeout.sh 600s /__w/aspect/aspect/tests/cmake/run_test.sh 0 /__w/aspect/aspect/build/aspect /__w/aspect/aspect/build/tests/dynamic_core_fully_solid.x.prm /__w/aspect/aspect/build/tests/output-dynamic_core_fully_solid/screen-output.tmp && /__w/aspect/aspect/tests/cmake/default screen-output </__w/aspect/aspect/build/tests/output-dynamic_core_fully_solid/screen-output.tmp >/__w/aspect/aspect/build/tests/output-dynamic_core_fully_solid/screen-output && touch /__w/aspect/aspect/build/tests/output-dynamic_core_fully_solid/runs
/__w/aspect/aspect/tests/cmake/run_test.sh: line 16: 67297 Floating point exception(core dumped) $BINARY $PRM > ${OUTPUT} 2>&1
-----------------------------------------------------------------------------
--                             This is ASPECT                              --
-- The Advanced Solver for Planetary Evolution, Convection, and Tectonics. --
-----------------------------------------------------------------------------
--     . version 3.1.0-pre
--     . using deal.II 9.6.2
--     .       with 32 bit indices
--     .       with vectorization level 1 (SSE2, 2 doubles, 128 bits)
--     . using Trilinos 14.4.0
--     . using p4est 2.3.6
--     . using Geodynamic World Builder 1.0.0
--     . running in DEBUG mode
--     . running with 1 MPI process
-----------------------------------------------------------------------------

-----------------------------------------------------------------------------
-- For information on how to cite ASPECT, see:
--   https://aspect.geodynamics.org/citing.html?ver=3.1.0-pre&mf=1&sha=&src=code
-----------------------------------------------------------------------------
Number of active cells: 768 (on 4 levels)
Number of degrees of freedom: 10,656 (6,528+864+3,264)

[2c087f678450:67297] *** Process received signal ***
[2c087f678450:67297] Signal: Floating point exception (8)
[2c087f678450:67297] Signal code: Invalid floating point operation (7)
[2c087f678450:67297] Failing at address: 0x55cc1c7fb826
[2c087f678450:67297] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x7f100a749520]
[2c087f678450:67297] [ 1] /__w/aspect/aspect/build/aspect(_ZNK6aspect19BoundaryTemperature11DynamicCoreILi2EE21compute_radio_heatingEd+0x226)[0x55cc1c7fb826]
[2c087f678450:67297] [ 2] /__w/aspect/aspect/build/aspect(_ZN6aspect19BoundaryTemperature11DynamicCoreILi2EE16update_core_dataEv+0x2f)[0x55cc1c7fd34f]

So we run into a floating point exception in DynamicCore::compute_radio_heating(). I think that the function checks all of the input arguments to the formulas, but apparently something still isn't working. Can you see which instruction the problem is, and which variable is invalid?

[gassmoeller]

No problem. Here is the full backtrace:

#0  aspect::BoundaryTemperature::DynamicCore<2>::compute_radio_heating (this=0x55555bff5da0, Tc=1000)
    at /home/rene/software/aspect/source/boundary_temperature/dynamic_core.cc:746
#1  0x000055555b785449 in aspect::BoundaryTemperature::DynamicCore<2>::update_core_data (this=0x55555bff5da0)
    at /home/rene/software/aspect/source/boundary_temperature/dynamic_core.cc:547
#2  0x000055555b77757a in aspect::BoundaryTemperature::DynamicCore<2>::update (this=0x55555bff5da0)
    at /home/rene/software/aspect/source/boundary_temperature/dynamic_core.cc:137
#3  0x000055555a62b019 in aspect::Plugins::ManagerBase<aspect::BoundaryTemperature::Interface<2> >::update (this=0x7fffffffa420)
    at /home/rene/software/aspect/include/aspect/plugins.h:387
#4  0x000055555a5b81dc in aspect::Simulator<2>::compute_current_constraints (this=0x7fffffff8b40) at /home/rene/software/aspect/source/simulator/core.cc:716
#5  0x000055555a5fee5b in aspect::Simulator<2>::set_initial_temperature_and_compositional_fields (this=0x7fffffff8b40)
    at /home/rene/software/aspect/source/simulator/initial_conditions.cc:232
#6  0x000055555a5bfb20 in aspect::Simulator<2>::run (this=0x7fffffff8b40) at /home/rene/software/aspect/source/simulator/core.cc:2211
#7  0x000055555b9b16de in (anonymous namespace)::run_simulator<2> (
    raw_input_as_string="# A simple setup for Earth convection model in a 2d shell\n# where the core mantle boundary (CMB) temperature dynamically evolves through time.\n# \n# This is a variation of dynamic_core.prm with a fully"..., 
    input_as_string="# A simple setup for Earth convection model in a 2d shell\n# where the core mantle boundary (CMB) temperature dynamically evolves through time.\n# \n# This is a variation of dynamic_core.prm with a fully"..., output_json=false, output_xml=false, output_plugin_graph=false, validate_only=false)
    at /home/rene/software/aspect/source/main.cc:672
#8  0x000055555b9abe7d in main (argc=2, argv=0x7fffffffd308) at /home/rene/software/aspect/source/main.cc:961

The offending variable is core_data.H which is NaN. At first glance this is surprising, because it is set in dynamic_core.cc:85, in the same function before dynamic_core.cc:137 which is in the backtrace above. However, I think the problem is the line dynamic_core.cc:99 in between the two lines above. I had to do a bit of digging, but it looks like both the postprocessor CoreStatistics and the boundary temperature plugin DynamicCore store a variable of type CoreData. In the first call to DynamicCore::update the member variable of DynamicCore is partially initialized (lines 84-85), then overwritten with the variable stored in CoreStatistics (line 99), then initialization continues assuming that the variable is already partially initialized.

I dont know why both plugins store a member variable of the same structure. I could guess that it had to do with serialization, i.e. because in the past postprocessors were serialized, but boundary temperature plugins were not, the variable in the postprocessor was used to serialize the structure. (this may be related to #6787, but I wasnt aware of the workaround in this plugin before).

[bangerth]

OK, I can trigger floating point exceptions again after fixing the issue in deal.II.

I looked into it and you're exactly right. Of course, the issue is: This was wrong before as well, and we used an uninitialized variable. It's just that nobody noticed. How do we proceed with this? I could of course just move the statement that initialized core_data.H down to after the copy of the core_data object, but I really wouldn't know whether that's the right thing..

@SiqiZhang Do you remember? Would you be able to help?