# 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)
% 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
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.
i:n=10 r:eps=0.03 qs:in=’test.in’
$ggen2 nbl=256,ymin=0.02,ymax=16.0,yrat=1.02646,igrid=1,lgrid=.true. $endwhich 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, /
12-aug-2014 documentation written, after some implementation PJT 13-aug-2014 finished implementing opend ended array PJT
Table of Contents