Working with Scenarios

A scenario can be created when a model is registered. This scenario contains the model properties the model had when it was registered. If a scenario was not created, a scenario can later be created by right-clicking on the model and select New Scenario from the context menu. This scenario is also identical to the model setup from which it was derived and running this scenario will in most cases be used as a baseline scenario in the scenario analysis. It will be useful to give the scenario a name which illustrates its condition.

New scenarios can be created under the same model by selecting New Scenario from the model setup context menu. The scenarios can contain variations in input parameters and input variables to represent changed conditions, e.g. as shown below:

A Scenario is opened by double-clicking or selecting "Open" from the Scenario context menu. A Scenario data view, very similar to the Model setup data view, will be opened. Only the Model object / variables that deviate from the Model Setup will be shown, and hence, the model object explorer will initially be empty.

To create a variation compared to e.g. the baseline scenario, the model object variables to be varied are selected from the model setup data view and added to the scenario either by drag-and-drop from the model setup data view to the scenario node in the scenario explorer, or through the Include in scenario entry in the model object variable context menu. As soon as a variable has been added to a scenario it will appear in the scenario data view.

The value of a model object variable can now be edited either by dragging an existing time series from the time series explorer to the variable in the scenario data view, or to create and edit a copy of the original value using the Edit entry in the model object variable context menu.

Notice that only output variables that have been added to a given scenario will be available in the simulation results after executing a scenario.

Create a new scenario

Right click on the Model setup to create a new scenario from a model setup and select New scenario from the context menu.

A new scenario node will be added under the model setup.

The default name will be Scenario of <Model name>. Initially, the scenario will be an exact copy of the model setup.

Note

In the example shown here the Current Situation scenario was created when the model was registered, the 2050 Future Scenario was created using the previous step and renamed. Initially they have both the same variables as the model.

Configure a scenario

A scenario can be configured opening the scenario and selecting each model object, or by opening the Configure Scenario dialog from the context menu of the scenario.

Select "Configure scenario" to open the Configure Scenario dialog.

The Configure Scenario Dialog, allows configuration of inputs, outputs and hot start files.

Configure Inputs

The Configure Inputs dialog will show all inputs of the model setup.

Column	Description
Enable	Check the box to include the input in the scenario.
Model Object Type	The type of the model object.
Type	The input type (e.g. Time Series).
Model Object	The name of the model object of the input.
Source	The source of the input mapped to the input time series. Time series - Use a time series from the time series explorer as input. Script - Use a script for generating the input.
Variable	The variable name of the input.
Time series	Path to the time series used as input. In case the source is Time series
Script	Path to the script used for generating the input in case source is Script.

Configure Outputs

The Configure Outputs dialog will show all outputs of the model setup.

Column	Description
Enable	Check the box to include the output in the scenario.
Model Object Type	The type of the model object.
Type	The Output type (e.g. Time Series).
Model Object	The name of the model object of the input.
Name	The name of the output.
Database	Save the output to the database (set by default).
Provider	Save the output into a provider already configured. Providers samples: MIKE Cloud Time Series Provider DIMS.CORE Time Series Provider MIKE Cloud Raster Provider
Folder	Save the output to a folder on disk.
Output format	The format of the output.
Path	Path to the output, overwriting default database or provider output.
Time series	Configure default provider root and database root location for time series output.
Raster	Configure default provider root and database root location for raster output.
Mesh	Configure default provider root and database root location for mesh output.

Configure Hot Start

The Configure Hot Start dialog will show available hot starts of the model setup.

Copy an existing scenario

A new scenario can also be created by copying an existing scenario.

This is done by selecting an existing scenario from the scenario explorer and select Copy from the context menu.

A new scenario is now added under the Model setup.

By default, the name will be Clone of <scenario name>. The scenario can be renamed by selecting Rename from the context menu.

Initially, the new scenario will be an exact copy of the scenario that was copied.

Open a scenario

Right-click on the scenario and select Open from the scenario context menu.

A data view with the scenario properties will now appear.

Note

In the following the data view for scenarios is called: Scenario view.

The scenario view has the same design as the model view.

It contains map section and an explorer section. Initially, the scenario view does not contain any model objects. These will be added manually to describe the scenario.

