increment simulation and recorders

2012-04-27
2016-05-14
  • Torben Veit

    Torben Veit - 2012-04-27

    It is possible to increment the simulation time? I mean that my incoming data ist faster than minutes.
    And if this is possible, where can I set this feature?
    The same question takes effect for the recorder object. Can I select data in millisecond,mikrosecond or maybe faster?

    The second question is can I create a residential object with multipe floors and defferent rooms? So I can simulate
    a hole building with every room every floor and even every plug?

     
  • Jason Fuller

    Jason Fuller - 2012-04-27

    The simulation time is designed to be flexible in GLD - time only updates when one of the objects signifies a desire for a state change.  So, for example, if you set your recording interval for 5 minutes, the simulation will be required to update MINIMALLY every five minutes.  However, within that five minute time frame, other objects may have required hundreds of updates at irregular time intervals.

    To force the simulation to update more often, you can decrease your recording interval down to 1 s (we currently do not support timesteps less than 1 second - subsequent versions of GLD are exploring this option).  This will require that every object update its state every second, and can significantly effect simulation time.

    Conversely, you can force GLD to ignore updates for a limited period of time by using #set minimum_timestep=60. This allows each object to internally update on its desired time intervals (down to 1s), but does not allow it to update its boundary conditions.  This creates a significant speed-up in simulation time, but does cause small errors, especially when control systems are branching across multiple objects.

    As for buildings, we only currently support a single-zone residential building model, effective for square footage up to roughly 3500 sq ft.  We do support multi-floor residential, but they are not specified independently.  If you are familiar with building energy simulation tools like EnergyPlus or DOE2, we do not go to that level of detail.  I like to say that we are somewhere about half way in between EnergyPlus-like models and current power system planning models (ZIP models with load shapes), capturing a lot of the general building behaviors and the effects on the power system, but not down to the detail of using economizers or multi-zone HVAC systems.

    You can find a more detailed description of the house model at:

    https://sourceforge.net/apps/mediawiki/gridlab-d/index.php?title=Residential_module_user%27s_guide

     
  • Varun Badrinath Krishna

    Hi Jason,

    I didn't fully understand: "you can force GLD to ignore updates for a limited period of time by using #set minimum_timestep=60. This allows each object to internally update on its desired time intervals (down to 1s), but does not allow it to update its boundary conditions."

    Assume I have an object that updates at a regular time interval of 20s and the minimum_timestep is set to 60s.
    At time 0s, the global clock calls my object's sync function. The function does what it needs to and returns 20s.
    At time 60s, the global clock calls my object's sync function. At this stage, my object might realize (if it recorded the last_sync_time) that the sync function was not called at 20s and 40s. So at 60s, what do the typical GridLAB-D objects do?
    a) Expect such a situation and execute their sync algorithms for 20s, 40s and 60s (one after another). For example, a waterheater might reach its maximum temperature at 40s and then switch off (causing the water to cool for a while). So its intermediate states (at 20s and 40s) are processed at 60s.
    b) Skip 20s and 40s and simply sync with 60s. This would assume that the intermediate events don't matter. Here the waterheater would heat the water past the maximum temperature (which would have happened at 40s) and realize only at 60s that the water temperature is way past the maximum temperature and that it needs to turn off.

    Also what exactly do you mean by boundary condition here?

    Thanks and Best Regards,
    Varun

     
  • Jason Fuller

    Jason Fuller - 2012-05-10

    Varun,

    That's a good question.  Let me clarify a little.

    The minimum_timestep is used to decouple the interactions of the different objects.  When not using this function, if one object requires the clock to stop and cause an update, then ALL objects are required to stop and re-synchronize.  This causes some major performance issues, especially with intensive algorithms like power flow. 

    For example, when running a feeder simulation with ~1000 homes, because of the diversity of the homes, the clock is stopped almost every second of the simulation.  However, there is very little effect on the powerflow, as load is only changing by a small percentage.  Now, depending upon your study, you may need this - say, the effects of a rapid drop in solar panel output.  But, when you are considering longer term energy effects, the slight change in voltage is somewhat overshadowed.

    So, the minimum timestep lets a user make that decision.  It lets each object update its clock just like normal.  However, it does not cause the entire simulation to pause and re-solve.  For your example above, (a) is very close to correct.  I say close to correct, because we don't usually have objects that update on a regular basis.  The requirements from GLD are that the objects return a time when their states would change considering no changes in boundary conditions.  For the water heater, the state transition would be when the temperature reaches its max allowable value (at 40s).  So, the first sync would be at 40s.  In normal operation, this would cause all 1000 houses to re-synchronize and re-calculate their next state transition.  With the minimum timestep, only the water heater will re-calculate.  At 60s, all of the objects will re-synchronize.

    Now, lets say you do have an object that requires multiple updates inside that one minute period.  Each of these will occur successively inside that object's sync cycle.  For your example, the global clock will try to advance, but this object would realize it needs some intermediate steps.  It will pause at +20s, re-calculate, and return its next update time (20 more secs or +40s).  The object's clock will advance to that time and re-calculate, then return it next update time.  At +60s, all of the objects will re-calculate and re-synchronize.  So, from the appearance of the global clock, this all occurred at the +60s mark.  However, the object in question tracks itself through the time interval just as it would have in a normal simulation, just without updating its information from other objects or causing other objects to re-calculate.

    Does this help?

     
  • Varun Badrinath Krishna

    Hi Jason,

    Thanks! This helps a lot!

    I'm am very clear about everything except this: "The object's clock will advance to that time and re-calculate, then return it next update time."

    Are you implying by "object's clock" that each object has its own clock that is independent of the global clock? My understanding is that there is only one clock in the system- the global clock (which would be more intuitive). So if the object needs to re-calculate, it can only do so when the sync function is called by the core. It cannot "track itself" (as you say), unless the core calls one of its sync functions. So my understanding is that the timing of every object's sync operations is entirely dependent on the core and global clock. The core maintains an event registry and advances the global clock to the next event. So an object cannot "track itself", "re-calculate" or do anything independently of the global clock.

    When the minimum_timestep is 60s, is this what happens?
    The core advances the global clock to the first event (say t = 20s), calls only that object's sync functions. It then advances to the next event (t=40s), calls only that objects sync functions. It then advances the global clock to 60s calls all objects sync functions. Only at 60s are objects synced with each other. Otherwise they are only synced with time. Even if the minimum timestep is 60s, the global clock will advance to 20s or 40s (or any t, where t < 60) in order to update an object. The only significance of 60s is that that's when objects sync with each other

    Please do correct me if I'm wrong.

     
  • Jason Fuller

    Jason Fuller - 2012-05-11

    Varun,

    What you said is correct - sorry for using "slang".  You are right, there is only one clock.  During the process, the global clock advances and only calls the required object's sync function at 40s, and not every other object, as would be done in a non-minimum timestep case.

     
  • Varun Badrinath Krishna

    Hi Jason,

    Thanks for the clarification! I'm sorry I didn't catch the slang! :)

    I actually tried to test my hypothesis with the metronome example and found that the results were unexpected.

    The metronome program is modified as follows (only the object is modified):

    //#set minimum_timestep=60
    class metronome {
            double bpm; // beats per minute
            int16 count; // beats left
            enumeration {TIC=0, TOC=1} side;
            timestamp last_t;
            intrinsic create (object parent) {
                    last_t = gl_globalclock;
                    return SUCCESS;
            };
            intrinsic sync (TIMESTAMP t0, TIMESTAMP t1) {
                    TIMESTAMP next_t = (TIMESTAMP)(last_t + 60/bpm);
                    if (t1==next_t) {
                            side = (side==TIC) ? TOC : TIC;
                            last_t = next_t;
                            count-;
                    }
                    return count>0 ? (TIMESTAMP)(last_t + 60/bpm) : TS_NEVER;
            };
    };
    module tape;
    object metronome {
            bpm 60;
            count 60;
            object recorder {
                    property side, count;
                    file "metronome1.csv";
                    interval 1;
                    limit 60;
            };
    };

    CASE1: No minimum time step.
    # file…… metronome1.csv
    # date…… Fri May 11 12:05:46 2012
    # user…… root
    # host…… (null)
    # target…. metronome 0
    # trigger… (none)
    # interval.. 1
    # limit….. 60
    # timestamp,side, count
    1970-01-01 00:00:01 GMT,TOC,59
    1970-01-01 00:00:02 GMT,TIC,58
    1970-01-01 00:00:03 GMT,TOC,57
    1970-01-01 00:00:04 GMT,TIC,56
    1970-01-01 00:00:05 GMT,TOC,55
    1970-01-01 00:00:06 GMT,TIC,54
    1970-01-01 00:00:07 GMT,TOC,53
    1970-01-01 00:00:08 GMT,TIC,52
    1970-01-01 00:00:09 GMT,TOC,51
    1970-01-01 00:00:10 GMT,TIC,50
    1970-01-01 00:00:11 GMT,TOC,49
    1970-01-01 00:00:12 GMT,TIC,48
    1970-01-01 00:00:13 GMT,TOC,47
    1970-01-01 00:00:14 GMT,TIC,46
    1970-01-01 00:00:15 GMT,TOC,45
    1970-01-01 00:00:16 GMT,TIC,44
    1970-01-01 00:00:17 GMT,TOC,43
    1970-01-01 00:00:18 GMT,TIC,42
    1970-01-01 00:00:19 GMT,TOC,41
    1970-01-01 00:00:20 GMT,TIC,40
    1970-01-01 00:00:21 GMT,TOC,39
    1970-01-01 00:00:22 GMT,TIC,38
    1970-01-01 00:00:23 GMT,TOC,37
    1970-01-01 00:00:24 GMT,TIC,36
    1970-01-01 00:00:25 GMT,TOC,35
    1970-01-01 00:00:26 GMT,TIC,34
    1970-01-01 00:00:27 GMT,TOC,33
    1970-01-01 00:00:28 GMT,TIC,32
    1970-01-01 00:00:29 GMT,TOC,31
    1970-01-01 00:00:30 GMT,TIC,30
    1970-01-01 00:00:31 GMT,TOC,29
    1970-01-01 00:00:32 GMT,TIC,28
    1970-01-01 00:00:33 GMT,TOC,27
    1970-01-01 00:00:34 GMT,TIC,26
    1970-01-01 00:00:35 GMT,TOC,25
    1970-01-01 00:00:36 GMT,TIC,24
    1970-01-01 00:00:37 GMT,TOC,23
    1970-01-01 00:00:38 GMT,TIC,22
    1970-01-01 00:00:39 GMT,TOC,21
    1970-01-01 00:00:40 GMT,TIC,20
    1970-01-01 00:00:41 GMT,TOC,19
    1970-01-01 00:00:42 GMT,TIC,18
    1970-01-01 00:00:43 GMT,TOC,17
    1970-01-01 00:00:44 GMT,TIC,16
    1970-01-01 00:00:45 GMT,TOC,15
    1970-01-01 00:00:46 GMT,TIC,14
    1970-01-01 00:00:47 GMT,TOC,13
    1970-01-01 00:00:48 GMT,TIC,12
    1970-01-01 00:00:49 GMT,TOC,11
    1970-01-01 00:00:50 GMT,TIC,10
    1970-01-01 00:00:51 GMT,TOC,9
    1970-01-01 00:00:52 GMT,TIC,8
    1970-01-01 00:00:53 GMT,TOC,7
    1970-01-01 00:00:54 GMT,TIC,6
    1970-01-01 00:00:55 GMT,TOC,5
    1970-01-01 00:00:56 GMT,TIC,4
    1970-01-01 00:00:57 GMT,TOC,3
    1970-01-01 00:00:58 GMT,TIC,2
    1970-01-01 00:00:59 GMT,TOC,1
    1970-01-01 00:01:00 GMT,TIC,0
    1970-01-01 00:01:01 GMT,TOC,-1
    # end of tape

    CASE2: Minimum time step is 60.

    # file…… metronome1.csv
    # date…… Fri May 11 11:59:27 2012
    # user…… root
    # host…… (null)
    # target…. metronome 0
    # trigger… (none)
    # interval.. 1
    # limit….. 60
    # timestamp,side, count
    1970-01-01 00:00:01 GMT,TOC,1
    1970-01-01 00:00:02 GMT,TOC,1
    1970-01-01 00:00:03 GMT,TOC,1
    1970-01-01 00:00:04 GMT,TOC,1
    1970-01-01 00:00:05 GMT,TOC,1
    1970-01-01 00:00:06 GMT,TOC,1
    1970-01-01 00:00:07 GMT,TOC,1
    1970-01-01 00:00:08 GMT,TOC,1
    1970-01-01 00:00:09 GMT,TOC,1
    1970-01-01 00:00:10 GMT,TOC,1
    1970-01-01 00:00:11 GMT,TOC,1
    1970-01-01 00:00:12 GMT,TOC,1
    1970-01-01 00:00:13 GMT,TOC,1
    1970-01-01 00:00:14 GMT,TOC,1
    1970-01-01 00:00:15 GMT,TOC,1
    1970-01-01 00:00:16 GMT,TOC,1
    1970-01-01 00:00:17 GMT,TOC,1
    1970-01-01 00:00:18 GMT,TOC,1
    1970-01-01 00:00:19 GMT,TOC,1
    1970-01-01 00:00:20 GMT,TOC,1
    1970-01-01 00:00:21 GMT,TOC,1
    1970-01-01 00:00:22 GMT,TOC,1
    1970-01-01 00:00:23 GMT,TOC,1
    1970-01-01 00:00:24 GMT,TOC,1
    1970-01-01 00:00:25 GMT,TOC,1
    1970-01-01 00:00:26 GMT,TOC,1
    1970-01-01 00:00:27 GMT,TOC,1
    1970-01-01 00:00:28 GMT,TOC,1
    1970-01-01 00:00:29 GMT,TOC,1
    1970-01-01 00:00:30 GMT,TOC,1
    1970-01-01 00:00:31 GMT,TOC,1
    1970-01-01 00:00:32 GMT,TOC,1
    1970-01-01 00:00:33 GMT,TOC,1
    1970-01-01 00:00:34 GMT,TOC,1
    1970-01-01 00:00:35 GMT,TOC,1
    1970-01-01 00:00:36 GMT,TOC,1
    1970-01-01 00:00:37 GMT,TOC,1
    1970-01-01 00:00:38 GMT,TOC,1
    1970-01-01 00:00:39 GMT,TOC,1
    1970-01-01 00:00:40 GMT,TOC,1
    1970-01-01 00:00:41 GMT,TOC,1
    1970-01-01 00:00:42 GMT,TOC,1
    1970-01-01 00:00:43 GMT,TOC,1
    1970-01-01 00:00:44 GMT,TOC,1
    1970-01-01 00:00:45 GMT,TOC,1
    1970-01-01 00:00:46 GMT,TOC,1
    1970-01-01 00:00:47 GMT,TOC,1
    1970-01-01 00:00:48 GMT,TOC,1
    1970-01-01 00:00:49 GMT,TOC,1
    1970-01-01 00:00:50 GMT,TOC,1
    1970-01-01 00:00:51 GMT,TOC,1
    1970-01-01 00:00:52 GMT,TOC,1
    1970-01-01 00:00:53 GMT,TOC,1
    1970-01-01 00:00:54 GMT,TOC,1
    1970-01-01 00:00:55 GMT,TOC,1
    1970-01-01 00:00:56 GMT,TOC,1
    1970-01-01 00:00:57 GMT,TOC,1
    1970-01-01 00:00:58 GMT,TOC,1
    1970-01-01 00:00:59 GMT,TOC,1
    1970-01-01 00:01:00 GMT,TIC,0
    1970-01-01 00:01:01 GMT,TIC,0
    # end of tape


    From this it would seem as though the metronome object synchronized itself at the start of the simulation to the state it should have held at t=59.

    I would have expected the following result:
    1970-01-01 00:00:01 GMT,TIC,60
    1970-01-01 00:00:02 GMT,TIC,60
    1970-01-01 00:00:03 GMT,TIC,60
    1970-01-01 00:00:04 GMT,TIC,60
    etc. etc.
    1970-01-01 00:01:00 GMT,TIC,0
    1970-01-01 00:01:01 GMT,TIC,0

    But I didn't get my expected result and I'm curious to know why. Here's what I would have expected for CASE2:
    At t = 0; All objects are synchronized so the recorder sees the initial values of count = 60 and side = TIC.
    At  0 < t < 60; Only metronome is synchronized. Recorder still sees count=60 and side=TIC.
    At t = 60; All objects are synchronized so the recorder sees the current value of the metronome which is count = 0, side = TIC.

    Do you have any suggestions?

     
  • David P. Chassin

    First, the sampling interval is 1 second and will be complied with regardless of what the minimum timestep is.  Remember, the minimum timestep does not prevent objects from synchronizing their clocks as they wish.  It only prevent other object from knowing when they're changing state at a rate faster than the minimum timestep.  As a result, the metronome changes state every second and the recorder sample every second, but the metronome advances in 1 minute blocks separately from the recorder advance in a 1 minute block.  As a result, the recorder see a single invariant state during the entire minute it is advancing.  There is no communication between objects during the minimum timestep interval.  None at all, especially state changes.

    Let me clarify a statement about object clocks.  Object do have private clocks for the sole purpose of knowing whether they are out of sync with the global clock.  The global clock represents the time the object should be at and the object clock represents the time the object is actually at.  Normally, the difference between these cannot exceed the difference between the last requested sync time and object next sync time.  However, if minimum timestep is set, that difference can be large than that limit and can be as high as the minimum timestep.

     
  • Varun Badrinath Krishna

    Hi David,

    According to you ("As a result, the recorder see a single invariant state during the entire minute it is advancing. There is no communication between objects during the minimum timestep interval."), the recorder in my example should be showing an invariant value of 60 (which also what I expected).

    Why 60 and not 1? It's because 60 is the starting value of count. Metronome decrements its value to 1 (see base case) and reaches 1 only at 59 seconds. If there is no communication between the recorder and the metronome, the recorder at time 0 to 59s shouldn't know the value of metronome at time 59s. Therefore, the recorder should record 60, not 1 However, the result shows the invariant value of 1 (not 60). The result basically states that somehow at time 0s, the recorder thinks the metronome is at time 59s and has a count of 1. The recorder then records an invariant value of 1 for the period of 0s to 59s. Why doesn't it record 60 from 0s to 59s?

    Also is your "object clock" = "last sync time"?

     
  • David P. Chassin

    The synchronization from 0-60 of the recorder is done asynchronously with that of the metronome.  Thus, the recorder is suspended while the metronome counts 60 beats and then the metronome is suspended while the recorder records 60 beats.  Thus the recorder sees the same count for all 60 beats.  This is the effect of using minimum_timestep-it prevents interobject communications at a shorter time resolution.  If you don't like that effect, don't use it.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks