integer times

[Doug Donalson]

Nelson, Roger, and Chris,

   I am starting to run into problems associated with the restriction that time 
be 
a 32 bit integer.  To get around the problem I chose a fractional part of my 
time 
to be four decimal places and then left shifted my floating point time by the 
precision and truncated it.  The 4 decimal places is not enough resolution for 
research purposes but will do for model validation.  Also, without wrap-around, 
by 
actual time ends at 800,000, again too short for research simulations.  I ran 
into 
two problems as a result of this.  At system time 4.25 billion (my time 
425,000), 
the BLT graph crashed with a message of x axis overflow.  I assume that this is 
because the X axis (time) only handles signed ints.  Sometime thereafter, I got 
the following message:

Schedule did not complete soon enough for its scheduled repeat. Schedule.m line 
552.

The requsit core dump immediatly followed.  I am assuming that this was the 
point 
where I hit the unsigned int limit.  Am I correct that both errors are from 
time 
overflows and if so do you have any suggestions?  

Also, at least from my point of view, SWARM really needs some way to allow 
floating point times for those of us who do asynchronous event simulations.  
Roger 
and I talked about one possibility.  This was to have a primary schedule based 
on 
an integer and a sub-schedule that would be indexed by the integer value and 
contain the fractional part of the schedule.  Is this in the future of SWARM?

Are any of the other beta sites doing asynchronous event simulations and if so 
how 
did you handle floating point times?

Cheers,

   Doug Donalson


PS  I was curious as to how much overhead the SWARM scheduler added to my 
simulation.  I made an extreamly simple scheduler and ran them against each 
other 
in my model.  First one to 2,000,000 events wins.  You'll be happy to know that 
the race was a draw!