[FEATURE] Incrementally update topology parameters when there is a parameter change

[TonyXiang8787]

Background

When the PGM get updated, we check if the topology is changed and/or the parameters are changed. For topology change we need to rebuild the whole topology. For parameter change we need to update the parameters in the math model.

Currently, we recalculate all the parameters in the math model. This is significant work. Mathematically, we just need to update the parameters which are impacted by the change.

Improvement

We propose to only update the math parameters incrementally when there are some changes.

1. Remove the single boolean status topology_param_up_to_date. Make a track of all the changed components which have impact on math parameter.
2. In the update parameter function, only calculate the math parameter of those components. And update them incrementally in the math model, mainly YBus class.

Consideration

Currently the mathematical parameters are stored as std:shared_ptr<const T> in the YBus. This makes sharing between the threads easy. But if we want to update the value, we have to re-allocate the whole struct and copy the old values. We need to think the trade-off of using std:shared_ptr<const T> or just by value.

[mgovers]

Most of this was resolved in #444 . Only removal of construction of all math parameters in main_model.hpp is left

[TonyXiang8787]

This has been implemented in #444

[mgovers]

Most of this was resolved in #444 . Only removal of construction of all math parameters in main_model.hpp is left

So we're not going to go all the way.

[TonyXiang8787]

Most of this was resolved in #444 . Only removal of construction of all math parameters in main_model.hpp is left

So we're not going to go all the way.

What do you mean removal of construction of all math parameters in main_model.hpp?

[mgovers]

Most of this was resolved in #444 . Only removal of construction of all math parameters in main_model.hpp is left

So we're not going to go all the way.

What do you mean removal of construction of all math parameters in main_model.hpp?

https://github.com/PowerGridModel/power-grid-model/blob/main/power_grid_model_c/power_grid_model/include/power_grid_model/main_model_impl.hpp#L1180-L1307

in this code section, we always calculate the calculation_parameters for all components, even if only one of them is updated. We can cache that and only calculate the calculation parameters for the components that have changed.

[TonyXiang8787]

Most of this was resolved in #444 . Only removal of construction of all math parameters in main_model.hpp is left

So we're not going to go all the way.

What do you mean removal of construction of all math parameters in main_model.hpp?

https://github.com/PowerGridModel/power-grid-model/blob/main/power_grid_model_c/power_grid_model/include/power_grid_model/main_model_impl.hpp#L1180-L1307

in this code section, we always calculate the calculation_parameters for all components, even if only one of them is updated. We can cache that and only calculate the calculation parameters for the components that have changed.

So we always calculate all the parameters, and for incremental update, we only use some of them to update the YBus?

If that's the case, we can indeed further optimize. Please create a separate ticket to explain the issue.

[mgovers]

Most of this was resolved in #444 . Only removal of construction of all math parameters in main_model.hpp is left

So we're not going to go all the way.

What do you mean removal of construction of all math parameters in main_model.hpp?

https://github.com/PowerGridModel/power-grid-model/blob/main/power_grid_model_c/power_grid_model/include/power_grid_model/main_model_impl.hpp#L1180-L1307
in this code section, we always calculate the calculation_parameters for all components, even if only one of them is updated. We can cache that and only calculate the calculation parameters for the components that have changed.

So we always calculate all the parameters, and for incremental update, we only use some of them to update the YBus?

If that's the case, we can indeed further optimize. Please create a separate ticket to explain the issue.

done in #766