Workflows are written in a dialect of ThetaML and allow the definition of data pre- and postprocessing. Typical applications can define iterations over a given pricing with variations in start values. Workflows can also define sources from which input data is read or results that should be written to. Thus, workflows provide the capabilities you would expect from a normal scripting language, without the support for simulation specific features such as expected values or scenariowise execution.
Workflows look very similar to ThetaML simulation models. However, they are evaluated by a different method. Hence, they allow much more more flexibility when it comes to complex data types. Moreover, workflows can take full advantage of the infrastructure integrated into the ThetaSuite. This includes the automatic generation of graphical user interfaces, the automatic extraction of data types and edit support with instantaneous error indicators.
Workflows are introduced with the workflow keyword followed by the workflow name:
workflow <WorkflowName> ... end
Workflows can import and export variables in analogy to ThetaML simulation models:
workflow testFlow import X "comment 1" import Y "comment 2" export report "Result object contains all interesting stuff" ... end
Workflows variables can have the following data types. Wherever possible, these types are automatically extracted from the workflow source with the usual method. Workflows are fully dynamically typed. Type definitions are only relevant for the user interface, where custom widgets are shown.
Float/String/Array all show the same configuration form field.
Workflows share the same set of statements from ThetaML simulation models, with exception of the theta and fork statements. Workflows do not maintain their own model time. Their statements are always executed in the same order as they are defined.
Assigments allow the definition of variables. They can be performed on variables, as well as their subfields and array components. The right hand side of the assignment can be any values or formulas.
X = ... X.field1.field2 = ... X.field1.field2[index] = ....
In workflows it is also possible to use dynamic field names.
The dynamic field must be a string. The name string may contain dots to short cut multiple subfield accesses:
X.('field') == X.field X.('a.b') == X.a.b
Loops in workflows share their semantics with ThetaML simulation models. They can be defined by the number of iterations or by an array with values. As compared to simulation models infinite loops (loop inf) are obviously forbidden.
Examples of using loops in workflows are given below:
loop 10 % do this ten times end
Array loops are possible
loop x : Array % for each element in array end
Loop results can be put into a result object
export report loop shift : ShiftArray report.shift[indexof(shift)] = .... end
Workflows use the same conditional evaluation statements as ThetaML simulation models:
if condition % do if true else % do if false end
Workflows can call each other in the usual fashion, using the same syntax as for calling sub_models in ThetaML simulation models:.
call subworkflow export context.param to param import report.case1 from report
Below we give a list of some supported operators and functions in workflows:
x[…], [1,2,3], length, …
Additionally workflows have access to file operations:
load: Load a
thetaml file, e.g. a pricing. If the argument to this function is imported from the configuration a file chooser is automatically inferred.
run: Run a loaded configuration. The argument to this function has to be a configuration that was loaded with the load command.
refresh: Refresh all formulas in the configuration. Again, the argument must be a configuration resulting from a load command.
A simple workflow can look like this:
workflow simple import file import shift export result conf = load(file) conf.param.value = conf.param.value + shift result = run(conf) end
Workflows can access all functionality that is available from the configuration page. That includes the @today parameter and all functions from the @matlab and the @ql name space. In case any custom extensions have been added to the Theta Suite they are also available.
Because results from the external functions are not automatically assumed to be numerical arrays, they are not expanded to the notation of implicitly handling scenario indices as in ThetaML simulation models. Hence, any return types (structs, arrays, cells, …) are allowed.
Obviously, Matlab actions can be triggered, such as storing data to disk, converting it to Excel, or opening some dialogues. Matlab statements that make modifications to the global Matlab workspace can have unexpected impact on the running workflows. They probably work, but they can not be universally supported.