Scenario Properties

When selecting a scenario node in the Scenario Explorer, the scenario properties are displayed in the property grid. The properties govern how the simulation is prepared and executed, and what is stored in the database.

Simulation times

A scenario has a simulation period defined with three date+time values:

• StartOfSimulation (SOS)
• TimeOfForecast (TOF)
• EndOfSimulation (EOS).

The general rules of calculation are:

• TOF = NOW - Offset.
  Adjust TOF with rules for rounding/truncation to nearest hour, minute or time of day
• SOS = TOF - Hindcast period
• EOS = TOF + Forecast period

These values can be derived in different ways, depending upon the SimulationTimesOption. When you change SimulationTimesOption a group of properties are shown (4) for specification of the details for the calculation:

• FixedDates
  For this setting the user specifies the three values explicitly and they do not change over time (until changed by the user).
  The dates are specified in the "Simulation times" section.
  This is the default setting for a new scenario and the dates are set as they were for the registered model.

• RelativeToDay
  This setting defines a time of day - and will change over time with each day.
  The Simulation times section changes to allow input of:

  • Forecast Period
    The timespan in days.hours:minutes:seconds defining the length of the forecast.
  • Hindcast Period
    The timespan in days.hours:minutes:seconds defining the length of the hindcast.
  • Period offset
    The timespan in days.hours:minutes:seconds defining the length of shift backwards in time from the current machine time to start.
  • Time of day
    The time in hours:minutes:seconds to use for TOF.
    
    The calculation will:
    
  • Take current machine time
  • Subtract the offset
  • Take the date
  • Add the time of day - and this becomes the TOF
  • Subtract the hindcast from TOF - this becomes SOS
  • Add the forecast period to TOF - this becomes EOS
    

  

• RelativeToRuntime
  This setting calculates dates similar to RelativeToDay, but with more detail.
  The Simulation times section changed to allow specification of:

  • Forecast Period
    The timespan in days.hours:minutes:seconds defining the length of the forecast.
  • Hindcast Period
    The timespan in days.hours:minutes:seconds defining the length of the hindcast.
  • Hour rounding
    Round the time down to the nearest multiple of this number.
  • Minute rounding
    Round the time down to the nearest multiple of this number.

  • Period offset
    The timespan in days.hours:minutes:seconds defining the length of shift backwards in time from the current machine time to start.
    
    The calculation will:

  • Calculate TOF:

    • Take current machine time (to the minute)
    • Subtract the offset
    • Round the hours
    • Round the minutes
  • Subtract the hindcast period from TOF - this becomes SOS
  • Add the forecast period to TOF - this becomes EOS

Initial conditions

Initial conditions is a set of files (as determined by the adapter) containing information allowing the model to be started with states describing a calculated solution.

MIKE OPERATIONS works with three types of states:

• Cold
  Cold typically signifies a set of initial conditions which are based on a historic run and represents a 'normal' set of states of the model, which may be used to get the model running at any time.
• Warm
  This is used for a set of initial conditions produced by a run with observed data, i.e. a realistic state.
• Hot
  states stored from a forecast run with inputs of observations and forecasted data.

A set of initial conditions may contain multiple timesteps (similar to the result files in MIKE models), so in MIKE OPERATIONS a set of initial conditions has, besides the file content and a name, three dates describing it:

• First date - the first timestep in the initial conditions
• Last date - the last timestep in the initial conditions
• Create time - the machine time at the time of the simulation run.

The system will request a date (typically the start of simulation), but it is the responsibility of the adapter to pick a proper timestep at runtime.

When running a model that uses hotstart (initial conditions), the scenario must specify two things:

1. If the result should include a new set of initial conditions to be available for subsequent runs.
   When a simulation is approved, any output initial conditions are stored in the database in the repository of initial conditions. The Output initial conditions specification decides which label is put on the initial conditions. The label is used in the initial conditions sections rule (see below).

   • Output initial conditions
     • None - no initial conditions are generated from the simulation run.
     • Cold - Cold typically signifies a set of initial conditions which are based on a historic run and represents a 'normal' set of states of the model, which may be used to get the model running at any time.
     • Warm - This is used for a set of initial conditions produced by a run with observed data, i.e. a realistic state.
     • Hot - states stored from a forecast run with inputs of observations and forecasted data.

