ModelicaSpecification
ModelicaSpecification copied to clipboard
modelica
Absolute time in Modelica (datetime)
Reported by leo.gall on 11 Apr 2018 06:41 UTC Probably this has been discussed before, so please point me to the old discussion, if I wasn't able to find it:
In Modelica we currently only have the built-in variable "time". For applications with longer simulation times and connection to real-time it would be good to have a safe synchronization to the absolute "kitchen time" (don't know the proper term for it).
In Matlab there are datetime (https://de.mathworks.com/help/matlab/ref/datetime.html?requestedDomain=true) data types to handle this.
From my point of view, it would be good to have a similar concept in the Modelica language. Then tools could support the user when importing boundary conditions and plotting these results in a better way.
Migrated-From: https://trac.modelica.org/Modelica/ticket/2245
Comment by leo.gall on 11 Apr 2018 06:45 UTC Important applications are:
- building simulation
- district heating
- battery aging ...
Comment by beutlich on 11 Apr 2018 11:00 UTC Not quite sure what your exact requirements are. Do you want to use absolute time for post-processing only (of e.g., yearly simulations), then it sounds like a tool issue for me. It also is kind of supported in libraries by block Buildings.Utilities.Time.CalendarTime or function Modelica.Utilities.System.getTime based on the Unix time stamp. Or, do you want to do real calculations with dates and times during transient simulation?
Comment by leo.gall on 12 Apr 2018 09:23 UTC Thank you for the hint to Buildings Library, I didn't know this block.
But, my idea was to really be able to work with date/time types in Modelica (so that the language and all tools know about this variable is a data/time stamp). data/time is not really a unit, but something similar to the "time" variable of Modelica.
Having this data type, a user could:
- Tell his Modelica tool to something like experiment(startTime = "2018-01-01 0:00", stopTime = "2019-01-01 0:00")
- Import boundary conditions with CombiTimeTable, not worrying about shifting time axes.
- A Modelica tool could know about days, weeks etc. (automatic plots showing week ends, holidays ...)
Lots of these features could be implemented in a tool-specific way. Some parts could be handled in MSL, but I don't think we could do it nicely. But, I think it would be worth to standardize so MSL, Buildings Library and others feel in the same way.
What do you think?
Comment by mwetter on 12 Apr 2018 22:58 UTC Date/time types for the use cases pointed out by Leo Gall would be very useful for building and district energy simulations. In addition, a function that adjusts time for daylight saving would be needed, as this affects when buildings are typically occupied.
Comment by cbuerger on 13 Apr 2018 08:15 UTC To provide "human readable" time ("kitchen time" :)) and functions to transform such should be part of the standard library and not of the language as such in my opinion; I don't think it is a good idea to introduce new keywords or language constructs but would rather suggest to improve respective facilities in the MSL.
If that is not sufficient for any reason, it would be good to give examples why; where exactly is the Modelica language as such lacking that could not be done properly given more advanced MSL functionality?
Comment by stefanv on 13 Apr 2018 13:53 UTC I think Christoff is right. This sort of functionality belongs in a (standard) library, not the language itself.
Comment by sjoelund.se on 13 Apr 2018 14:05 UTC I agree most of the functionality does belong in a standard library, but most likely for Modelica there needs to exist something more for tools to handle setting dates in a given timezone correctly. I assume the standard library might choose to use the time variable as a Real number of seconds corresponding to Unix start time; writing a library to convert strings and numbers back and forth is fine.
But I think it's sort of the same things as the color/file pickers and perhaps something for experiment to say that times are Unix times in some timezone (or UCT and to display a different time?). It could be done with some vendor annotations, but they are not allowed in the MSL.
Comment by hansolsson on 13 Apr 2018 15:12 UTC I agree that most of the work should be in e.g. MSL. However, we might need to know whether time is absolute in this sense, or not.
Thus since we allow the annotation startTime=0.2 in the Modelica Language we might generalize this to allow startTime = "2018-01-01 0:00" as suggested above (and the same for stopTime).
That seems like a minimal change in the language.
Tools can already now support this when setting up simulations, and just mark this simulation specially in the result file to allow different plotting. -- As for the details in general absolute time might not be "Unix time", but seconds in an "epoch"; which could be "Unix epoch time" - January 1st 1970.
The first question is if this is good enough:
The only minor inaccuracy is leap-seconds, and I believe that building simulations measurements aren't that accurate anyway.
The precision if using double is currently about a third of a micro-second, which seems precise enough. There would be problem if someone used e.g. rapid pulse-width-modulations with shorter intervals as heat-source, but I don't see anyone doing that in a building simulation due to scaling issues.
Anyway if that were a problem the solution would be to have a way of setting the epoch. (Note that this is different from the accuracy problem.)
If the functions are constructed in a good way that shouldn't be a problem, i.e. if we have a function to return "time in epoch" where epoch is an argument with default corresponding to e.g. January 1st, 1970 it wouldn't matter if another epoch is used behind the scenes. Another reason for having epoch as an argument to such a function is that I assume people want to import data from e.g. Excel and Matlab and as far I know they use different epochs.
Comment by anonymous on 16 Apr 2018 05:15 UTC Replying to [comment:8 Hans Olsson]:
Thus since we allow the annotation startTime=0.2 in the Modelica Language we might generalize this to allow startTime = "2018-01-01 0:00" as suggested above (and the same for stopTime).
That seems like a minimal change in the language.
Wouldn't it then be even simpler to just allow calling functions in the annotation? So you could do startTime = Modelica.Utilities.Time.fromString("2018-01-01 00:00", optionalFlags=???).
Comment by cbuerger on 16 Apr 2018 09:36 UTC Replying to [comment:9 anonymous]:
Replying to [comment:8 Hans Olsson]:
Thus since we allow the annotation startTime=0.2 in the Modelica Language we might generalize this to allow startTime = "2018-01-01 0:00" as suggested above (and the same for stopTime).
That seems like a minimal change in the language.
Wouldn't it then be even simpler to just allow calling functions in the annotation? So you could do
startTime = Modelica.Utilities.Time.fromString("2018-01-01 00:00", optionalFlags=???).
That's what I had in mind as well when thinking of MSL support. It would be great to utilize MSL functions in the experiment annotations to specify the start and stop times in a human readable format that at the same time is transformed by said functions to the time-format used internally by Modelica.
Comment by hansolsson on 16 Apr 2018 10:10 UTC
Both startTime = Modelica.Utilities.Time.fromString("2018-01-01 00:00", optionalFlags=???) and startTime="2018-01-01 00:00" would work, and either would be fairly simple to specify (currently the annotation is specified in terms of syntax - and allowing a string-literal is easier in that format; if we want to allow a function call it might be easier to just opt for allowing any expression - and have a semantic restriction that it should be a number).
However, using a function call is in itself not a complete solution.
In particular it would be good to know that the input above is actually a time (since it could be any function), so something like: {input String dateTime annotation(Dialog(dateSelector=true));.
The tool could then use this to present a reasonable dialog and verify the input.
But that would then lead to additional considerations:
- How to specify a time-interval? Perhaps just specify that one input is minimum for another in some way?
- What about the clock part?
However, this would also allow such functions for normal parameters in models.
Comment by anonymous on 23 Apr 2018 06:14 UTC
-
I think function calls would be a good solution, because it gives more flexibility.\ One example: you could have a function reading the first and last line of your boundary conditions (table files) and adjust the simulation time, accordingly.\ Probably, users would start trying to use model parameters in the startTime annotation. The question is, wether all tools would be fine with reading parameter values from the model in order to influence simulation time. It should be possible to access parameters after translation in order to use them as an argument to simulate model commands?
-
Yes, an annotation for dateSelector would also help to make tools "date-aware".
-
To Hans' question "time-interval": I don't have an answer. Maybe someone familiar with web programming knows better, because it is very usual to have these date/time fields with a start and end time. JavaScript seems to have a lot of conversion functions: https://www.w3schools.com/jsref/jsref_obj_date.asp
-
To Hans' question "clock part": I'm not sure how the clocked part would be affected by datetime? Did you think about complicated things like clocks ticking at each new day (including leap-seconds)?
-
Just a side-note: It would be good to transfer these time stamps into the result file. Unfortunately, even HDF-5 doesn't have support for datetime. https://stackoverflow.com/questions/23570632/store-datetimes-in-hdf5-with-h5py
Comment by leo.gall on 23 Apr 2018 06:15 UTC Forgot to log in, sorry! Last comment was by me.
There is an implementation now by @pstelzig https://github.com/pstelzig/DateTime
I did not test it, yet.
I think this is a potential feature for MSL? @casella
