Changes between Version 9 and Version 10 of EcosimVariableTimestepPluginExample


Ignore:
Timestamp:
2010-02-25 14:47:34 (14 years ago)
Author:
joeb
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • EcosimVariableTimestepPluginExample

    v9 v10  
    1313=  = 
    1414= Running Ecosim on a variable time step = 
    15 Ecosim can be run on a variable time step via a plugin. When run from the Scientific Interface Ecosim runs 1 time step per month, 12 time steps per year. The number of timesteps per month can be set in code via the cEcosimDataStuctures.!StepsPerMonth property. This allows a plugin to run Ecosim on sub time steps, multiple time steps in a month. 
    16  
     15= By default Ecosim runs on a monthly time step, 12 time steps per year. To accommodate a variable time step Ecosim can be told to run more then one time step in a month via the  cEcosimDataStuctures.!StepsPerMonth property. The !StepsPerMonth property is only accessible from code and can not be set in the Scientific Interface. This allows Ecosim to run on a sub time step scheme by setting the cEcosimDataStuctures.!StepsPerMonth property to the number of sub time steps to run in a month. At the end of each run Ecosim will set cEcosimDataStuctures.[wiki:StepsPerMonth] back to its default value of one. = 
    1716==== Sub time step data ==== 
    1817When running on sub time steps Ecosim will only update its results objects cCore.cEcoSimResults(), cCore.cEcosimGroupOutput(), cCore.cEcosimOutput() and cCore.cEcosimFleetOutput()  once at the end of the month. Data computed for the sub time step can only be access via the cEcosimDataStrucutres provided by the IEcosimSubTimestepsPlugin.!EcosimSubTimeStepBegin() and IEcosimSubTimestepsPlugin.!EcosimSubTimeStepEnd() plugin points. The IEcosimBeginTimestepPlugin.!EcosimBeginTimeStep() and IEcosimEndTimestepPlugin.!EcosimEndTimeStep() will only be call at the start and end of the month not during the sub time step and will not contain the sub time step data. 
     
    2221IEcosimSubTimestepsPlugin.EcosimSubTimeStepBegin(ByRef BiomassAtTimestep() As Single, ByVal TimeInYears As Single, ByVal DeltaT As Single, ByVal SubTimestepIndex As Integer, ByVal EcosimDatastructures As Object) 
    2322}}} 
    24  
    25  
    2623 * Called at the start of a sub time step. 
    2724 * !BiomassAtTimestep() contains the biomass that will be used for the time step. Any changes to biomass by a plugin point will be use be by Ecosim for the time step. 
     
    3027IEcosimSubTimestepsPlugin.EcosimSubTimeStepEnd(ByRef BiomassAtTimestep() As Single, ByVal TimeInYears As Single, ByVal DeltaT As Single, ByVal SubTimestepIndex As Integer, ByVal EcosimDatastructures As Object) 
    3128}}} 
    32  
    33  
    3429 * Called at the end of a sub time step. 
    3530 * !BiomassAtTimestep() contains the biomass computed for the time step. 
    3631 
    3732= Running Ecosim on a separate thread = 
    38 Ecosim can be run on its own thread by setting the cEcosimDataStuctures.bMultiThreaded Boolean flag to True. The next time Ecosim is run it will run on its own thread. Once the Ecosim run has completed the cEcosimDataStuctures.bMultiThreaded flag will be automatically set to its default value of False and all subsequent runs will be on the main application thread. All plug-in calls that originate on a thread other than the main thread will be marshaled to the main thread. This is for robustness, in .NET user interface controls cannot be accessed from a thread other than that which they were created on. Plug-ins are created and run on the main thread by the EwE framework. By automatically marshaling all plug-in calls to the main thread plug-in points do not have to marshal calls to an interface. 
     33Ecosim can be run on its own thread by setting the cEcosimDataStuctures.bMultiThreaded Boolean flag to True. The next time Ecosim is run it will run on its own thread. Once the Ecosim run has completed the cEcosimDataStuctures.bMultiThreaded flag will be automatically set to its default value of False and all subsequent runs will be on the main application thread. All plug-in calls that originate on a thread other than the main thread will be marshaled to the main thread. This is for robustness, in .NET user interface controls cannot be accessed from a thread other than that which they were created on. Plug-ins are created and run on the main thread by the EwE framework. By automatically marshaling all plug-in calls to the main thread plug-in points do not have to marshal calls to an interface.