You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reported by beutlich on 30 Apr 2014 11:29 UTC
The blocks Modelica.Blocks.Sources.TimeTable and Modelica.Blocks.Sources.CombiTimeTable require the first column of the table matrix/array to be in the SI unit Seconds. Unfortunately there is no unit handling (possible) for array data but Seconds is somehow unsuitable for weather data (where units can be in Hours, Days etc.) and leads to nicely tuned tables like seen in Buildings.Examples.Tutorial.Boiler.System1
I propopse to add a new, non-zero parameter timeBase of type Modelica.SIunits.Time that is used to scale the input time of the time table. See the demonstrative model.
model A parameter Modelica.SIunits.Time timeBase(min=Modelica.Constants.eps)=1"Time base of first table column";
Real y "Scaled time";
equation
y = time/timeBase;
end A;
The milestone is MSL3.2.1 since this tiny enhancement can be done in a backward compatible way.
If there is no contribution to this enhancement within the next two weeks (till 14th of May 2014) I consider this as agreement and will perform the above proposed changes. Nevertheless I hope to see some contribution from members of ModelicaTablesList and other readers.
I know there was an article about general unit and type safety for table data at the last MoCo but this is compeletly out of scope here.
Comment by beutlich on 16 May 2014 11:40 UTC 70f01e3 introduces a new parameter timeScale for TimeTable and CombiTimeTable. Since it was not a single line change I decided to only add to the trunk (i.e. MSL > 3.2.1).
The fix is physically correct w.r.t. to quantities and units. The table is unitless, especially is the first column that previously was interpreted as time axis. Thus if a unitless, scaled timeScaled=time/timeScale is used the table look-up does no longer depend on units.
There is one small issue in CombiTimeTable though. Parameters t_min and t_max are of type SIunits.Time and previously returned the min/max abscissa values of the table. I decided to keep the units for t_min/t_max therefore they now return the scaled min/max abscissa values (which breaks backward compatibility in case timeScale is not equal to one). The original min/max values of the table are returned by new parameters t_minScaled/t_maxScaled, respectively.
Changelog modified by beutlich on 16 May 2014 11:40 UTC
Added new parameter timeScale to Modelica.Blocks.Sources.TimeTable and Modelica.Blocks.Sources.CombiTimeTable to explicitly scale the first table column
Reported by beutlich on 30 Apr 2014 11:29 UTC
The blocks Modelica.Blocks.Sources.TimeTable and Modelica.Blocks.Sources.CombiTimeTable require the first column of the table matrix/array to be in the SI unit Seconds. Unfortunately there is no unit handling (possible) for array data but Seconds is somehow unsuitable for weather data (where units can be in Hours, Days etc.) and leads to nicely tuned tables like seen in Buildings.Examples.Tutorial.Boiler.System1
I propopse to add a new, non-zero parameter timeBase of type Modelica.SIunits.Time that is used to scale the input time of the time table. See the demonstrative model.
The milestone is MSL3.2.1 since this tiny enhancement can be done in a backward compatible way.
If there is no contribution to this enhancement within the next two weeks (till 14th of May 2014) I consider this as agreement and will perform the above proposed changes. Nevertheless I hope to see some contribution from members of ModelicaTablesList and other readers.
I know there was an article about general unit and type safety for table data at the last MoCo but this is compeletly out of scope here.
Migrated-From: https://trac.modelica.org/Modelica/ticket/1473
The text was updated successfully, but these errors were encountered: