Decision on unit system for simulator and simulator-core

[MichielTukker]

Simulator/Simulator-core will be using SI unit system internally and for its output.

Questions:

• [x] What is Mapeditor/Esdl using? @edwinmatthijssen
• [ ] Communicate with TPG/frontend teams, they need to convert for visualisation? @WouterSpaak
• [ ] Unit system for Database structures? (@TNO-SlaFleur ?)

[edwinmat]

There's two answers. And they both relate to the ESDL language (The MapEditor just follows the ESDL 'conventions'):

• standard attributes of ESDL objects/assets have a default unit as defined by the ESDL language itself. You can query the ESDL meta model to find out about the unit. Also the unit is mentioned in the documentation automatically whenever we update the language model and regenerate the documentation. Most of them are SI units, with very few exceptions. I remember we had a long discussion about one unit for a specific parameter (I can't remember which), where everybody uses a non SI unit. In that case, we choose to 'common unit' instead of the SI unit.

• On a lot of other places where users can attach profiles, the user MUST specify the unit (and the quantity) himself, by adding a QuantityAndUnit object to the profile. For example, this is the case for cost profiles, energy profiles, temperature profiles, pressure profiles, and so on. And please be aware, we also have SingleValue profiles, to represent one value.

W.r.t. the databases.... It could be the case (but I don't have the complete overview) that all information in a database is referenced to from an ESDL. Then the ESDL indicates what unit is meant.

[lfse-slafleur]

@MichielTukker For what interactions do you expect to need access to the postgresql db? (or are you referring to a different db?) We of course also have the protocol between frontend/backend en between the orchestrator and worker/simulator. Whatever units choose, lets try to be consistent. I would be more than happy to just use SI everywhere we can/is relevant. Specifically timestamps I would propose to use unix epoch.

[vanmeerkerk]

@MichielTukker and @samvanderzwan can we close this issue?

[samvanderzwan]

Yes, Internally omotes simualotr core will use SI. Conversion will be done at import, when needed

[samvanderzwan]

Will close this issue

[edwinmatthijssen]

Just came back from holidays, not sure if replying to the email is still required (and works) but I’ll give it a try.

In MapEditor/ESDL there are two cases:

• For simple attributes of classes the unit is standardized by the ESDL language (power is in Watt). For 99% of the cases we choose SI units, but there are some exceptions (which I don’t remember by heart) where we deviated from the SI units (mostly by an explicit request from the user/project/use case).
• For profiles (and this can be single value profiles, ranges, time series) the user can (or must) specify the quantity and the unit him/herself. This is fully flexible (for example costs can be in EUR, MEUR, kEUR, EUR/MW, MEUR/GJ or whatever…), but requires users to be explicit. The MapEditor provides some support to make this easy from an end user perspective.

From: Michiel Tukker @.> Sent: donderdag 5 oktober 2023 15:39 To: Nieuwe-Warmte-Nu/simulator-core @.> Cc: Matthijssen, E.F. (Edwin) @.>; Mention @.> Subject: [Nieuwe-Warmte-Nu/simulator-core] Decide on unit system for simulator simulator-core (Issue #10)

Simulator/Simulator-core will be using SI unit system internally and for its output.

Questions:

• [ ] What is Mapeditor/Esdl using? @edwinmatthijssenhttps://github.com/edwinmatthijssen
• [ ] Communicate with TPG/frontend teams, they need to convert for visualisation? @WouterSpaakhttps://github.com/WouterSpaak
• [ ] Unit system for Database structures? @.***https://github.com/TNO-SlaFleur ?)

— Reply to this email directly, view it on GitHubhttps://github.com/Nieuwe-Warmte-Nu/simulator-core/issues/10, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKJ4KQ7DQ5NZ3NGZ3LWTMRDX522AHAVCNFSM6AAAAAA5UI7QSCVHI2DSMVQWIX3LMV43ASLTON2WKOZRHEZDQMZRG4ZTCNI. You are receiving this because you were mentioned.Message ID: @.**@.>>

-- This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.