Versions Compared

Key

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

1.2 Basic concepts of CPO, UAL and migration of the codes (Split 11.2014)

 
Image RemovedWarning

Stop here for a moment. Make sure you have followed the configuration setup before proceeding any further!

Configuration related tutorial is here -> Click me! <-

 

Quote of the day:
It works for me ...
- Anonymous support employee

 

 

Image Removed
Info

In this tutorial

  • what CPOs are
  • what UAL is
  • how can you integrate your code with UAL
  • how can you access data via UAL

     

     

    Table of Contents
    Table of Contents


     

    1.1. CPO - Consistent Physical Object

    A Consistent Physical Object (CPO), is a data structure that contains the relevant information on a Physical Entity, e.g. the plasma equilibrium, the core plasma profiles (densities, temperature etc.), distribution functions, etc.

    What is important from the user's perspective is the way CPO data are stored. Each CPO structure can be accessed via UAL documentation at the ITM portal ITM Portal.

    Accessing documentation structure is fairly easy. Open ITM Portal web page in browser and navigate to ISIP related documentation.

     

    ...

    ITM Portal page
    Image AddedImage Added

     

    After documentation is opened browse to: "Data structure" (it is located at the bottom of the picture)

     

    ...

    ITM Portal - ISIP related section
    Image AddedImage Added

     

    You should see web page similar to the content of picture below

     

    ...

    UAL documentation
    Image AddedImage Added

     

    After choosing "Browse" you will see the structure of the CPOs.

    ...

    CPOs within data structure
    Image AddedImage Added

     

    What you can see at the picture above is collection of CPOs. All CPOs are bound to the top level element. After you expand particular CPO you can browse it's details. In this case magdiag (Magnetic diagnostics) was expanded.

     

    ...

    Tip

    Downloading structure

    If you plan to browse structure extensively, it is advised to download it to your local system.

     

    Exercise no. 1 - After this exercise you will:
    • know how to find CPO related documentation
    • know how to browse through the tree structure
    • know how to access CPO details
    Exercise no. 1 (approx. 10 min)

    In this exercise you will browse documentation of CPO elements.

    1. Log in into ITM Portal link

    2. Browse to Documentation -> ISIP -> Data structure

    3. Choose "Browse" from "Data structure 4.10b (Browse) (Download)"

    4. Check few CPOs to get familiar with documentation

    1.1 Structure of

    ...

    CPO

    ...

    cpodump 13 3 equilibrium
    

    1.1.1 Time independent CPOs vs. time dependent CPOs

    In general a CPO can contain both time-dependent and time-independent information. Typically, information related to the tokamak hardware will not be time-dependent, while the value of plasma physical quantities will likely be time dependent. Therefore the fields of a CPO can be either time- dependent or time-independent. The CPO itself will be time-independent if it contains only time- independent fields. It will be time-dependent otherwise. Only few CPOs in the ITM database

    ...

    are time-independent (e.g. topinfo

    ...

    ), while the others will describe physical phenomena which vary over time.

    1.1.2 Time slices

    Time is of course a key physical quantity in the description  of a tokamak experiment. Present day integrated modelling codes all have their workflow based on time evolution. Time has however a hybrid status because of the large differences in time scales in the various physical processes. For instance, the plasma force balance equilibrium (which yields the surface magnetic topology) or Radio Frequency wave propagation are established on very fast ime scales with respect to other processes such as macroscopic cross-field transport. Therefore such physical problems are often considered as “static” by other parts of the workflow, which need to know only their steady-state solution. In fact such a configuration appears quite often in the physics workflows: a physical object that varies with time during an experiment (e.g., the plasma equilibrium) can also be considered as a collection of static time slices, and the other modules in the workflow will need only a single static time slice of it to solve their own physical problem at a given time. Therefore the CPO organisation must be convenient for both

    From "A generic data structure for integrated modelling of tokamak physics and subsystems", F. Imbeaux at al.https://infoscience.epfl.ch/record/153304/files/1005201.pdf

    Time-dependent CPOs are treated as arrays of the elementary CPO structure, i.e. in Fortran: equilibrium( : ) is a pointer and equilibrium( i ) is an equilibrium structure corresponding to time index i. Since many physics code manipulate only one time slice at a time, special UAL functions exist to extract a single time slice of the CPO : these are the GET_SLICE and PUT_SLICE functions.

    source: UAL User Guide

    ...

    Each time slice is located at given index. When you are looking for a time slice, there are three possible ways of finding "correct" time slice.

    • 1 : CLOSEST_SAMPLE
      the returned CPO is the stored CPO whose time is closest to the passed time;
    • 2 : PREVIOUS_SAMPLE
      the CPO whose time is just before the passed time is returned.
    • 3 : LINEAR INTERPOLATION
      the values of the time-dependent return CPO fields are computed according to a linear interpolation between the corresponding values of the CPOs just before and after the passed time;

    1.1.3 Occurences

     

    For modelling tokamak experiments, multiple source terms are needed because many different heating/fuelling/current drive mechanisms are commonly used simultaneously. In present  day integrated modelling codes, this is usually done by pre-defining in the data structure slots for each of the expected heating methods. Moreover, the way to combine these source terms is also usually pre-defined, though present codes have some possibility to tune their workflows with a set of flags – still within a pre-defined list of possible options. In view of providing a maximum flexibility of the workflow (which can also be something completely different from the usual “transport” workflows), we have to abandon this strategy and go for multiple CPO occurrences. For each physical problem we have defined a CPO type that must be used to exchange information related to this problem. While the elementary CPO structure is designed for a single time slice, we have gathered all time slices referring to the same physical object in an array of CPO time slices. This array is the unit which is manipulated when editing workflows. We now introduce the possibility to have in a workflow multiple CPO occurrences, i.e. multiple occurrences of arrays of CPOs of the same type.
    We may have in the workflow an arbitrary number of particular modules, each of them producing specific output. These output CPOs must be initially clearly separated since they are produced by independent modules, therefore they are stored in multiple occurrences of the generic CPO. The various source modules may be called at different times of the workflow, this is allowed since all occurrences are independent: they can have an arbitrary number of time slices and each has its own time base.
    During a workflow, multiple occurrences of CPOs of the same  type can be used, when there are multiple actors solving the same physical problem. In most cases, these occurrences can be used for exchanging intermediate physical data during the workflow, i.e. data that the user does not want to store in the simulation results (such as all internal time step of a transport equation solver).

    1.1 Browsing CPOs

    In this section we will take a closer look at the data. After copying MDSPlus database files into your account's public area you can dump the data using cpodump script or jTraverser app.

    1.1.1 CPO dump

     

    Code Block
    languagebash
    titlecpodump script
    cpodump 13 3 equilibrium
     

    1.1.2. jTraverser

     

    Exercise no. 2 (approx. 10 min)

    In this exercise you will browse MDSPlus database using jTraverser application.

    1. source ITMv1 script by invoking

    source $ITMSCRIPTDIR/ITMv1 kepler test 4.10a > /dev/null
    

    2. Setup the location of your database files (in this use-case we will use machine "test")

    setenv euitm_path $HOME/public/itmdb/itm_trees/test/4.10a/mdsplus/0
    

    3. Start jTraverser application

    jTraverser
    

    4. Open database file

    File -> Open
    Tree: euitm
    Shot: [the number following "euitm_" prefix]
    5. You can now browse data

     

    1.2. UAL - Universal Access Layer

    In order to cope with multiple languages and maintaining at the same time a unique structure definition, the UAL 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 UAL as well as the developers of support tools for ITM management.

    source: UAL User Guide

    3. Writing simple code for accessing CPO data

    Accessing data from UAL requires some modification to your code. In this part of tutorial, we will take a closer look on how to access CPO via UAL.

    3.1 Accessing data using Python

    ...

    • know how to access UAL using Python
    • know how to retrieve CPO from UAL
    • know how to access CPO data

    ...

    In this exercise you will browse MDSPlus database using jTraverser application.

    1. source ITMv1 script by invoking

    source $ITMSCRIPTDIR/ITMv1 kepler test 4.10b > /dev/null
    

    2. Go to example directory

    cd $ITMWORK/tutorials/split-2014/cpo_basics/python
    

    3. Execute sample code

    python put_cpo.py
    

    4. Open example file

     

    ...

     

    vi $ITMWORK/tutorials/split-2014/cpo_basics/python/put_cpo.py
    

    What you can see here is a simple code that stores particular CPO into MDSPlus database using UAL.

    import sys
    from pylab import *
    import ual
    
    cpo = ual.itm(12,2)
    cpo.create()
    
    if not cpo.isConnected():
        print 'error during itmdb entry creation'
        sys.exit(1)
    
    cpo.equilibriumArray.resize(1)
    
    equi = cpo.equilibriumArray
    equi.array[0].time = 0.0
    
    equi.array[0].datainfo.dataprovider = 'MKO'
    equi.array[0].datainfo.putdate = '18/02/2013'
    equi.array[0].codeparam.parameters = 'param'
    
    equi.array[0].eqgeometry.boundary.resize(1)
    equi.array[0].eqgeometry.boundary[0].r = sin(arange(0,2*pi,2*pi/100))
    equi.array[0].eqgeometry.boundary[0].z = cos(arange(0,2*pi,2*pi/100))
    
    
    print equi.array[0].eqgeometry.boundary[0].r
    print equi.array[0].eqgeometry.boundary[0].z
    
    equi.put()
    
    cpo.close()
    

    Let's check how to read these data in Fortran.

    3.2 Accessing data using Fortran

    ...

    • know how to connect to UAL
    • know how to retrieve data from UAL
    • know how to prepare Makefile for your Fortran code

    ...

    In this exercise you will read CPO and print some data stored inside.

    1. source ITMv1 script by invoking

    source $ITMSCRIPTDIR/ITMv1 kepler test 4.10b > /dev/null
    

    2. Change directory to a demo location for this exercise

    cd $ITMWORK/tutorials/split-2014/cpo_basics/fortran
    

    3. Open GetSlice.f90 file

    vi GetSlice.f90
    

     

    ...

    Esc Esc : q ! Enter
    

     

    1.3. Kepler

    Kepler is a workflow engine and design platform for analyzing and modeling scientific data. Kepler provides a graphical interface and a library of pre-defined components to enable users to construct scientific workflows which can undertake a wide range of functionality. It is primarily designed to access, analyse, and visualise scientific data but can be used to construct whole programs or run pre-existing simulation codes.

    Kepler builds upon the mature Ptolemy II framework, developed at the University of California, Berkeley. Kepler itself is developed and maintained by the cross-project Kepler collaboration.

    The main components in a Kepler workflow are actors, which are used in a design (inherited from Ptolemy II) that separates workflow components ("actors") from workflow orchestration ("directors"), making components more easily reusable. Workflows can work at very levels of granularity, from low-level workflows (that explicitly move data around or start and monitor remote jobs, for example) to high-level workflows that interlink complex steps/actors. Actors can be reused to construct more complex actors enabling complex functionality to be encapsulated in easy to use packages. A wide range of actors are available for use and reuse.

    1.4. FC2K

    FC2K is a tool for wrapping a Fortran or C++ source code into a Kepler actor. Before using it, your physics code should be ITM-compliant (i.e. use CPOs as input/output). After running the ITMv1 script (to properly set up the environment variables), FC2K can be run simply by typing fc2k in the Linux command line. FC2K was developed by ISIP in Java/Python. You can find more regarding FC2K at following location.

     

    4. You should see code similar to following one

    program diagnostic
        use euitm_schemas
        use euitm_routines
        use write_structures
        implicit none
    
        integer :: idx
        type (type_equilibrium), pointer :: equilibrium(:)
    
        Integer x
    
        call euitm_open('euitm', 12, 2, idx)
    
        call euitm_get(idx, 'equilibrium', equilibrium)
    
        write (*,*) "Size of CPO: ", size(equilibrium)
    
        write (*,*) "Value of r: ", equilibrium(1)%eqgeometry%boundary(1)%r(1)
        write (*,*) "Value of z: ", equilibrium(1)%eqgeometry%boundary(1)%z(1)
    
        call euitm_close(idx)
        call euitm_disconnect()
    end program
    
    

    5. Run the code

    make clean
    make
    ./readEquilibrium
    

    6. You should see values that we have stored using Python based code.

    4. FC2K - Fortran Code to Kepler

    It is possible to encapsulate Fortran/C++ code with Java code that represents Kepler actor. This way, you can easily incorporate your Fortran code with existing Kepler workflow. In order to make it happen you will have to:

    1. Prepare Fortran code that has a subroutine to be called and is compiled as a library
    2. Prepare FC2K based description of the actor
    3. Recompile Kepler with newly created actor

    After these steps are performed, you will have an access to Kepler actor that encapsulates your Fortran code.

    All these topics will be covered in separate tutorial: 1.4 Using FC2K for embedding Fortran code into Kepler

    Powered by a free Atlassian Confluence Open Source Project License granted to Migrating Desktop. Evaluate Confluence today.

    ...