topic Quote:jm-nichols@tamu.ed in Intel® Fortran Compiler

Old Feature

nichols__john — Mon, 07 Dec 2015 21:24:29 GMT

I was looking at some old code in a Structures manual.

IF(ALPHA) 105,104,105

Alpha is the co-efficient of thermal expansion. I thought arithmetic if statement had been taken out of Fortran, but for fun I tested it and it worked, much to my surprise. Here it was used to make sure the alpha had a value if they forget to put on into the input routine.

My next thought is how zero is the zero in the middle?

Will it actually be removed or is it just a wish that it should not be used. Makes it horrible to read code.

John

See this in Intel Fortran's

FortranFan — Mon, 07 Dec 2015 21:32:20 GMT

See this in Intel Fortran's online documentation: https://software.intel.com/en-us/node/580743

They are very unlikely to

andrew_4619 — Mon, 07 Dec 2015 21:42:26 GMT

They are very unlikely to remove that feature as it would break a large number of old codes that work and lead to unhappy customers!

Yes the old conundrum of a

nichols__john — Mon, 07 Dec 2015 21:52:00 GMT

Yes the old conundrum of a happy customer -- thank you for the pointer to the documentation. yes if it is used as an integer test as they show in the manuals it appears to not be a problem, I was just surprised in the book to see it used to check very small real numbers 0.0000059 in this case as existing.

Thanks

john

Arithmetic IF is still in the

Steven_L_Intel1 — Mon, 07 Dec 2015 22:34:06 GMT

Arithmetic IF is still in the Fortran 2008 standard, continuing to be classified as obsolescent. It will finally get pulled in Fortran 2015. However, I don't know of any implementations planning to actually remove support from their compiler. You will get a standards warning if you have that option enabled.

A floating point number would

TimP — Mon, 07 Dec 2015 22:41:11 GMT

A floating point number would be taken as zero only if exactly zero. There may be changes in code behavior according to whether abrupt underflow is in effect, as it generally was in the f66 days.

As the question of undefined data was raised, those were un normalized zeros on many machines in those days, which still would be taken as zero.

Quote:Steve Lionel (Intel)

FortranFan — Mon, 07 Dec 2015 23:05:00 GMT

Steve Lionel (Intel) wrote:

Arithmetic IF is still in the Fortran 2008 standard, continuing to be classified as obsolescent. It will finally get pulled in Fortran 2015. However, I don't know of any implementations planning to actually remove support from their compiler. You will get a standards warning if you have that option enabled.

Steve,

Just making a note in case this ever comes up for consideration within the Intel compiler team: my own personal preference would be for the Intel compiler to issue an error rather than a warning for "deleted" features from the standard when standards checking (/stand) is in effect; that's how gfortran seems to work, if I recall correctly.

Quote:jm-nichols@tamu.ed

FortranFan — Mon, 07 Dec 2015 23:10:00 GMT

jm-nichols@tamu.ed wrote:

I was looking at some old code in a Structures manual. ..

Some questions out of curiosity: can you share the publication date of the manual? Is there a recent version (say 2010 or later) version of the manual (or one being planned for publication in the near future?) If yes, what would be the programming paradigm/language of choice? i.e., MATLAB/spreadsheet (Excel) type of approach or still a compiled language? If the latter, will it still be Fortran?

FortranFan, we'd have too

Steven_L_Intel1 — Tue, 08 Dec 2015 00:43:45 GMT

FortranFan, we'd have too many complaints if we did that. We do have an option, /warn:stderror, that turns standards warnings into errors, if that's what you want.

gfortran has a different sort of customer base than we do. What's right for them isn't always right for us, and vice-versa.

Dear Fortran Fan:

nichols__john — Tue, 08 Dec 2015 15:15:19 GMT

Dear Fortran Fan:

I was trying to keep this simple. Here is the Fortran File -- and a sample input file. It needs to be renamed to a.inp or fix the Fortran code.

The manual is actually Harrison's '73 textbook from the Prentice Hall (Newmark) Series. I have copied the relevant pages into a PDF file - I do not think I am breaking copyright doing this. The code is as close as I could get to the original allowing for the modern compiler and FORTRAN.

I was not getting the code to run as shown in the book with the examples, because it kept getting caught on this set of statements

620     IF(A(I,I)) 640,639,640
639     A(I,I) = 0.001

639 originally was a stop statement with note that A(I,I) was zero. If set as is at the moment it stops here on these problems.

