[FEATURE] initialize input/update/output data to nan

[petersalemink95]

Input, update and output data needs to initialize as nan.
To do this, update the code generation functions + rerun.

Some unit tests depend on the fact that the input/update/output data defaulted to zero - these have to be explicitly set to zero.

[mgovers]

i think we can add the good first issue label to this, no?

[TonyXiang8787]

@mgovers

After some experiments I have found this is not as straightforward as we thought. We actually rely on the fact that the current value initialization of the structs is zero, not only in some test code, but also in the calculation core. See an example below:

power-grid-model/power_grid_model_c/power_grid_model/include/power_grid_model/component/branch.hpp

Lines 146 to 150 in 887cf99

	template <symmetry_tag sym> BranchOutput<sym> get_null_output() const {
	BranchOutput<sym> output{};
	static_cast<BaseOutput&>(output) = base_output(false);
	return output;
	}

We are currently relying the value initialization to zero when we want to create a zero-ed output struct. If we change the default value to nan, we have to explicitly write zeros above for all attributes, which can be done. I just wonder which do we prefer.

[mgovers]

hmmm... this is indeed tricky.

relying on zero-initialization while the components' default values are not provided is quite dangerous in the first place (except if explicitly {} is provided).

maybe a shorthand for get_component_nan would be useful? e.g.

template <symmetry_tag sym> get_zeros<BranchOutput<sym>>;
template <symmetry_tag sym> get_nans<BranchOutput<sym>>;

in the types itself, we can also do something to explicitly ask for certain default values, e.g.

namespace initialize_with {
struct zeros_t{};
struct nans_t{};

constexpr zeros_t zeros_v{};
constexpr nans_t nans_v{};
} // namespace initialize_with

typename <symmetry_tag sym>
struct BranchOutput {
  // attributes

  BranchOutput() = default;
  BranchOutput(initialize_with::zeros_t /* tag */, ...);
  BranchOutput(initialize_with::nans_t /* tag */, ...);
};

// usage
auto const branch_output = BranchOutput<symmetric_t>{initialize_with::zeros_v, ...};

but then it becomes impossible to provide e.g. only a subset of the attributes unless we explicitly provide an initializer list overload (which i think is overengineering).
the question then is whether disallowing partial specification would be a bad thing...