2. How a stored initial condition should be picked and provided at runtime. This is done through the selection rule and timestep.

   • Selection rule
     • Specific - Manually select any of the available initial conditions. And specify a timestep between first and last timestep.
     • Cold - Similar to specific, but only pick between available Cold initial conditions.
     • Warm - Similar to specific, but only pick between available Warm initial conditions.
     • Hot - Similar to specific, but only pick between available Hot initial conditions.
     • Warm Latest - Let the system pick between available Warm initial conditions covering Start Of Simulation.
     • Latest - Let the system pick between all initial conditions covering Start Of Simulation.
   • Timestep
     Pick a timestep between First and last timestep of the selected initial conditions.
     
     

   When using Warm Latest and Latest rules, the system will attempt to find best match:

   • Latest:
     • Find initial conditions covering Start Of simulation.
     • If multiple are found, pick the one with the latest Create Time - assuming it is the best match.
     • If none are found, pick among all the one with the latest Create Time, irrespective of coverage of Start of Simulation.
   • Warm Latest:
     • Find Warm initial conditions covering Start Of simulation.
     • If multiple are found, pick the one with the latest Create Time - assuming it is the best match.
     • If none are found, pick as Latest.

For both automatic rules the requested timesteps is set to Start Of Simulation, the picked set of initial conditions covers it. Otherwise, the First timesteps or the Last timesteps is chose - whichever is closest to Start of Simulation.

Scenario settings

Input preparation

Scenario settings allow control of how the scenario inputs are prepared.

• Generate input timeseries
  This setting determines how input time series are generated. Options are.

  • Variations (default)
    Scenario Manager will only generate time series data for input timeseries included in the scenario. Any other time series are assumed to be in the model setup or provided by other means.
  • All
    Scenario Manager will generate time series data for all input time series in the model setup. For input timeseries NOT included in the scenario, a copy of the model setup time series will be stored with the simulation.

• Timeseries interval
  Specify if scenario manager shall by default "cut" the input time series to a certain period. This is the overall setting for a scenario, which can be overridden for the individual input timeseries in the scenario.

  • Full Timeseries
    No cutting takes place. So, if a reference is given to a long historical series, all this data will be given to the model and stored in the database (depending upon the "Store input time series" setting).
  • Hindcast period
    Only provide data in the hindcast from SOS to TOF
  • Forecast period
    Only provide data in the forecast from TOF to EOS

Scenario Execution Information

Scenario settings allow control of how the scenario is executed.

Information on where the scenario should be executed.

• Workstation
  Will use the current workstation or the host information specified for running the simulation.

• Provider
  Use an external model execution provider.
  Select the provider from the list of providers configured.
  Execution providers are configured from the root node of the scenario explorer.

  • Root folder
    Remote root folder (path to a sub-project) of a document provider configured in the MIKE Cloud blob storage, where model files are uploaded to before the the model runs.
  • Pool type
    The type of machine to use for executing the model.
  • Node count
    Number of nodes (threads) to use for executing the model. Note that the engine type should support running on more nodes.
  • Parameters (available with MIKE OPERATIONS 2025.2)
    The MIKE Cloud platform can pass on additional parameters to the engine. Those optional parameters are engine specific and can be found in their corresponding documentation.
  • Remove remote files
    Un-ckecking will allow simulations to re-use the remote folder, so that only changed files needs to be syncronized to the MIKE cloud.
    When checked, remote file folder will be removed after the remote simulation has completed.
    When checked, the remote folder name will be the simulation name. When un-checked, the remote folder name will be: <Model Setup Name>_<Scenario name>.

Note

Note that it is not allowed to run multiple simultaneous simulations for the same scenario using Cloud execution when Remote files are not removed.

Warning

When running a FEFLOW engine, the license must be specified in the Parameters (optional) text field.
e.g. "-license=FMH3
This should be the name of the license purchased/available, and not the license the model needs.
MIKE Cloud will check if the specified license exists on the Internet License account of the user.
So even if a model can run with a F3 license, if the user only has a FMH3 license, FMH3 should be specified.

