Re: setRepeatInterval [os:all swarm:all lib:activity]

[Steve Emsley]

>>>>> "Marcus" == Marcus G Daniels <address@hidden> writes:

    Marcus> I'm gasping for facts...

Hmm, this is where a whiteboard would be useful!

          GraphicSwarm                     BatchSwarm
               |______________________________|
                              |
                         ModelSwarm
                              |
                         OceanClass
            __________________|_________________
            |                 |                 |      |- LightClass
       LightClass     list of WaterClass     POMClass--|
                              |                        |- LightClass
                         ModelClass

O.K. my plankton model hangs off the OceanClass object. The LightClass
objects needs simulated dayNumber since it calculates sunlight which
is used to grow plankton and mix the ocean (also to give a reference
point to climatological data sets). So, each object has an instance
variable, dayNumber, and a stepping interval, timestep.

ModelSwarm runs a schedule, modelSchedule with a repeatInterval: 1 and
an action   [modelActions createActionTo: oceanID   message: M(step)].
The ocean object first updates it's dayNumber
                 dayNumber += timestep / 24.0
and propogates this through the model since every object has a step
method that does the same. O.K.

ModelSwarm also has a schedule, outputSchedule with an initial
repeatInterval = 96 and an action   
    [outputActions createActionTo: oceanID   message: M(output)];

The initial timestep = 0.25 hours (or 15 minutes). There are, thus, 96
steps within a day with a stepsize of 15 minutes. Thus, the
outputSchedule signals output once every day.

In graphicsSwarm there are several such outputSchedules with
repeatIntervals appropriate for everyWeek, everyMonth etc. Since a
minimal spun-up run of my model is 10 years I try to keep the results
file < 10 Mbyte.

O.K. that all works fine. The output file (debugging) is reproduced
below: 

      : day 0 at 00:00  step 7.50    96 --> 192      0
      : day 0 at 00:00  step 3.75   192 --> 384      0
OUTPUT: day 0 at 00:03  step 3.75                    0
      : day 0 at 23:59  step 7.50   384 --> 192    384
OUTPUT: day 1 at 00:07  step 7.50                  384
      : day 1 at 02:44  step 3.75   192 --> 384    406
OUTPUT: day 1 at 13:26  step 3.75                  576
      : day 2 at 02:45  step 7.50   384 --> 192    790
      : day 2 at 04:52  step 3.75   192 --> 384    807
OUTPUT: day 2 at 14:29  step 3.75                  960
      : day 3 at 04:52  step 7.50   384 --> 192   1191
      : day 3 at 06:44  step 3.75   192 --> 384   1206
OUTPUT: day 3 at 15:26  step 3.75                 1344


    Marcus>   1) where does HH:MM come from?  Is it derived from the
    Marcus> moduleSchedule?


O.K. Lines marked OUTPUT come from the oceanClass object triggered by
the modelSwarm outputSchedule. I've formatted it for readability. The
day and HH:MM are derived from dayNumber and the step is the current
timestep converted into minutes. These are all simulation parameters
not swarm parameters.


    Marcus>   2) What triggers a repeatIntervalDouble?  Why are there
    Marcus> two at 00:00?  The context of that determines which
    Marcus> getCurrentTime() queries for the time.


The problem. The bottom level ModelClass object contains 5 coupled
ordinary differential equations and a Runge-Kutta routine to solve
them. The initial timestep = 0.25 hour (15 minutes) is just a
guess. Sometimes it doesn't work and I get negative solutions which
mean that my results file ends up full of NaN (for upstream reasons)
and, thus, I need to reduce the timestep.

OceanClass knows this is required to halves the timestep (resets the
dayNumber to the previous model step) and sends a message to
modelSwarm to:
           [outputSchedule setRepeatInterval: 
           [outputSchedule getRepeatInterval] * 2]
The lines in the output above including 192 --> 384 are debugging info
printed from this method. The formatted dayNumber is included to aid
debugging.

Of course, just because the Runge-Kutta needed a smaller timestep at
one point doesn't mean it'll always need it so once I halve the
timestep I set a counter so, after 1 simulated day, it doubles the
timestep and sends a message to modelSwarm:
          [outputSchedule setRepeatInterval: 
          [outputSchedule getRepeatInterval] / 2]
This leads to a debugging message including 384 --> 192. Note that if
I halve the simulation timestep I double the repeatInterval and vice
versa.

The final column in the output is the result of printing
getCurrentTime() which is the clock tick for modelSchedule i.e. the
absolute time since the Swarm was activated.


    Marcus>   3) I don't understand the pattern of step 7.50 vs 3.75?
    Marcus> Is that printed in an adjacent place?


The reason for the lines:
      : day 0 at 00:00  step 7.50    96 --> 192      0
      : day 0 at 00:00  step 3.75   192 --> 384      0
is that at the first model step the Runge-Kutta signalled that 15
minutes was too large so halved it to 7.50 minutes (doubling
repeatInterval to 192). However, this was also too large so it halved
it to 3.75 minutes (repeatInterval 384) and then got going. Note that
these repeatIntervals are for outputSchedule, modelSchedule still has
a repeatInterval of 1 as is reflected in the final column.

O.K. so day, HH:MM and step are my simulations variables but the
others are swarm parameters. Everything from OceanClass and below is
working in synchrony. However, it seems that every time outputSchedule
triggers and OUTPUT line it then takes the current outputSchedule
repeatInterval and signals the next output event based on
that. However, as can be seen during the wait the timestep can change
which, since the model advances based on modelSchedules repeatInterval
of 1 and this advances dayNumber += timestep/ 24.0, means that the
models simulated time and the repeatInterval of outputSchedule get out
of synchronization. i.e. If it decides to do 384 steps of 3.75 minutes
until the next output but, during that time, timestep becomes 7.50 and
repeatInterval = 192. This leads to output > 24 hours after the last.

So, changing repeatInterval in outputSchedule only kicks in from the
next output event. What I need to do is get into the currentTime of
the outputSchedule to reset that to take into account the change in
repeatInterval. Trouble is I can't find the syntax to do that ... I
just get currentTime for the running activity i.e. modelSchedule. Also
I will need to modify it and I can't see how.

O.K. In this instance, I could simplify things so that outputSchedule
repeatInterval = 1 and I just test my simulation variable dayNumber as
to whether I should produce output. I'd rather not coz' (1) it's
inelegant (2) probably inefficient (3) not easy with doubles and
rouding errors. In any case, as I said, graphicsSwarm is full of
similar routines and not amenable to such a solution since it's pure
swarm.

Sorry to burden you with this tome of an email. I checked the FAQ and
mailling list but haven't found any appropriate pointers. I guess it's
probably quite straight-forward, maybe even part of mousetraps or soem
gridturtle. I've looked and its's not obvious to me. Sorry.

Thanks,
Steve.

-- 
---------------------------------------------------------------------
 Steve Emsley                 Ecosystems Analysis & Management Group
 address@hidden              University of Warwick, England
 http://www.oikos.warwick.ac.uk/~sme/           (+44) (0)1598 753648
---------------------------------------------------------------------

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.
                  ==================================