Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »

Overview

The SubSource plugin is developed to run a second Source model at different points during the main model run. This plugin is typically used to forecast water allocations or integrate different time steps in the operation model. The sub-model is run using the Source Service.

The basic concept, as shown in Figure 1, can be explain as follows:

The main model (blue) steps through the simulation period, using some information from the sub-model (yellow) to calculate water allocations. At each call from the main model, sub-model (yellow) simulates the scenario such as a worst dry case until the end of the water year (or a defined end time by the user) to estimate harvestable inflows and losses for the main model.

Figure 1 The basic concept of SubSource

Although the plugin was originally developed for a specific project, it has since been extended to be a flexible generic tool and may be used to address different needs in more complex water system models. The main model and sub-model scenarios can be defined in the same Source project file or separate Source project files. It is also possible to use the same scenario for both the main model and sub-model using different running configurations, input sets, and recorder sets. The developed interface allows the user to choose different parameter values for their requirements. The models can use catchment mode or network mode. Users can design their own data mappings between the main model and sub-model.

Basic procedure for using the SubSource plugin

The basic procedure for the use of the SubSource plugin is described below:

  • Step 1 Create the Source model using SubSource function
    • Load the SubSource plugin from CommunityPlugins\SourcePlugin.SubSource.dll in the Plugin Manager.

    • Create a new project (or alternatively open an existing project to add the plugin to)
  • Step 2 Create models
    • Create a main model (scenario) in the current project (see Figure 2(1))

    • Save the project

    • Create a sub model (scenario) in the current project (see Figure 2(2)) or another Source project file

    • Save the project.

  • Step 3 Prepare the mapping between the main model and sub-model.
  • Step 4 Save the Source project file(s) after the Sub-model analysis has been set up or modified.
    • Although the latest version of the SubSource plugin can automatically save the project to a temporary location prior to run, it is recommended to save the project to make sure changes to the the sub-model are applied.
  • Step 5 Run Main Model.
Figure 2 SubSource plugin components

Sub-Model Analysis configuration

The Sub-Model Analysis running configuration is based on the Single Analysis running configuration with one additional section, Sub-Model (see Figure 3).

The Sub-Model section allows the configuration of:

  1. the mapping between the main model and sub-model; and
  2. the parameters for the sub-model run;
Figure 3 Sub-Model Analysis Configuration dialog

Main model to sub-model mapping

Select the mapping to use for passing values between the main and sub-models. Click Edit to open the Sub-model Mapping Manager to modify or create new mappings.

Sub-model run parameters