Storage

Scenario settings allow control of how the scenario stores data.

• Generate change log – true/false (default). Scenario Manager will generate change log for modified and generated time series according to this setting. Not doing it will improve performance.

• Store Mesh Output Timeseries
  Mesh output can be stored either in the MIKE OPERATIONS database or using an external mesh data provider configured in the GIS Explorer (on the root node).
  Click the eclipse button on the property in the properties window.

  

  

• Store Raster Output Timeseries
  Raster output can be stored either in the MIKE OPERATIONS database or using an external raster data provider configured in the GIS Explorer (on the root node).

• Store simulation content
  This setting defines when a (zipped) copy of the simulation files is stored with the simulation. Options are:
  • True - this will always store a copy.
  • False - This will never store a copy.
  • OnlyOnFailure - this will only store a copy if the simulation fails.
• Store simulation input time series
  Specify if a copy of the timeseries given to the model is kept with the simulation:
  • None - To not store anything.
  • Variations - Only store for the timeseries defined in the scenario.
  • All - Store a copy of all generated input time series.

Pre- and Post-processing scripts

The Preprocessing and Postprocessing scripts allow specification of a script to be executed as part of the simulation.

They need not take parameters, but if they take IModelSetup, IScenario or ISimulation the easiest way to specify the script and arguments is to copy the full path to the property grid and press Enter. This will automatically configure the parameter specifications. If other parameters exist, a pop-up dialog will be shown where they can be entered (similar to running scripts from the Script Editor).

The below example illustrates the steps of applying such scripts.

Scenario

1. Scenario
   Register a model and execute the scenario to generate a simulation

   

2. Define scripts
   In this case we have two simple scripts for Preprocessing and PostProcessing respectively as well as a script for testing that they can execute.
   They both take arguments of type IScenario and ISimulation. The Proprocessing script additionally takes a string to use for changing the name.

   import clr
   
   def PreProcessingScript(scenario, simulation, newprefix):
       """
       <Script>
       <Author>admin</Author>
       <Description>sample script to explain the arguments</Description>
       <Parameters>
       <Parameter name="scenario" type="IScenario">reference to the scenario of the current simulation</Parameter>
       <Parameter name="simulation" type="ISimulation">reference to the current simulation</Parameter>
       <Parameter name="newprefix" type="string">the new prefix of simulation name</Parameter>
       </Parameters>
       </Script>
       """
   
       print("PRE", scenario.ModelSetup.Name)
       print("PRE", scenario.Name)
       print("PRE", simulation.Name)
   
       #change the name of the simulation by replacing the part before the date    
       newname = newprefix + simulation.Name.Substring(simulation.Name.LastIndexOf(" at "))
       simulation.Name = newname 
   
   def PostProcessingScript(scenario, simulation):
       """
       <Script>
       <Author>admin</Author>
       <Description>sample script to explain the arguments</Description>
       <Parameters>
       <Parameter name="scenario" type="IScenario">reference to the scenario of the current simulation</Parameter>
       <Parameter name="simulation" type="ISimulation">reference to the current simulation</Parameter>
       </Parameters>
       </Script>
       """
   
       print("POST", scenario.ModelSetup.Name)
       print("POST", scenario.Name)
       print("POST", simulation.Name)
   
   def TestProcessingScript():
       """
       <Script>
       <Author>admin</Author>
       <Description>testing execution of other scripts</Description>
       </Script>
       """
   
       # Get a reference to the Scenario Manager
       sceMgr = app.Modules.Get('Scenario Manager')
   
       # Use it to read a simulation and scenario
       simpath = "/Group of cali/cali/Scenario of cali/Simulation of Scenario of cali at 2022-12-30 11:37:24"
       sim = sceMgr.SimulationList.Fetch(simpath)
   
       sc = sceMgr.ScenarioList.Fetch(sim.ScenarioId)
   
       PreProcessingScript(sc, sim, "test")
       PostProcessingScript(sc, sim)    
   

   Note that an unhandled exception in the script is propagate to the scenario execution and will terminate the processing. Hence, it may be good to consider encapsulating the logic in a try-except clause.

