Home > Archive > Fortran > March 2004 > Re: Needed: Library or function that can read program settings from
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Needed: Library or function that can read program settings from
|
|
| Arjen Markus 2004-03-27, 12:17 am |
| Claus Pedersen wrote:
>
> Hi everyone,
>
> For a simulation that I am about to program, I need a
> library/function/code that enables my program to read a plain text file
> containing simulation settings and use these during the simulation.
>
> I'll try to elaborate. The purpose is that I in some way can write text
> files with different parameter settings (i.e. integer, real, complex
> numbers and arrays of these with varying dimensions depending on my
> simulation scenario) that should be used in my simulation when I pass one
> of these settings files as argument to the simulation program.
>
> I know that it would be possible to program this myself -- but I cannot be
> the first person to have this kind of problem and the thing I need is
> merely a tool for making my program flexible to different inputs.
>
> Preferably, the library/code should be:
> - free for non-commercial use, under GPL or the likes.
> - available for Fortran 90 under SunOS 5.8, 5.9 and SGI IRIX 6.5.
>
> Any suggestions that could point me in the right direction will be greatly
> appreciated.
>
You are certainly not the first person with this problem.
Depending on the kind of data you have:
- Write a few routines that simply read the data you need (Fortran has
excellent facilities for doing so). The advantage is that you can
control
exactly what the format of the data is. The di vantage is that it
may
be a lot of work to get it foolproof. Still, if you have data like
a matrix of values, that may be the best chance.
- You can use a small library that reads a specific format. I guess many
people have such libraries and I myself have a small library for
reading
files like Windows INI files or Java properties files. I also have a
library (in Fortran) to read XML files. You can have either, if this
is all you need.
- You can also resort to embedding a scripting language. My personal
favourite is Tcl and I have written a small library to embed Tcl in
Fortran programs. The advantage there is that with a bit of care
data can be executed as Tcl code - making the effort of getting
data from a file almost null. Again: this is available, just say
the word.
The real problem is: what kind of data are you dealing with?
Regards,
Arjen
| |
| Arjen Markus 2004-03-27, 12:17 am |
| Gordon Sande wrote:
>
> In article <405ACF83.7E98437D@wldelft.nl>,
> Arjen Markus <arjen.markus@wldelft.nl> wrote:
>
>
> For close to zero extra work but with some number of restrictions
> you can use Fortran's NAMELIST.
>
> So
>
> &parms eps=1.0e-5, population=867 /
>
> will set eps and population and leave any number of othe parameters
> at their defaults. The restriction is that you need the NAMELIST name
> and format (the &parms above) and must use their convetions on arrys etc.
> To get you going until you write your own data parser it is the best
> deal in town. It is so good that you might even not bother with doing
> your own data parser. For very heavy duty you probably will do your
> own but such things look less attractive once you figure out how to use
> NAMELIST effectively. I tend to use NAMELIST for testbeds and small
> one offs but have a collection of template matching parsers for bigger
> problems. Each has its use where the other is not cost effective.
>
Yes, darn, I had forgotten about that feature - thanks.
To round it up: the problem of getting user/configuration data has
many solutions, none of which is universally applicable.
Regards,
Arjen
| |
| Arjen Markus 2004-03-27, 12:17 am |
| "Dr Ivan D. Reid" wrote:
>
> On Fri, 19 Mar 2004 15:35:15 +0100, Arjen Markus <arjen.markus@wldelft.nl>
> wrote in <405B0523.8FEF4C1C@wldelft.nl>:
>
> ^^^^^^^^^^^^^^
>
> I'm more used to truncating towards zero... ;-)
>
Truncating towards zero is but one of many possibilities :)
Regards,
Arjen
|
|
|
|
|