The options in the lower section of the Configuration tab (Figure 3) are for controlling the sub-model run. In this section, "Main Model" is used to denote values / settings taken from the current state of the main model when the sub-model run is triggered, while "Sub-Model" denotes the original values / settings defined in the sub-model running configuration. Using "Main Model" will update the running configuration of the sub-model prior to starting the sub-model run.

  • Time Step: this parameter provides three options (i.e. From Main Model, From Sub-Model and Custom Time Step) to set the simulation time step for the sub-model run:

    • From Main Model: the time step used in the sub-model run will be the same as the one defined in the Main Model section of the Configuration tab.

    • From Sub-Model: the time step used in the sub-model run will not be modified, using the the original running configuration setting.

    • Custom Time Step: this option will display an additional dropdown list for the user to select the required time step. Users need to consider the time step used in the main model and data sources in the sub-model for a reasonable matched time step.

  • Start Time: this parameter provides four options, called From Main Model, From Sub-Model, Custom Start Time and Main Model Trigger Time, to set up the simulation start time for sub-model run. The first three options are self-explanatory, and their mechanisms are same as those in Time Step. Specifying the Main Model Trigger Time option, the default option, will use the time when the main model triggered the sub-model run as the simulation start time of the sub-model run. For example, if the main model triggered a sub-model run on the 1st September 2000, the start time of the sub-model run will be modified to simulate the water process from 1st September 2000.

  • Run Period: this parameter provides four options (i.e. From Sub-Model, End of Water Year, Number of Time Steps and Custom End Time) to set up the simulation period for the sub-model run:

    • From Sub-Model: the sub-model run period will be adopted from the sub-model's running configuration. The run end time could be different to the one defined in the sub-model's running configuration if the selected start time is not also set to From Sub-Model.

    • End of Water Year: the run period will be from the simulation start time to the end of the water year. This option will display an additional entry field (at the bottom of the tab) to define the water year.

    • Number of Time Steps: the sub-model run period will be a fixed number of time steps from the simulation start time. This option will display an additional entry field for the number of timesteps to run.

    • Custom End Time: allows the user to specify the end time to be used for the sub-model run. This option will display an additional entry field to enter a date as the simulation end time.

  • Run Frequency: this parameter provides five options (i.e. Start of Week, Start of Month, Start of Water Year, Number of Time Steps and Custom Trigger) to specify when the sub-model will be triggered during the main model run:

    • Start of Week: the sub-model run will be triggered at the beginning of each week.

    • Start of Month: the sub-model run will be triggered at the beginning of each month.

    • Start of Water Year: the sub-model run will be triggered at the beginning of each water year. This option will display an additional entry field (at the bottom of the tab) to define the water year.

    • Number of Time Steps: the sub-model run will be triggered after a recurring number of timesteps. This option will display an additional entry field for the number of timesteps.

    • Custom Trigger: the sub-model run will be triggered when the specified Boolean function evaluates to True. The function can be a system conditions such as the water level at one reservoir reached to a certain level (and then Sub-Model will start to run). The function time of evaluation must be prior to when the sub-model run will be triggered, such as End of Timestep. This option will display an additional entry field for selecting the function.

  • Water Year: this parameter is linked to options of End of Water Year and Start of Water Year. It is used to specify the start day and month of the water year.

The user needs to consider above parameters together to define their values in a systematic approach.

The models also need a proper design and debugging, especially for data transfer between main model and sub model.

The latest version of Source can read the meta data from the loaded project even if that project was created by a previous version of Source with a different user interface for SubSource function.

Sub-model Mapping Manager

The Sub-model Mapping Manager dialog (Figure 5) is used for defining mappings between main and sub-models. A Source scenario may have multiple mappings defined and each mapping may be used by multiple Sub-Model Analysis running configurations within the scenario. Mappings are defined in the main model scenario. No mappings settings are required in the sub-model scenario (other than the required functions and recorders).

The Sub-model Mapping Manager dialog (Figure 5) may be accessed either by clicking the Edit button next to the Main model to sub-model mapping setting in the Sub-Model Analysis Configuration dialog (Figure 3), or from the Source Tools menu, Tools » Sub-model Mapping Manager (Figure 4).

Figure 4 Access Sub-model Mapping Manager from the Tools menu

Figure 5 Sub-model Mapping Manager dialog


Define sub-model mappings

The left box in Figure 5 can be used to display the list of multiple names and it allows the user to manage this list of Sub-model Mappings:

  • Right click on any empty place in the left box of Figure 5 will display the Add Mapping button shown as Figure 6. Click on the Add Mapping will display all parameters, which are associated with the definition of a Sub-model Mapping, in the right box with empty value.  

Figure 6 Add Mapping

  • Right click on any name in the left box of Figure 5 will display the Delete button and click on this Delete will delete this name (, or a definition of Sub-model Mapping,) from the modelling.

  • Click on any name in the left box of Figure 5 will display all parameters values associated with the definition of this selected Sub-model Mapping in the right box. The user can display or edit this sub model mapping definition.

The details of all parameters associated with a definition of one Sub-model Mapping are given below:

  • Name: the unique name of the current Sub-model Mapping.

  • Use Current Project: this tick box defines which Source project file is used to select a scenario as Sub-Model. If it is ticked, the interface will load all scenarios from the current project into Scenario dropdown list for the option. If it is not ticked, Project Path parameter will be activated to define the source project file.

  • Project Path: this parameter allows the user to choose a Source project file (other than the current project file) as the source of Sub-Model. It is disabled when Use Current Project is ticked.

  • Loading…: this progress bar will display the progress information loading all scenarios in the project file to Scenario dropdown list ( talk below).

