Runtime parameter file.

An important issue for our framework is organised structure of runtime parameters that would allow for simple modiffication of parameter list without introducing conflicts between different code parts. As old ###.rea file does not provide sufficent flexibility, all tool developers are obligated to use new ###.par file instead, as it organises runtime parameters by sections and in addition to 20 user parameters in [GENERAl] section allows to introduce user defined sections. Every section starting with underscore is treated as user section and its consistency is not checked by Nek5000 core code. Following examples shows two native Nek5000 sections and three user sections:

#
# nek parameter file
#
[GENERAL] 
#startFrom = rst_lid.1
stopAt = numSteps #endTime
#endTime = 1.0
numSteps = 100
 
dt = -1.0e-03
timeStepper = bdf3 #char #steady
variableDt = no
targetCFL = 0.3
 
writeControl = timeStep #runTime
writeInterval = 50  
 
dealiasing = yes
filtering = hpfrt
filterWeight = 10.0
filterCutoffRatio = 0.84
 
userParam01 =-3     # param(54) fixed flow rate dir.
userParam02 = 1     # param(55) vol. flow rate
 
[PROBLEMTYPE]
stressFormulation = no
#dp0dt = yes
variableProperties = no
 
[PRESSURE]
#preconditioner = # Schwarz is default for Nekp4est - this line should be commented0
residualTol = 1e-8
residualProj = yes
 
[VELOCITY]
residualTol = 1e-8
residualProj = yes
density = 1.0
viscosity = -2.5E+03
advection = yes
 
#
[_RUNPAR]               # Runtime parameter section for rprm module
PARFWRITE            = no                     # Do we write runtime parameter file
PARFNAME             = outparfile             # Runtime parameter file name for output (without .par)
#
[_MONITOR]              # Runtime parameter section for monitor module
LOGLEVEL             = 4                      # Logging threshold for toolboxes
WALLTIME             = 23:45                  # Simulation wall time
#
[_STAT]             # Runtime paramere section for statistics module
AVSTEP               = 10
IOSTEP               = 50

Module's runtime parameters.

We utilize user defined sections in ###.par to set values of runtime parametes defined in different modules. To simplify interaction between different tools the frame module provides dynamical database of all available runtime parameters in the framework. To provide requred information to the framework we introduce the module registration phase and split if from the module intialistation. All these steps are performed by frame_start, which initialises the framework itself and next calls a user interface frame_usr_register. This routine shoud be placed in ###.usr and contain calls to the module registration routines. The registration of the module consists of signing up the module in the database followed by the runtime parameters definitions (name, type, description and default value) and finalised with timers definitions. This information is used to check consistency of the ###.par file and to fill in runtime parameter database. Next user defined frame_usr_init is called by frame_start. It initilises all the modules by calling their initialisation routines. This operation consists of taking back updated values of runtime parameters from the database and performing requred by the module addtional operations.

Following example shows the way a statistics module is initialised:

!======================================================================
      subroutine userchk
      implicit none
      include 'SIZE'            !
      include 'TSTEP'           ! ISTEP, lastep, time
      include 'INPUT'           ! IF3D, PARAM
 
      if (istep.eq.0) then
!     start framework
         call frame_start
 
!     set volume flow parameters
         param(54) = uparam(1)
         param(55) = uparam(2)
      endif
 
!     monitor simulation
      call frame_monitor
 
!     for statistics
      call stat_avg
 
!     finalise framework
      if (istep.eq.nsteps.or.lastep.eq.1) then
         call frame_end
      endif
     
      return
      end
!======================================================================
      subroutine frame_usr_register
      implicit none
 
      include 'SIZE'
      include 'FRAMELP'
!-----------------------------------------------------------------------
      call stat_register
 
      return
      end subroutine
!======================================================================
      subroutine frame_usr_init
      implicit none
 
      include 'SIZE'
      include 'FRAMELP'
!-----------------------------------------------------------------------
      call stat_init
 
      return
      end subroutine
!======================================================================
      subroutine frame_usr_end
      implicit none
 
      include 'SIZE'
      include 'FRAMELP'
!-----------------------------------------------------------------------
      call stat_end
      
      return
      end subroutine
!======================================================================

Each tool has to provide routines for registration, intialisation and finalisation of the given module. chkpt_register and chkpt_init are good example of them.

Dependencies between different modules can be expressed as a tree structure, which we would like to follow in our database. That is why each module during registration has to specify its parent, which can be its real parent module (for submodules) or FRAME module (the first module registered by frame). In a similar way we specify parents for timers.

The list of all defined parameters, their dafault values and dependency between different modules are described in following pages: