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.