The examples in the tutorial show how to build up a suite definition using the python api.However the suite definition describes the static structure, it's not until it the definition is loaded in the server, that we see its dynamic behaviour.
The python api allows the simulation of With ecflow python API, the dynamic behaviour of the suite can be simulated, ( i.e. in the same manner as the server).
...
- Exercise the suite definition. There is no need for '.ecf' files
- Allows for very easy experimentation.
- Can be done on the client-side, no need for server
- Can help in detecting deadlock's
- Will simulate with both 'real' and 'hybrid' clocks
- A year's simulation can be done in a few seconds
- Can be added as a unit test, to prevent regressions
The simulation relies on you adding simple verification attributes. (This is similar to c/c++/python asserts). These can be added to a task, family, and suite nodes. (see below for an example)
There are however restrictions. If the definition has large loops due to, crons or Repeat date attributes, which run indefinitely, then in this case the simulation will never complete, and will timeout after a years year's worth of run time.
This can be compensated for by adding start and end clock. If no start/end clock is specified, the simulator makes the following assumption about the simulation period.
- No time dependencies - simulate for 24 hours.
- day attributes - simulate for 1 week
- date attributes - simulate for 1 month
- cron attributes - simulate for 1 year
- repeat attributes - simulate for 1 year
Additionally if time base attributes like, time, today,cron has no minutes, then the simulator will use 1-hour resolution.
Here is an example of a text-based suite definition that use uses a verify attribute, for which we want to check our assumption about the dynamic behaviour.
Code Block | ||||
---|---|---|---|---|
| ||||
suite year # use real clock otherwise the date wont change clock real 1.1.2017 # define a start date for deterministic simulation endclock 1.1.2018 # When to finish. A endclock is *ONLY* for use with the simulator. family cronFamily task t cron -d 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31 -m 1,2,3,4,5,6,7,8,9,10,11,12 10:00 # run every day at 10am for a year verify complete:365 # assertverify that this task completes 365 times endfamily endsuite suite leap_year # use real clock otherwise the date wont change clock real 1.1.2016 # define a start date for deterministic simulation endclock 1.1.2017 # When to finish. A endclock is *ONLY* for use with the simulator. family cronFamily task t cron -d 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31 -m 1,2,3,4,5,6,7,8,9,10,11,12 10:00 # run every day at 10am for a year verify complete:366 # #verify assert that this task completes 366 times in a leap year endfamily endsuite |
This python segment show shows how to load a text-based suite definition(cron.def) and simulate it in python.
Code Block | ||||
---|---|---|---|---|
| ||||
import ecflow defs = Defs("cron,.def") result = defs.simulate() assert len(result) == 0, "Expected simulation to return without any errors, but found:\n" + result |
...
- defs.depth: This file shows a depth-first view, of why simulation did not complete.
- defs.flat: This shows a simple flat view, of why simulation did not complete
Both files will show which nodes are holding, and include the state of the holding trigger expressions. def simulate_deadlock():
Deadlock
This simulation is expected to fail , since we have a deadlock/ race condition
|
|
|
|
|
|
|
|
|
|
|