Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

What

Required

Description

schema location

WorkflowDescriptors.xml

yes

Definition of workflows

httphttps://fewsfewsdocs.wldelftdeltares.nl/schemas/version1.0/workflowDescriptors.xsd

Each root workflow file configured in DELFT-FEWS must be registered in the WorkflowDescriptors configuration. This is required to identify the root workflows to DELFT-FEWS. The configuration also sets some properties of the workflow. Do not add workflow descriptors for workflow files that are only used as a sub workflow file.

...

  • Id: Id of the workflow. This Id must be unique. Normally a string is used that gives some understanding of the role of the module (e.g. ImportExternal).
  • name: Optional name for the module. Used for reference purposes only.
  • visible: Boolean toggle to indicate if workflow is visible for selection in the manual forecast display. Default is true.
  • Forecast: Boolean flag to indicated if workflow is identified as a forecast. This should be the case for workflows with simulated time series as a results. Only Forecast workflows can be approved and made current. Import workflows of external data are not forecasts. Default is true.
  • allowApprove: Boolean flag to indicate if workflow may be approved a-priori through manual forecast display (stand-alone only). Default is true.
  • allowSelection: Boolean flag to indicate if workflow can be executed for specific selected locations. Default is false
  • autoApprove: Boolean flag to indicate workflow should automatically be approved a-priori (stand-alone only). Default is false.
  • autoSetSystemTime: Boolean flag to indicate workflow should automatically adjust the system time. When the workflow is completed and is fully or partly successful, the system time wil be set to the start time of the period written by this workflow.
    If the start time is not a valid time in accordance with the cardinal timestep, the next valid time wil be used.
    Default flag value is false. Applicable only on stand-alone.
  • maxEnsembleParts: Positive integer. Determines in how many parts (i.e. forecasting shell instances available) at most the workflow can be split up to run in parallel for ensembles. Ensembles can/will only be split up if this element is specified and the number specified is larger than 1.
  • timeOut: optional timeout that a workflow is allowed to run before the Forecasting Shell terminates it. Defaults to 4 hours.
  • showWarningInLogCompletion: Boolean to report whether warning messages were logged during the execution of the workflow, default false.
  • waterCoachDelay: Prevents simulated forecasts becoming available too early in water coach mode. The forecasts are finished in real life at time zero plus delay. The delay includes the run time and the time0 shift. When a forecast is scheduled at 7:00 am with a time0 of 0:00 am and the runs takes approximately an hour you should specify an delay of 8 hours. For external forecasts the delay is configured in the moduleInstanceDescriptors.xml
  • runExpirytime: Used for runs of simulated timeseries to override expiry time from global properties DEFAULT_EXPIRY_DAYS. When timeseriesets expirytime is also configured, the minimum of runExpiryTime and the timeSeriesSets expirytime is used. Obsolete for import data since 2017.01.
  • cardinalTimeStep: this settings allows for specification of the timesteps the workflow can be ran (eg specific hours per day, or every day at 00:00). This can be useful for imports or model runs that should take place on certain moments. In the Manual Forecast Display the effect can be seen when changing the T0. The cardinaltimestep is also respected by the MasterController: if the workflow is scheduled at a different moment than the cardinalTimeStep, the T0 will be adjusted (comparable to a T0 timeshift).
  • workflowFileName: Defines the root workflow config file that should be started. By default the config file name equals the workflow id. Multiple descriptors can share the same config file by using moduleConfigProperties. The config file is used as template and the $key$ are replaced by the property values, also in all references child workflow files and module config files
  • properties: These properties can be referenced in workflow and module config files with $key$, similar to global properties. $key$ is resolved by first searching in the properties defined in the workflow files defined and than in the workflow descriptor of the running task and after that in the moduleConfigFileProperties defined in the the region config and at last in the global properties in the region home
Code Block
xml
xml

<workflowDescriptor id="Run_Model_Catchment_A">
	<workflowFileName>Run_Model_Template</workflowFileName>
	<properties>
		<string key="CATCHMENT" value="A"/>
	</properties>
</workflowDescriptor> 

...