3. Applying the scripts
   The concept is the same for both types of script:

   • Get the full path of the script

     

   • Select the scenario in Scenario Explorer and paste the path to the corresponding property of the scenario in the property grid

     

   • Press Enter - it will pop-up a script parameter dialog. IScenario and ISimulation arguments will be prefilled with a Model Setup Reference, which at runtime will resolve into arguments of the current scenario and model setup.

     

     Specify any missing arguments and press OK.
     As an alternative the script can be specified by clicking on the "..." button next to each of the script properties. It will pop-up the same box as above from where the script can be selected from the drop-down and arguments specified manually.
     Notice from the script source that the ModelSetup can be obtained from the scenario, so if access to the model setup is required by the script, simply specify a variable of type IScenario as argument.

   The scripts will be executed:

   • PreProcessing: - before the execution of the adapter (but after it is instantiated), so no access to files on disk is possible
   • Postprocessing: - after the completion of the adapter execution and retrieval of outputs (so the ISimulation object is populated) but before calculation of indicators.
     

   For a linked model setup, the scripts will be executed for each of the participating linked models. As a simulation is created for each of the linked model setups, it is possible to detect which model setup a particular call is for (in case the script is only relevant to parts of the linked model setup.

   For an optimization the script will be called in each iteration.

   If the script editor is open and breakpoints are set in the script code, it will be possible to step through execution of the scripts in the context of a simulation started from the Scenario Explorer
   

   

   Any printed output from these scripts is printed in the job log if the simulation is executed via the RunScenario task. Or visible the "View Log" menu item on the simulation (notice how the scripts have altered the simulation name)
   

   

4. Removing a script
   Simply blank the property to remove the script reference and arguments from a scenario.

Populate a scenario

The scenario should be populated with objects, which will have their variables changed compared to the basic model scenario. All other object variables remain unchanged compared to the basic scenario. The objects are retrieved from the model view.

Go back to the model view.

The model view contains all the variables available for change. The variables can be added to the scenario by

Right click on the variable and select the scenario where it should be included.

Note

Only the output variables that are added to a scenario can be accessed after running a simulation.

The variable can also be included in the scenario dragging and dropping it from the model object explorer to the scenario in the scenario explorer. Multiple variables can be dragged and dropped at the same time. To select more than one variable, hold the Ctrl key while selecting the variables. The search functionality is useful for selecting multiple variables containing the same name, e.g. water demand.

Edit model object variables

The model object variable can now be edited to create a variant compared to the base scenario.

Otherwise it will remain unchanged compared to the model setup.

One way to create a variation is to associate the variable to an existing time series of the same type as the original series but having different values.

This can be done by dragging a time series from the time series explorer to the model object variable in the scenario data view,

The full path of the time series that has been associated to a variable can be seen in the fly-by text when holding the pointer above the variable. This is useful for checking that the right scenario contains the correct modified time series.

Alternatively, a copy of the original model input time series can be created and edited:

Right-click on a variable and select Edit to edit the time series.

A message will be issued informing the user where the copy will be located, and a copy of the time series will be opened in a table view.

After editing:

Click Save and close the table.

Use Hierarchy tool

The Hierarchy tool allow the user to define the input timeseries of a scenario in a robust and user-friendly way.

Note

This menu is only available if one or several timeseries are included in the scenario. The “Define Input Hierarchy” menu will be hidden if there is no timeseries to configure.*

Right click on your scenario and select Define Input Hierarchy.

A window pops up on the screen with two panels: listing on the left panel all the input timeseries defined in the scenario.

• On the left: the scenario input timeseries with no rules defined (unchanged)
• On the right: the scenario input timeseries for which a rule has been defined

Each input type has its timeseries represented in a separate tab (e.g. boundary, structures, catchment, data assimilation, etc.)

Note

To enable timeseries in a scenario you should add them from the model object

Select the scenario input timeseries to create rules for and click on the right-pointing arrow

Note

Timeseries that are not included at this step will not be generated by the Hierarchy Tool at runtime. This means that the timeseries not included in the tool have to be edited elsewhere (e.g. through a script, a job, etc.) or that the original timeseries (imported in the database during model registration) is long enough to cover the simulation period.

Once the scenario input timeseries has been added to the selection, its status is updated to “Rule required” in the right panel.

Clicking on the Set rules for timeseries button to define each input timeseries rules.

This allows the user to add as many rules as needed.

Note

A rule is a succession of steps dictating how to create an input timeseries from different timeseres and / or constant values.

Each rule in the list corresponds to a specific way of creating an input timeseries, ranked from best-case scenario to worst-case scenario. * The top rule is the best-case scenario, typically all required data is available. * Then, going down the list, rules less and less restrictive should be defined (for example: only observed is available, nothing is available, etc.).

Rules should reflect different combination of timeseries / constant values to generate the desired scenario input timeseries.

A rule will be applied only if a rule with higher priority fails. This means that if a rule succeeds, the following rules are ignored.

For each of those cases, the corresponding timeseries to use should be defined by clicking “Configure”.

1. Under “Timeseries” the Full path to the time series in the time series manager should be entered.
2. How the current timeseries should be appended to the target scenario input timeseries is defined using functions. See the table below for descriptions of the available functions.
3. The field “Factor / Value” is used when the function requires a numeric input.
4. The field “To Value” is used with the function ReplaceValue to define the replacing value.

Description of the available functions

Function name	Description
None	The raw timeseries is used. TimeStep/Offset is added to timesteps if specified.
Prefix	Creates timesteps with the specified timestep length from “Time Step” and constant value specified in the field “Factor/Value". The timesteps are added at the start (prefix) of the timeseries using the “From” and “To” dates.
Postfix	Creates timesteps with the specified timestep length from “Time Step” and constant value specified in the field “Factor/Value". The timesteps are added at the end (postfix) of the timeseries using the “From” and “To” dates. If no dates are defined, only one value is added at the last timestep of the simulation (EOS).
Constant	Creates timesteps with the specified timestep length from “Time Step” and constant value specified in the field “Factor/Value". The timesteps are added in the interval defined by the “From” and “To” dates.
RemoveTimeSteps	Removes timesteps in the interval defined by the “From” and “To” dates.
ReplaceValue	Replaces timesteps by the value specified in the field “To Value” in the interval defined by the “From” and “To” dates.
FadeIn	Extends with the current time series, fading in the difference in case of a gap in the timesteps. The field “Time Step” defines the timestep length and “Factor/Value” defines the relative increase in value between each time step. Value=0 means that the fade in should be linear. FadeIn requires a time series.

Example of a set of flags for the rule AllTimeseriesAreImported

The image above represents a case where:

• Flag 1 The specified timeseries is used from 2 days before the Time Of Forecast (TOF), as defined by “From” all the way to the TOF, as defined by “To”. This timeseries has a different time zone so the times are shifted by 1 hours (“Time Step”).
• Flag 2 The specified timeseries is used from TOF to TOF+1 day.
• Flag 3 Finally, the specified timeseries is used from TOF+1 day to TOF+4 days.

Validity criteria

The validity criterion is used to determine if the input timeseries generated by the rule is usable or not (= if the rule is valid or not). When assessing the validity of the generated timeseries, if it fails to fulfil the requirements, the rule will be ignored and and the next rule in the “Rule Prioritization” form will be assessed.

Three criteria are supported:

• Need Hindcast: the generated timeseries should cover at least from SOS to TOF
• Need Forecast: the generated timeseries should cover at least from TOF to EOS
• Need Full Coverage: the generated timeseries should cover at least from SOS to EOS. This case is equal to checking both “Need Hindcast” and “Need Forecast”.

Complete the rule configuration

Once the rule contains flags and a validity criterion, press OK to go back to the Prioritisation window. The rule status is now to tagged as “Yes” under “Configured”.

Once all the rules are configured, the button OK becomes available and Rule Prioritisation can be saved. In the Timeseries selection window, the status of the input timeseries is now “Rule defined”. Complete the same process for all the required scenario input timeseries and click OK to save the Input Hierarchy Configuration.

Analyze model object variables

To analyze one or more model object input variables:

Browse to the variable or perform a search to get a list of the input variables.

Select one or more input variables and select the tools in the Tool explorer to analyze the variable(s).

Note

The toolbox becomes available with the tools that apply to the selected model object variable type (e.g. time series).