forums.silverfrost.com

[mecej4]

The input items for each namelist input should be terminated by a '/' character instead of '&End'.

Some compilers allowed other ways of formatted namelist input, including the use of '$'. Better not to rely on any of these non-standard ways.

[DanRRight]

I never used namelists so here is the question: when namelist is used - at compile/link or at run time?

[LitusSaxonicum]

Dan,

NAMELIST (which I don't use either) is a way of labelling data values which otherwise appear as semi- (or totally-) incomprehensible list of numbers etc in a datafile. The downside is that the user preparing the datafile has to know the corresponding internal variable names. It therefore appears in the source code, and the corresponding names have to appear in the datafile.

In a fully-fledged Windows program, where the user inputs data interactively and then saves the file, it's a moot point as to whether the plain list of data is that much of a difficulty, and I can see that NAMELiST might have a use if the programmer wants it.

Eddie

[mecej4]

A namelist allows one to keep input data in a self-documenting style. Consider, for example, the thermodynamic state of a pure substance, which can be specified by any two independent properties from the set T, p, v, u, h, s, a, g. The program contains the declaration

[JohnCampbell]

I too am a namelist sceptic.
It appears to be a data input format suited for the program developer, rather than the user.
However it does have some flexibility that is of interest.

mecej4, for the case you outline where data inputs are optional, is there an easy way to find out what values have been updated, or do you have to check values against a previously set invalid value to confirm the value was updated by the namelist statement ?

I have struggled for years, either
a) re-writing a flexible user input approach, something like:

DO
call get_next_token (...)
call get_token_value (...)
select case (token)
case ...
END DO

or
b) giving up, generating data in excel, dumping as a .prn file and reading a fixed format data layout, usually with some section headings.

I am at the stage now where my finite element data generator is a mix of Excel and Fortran, prefering the fixed layout data input option for my analysis program.

[LitusSaxonicum]

JC,

If you have an internal null data set at program initialisation, then you need to input all the data values before you can do a meaningful analysis, but if you launch your program with a data set that is internally complete, then you can (subject to what you do with the data values) update them one at a time.

In a Clearwin+ / Windows context, this is the difference between (say) �File | New� and �File | New from template�.

In the former, you might present the user with a set of input boxes asking for �Number of elements�, �Number of nodes�, �Number of supports�, �Number of loads� etc, then get the coordinates and connections � in other words, step through your traditional text file input. You will find doing the file in Excel far more effective than that. You don�t need NAMELIST.

The alternative approach (which I use) is to go for the �New from template� approach. In a finite element context, it might start with a single element, with 2 support nodes and the third with a load on it, already supplied with a constitutive law and material properties. You could analyse that, and get an answer, although not very useful, I admit. Then, your user can add to it, maybe stretching and distorting that first element, then adding lines of elements (or areas that the program infills with a mesh), at all times keeping a dataset internally that is fully valid.

If there is only a small set of changes that the user can make, they are selected with appropriate mouse clicks, possibly with SHIFT, CTRL or ALT key modifiers. If there is a bigger set of editing options, the user must select each from a palette of options � in my case, one that pops up with a double click � but which can be on a toolbar. If you save such a dataset, there is no need to use NAMELIST, but you can, of course, because as the programmer you do know what the variable names are. However, it does make �File | Open� and �File | Save� (or �Save As�) callbacks far more complicated. I use formatted output, and unformatted input, when saving or opening such files.
The big advantage of the �New from template� approach is that you never need to test your dataset for completeness.

My main interest is not FE analysis any more (it has been in the past) but I still dabble. I�m working (intermittently) on a system of creating closed polygons that the program fills with elements and nodes via a mesh generator.

For me, NAMELIST is, and always has been, a facility that I can see might have attractions to someone, although that someone is not me.

Eddie

PS. You can always fill your initial internal dataset with values that scream 'I am not defined'.

[mecej4]

NAMELIST is for formatted character mode I/O, and has been part of Fortran since Fortran IV. It is probably not useful in a GUI program or for programs that produce graphical output.

NAMELIST is appropriate when the programmer writes a tight and precise specification for the input to the program, and expects the users of the program to follow that specification. If the user's input is incorrect, eventually there may be an error message issued to say so, or the results output by the program may be wrong, but detecting such errors is the user's responsibility.

I am also a very infrequent user of NAMELIST. One situation where I have found it helpful: if a program that I am debugging has a large number of local variables, and I suspect that some of those are getting changed even when I did not expect them to change, I can put a selection of those into a NAMELIST, and add WRITE(*,NML=<namelist>) at a number of places. Or, if the compiler's symbolic debugger supports displaying the values of NAMELIST members, I can use that facility instead of WRITE.

Here are two examples of packages that use NAMELIST:

http://jules-lsm.github.io/vn4.2/namelists/contents.html

http://www.tampa.phys.ucl.ac.uk/rmat/

[LitusSaxonicum]

mecej4,

Yep, I think that NAMELIST may even have been in my now long-lost copy of McCracken's book. It turned out to be one of those facilities not always available (especially in 'subset' compilers like the IBM1130 or early MS Fortran on the PC), and therefore something to be avoided if one wanted to ensure programs worked on a variety of machines. It therefore fell outside my personal 'safe subset' of any breed of Fortran. After nearly 50 years of never finding a use for it, I suppose that I never will ...

Eddie

[PaulLaidler]

John

I think that you have misunderstood mecej4's comment. He can reproduce your problem by hiding SRC in some way (for example by changing its name).

I guess I could confirm this but otherwise it works OK for me.

[mecej4]

John S.: If you remove the line containing "RESOURCES" from the *.RC file before running SRC on it, things will work fine. This line is probably a label that is used by the compiler to separate the resource declarations from the preceding Fortran source lines.