Versions Compared

Key

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

Table of Contents

05.2.1. AL - Access Layer

  • API providing access methods (read/write) to an ITER physics Database based on the ITER Physics Data Model
  • Provided in Fortran, C++, Matlab, Java, Python
  • The only effort for using the Data Model is to map the input/output of your code to the Data Model and add some GET/PUT commands
  • The access methods are writing to a local database stored in your account
  • These local databases can be shared among users (for reading only) and can be accessed remotely

In order to cope with multiple languages and maintaining at the same time a unique structure definition, the AL architecture defines two layers. The top layer provides the external Application Programming Interface (API), and its code is automatically produced from the XML description of the ITM database structure. For each supported programming language, a high level layer is generated in the target language. The following sections will describe the language specific API, and they provide all the required information for simulation program developers.

The lower layer is implemented in C and provides unstructured data access to the underlying database. It defines an API which is used by all the high level layer implementations. Knowledge of this API (presented in a later section) is not necessary to end users, and is only required to the developers of new language specific high level implementations of the AL as well as the developers of support tools for ITM management.


First use case: User or code accessing Data Base through Access Layer

...

  • The structure is layered so that functionalities are clearly separated
  • It is generic and independent of e.g. the launching script/workflow engine

  • The Physics solver part (dark green) is not changed, it is not linked to the ITER Data Model. It may use the ITER Data Model internally or not.
  • The architecture is identical to the case of a component called within a workflow engine
  • The Physics Subroutine can be directly reused to generate a workflow component – the IMAS Infrastructure provides a tool that generates the component (pink part) automatically

  • Exception: for codes handling massive amounts of data, Data Access is usually parallelised and must be done inside the physics_solver (no processor has enough memory to gather all data)

Conclusion

  • This introduction presented the IMAS basic concepts and some details on the ITER Physics Data Model
  • Other training sections will guide you for interfacing codes, generating workflow components, running workflows
  • The Physics Data Model User Guide is the technical reference for using IMAS and the Access Layer. You can find it (and many other information) on https://confluence.iter.org/display/IMP
  • In case of any question, raise it on https://jira.iter.org