Rose & Cylc Introduction ROSE: http://metomi.github.io/rose/doc/rose.html CYLC: http://cylc.github.io/cylc/ Contents What are Rose and Cylc?... 1 Sharing Work... 3 Modifications Made Simpler... 4 Interactive Operation... 5 Summary... 5 What are Rose and Cylc? Rose and Cylc together constitute a workflow designer and manager, providing a more sophisticated and easy to use interface to running jobs on Raven. For conciseness we shall refer to Rose & Cylc as a single entity, Rose/Cylc, unless specifically referring to one component. For the average user it s not necessary to distinguish between them: most operations will be performed via Rose, with Cylc being run automatically when required. 1 P a g e
The best way to demonstrate how Rose/Cylc works is via an illustration, obtained from Cylc s web page: This graph shows some of the concepts of a Rose/Cylc workflow, or suite: Task dependencies. A particular task, such as copying data, running a model, or performing some postprocessing operations, is defined as being dependent on the success or otherwise of another task. The Cylc task scheduler intelligently builds a dependency graph and runs tasks when all their requirements have been met. Each task will run independently on Raven as a separate job, so it s easy to chain smaller tasks together without running into the scheduler wall clock limit, and Rose/Cylc s flexibility allows some very sophisticated suites to be defined without having to laboriously trace a path by hand through the workflow. Task cycling. Rose/Cylc is built around the concept of repeating tasks at scheduled times/intervals. So, for example, if you want to run a particular set of tasks every three hours for a week and then stop and collate the resulting data then that s a simple process. It is also possible to define tasks as being dependent upon a particular task from a previous cycle, or even a task in another suite. Of course, cycling is purely optional, and if you simply want to run a suite once and exit then that is not a problem. Task parallelism. We stated earlier that Cylc creates its own dependency graph. As part of that it also tries to run as many tasks simultaneously as possible. For 2 P a g e
example, if you have two tasks that require the output from some particular model but are not otherwise related then these two tasks can run at the same time. Error handling. A task may fail, and it is possible to define what actions are performed in this case, whether attempting to re-run the task a set number of times in case of transient access to data, holding the suite at that point for manual intervention, or performing an alternate action. Sharing Work Rose/Cylc suites are built around the concept of remote storage, with a built in suite discovery engine allowing a user to search for similar suites, or ones running similar software. In the example below we are searching for suites that run CP2K: Once found it is a simple matter to copy a suite so you can modify your own version without affecting the original. Each change is marked by a particular revision number, so that you will know exactly which version of the suite is used to produce which data, and if you share a suite with other users you can specify exactly which version you want them to use. In addition to making it easier to share suites, this revision control mechanism provides incremental backups whenever a change is made, and allows comments to be 3 P a g e
attached to each revision so that it s clear what changes have been made a why. This ensures that there need be no ambiguity as to what tasks are being performed. For lectures and researchers with PhD students simply specifying the name of the suite will allow the students to obtain their own copy, and should the supervisor need to examine the work it is a simple matter to download a copy. Modifications Made Simpler For suites using software with complex configuration files and command line arguments, the ability of Rose/Cylc to attach documentation, type, and permitted values to variables means that it is possible to error check input for validity before the suite is even run, reducing the chance of running tasks with incorrect or unstable settings. It is then possible to wrap these settings in a graphical user interface to make it easy for those unfamiliar with the underlying tools to be assisted in their configuration. In the above simple example the job submission settings are annotated, options are limited in some cases to permitted values, such as the job queue, and where freeform input is allowed the values can be checked automatically before saving. In more complex cases an 4 P a g e
entire configuration file could be constructed like this and then written out before the job is run, without the user having to touch a text editor. Interactive Operation While a suite is running it is possible to view the status of tasks: waiting, running, completed, etc., and even view the output and error messages from tasks via a graphical interface: This provides immediate feedback on the status of a suite and allows the suite to be paused at any point in case of anticipated failure. In addition, tasks may be triggered manually and repeated on demand. Summary To summarise, Rose and Cylc provide an alternate way of scheduling jobs on Raven, using the concepts of workflows, shared development, and task dependency. For more information and to try Rose/Cylc for yourself, please see the ARCCA Rose Setup guide, and the suite development guide. 5 P a g e