Conditions refactor

[ffelten]

Currently, conditions are limited to scalar values. We'd like to extend this support to other data types: 2d arrays, graphs, etc.
Find a way to encode the dimensions and bounds, and make it easy to pass to algorithms.

Idea: use Gymnasium spaces as for the design_space.

Also, conditions in dictionaries and classes used for constraints duplicate the information. Find a way to unify this.

[g-braeunlich]

Pushed a 1st step: Deduplication of constraints and conditions.
Also note that this additionally reduces the complexity of the constraints. Previously, we had to declare dataclasses inside __init__ of some problems, just to pin some instance variable as default values to the dataclass.
Now: dataclasses only at class level, instance level variables will be stored in dataclass instances.

The idea now is that both Config and Conditions declare types, constraints and defaults and Config inherits from Conditions => no duplication.
There is also a new utils.upcast.upcast() function which allows upcasting Config -> Conditions (restricting to the fields of Conditions).

If you like the idea, I would also adapt the docs.

Further steps:

• Split Config into ConfigSimulate and ConfigOptimize? -> Getting rid of constraint categories?
• Have a look at gymnasium spaces (but honestly, I did not see yet an advantage of using spaces here. What did you have in mind?)
• Introduce wrapper classes for np.array, providing named views into the array, i.e. giving names to slices or elements. There we also potentially could introduce the constraint api. Especially having power electronics in mind here.

[ffelten]

@g-braeunlich could you make a PR so I can see the changes?

• I do not think this is the most pressing matter, most of the problems have a lot of common config fields between simulate and optimize.
• They are very useful on the ML side: size the neural networks, get boundaries on components, flatten/unflatten spaces.
• Eager to see a proto API of this :).

[g-braeunlich]

Yes, sorry. I am too much used the gitlab workflow, which automatically would have created a PR (MR)

[g-braeunlich]

They are very useful on the ML side: size the neural networks, get boundaries on components, flatten/unflatten spaces.

But are there also useful in this context (declaring defaults, conditions and constraints)?
Constraints I can see a bit, but only to a limited extend, or do I miss something?

[ffelten]

AFAIK, we don't use them for constraints and conditions for now. It was proposed somewhere to rely on this for multidimensional conditions (to describe their size and bounds), but I agree it is probably not the best fit.