Design or adapt a Deployment DSL for Ocean Models

Type Bachelor (evaluation with MITgcm or UVic scenarios)

Type Master (evaluation with MITgcm and UVic scenarios and in conjunction with domain experts)

Tasks Based on a given set of domain knowledge, concepts and sample deployment scripts, design a textual, external DSL to control deployment of models based on the two case studies UVic and MITgcm addressing all three deployment scenarios (local, dedicated host/node, and kubernetes). The DSL includes a code generator, interpreter or Jupyter kernel which performs the deployment.

Deployment is handled differently in the scientific modeling domain than it is in enterprise and embedded systems. Starting configured and compiled models is done with scheduling systems/schedulers, e.g., Slurm ​[5]​ and OpenPBS ​[2]​. On top of such schedulers tooling, like CYLC are proposed, as an overall workflow engine ​[3]​.

CYLC could already cover all our needs or parts of them. Therefore, it is your task to analyze the domain to understand what scientists do to configure and setup scientific models and then run them. Show whether this can be achieved with CYLC (if possible), what is missing, and how to integrate this with our other DSLs.

Resources and Notes

• Introductions to how to write a thesis https://www.se.informatik.uni-kiel.de/en/student-theses/useful-hints
• Ansible is a deployment and configuration language https://www.ansible.com/overview/how-ansible-works
• The deployment process for ocean models can be quite different from those established in enterprise software where Ansible is designed for. Typical processes is (so far) configure code, compile, configure program, setup, run. All these tests can be done locally or remote. However, at the point when it goes remote it stays remote from that point on. That means when code configuration happens locally, but compiling is done remote, the rest is also done remote.
• Access to remote machines happen via ssh (legacy) or via Jupyter (latest).
• Version management and file synchronization is done via git.
• The DSL must be able to describe all phases of the deployment. This could be done similarly to a build pipeline from
  • Jenkins https://jenkins.io/doc/book/pipeline/syntax/
  • Travis CI
  • Slurm https://slurm.schedmd.com/
• Sprat Deployment based on Ansible
  • https://github.com/cau-se/sprat-deployment
• The Sprat Approach (see also below), specifically the simulation configuration DSL
  • Sprat http://eprints.uni-kiel.de/32070/
    • Chapter 7 Especially 7-7.2.2
    • Metamodel in 7.2.3 to understand the general relationship of the terminology, the property definition in 7.2.3 is done in Object-Z, but essentially the name on the top refers to the class from the metamodel and the pairs of names in the inner frame are the properties for the class and additional constraints. Inheritance in Object-Z is shown in the defition of Internal_DSL and External_DSL (the internal DSL has also a property host language).
    • 7.3 Applying the Sprat Approach To understand how and where the separation between domains happen, you need to define roles. This is described in 7.3.1
  • Source Code
  • https://github.com/cau-se/sprat-ecosystem-dsl-xtext
• Case Studies
  • MITgcm https://mitgcm.readthedocs.io/en/latest/
  • UVic (see OceanDSL internal)
• External DSL notation for syntax and semantics Syntax EBNF
• Operational semantics for programming languages
  • 2002_Pierce__Benjamin_C._Types_and_Programming_Languages.pdf ​[4]​
  • Generator Composition Approach http://eprints.uni-kiel.de/33602/ ​[1]​ Summary on type system semantics (Chapter 2)
    • Summary on Models and Metamodels (Secion 3.1)
    • Syntax and Semantics of Metamodels (Chapter 6)