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
We should clearly define (and document) the interaction between step() and simulate() within the context of a simulation, and how it may interact with exposing the current step to the user.
Expected use is that a user will call simulate() to run the configured number of steps.
Alternatively users may wish to call step() for individual simualtion steps (i.e. integration with custom visualisations in flamegpu1).
However, if step() has been called, currently simulate() will run for --steps regardless (i.e. if steps is 12, 13 iterations would have been called.
Additionally, what should happen with multiple calls to simulate() (with or without calls to reset()), and how does this affect the step counter?
What happens to the result of exitConditions in this case? (forwarded by the returnvalue of step currently).
We could:
Block simulate() from being called after step() - make it explicitly unsupported.
Allow step() and simualte() to be called before/after each other, but:
Add a parameter to simulate so that it will run N steps (which defaults to --steps if not passed?
And/Or Only run simulate() until --steps has been achieved including prior runs (via step_count)?
How visualisation is implemented makes this more complex too - should step() be callable by the user if a visualisation is present?
Resolve the step() vs simulate() decision
Decide how this fits with reset()
Let users call INIT and EXIT functions themselves if `step() can be called.
Decide / document for exit conditons work with step()'d simulations
The text was updated successfully, but these errors were encountered:
Looking at step() visualisation should currently work regardless whether step() or simulate() is used.
It operates in a separate thread, and step() calls updateBuffers() at the end (if required).
Robadob
changed the title
Interaction of step() and simulate() in Simulation/CudaAgentModel
Interaction of step() and simulate() in Simulation/CudaSimulation
Oct 22, 2020
step() is going to continue calling Exit Conditions and return a boolean indicating if the sim should continue or not. It is up to the user to handle this. Subsequent calls to step will continue to execute.
This will be documented, but as it is not intended use it is not as high priority as other documentation / code changes.
We should clearly define (and document) the interaction between step() and simulate() within the context of a simulation, and how it may interact with exposing the current step to the user.
Expected use is that a user will call
simulate()
to run the configured number of steps.Alternatively users may wish to call
step()
for individual simualtion steps (i.e. integration with custom visualisations in flamegpu1).However, if
step()
has been called, currentlysimulate()
will run for--steps
regardless (i.e. ifsteps
is 12, 13 iterations would have been called.Additionally, what should happen with multiple calls to
simulate()
(with or without calls toreset())
, and how does this affect the step counter?What happens to the result of exitConditions in this case? (forwarded by the returnvalue of
step
currently).We could:
simulate()
from being called afterstep()
- make it explicitly unsupported.step()
andsimualte()
to be called before/after each other, but:simulate
so that it will run N steps (which defaults to--steps
if not passed?--steps
has been achieved including prior runs (viastep_count
)?How visualisation is implemented makes this more complex too - should
step()
be callable by the user if a visualisation is present?step()
vssimulate()
decisionreset()
INIT
andEXIT
functions themselves if `step() can be called.step()
'd simulationsThe text was updated successfully, but these errors were encountered: