IDF(5NEMO) manual page

This HTML automatically generated with rman for NEMO
Table of Contents

idf files describe named and typed parameters in a textual layout, which is then matched to an actual instantiation of this parameter file. Programs such as idf(1NEMO) can then be used to replaced such named parameters and create a new parameter file, to be used by an external non-NEMO program to be run.

Format

Parameters are (uniquely) typed and named, using the : as separator. Comment lines that don’t count in the matching parameter file can be given using the usual # symbol, true comment lines are directives that start with c:

  #  a comment line for the sake of commenting the IDF, otherwise ignored
  c:comment    # a comment line (expected in the parameter file)
  r:eps        # a real parameter, named eps
  i:nmax       # an integer
  b:verbose    # a boolean
  s:name       # a string, no quotes 
  qs:file      # a (single) quoted string
  i:n1 i:n2    # a line with multiple parameters is allowed too
  r:size[n1]   # an array with ’n1’ values, can span many lines ** not implemented
**
  r:rad[]      # an array with as many values as left in the file (one
per line)

Examples

In the following example, we use the technique in NEMO where named parameters are defined before the "--", and client parsed command line arguments after. See also the getargv() function in getparam(3NEMO)

   % idf idf=nbody.idf par=run1.par out=run2.par  --   eps=0.02 n1=4 size=1,2,3,4
rad=10,20,30,40
   % cat run2.par
   Example to run that fortran nbody program
   0.02   
   10   
   T      
   Benchmark Example 
   ’file.out’
   4 6 
   1 2 3 4 
   10 
   20 
   30
   40
   % nbody0 < run2.par

Caveats

This parameter list is very static, there is no room for an additional line, depending on the value or presence of another parameter, the only exception being the last (list) of numbers

The idea of an array "r:size[n1]" is still just an idea, there is no use case for this yet. Also we probably need to agree if they can (or must) be on a single line, or can they span. What if you then allow two array parameters, like "r:x[n1] r:y[n1]", that would suggest to pair them up

      x1 y1
      x2 y2
      ...

otherwise they should appear on two separate lines. So most likely a array notation like this means they should be on separate lines

What about the filler space in the parameter file. Should we allow an option to have them comma separated? Currently only spaces are produced, although the input parameter file can have spaces and tabs.

The (single) quoted string is sometimes needed in fortran, but not in C. Makes one wonder if we need a double quoted (qqs?) string at some point.

Future1

Should there be an option to start with an IDF file that has defaults set? Viz.

i:n=10
r:eps=0.03
qs:in=’test.in’

Future2

Should it be able to process a classic fortran NAMELIST? Example of cmhogin we use:

$ggen2 nbl=256,ymin=0.02,ymax=16.0,yrat=1.02646,igrid=1,lgrid=.true. $end

which gets processed to cmhogout:

&GGEN2
 NBL=        256,
 YMIN= 1.99999996E-02,
 YMAX=  16.000000    ,
 IGRID=          1,
 YRAT=  1.0264601    ,
 DYMIN=  0.0000000    ,
 VGY=  0.0000000    ,
 LGRID=T,
 /

Author

Peter Teuben

Update History

12-aug-2014    documentation written, after some implementation    PJT
13-aug-2014    finished implementing opend ended array     PJT

Table of Contents

Name
Description
Format
Examples
Caveats
Future1
Future2
See Also
Author
Update History