How to deal with ConfigGroup.setLocked() when modifying config entries during a simulation run?


It appears as if the decision has been made to keep config group parameters immutable throughout a simulation run. I assume that this is for consistency reasons, presumably because the controler reads config information only once upon startup such that later changes may not automatically carry through to the simulation logic.

This obviously leads to problems for any algorithm that changes config parameters during the simulation. Optimization is one example, calibration is another one.

From what I see, such algorithms would now have to duplicate the config container, to not lock the duplicate, to then make within-simulation changes to the duplicate, and to re-build the relevant objects (in my concrete case, ScoringParameters) from the duplicate.

Apart from being awkward (I cannot find a "deep copy" function in the config), the original design of locking the config would still be invalidated, just now the other way around: simulation parameters are changed, but the config is not updated.

Locally replacing by a c&p version that does not have lock is becoming a tempting option...




Gunnar Flötteröd
October 6, 2019, 8:32 AM

My problem with this disappears when replacing the entire CharyparNagel scoring infrastucture. Not sure if this is of any broader interest, hence closing the issue.

Kai Nagel
October 6, 2019, 6:21 PM

The problem is exactly as you say: Things are read from config and then kept elsewhere in memory, and in consequence we are trying to lock those config params where that happens. Not sure if that makes me happy, but it is the way it is. And it seems to be the way people learn this in software design (“defensive copies”).

I would, however, not be against changing this. The scoring functions are constructed anew in every iteration anyways. Thus, there is really no reason to cache the parameters somewhere.




Gunnar Flötteröd