Compute weekdays

[Mathadon]

I propose to add the functionality to compute weekdays. This requires a link to be made between the Modelica variable time and our calendar system. Therefore there must be a way for the user to specify what it means if time = 0. For instance time = 0 may mean that it's either

1. new year 2014,
2. new year 2015,
   etc..
3. new year 1970 (corresponding to unix time stamp = 0)
4. some custom date

Since the concept of time is linked to the input file I propose to add it in Annex60.BoundaryConditions.WeatherData.ReaderTMY3. This way it can also be integrated easily into IDEAS.

I'll propose an implementation that is disabled by default.

This relates to open-ideas/IDEAS#534

[Mathadon]

@mwetter I'd like to merge this into IDEAS. Can I expect a review in the coming days? Otherwise I'll just copy over the code manually for now!

[Mathadon]

@rubenbaetens if you're interested to verify as well..?

[mwetter]

@Mathadon
I reviewed most of the code and have a few comments and an issue :(

My issue is that I think setting t=0 for anything other than Jan 1 midnight is dangerous and we should not allow the user to do so. I believe the parameters monthRef etc are meant to allow the user to set monthRef=6 and then the Modelica variable time=0 would mean it is June 1. Why is this a bad idea? First, all models that use time, such as the ones that compute the position of the sun will assume it is January 1, but the user expects the simulation to simulate June 1. Second, if a user uses a yearly schedule, such as the weather data, or maybe another schedule with measured data, then this schedule likely has t=0 for Jan 1 (anything else would be surprising in my view). If this schedule is read with CombiTimeTable, it would at time=0 read the value for Jan 1, not for June 1, as the user may expect. Hence, I think that allowing monthRef etc to be a parameter can cause users to make errors that they are not likely to detect. I therefore recommend to remove these parameters.

I also added some other fixme as old implementations are not deleted, and as you can make the model more efficient by avoiding events. Please see the code.

Also, the regression tests fail:

RunScript("/home/mwetter/Desktop/test/modelica-annex60/Annex60/Resources/Scripts/Dymola/Utilities/Time/Examples/CalendarTime.mos");
simulateModel("Annex60.Utilities.Time.Examples.CalendarTime", stopTime=1e+08, numberOfIntervals=0, outputInterval=1001, method="dassl", resultFile="CalendarTime");
 = false

=======================
Log-file of program ./dymosim
(generated: Tue Aug  9 22:08:07 2016)

dymosim started
... "dsin.txt" loading (dymosim input file)
(j>=1)&&(j<=dim)
The following error was detected at time: 0
Index out of bounds
First evaluation failed for non-linear solver.

(j>=1)&&(j<=dim)
The following error was detected at time: 0
Index out of bounds
Non-linear solver will attempt to handle this problem.

(j>=1)&&(j<=dim)
The following error was detected at time: 0
Index out of bounds
Non-linear solver will attempt to handle this problem.

ERROR: Failed to solve non-linear system using Newton solver.
To get more information: Turn on Simulation/Setup/Debug/Nonlinear solver diagnostics/Details
Solution to systems of equations not found at time = 0
   Nonlinear system of equations number = 1
   Failed to evaluate any residual. Try to give better start-values.
   Iteration is not making good progress.
   Accumulated number of residue calculations: 2
   Last values of solution vector:
calendarTime2016.timOff = 1E-08
(j>=1)&&(j<=dim)
The following error was detected at time: 0
Index out of bounds
First evaluation failed for non-linear solver.

(j>=1)&&(j<=dim)
The following error was detected at time: 0
Index out of bounds
Error: Failed to start model.

[Mathadon]

Regarding the first and second issue. I agree that this is a problem. This is the reason why I originally suggested to put this model in Annex60.BoundaryConditions.WeatherData.ReaderTMY3. And from there send the 'correct' time to any other models that would require this. Would this be an option?
Alternatively I would set final montRef=1 etc such that we can keep the code?
Or another alternative: throw a warning when monthRef>1.

I will have a look at the error. It worked for me but I guess I made some last-minute changes.

Edit:
the error was caused by merging two initial algorithm sections into one. This caused dymola to be unable to properly order the equations such that blocks of code could be solved in sequence, i.e. a mixed system of equations was formed, which could not be solved.

[Mathadon]

I addressed most of the fixme's.

Todo:

• agree on how to integrate this with ReaderTMY3
• solve fixme in example

[mwetter]

Setting final Real monthRef=1 (and all other similar parameters) is fine, but then this constant may as well be removed unless having it aids in readability of the code.

If we have final Real monthRef=1 etc then there is nothing we need to do with ReaderTMY3, or is there? Note that TMY3 data do not have leap years. From www.nrel.gov/docs/fy08osti/43156.pdf

2.5 Leap Years
TMY2 and TMY3 files do not include data for February 29. Consequently, data for February 29 were not used in leap year Februarys to determine their candidate month CDFs. However, to maximize the use of available data, data for February 29 were included for determining the long- term CDFs.

[Mathadon]

I prefer to keep the implementation since some people may then easily change to code to get the added functionality (i.e. this is what I will do in IDEAS).

There is no need to change ReaderTMY3 although it may be convenient that the model contains date/time/hour etc for occupancy schedules etc.

[Mathadon]

I think I fixed everything!

[mwetter]

@Mathadon

Can you please address the following:

• The info section says "The block currently contains support for the calendar of 2010 up to 2020." and further down "The user can choose from new year, midnight for a number of years, including 1970..." . This is not clear. Is 1970 to 2020 supported?
• Address new "fixme"
• The parameter timRef allows "user specified". Should this be removed now, or how would one specify it?
• Do we need hourRef, minuteRef, secondRef as these are just used to add and multiply by zero.
• Please check that making some parameters to be final constant is OK.
• At t=1800, the regression test has calendarTime2016.hour = 0, but minutes are calendarTime2016.minutes= 1.4E9, with units of seconds (in the plot). Shouldn't minutes be 30?
• If hours only take on integers, it should be an integer output (and similar for other quantities that only take on integers).
• The model seems to trigger a state event every hour. This can be avoided using a when condition.

Note that protected parameters should still be final. Consider the following correct code:

package Test

model m1
protected
  parameter Real one = 1;
end m1;

model m2
  extends m1(one=2); // This is correct, but probably not what model m1 wants
end m2;
end Test;

[Mathadon]

When timRef=Custom the user may used yearRef to define the year when t=0. This may still be useful if the user wants to use an integer to specify the year, rather than working with the enumeration. I adjusted the parameter comment to clarify this.

I removed hourRef, minuteRef, secondRef since this was a bit overkill.

Final constant is not what I had liked, but ok.

Clearly there was a bug where minutes should indeed equal 30. Not sure how I overlooked that.. Thanks! I updated unit test results.

You got me confused now about the Real/Integer output. I thought we changed it to Real outputs to have the same output as minutes? I guess your suggestion was then to not round off the hours? I would like to have a proper (i.e. not decimal) hour, so I should revert to the previous implementation then?
We could also have outputs for both.
I.e. if it's 16:15 we can have IntegerOutput hourInt=16 and RealOutput hour = 16.25?

Having a state event every hour in an optional model does not seem problematic to me. I therefore prefer to have a clear implementation using floor() and rem() instead of having to resort to more complicated code. Moreover this is a bug that should be fixed in Dymola in a future release and even using a when statement may not be sufficient since tim is a model input and Dymola does not seem to take into account that an input may be a function of time only.

[mwetter]

@Mathadon : can you please have a look at the 'fixme' comments on version ec05cf7 (branch issue501_weekDay) and address them.

[mwetter]

@Mathadon

I revised Examples.CalendarTime to remove the state events, as state events were present in Dymola, JModelica and OpenModelica.

Interestingly, the computing time did not decrease much, probably because the events are easy to compute for this model. However, as this model likely is to be used with a controller, I think the new implementation is better as the events are exactly triggered at the full hour, rather than having to be approximated by the state event detection algorithm. This is in my view important because if you have two models that sample at the full hour, such as this model and a controller with a sampling rate of say 2 minutes, then you want the events to be simultaneous. This cannot be guaranteed if one of the model uses a state event, rather than a time event.

I also tried an implementation using Clock() but this is not supported yet in JModelica, and neither in IDA-ICE as far as I know.

However, there are still some issues, as I think the design with using GMT does not work for other time zones. See the comment near the 'fixme'.

[Mathadon]

I addressed the fixme's!

I think that (implementation-wise) it does not matter whether time=0 corresponds to unix time stamp GMT or local time as long as time and timeReference use the same convention. Therefore I changed 'GMT ' to 'local time' to avoid confusion. I think this addresses the problem?

I renamed timRef / TimeReference to zerTim/ZeroTime