SMS triggers check are from the client side only,
ie under care of the user. It is simple to reach a situation where,
from the server side, triggers are no more valid, and related task remains queued (deadlock).
To prevent that, ecFlow triggers check is more robust:
- triggers have to be consistent from the client side.
- 'extern' can only refer to an external suite's node
- server can be requested to confirm that all triggers are referring to an existing node,
in already loaded suites.
Like the SMS, a ecFlow suite can be used for team work. It is suite design and management skill to decide
how to split the suite for a good collaboration within team members.
At ECMWF, operational suites are defined in files describing the full content.
- the definition file is split into different python modules for
- observations retrieval
- analysis and forecast
- products generation and dissemination
- plots generation
- then a python script is in charge to put all things together and to create the suite
- the user decides to load the full suite, only a sub-tree from the suite or to load it as an e-suite (test suite)
- a SCM is used to identify the modules edited by different users, merge their updates, resolve the conflicts or allow them to work in an branched version or the suite for the next release.
The following example shows that with ecflow
- a master definition file may provide the suite structure (multi1.def), with the right setting of inlimits, limits, triggers,
- a developer in charge of adding test task to the suite may update it with a task test2, below an agreed family (/multi/main/00/test),
- another tester may add some other tests as a different suite, triggered from 'multi' suite.
ecflow_client --load multi1.def ecflow_client --replace /multi/main/00/test/fc_complete/test2 multi2.def ecflow_client --replace /test20121123 multi3.def python TestBench.py multi1.def python TestBench.py multi3.def