GIT resources
- [Update] Access-layer: branch improvement/develop_new_low_level
NOTE: this branch is a clean fork of develop where we imported sources from improvement/new_low_level (which was based on Access Layer Unified, so with a messy history). If you have things in improvement/new_low_level, or any other branch of it, please import them into this new branch by one of the following ways: if changes are in a very small number of commits, you can try to cherry-pick them, otherwise, I would simply advise (only this one time import) to do from improvement/develop/new_low_level a 'git checkout mybranch myfile' (for files which do not exist yet in improvement/new_low_level) or 'git checkout --patch mybranch myfile' (for existing files, allowing you do decide by hunks which part to keep or not).
- [Update] Data-dictionary: branch improvement/new_low_level_rebased_3.16.0
NOTE: this branch of the DD (was previously improvement/all_in_utilities, and before that improvement/new_lowlevel) aims at improving IDSDef.xml so it contains needed info to build all automatically generated source codes, especially when it comes to sub-structure definition. This is subject to some changes as we discuss fixes and cleaning with Frederic.
Build notes
This version should be already installer compatible (see note below), but as the installer does not provide the best environment to develop/test the UAL, we are bypassing it and using our own script to set a compatible compilation environment. The core of the new lowlevel layer is developed in C++ and requires a compiler implementing some of the C++11 standards (Intel >= 13, and GCC >= 4.9). You will note that currently IFORT is disable from Makefile.common, as this version of the DD crashes ifort (typically when compiling edge_transport_put/get.f90): we hope to avoid this issue as soon as get/put modules have been implemented using subroutines at the sub-structure level (so far done only for copy_struct and deallocate_struct, will still require some update to IDSDef.xml, see DD note above).
Preamble
You need to build the data-dictionary in order to create the IDSDef.xml, for that the only requirement is to load the saxon module (called "saxon-HE" at ITER, and "saxon" at GW), then:
...
cd access-layer
ln -s ../data-dictionary xml
Setup on Gateway
To ease this and make sure we ended up with a identical environment/build when debugging the backend with Gabriele, I've added 2 scripts (bash or tcsh) to be sourced before compiling the UAL or running any tests. They can be found at the root of the access-layer, and are sufficient regardless of your initial environment (they take care or purging and loading the correct modules):
source setup.GW.csh
or
source setup.GW.bash
Setup on ITER cluster
We were doing most of the development and testing work on the Gateway, but when it is down or just to make sure it still compiles/runs the same on the ITER cluster you, I just added equivalent script setting the environment at ITER:
source setup.ITER.bash
Compilation
To build the lowlevel+backends only:
...
To build everything (with Fortran HLI, but try to be reasonable with the number of parallel threads 
, and do understand that the fortran HLI might be not fully working as I have a few commits to be pushed and DD is being updated/fixed):
make -j16 install
Through the installer
Set the following environment before calling make (not tested recently):
export IMAS_HOME=/home/ITER/hoeneno/test-install
export IMAS_VERSION=improvement/new_low_level_rebased_3.16.0
export UAL_VERSION=improvement/new_low_level
export IMAS_CPP=no
export IMAS_PYTHON=no
export IMAS_JAVA=no
export IMAS_MATLAB=no
export G95=no
export IFORT=no
export PYTHON=no
export PYTHON2=no
export PYTHON3=no
export JAVA=no
Building the tests
We have hand-made Fortran test programs
...
cd fortraninterface/tests/generator
make
Sources organization (what-where)
access-layer/lowlevel
It contains the C++ implementation of the new lowlevel, following the naming convention ual_"somename" (no special characters in "somename"). It is composed of a hierarchy of Context classes (in ual_context.h/cpp), a hierarchy of exception classes (in ual_exception), some constants definitions (ual_const and ual_defs), the backend abstract class (ual_backend) and some of its implementations (dummy no_backend, mdsplus_backend, memory_backend), and finally the core of the lowlevel itself with C bindings (ual_lowlevel).
...
The only exception from these left overs is ual_low_level.h/c, which corresponds to the old LL API, but now implemented using calls to the new LL API. Thus it is a possibility to develop the HLI from this almost old-API based version (as it was done, for historical reason in Fortran), but it is not a requirement! Plus the signature of some of this old-API has to be slighly changed in order to reflect the most logically different aspects, especially concerning context management and array of structure operations.
Approach and few notable changes
The main idea is to have single read and single write function passing the data using void pointer with extended set of arguments allowing to specify type, dimension and size. Then the type of read/write operation (timed, sliced, which IDS, etc...) is handled by a reduced set of functions changing a "context". All new API functions starts with "ual_" and are of two types:
...
Another important change is the disappearance of "string" concept from the new LL, as string is not a data but has different meaning depending of the programming language. Instead in the lowlevel we only deal with characters, a string being now a 1D array of chars.
access-layer/fortraninterface
Not much there as sources are to be mostly generated from the IDSDef.xml. IDSDef2F90Routines.xsl is the main XSL transform there, ones based on xsd are (xsd2copy_structures, xsd2deallocate_structures) or will be (xsd2F90TypeDef) deprecated when IDSDef.xml will be complete. Note that we are already in this branch using the single Makefile (merged from develop) instead of XSL generated makefile.
The Fortran compatibility layer is under "wrapper" subdir. It defines using ISO_C_BINDING all lowlevel functions (old and new APIs) and implements wrappers (Fortran subroutines) around these functions. It also defines Fortran version of the constants (if someone see a cleaner and extensible way to define uniquely these constants I would be happy to change the current implementation).
New lowlevel developer documentation
When you will compile the lowlevel, it will also build Doxygen documentation of the related classes and sources. There might be some small descrepencies but it should mostly be up to date and give a usefull overview of the APIs and meaning of the arguments. By browsing per files, you can check the C-API of the new LL in 'ual_lowlevel.h' with complete description of the arguments and some example usage (in implementing the old LL-API).
...