Implementations and use of J_EAConsumption, J_EAProduction and J_EAProfile are confusing

[GillisHommen]

J_EAProduction takes in a 'J_ProfilePointer' that should have normalized power as values.

J_EAConsumption takes in a 'J_ProfilePointer' that should have annual-consumption-fraction as values. (so for a 'flat' consumption profile the value for every timestep should be 1/8760)

J_EAProfile has its own internal array with consumption [kWh] per timestep; which can also be negative (production!)

And, for maximum confusion, the 'default' time-series for J_EAProduction and J_EAConsumption are stored in the same db_profiles excel without any explanation.

[GillisHommen]

Options to clean things up:

• Have multiple asset-types (consumption, production, etc.) that implement a 'profileAsset' interface.
• Make a single asset that combines the functionalities of the current consumption, production and profile assets.

What to do with fixed-assets that don't use an (quarter-)hourly profile? Like diesel/hydrogenVehicles? Let them also implement a 'profileAsset' interface, but with their own implementation?
Perhaps a better term is just fixedAsset, or fixProfileAsset, or nonFlexAsset...

[GillisHommen]

Additional requirements:
-Profiles/timeseries should have a start 'instant' in a common java dateTime format, as well as an 'increment' variable to set the resolution of the timeseries.
-Profiles/timeseries should have a 'unit' or 'type' enum, to differentiate between various types of profiles:

• Normalized power (currently used for wind/solar assets)
• Energy per timestep (such as 'kwartierwaarden')
• Normalized energy consumption (all values add up to 1)
• ...

More generally about asset-types; at the moment the class-inheritance structure goes mainly along the 'dimension' of functionalities, regardless of what kind of 'device' is being modeled. To assign a 'device-type' to an energy asset, we use OL_EnergyAssetType. (although of course there are specific implementations for specific 'devices', where the class and the physical device are 'the same', such as the building thermal model.
We can aim for, when possible, using existing J_EA child classes, and using the OL_EnergyAssetType entries for specific types of assets. (such as: gasBurner is basically a J_EAConversion with OL_EnergyAssetType = GasBurner) When J_EAConsumption, J_EAProduction and J_EAProfile are merged, this will become extra important as the OL_EnergyAssetType will be the only differentiator. That differentiator is used for accounting of energy flows for different EnergyAssetTypes, even when they share the same class because they use the same functionalities.

[Erikvv]

Additional requirements:

• track if data is original, synthetic or fudged
• a single interface which can be backed by an array or a lazy generator function
• be able to do basic arithmetic

task: define a basic interface (or a few)

[GillisHommen]

Making our own time-series object may also be a benefit for serialisation/deserialisation, as the Anylogic TableFunction object is not suited for serialisation using jackson.

[GillisHommen]

Idea is now to converge on a single implementation for these three assets, and add a 'unit' option-list to the profilePointer objects. There may still be child-types of the main 'profile asset', but they will only have a different constructor (as they use different input parameters), but share the same implementation as defined in the parrent class.

For now, we keep using the anylogic TableFunction object to store the timeseries. When we have our own suitable alternative, it's probably fairly easy to substitute.

[GillisHommen]

TableFunction has also been phased out from profilePointer too and replaced with a regular array, timestep and starttime.

[GillisHommen]

A cleaner structure has been implemented in #243