Versions Compared

Key

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

The event keyword assigns an event to the task currently being defined. Only tasks can have events and they can be considered as an attribute of a task. There can be many events and they are displayed as nodes.
An event has a number and possibly a name. If it is only defined as a number, its name is the text representation of the number without leading zeroes. For example, event 007 can be accessed as event 7 or as event 007. Event's numbers must be positive and their name can contain only letters and digits. The use of letters is optional; the event name can consist simply of digits.
If a name is given, you can only refer to the event by its name, not by number. As such there is no point in using a number and a name, unless they are the same:

Code Block
task x

...


 event 1 # Can only be referred to as x:1

...


 event 2 prepok # Can only be referred to as x:prepok

...


 event 3 99 # This is asking for trouble! 


When a job sends an event, it is saying that part of its task has been carried out and that any task waiting for that part can now start, unless it also needs other conditions to be met. If the job then aborts and the task is resubmitted, the restarted job should be able to carry on from where it previously left off. Otherwise, there is the possibility of destroying information needed by the task triggered by the event.
In order to use events you have to first define the event in the suite definition file, e.g.
suite x
family f
task t
event foo
Where 'foo' is the name of the event. The default value for event is "clear" or false (the value shown when the suite begins). After (command begin) it looks like:

Then you can modify your task to change this event while the job is running, e.g.
ecflow_client --init $$
ecflow_client --event foo
ecflow_client --complete
After the job has modified the event it looks like:

Now the value of the event is "set" or true.