Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Fortran Programming Language

storing multiple parameter sets in an input file


Sometimes I have trouble duplicating prior results of a program
because I have changed the input file used to generate them. I am
thinking of a way to store multiple parameter sets in a data file, and
I think NAMELIST may be too restrictive. For one thing, NAMELIST won't
work for reading allocatable arrays.

I am thinking of using an input file format such as the following:

2 # which parameter set
random text
more random text
parameter_set_1
# comment line 1
# comment line 2
1.1 # x
2.3 # y

parameter_set_2
# comment line 1
3.1 # x
1.3 # y

where the name of the parameter set is read in the first line, lines
are discarded until a line starting with parameter_set_name is
encountered, and further lines starting with # are discarded until the
variables x and y are read. I could implement this with READ,
including internal READs. Does anyone do something similar to store
multiple parameter sets in a single input file?

On Apr 10, 3:04 pm, "Beliavsky" <beliav@aol.com> wrote:
> Sometimes I have trouble duplicating prior results of a program
> because I have changed the input file used to generate them. I am
> thinking of a way to store multiple parameter sets in a data file, ...

... snip some sample data ...

> ... Does anyone do something similar to store
> multiple parameter sets in a single input file?

Not by modifying a program to handle multiple cases as you've
demonstrated, no.

But, in a previous life when still doing nuclear design where NRC
required full documentation and reproducibility, I used a software
version control system to catalog input runs by project and analysis
so had tracking and change log automated as well as the ability to
reproduce input decks at will.  Something similar would be much more
easily maintained and integrated into other parts of the engineering
analysis now than it was then.

On 10 apr, 22:04, "Beliavsky" <beliav@aol.com> wrote:

How about using XML files? If you leave out all the hype and
buzz words that surrounds them, they can be very useful indeed.
The structure allows for easy storage of hierarchical data, but
that hierarchy can be easily flattened to a one-dimensional
array of cases.

If you use my library for reading XML files (and the accompanying
xmlreader program that creates a module to read such files based
on a description), then it is no more difficult than calling
a single subroutine (which is generated and takes care of the
gory details) and using the elements of the array that it fills.

See: http://xml-fortran.sourceforge.net

(The CVS version currently contains a flaw that I still need
to repair, but the released tar-file should be okay. If you have
any questions, let me know).

And there are plenty of other libraries (also in Fortran) to read
these files.

Regards,

Arjen

On Apr 10, 4:04 pm, "Beliavsky" <beliav@aol.com> wrote:

Well if I was going to do this, I would look at pre-processing the
input file to a scratch file using a scripting language such as AWK.
AWK has a "range pattern" /parameter_set_1/,/parameter_set_2/ which
extracts the marker lines and all lines between them. The only minor
problem is that the pattern must be a literal and not an expression.
You can set this up with a .bat file and 3 AWK scripts. The first
script reads a command line argument, evaluates it, and creates the
second script at run time. The third script strips out the marker
lines, lines starting with # and blank lines. It then removes the
trailing "comments" from the remaining input lines. The .bat file puts
it all together, piping the output from the 2nd script though the 3rd
script.

Sorry, I don't have a *Fortran* solution to this. :-).

-- elliot

Or you could probably do it all with one Perl script.

Languages like Perl and Awk have two advantages:  They're good at string
manipulation, and they take care of memory allocation and deallocation
for you.

They're also comparatively slow.  You wouldn't want to do number
crunching in Perl, although you could.

Louis

Beliavsky <beliav@aol.com> wrote:
> Sometimes I have trouble duplicating prior results of a program
> because I have changed the input file used to generate them. I am
> thinking of a way to store multiple parameter sets in a data file, and
> I think NAMELIST may be too restrictive. For one thing, NAMELIST won't
> work for reading allocatable arrays.
> I am thinking of using an input file format such as the following:
> 2 # which parameter set
> random text
> more random text
> parameter_set_1
> # comment line 1
> # comment line 2
> 1.1 # x
> 2.3 # y

I generally use an input style that's easy to digest
with list-directed input.  Approximately like this:

    / comment
    keyword1
    keyword2 value      / comment
    keyword3 value_a, value_b, optional_value_c
    array_keyword 4
        / 4 lines of input go here, no comments allowed
    keyword4 value value

To do this, first I decide on a maximum line length.  (Have to pick
a max :-( .)  Then I read each line in a string variable with one
more character than the maximum;  I set the extra terminal character
to a slash and parse the line.  If it's a comment, I skip.  If I
recognize the keyword, I list-directed read the parameters starting
one past the end of the keyword.

The added terminal slash is to allow optional parameters:  I set
defaults before reading, then attempt to read all my variables.
If the input line contains fewer values than possible, the
list-directed read hits the terminal slash and leaves the remaining
variables to their default value.

The bulk of the read loop is a gigantic boring if:

    if(line(1:1).eq.'/') then
        cycle
    else if(line(1:4).eq.'TOTO') then
        a= 1; b= 2; c= 3;       ! defaults
        read(line(5:),*) a, b, c
        call do_something(a, b, c)
    else if(line(1:10).eq.'TSOINTSOIN) then
    ...

For allocatable arrays, I would require the keyword line
to specify the size;  in the matching if body I would
allocate the array and run a loop to read n lines of values.

Note that this type of read loop is not limited to data input:
the keywords can trigger subroutine calls, thus providing a
primitive scripting capability.

--
pa at panix dot com

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc