Silverfrost Forums

Welcome to our forums

FTN95 beta testing

15 Aug 2018 8:54 #22470

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'.

15 Aug 2018 10:29 #22471

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/
15 Aug 2018 11:17 #22474

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

17 Aug 2018 5:58 #22479

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.

18 Aug 2018 11:40 #22482

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.

Please login to reply.