ekblad
commented
3 years ago it sounds like you could evolve reservoirs (very cool). this would avoid the generation of state changes beforehand, and lend computational adaptability during a simulation.
finding some sort of list-like representation and applying a GA is a good general approach for these types of applications. consideration of the total complexity of the reservoir "space" that you are searching over must be taken (estimate how many possible reservoirs there are), in order to appropriately constrain your search. this usually looks like a representation length bound or something similar.
there are a couple of complexity measures that could be helpful for determining the overall expressiveness of the reservoir object as a function, such as Vapnik–Chervonenkis dimension and Rademacher complexity. (how flexible should our reservoirs be?)
your (1) and (2) roughly correspond to structural (crossover) vs. parametric (mutation) changes to me, and maybe they could be generically treated as such. you just need a way to collapse a reservoir object into a mutable, reconstructible representation, like a parser, or mapping.
JohnRushKucharski
https://github.com/JohnRushKucharski/canteen/blob/e5dcf2372aecb3d93992b485d22a31b457f9f442/src/reservoir.py#L10-L10
How should reservoir state changes, from depreciation, broken gates, etc. be incorporated into the canteen project?
For instance, is a list of reservoirs containing state change generated before a simulation (so that the reservoir objects themselves are still immutable) or is instance of the Reservoir class mutated?
There are a few styles of state changes that need to be considered:
(1) step changes (i.e. a broken [stuck closed] or repaired gate) that might be modeled by deleting a element in the gate list, or setting a property (like the capacity).
(2) smooth changes (i.e. sedimentation, or generic depreciation of the asset - and its functionality) that might be modeled as a functional change, e.g. state = f(time, past storage or inflow, etc...)
This also has implications for the simulation module (which accepts a reservoir not a list of reservors). If the reservoir is made mutable (the simultion would not need to change (its state could be driven by the simulation), if it remains mutable a seperate simultation object might need to be constructed (or a multiple dispatch might need to be added - or something like that).