In Sub-mode Running Configuration frame in Figure 5:

  • Scenario: the user can select one relevant scenario from this list as Sub-Model. All scenarios in the used Source project file are available for choice.

 Sub-Model not only can be selected from same or different project where the main model comes from, but also can use the same model (scenario) as that for the main model.

  • Override Run Configuration: this tick box allows the user to change the default of Running Configuration names for the selected sub model. When it is ticked, the Configuration dropdown list will be activated.

The Running Configuration names are defined by Running Configuration Management from Scenario Options menu.

  • Configuration dropdown list: It provides the available options of Running Configuration names (such as single analysis, linked analysis, custom 1) for Sub-Model. The model will run Sub-Model using selected Running Configuration name from this parameter and ignore default one in the sub model / original scenario. It is only available when the Override Run Configuration tick box is ticked.

  • Scenario Input Set: this parameter allows to select different existing Scenario Input Sets for Sub-Model run.

From Variable Mapping From Main Model to Sub-Model frame, the user can use it to set up data transfer from the main model to Sub-Model and it is happed when Sub-Model is triggered by the main mode to start running:

  • Main Model Value: it is used to define a source value in the main model. This source can be a specific value, a data in data source or a function. It will be signed to the objective function in Sub Model when the main model triggers running of Sub-Model.

  • Sub-Model Function: it is used to specify a function (existed in Sub-Model). This function will adopt the value from Main Model Value when Sub-Model starts running. Although all functions in Sub-Model are available options in its dropdown list, but the user needs to select a corresponding function to transfer the data.

Note that:

  • The time for the main model is the end of last time step while the time trigged to run the Sub-Model is the start of the time step. For example, the main model (daily time step) trigged Sub-Model (Monthly time step) to run from 1 September 2000. The time for the main model is the end time step of 31 August 2000, and the condition (data) at this time step will be used to setup the initial condition of Sub-Model. The time for Sub-Model is the start of 1 September 2000. This time will be used to receive the initial data from the main model. These concepts are practically for Time of Evaluation.

  • For the function in this frame, the user can add as many as they need.

  • Each function only allows one value to be used for the data transfer. If the time series is used, the last value will be taken.

  • All initial conditions of the water system in Sub-Model need the setting up such as storages' initial volume, water account balance in RAS. These initial values often are passed though the functions from the man model to Sub-Model.

  • Run Initialisation" and "Start Of Run” of Time of Evaluation are specifically developed for this plugin:

  • "Run Initialisation" functions are functions which are used when initialising the run and network elements. Functions which are set to this Time of Evaluation cannot use Model Variables

  • "Start Of Run" will be evaluated after initialisation (reset), and can be used to prime functions and Model Variables with calculated initial values

From Variable Mapping From Sub-Model to Main Model frame, the user ca use it to set up data transfer from Sub-Model model to the main:

  • Sub-Model Recorder: it is a recorder in Sub-Model to save desired running results as a data source and this source value(s) will be signed to an objective function in the main model when Sub-Model completed a running process.

  • Main Model Function: it can be used to specify a function (existing in the main model), which will adopt the value(s) from Sub-Model Recorder when Sub-Model completed a run process. Again, the user needs to select a relevant function to transfer the data.

     Note that:

  • The user only needs to save the recorders, which are necessary for data transfer, in Sub-Model. This can reduce the model running time and the computer memory.

  • The principle of above notes for Variable Mapping From Main Model to Sub-Model is also applied for this frame.

Select a mapping

Th selected mapping in Figure 5 by the user will be displayed on the dropdown list of Mapping such as “my Sub Model Mapping” in Figure 3, and this mapping will be used during the model running. The user also can directly select the existed /pre-defined mapping items from the dropdown list of Mapping.

Note that if the main model and Sub-model are from different project files,  the user must remember to save the Source project file before you run the mode because the setting up is functionalized only after the project is saved.


  • No labels