Fix Constraint checkpointing

[jngrad]

Fixes #2943

Enable checkpointing of all Constraint classes which are not based on shapes. This also solves the iterator issue in #2943.

API change: it is now required to instantiate all Constraint classes with named arguments instead of positional arguments.

[codecov]

Codecov Report

Merging #3105 into python will increase coverage by <1%.
The diff coverage is 85%.

@@           Coverage Diff           @@
##           python   #3105    +/-   ##
=======================================
+ Coverage      83%     84%   +<1%     
=======================================
  Files         530     530            
  Lines       26141   26142     +1     
=======================================
+ Hits        21954   21967    +13     
+ Misses       4187    4175    -12

Impacted Files	Coverage Δ
src/core/field_coupling/fields/Interpolated.hpp	100% <100%> (ø)	⬆️
src/script_interface/constraints/fields.hpp	91% <100%> (+15%)	⬆️
src/script_interface/get_value.hpp	86% <75%> (-1%)	⬇️
src/core/electrostatics_magnetostatics/p3m.cpp	85% <0%> (-1%)	⬇️
...script_interface/constraints/ExternalPotential.hpp	75% <0%> (+5%)	⬆️
src/script_interface/constraints/ExternalField.hpp	88% <0%> (+5%)	⬆️
src/script_interface/constraints/couplings.hpp	65% <0%> (+8%)	⬆️
src/core/constraints/ExternalPotential.hpp	100% <0%> (+10%)	⬆️
src/core/constraints/ExternalField.hpp	100% <0%> (+10%)	⬆️
... and 1 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e2e7c5d...4382a4a. Read the comment docs.

[jngrad]

@fweik I'm not sure how to interpret the ASAN error stack-use-after-scope here. It's triggered by:

espresso/src/script_interface/constraints/fields.hpp

Lines 144 to 150 in e2e7c5d

	{"_field_data", AutoParameter::read_only, [this_]() {
	auto &field_data = this_().field_data();
	auto data_ptr =
	reinterpret_cast<const double *>(field_data.data());
	return std::vector<double>(
	data_ptr, data_ptr + codim * field_data.num_elements());
	}}};

When adding a printf to show data_ptr[0], it becomes an ASAN heap-use-after-free error. Is the boost::multi_array returned by this_().field_data() holding an array that has been freed by the time we run the lambda in the AutoParameter constructor above? Here is the field_data() function:

espresso/src/core/field_coupling/fields/Interpolated.hpp

Line 94 in e2e7c5d

storage_type const &field_data() const { return m_global_field; }

This issue didn't show up before because field_params_impl<Interpolated<T, codim>>::params() isn't tested.

[jngrad]

The two ASAN errors stack-use-after-scope and heap-use-after-free are now gone in the Clang version installed in the docker image after 74ff66e. On the older Clang version installed at the ICP, an ASAN error is still raised but it doesn't show a backtrace nor an error message, only the string "((IsAligned((uptr)ptr, alignment))) != (0)" (0x0, 0x0) (fixed by D44404 in our Docker image). Still not sure why the boost::multi_array would be memcopied somewhere else and the original array freed in the middle of a simulation setup.

[jngrad]

Nevermind, the cryptic error message fixed by D44404 pops up everywhere when running the core unit tests of the python branch with our outdated Clang compiler. We can safely ignore it.

[jngrad]

bors r=RudolfWeeber

[bors]

Build succeeded

• ICP GitLab CI