If instead of stopping I set A(I,I) to some small stiffness (which is a trick I learned from ULARC, where the author there had a similar problem in the mid '70s and always gave all elements a small duplicate stiffness.) the program ran and gave me the published answers. Which is where this post started. I was putting in print statements to understand how he created the problem, encoded it and then inverted the result. The author comes from Sydney Uni - so he is very good, obviously he was using punch cards and so made it terse.

I was merely re-teaching myself some analysis steps -- been using FEM programs to long.

John

Steve:

nichols__john — Tue, 08 Dec 2015 15:17:49 GMT

Steve:

Good solid commercial answer. Of course my mother would have just raised her eyebrow.

John

I'm sorry to hijack this post

James_Pearson — Tue, 08 Dec 2015 15:27:46 GMT

This comment has been moved to its own thread

Quote:jm-nichols@tamu.ed

FortranFan — Tue, 08 Dec 2015 15:35:00 GMT

jm-nichols@tamu.ed wrote:

.. I was trying to keep this simple. Here is the Fortran File -- and a sample input file. It needs to be renamed to a.inp or fix the Fortran code.

The manual is actually Harrison's '73 textbook from the Prentice Hall (Newmark) ..

@John,

Thanks, interesting. I assumed as much i.e., that you and most readers would like to keep it simple and prefer to make little to no changes to the code from the book and use it as-is in order to understand the concepts surrounding the method/analysis in question. But since you had mentioned your source was a manual, it made me curious as to whether in year 2015, engineers and scientists working on Structures (physical ones with planes and trusses etc.!) have recent editions of manuals or only those that go back decades! And if there are current publications, what is the programming paradigm of choice i.e., whether Fortran has been passed over for other approaches?

I assume for your immediate need to try out the code, you made suitable changes (per Tim Prince's message #7 above) in the few places where arithmetic IF was being used.

1. Most structural engineers

nichols__john — Tue, 08 Dec 2015 16:07:08 GMT

1. Most structural engineers these days use packages like ANSYS which they learnt in UNI. I have access to Strand7 a good package, but if you want to play with the code you are back to olden days. You can write Fortran code for ABAQUS.

2. Most engineers are now taught MATLAB, I have had masters students who did things in 200 lines of matlab badly that was 5 lines in decent Fortran or LISP or C#. Rather than show them - I just did it. poor teaching - but I am not here to fix earlier mistakes and they do not see the need.

3. I like MIT's approach in teaching engineers a good computer language first - LISP, Scheme etc.. Once you can LISP - Fortran is easy.

4. My wife has current textbooks, mine are all in Australia and I am in Texas, and she hates it if I borrow hers, so I found the one in the library with some decent code and examples, library has stopped buying books and I wanted one I could read at home - '73 was a good year. Real structural analysis program algorithm methods have changed little since 1970. Actually there is a move towards those methods of limited memory as big data gets stellar. Benedetti was just doing some analysis on our data and quotes a text from the 1960's and then the standard Timoshenko text from the 1950s ??

5. I have been reading the Dissertations from the researchers who made DRAIN3DX. One was complaining that the code worked on DOS on Lahey's compiler, but on Windows with the Microsoft compiler they had problems. That is all that is said. I sent the person a note but have not heard back.

Best answer I can give. Education is about 120 hours only - at least 48 hours of state and uni mandated liberal stuff -- it is lucky if they spell engineer.

John

Quote:jm-nichols@tamu.ed

FortranFan — Tue, 08 Dec 2015 16:26:00 GMT

jm-nichols@tamu.ed wrote:

.. Best answer I can give. Education is about 120 hours only - at least 48 hours of state and uni mandated liberal stuff -- it is lucky if they spell engineer. .. John

Appreciate it, thanks much - your comments are eerily similar to those one hears about in other disciplines!

CODE ERROR

nichols__john — Tue, 08 Dec 2015 16:29:29 GMT

** CODE ERROR **

I found the code error in the FORTRAN file

    DO 680 I=1,L
        IP1=I+1
        TEMP=ABS(A(I,I))
        K=I

I had K=1 from the optical recognition and missed it. Apologies. Fixed code attached. I know no-one will use it - but better to be right.

John

Quick Fix

nichols__john — Tue, 08 Dec 2015 19:14:05 GMT

Quick Fix

So the new program was terminating with an error on read -- not nice

!--------------------------------------------------------------------------------------------------------------
10  If (Iflag .eq. 0) then
        READ(1,*, ERR = 1000, END = 1100)JJ,JJJ,JCT,NM,TR,ALPHA,E
    else
        goto 1020
    endif

So I set a flag to test for the end of the input as the program had a -1 in the last line. Then used a uncontrolled goto to jump for an if block. I am so bad.

My Fortran teacher from 1978 just rolled over in his grave and screamed no.

This may have been due to

jimdempseyatthecove — Tue, 08 Dec 2015 19:42:51 GMT

This may have been due to cosmetically removing a FORMAT that specified field widths and replacing it with *. The former FORMAT statement (on last line) would have resulted in -1 in JJ and 0's in remaining fields. * results in error for missing fields. Another situation of "irrational exuberance" about getting rid of old language features.

Jim Dempsey

No the original code was read

nichols__john — Tue, 08 Dec 2015 20:14:29 GMT

No the original code was read(1)

And a straight goto 10 at the

nichols__john — Tue, 08 Dec 2015 20:20:22 GMT

And a straight goto 10 at the end of the code always sent the program back to the read statement even after checking for the end of the data.

Read(1) not sure this will work - it does not gives format runtime error