Interesting find of an old useful Fortran Program

[JohnNichols]

I was looking for some stuff yesterday and I stumbled on this old Fortran program, which is likely useful if updated.  

[jimdempseyatthecove]

This is an exceptionally good representation how programs were documented and written. Thanks for the post.

Using Acrobat Reader, I can copy the text of the scan, though it occasionally drops a C for comment and/or line number. I haven't experimented too much to see if there are issues with "." and ",".

Jim Dempsey

[JohnNichols]

I am going to use scan reader and put code in, I have an old bridge and I need to check a 1960s prestressed beam.  Better than doing it by hand.  

[mfinnis]

A Windows version of what looks to be the current incarnation is here: https://ftp.dot.state.tx.us/pub/txdot-info/isd/txdotapps/pstrs14_v6.1.1.zip

with user guide: https://ftp.dot.state.tx.us/pub/txdot-info/isd/txdotapps/support/user_guide_pstrs14.pdf

[JNichols]

I was after the code not the exe, but thank you.  

[jimdempseyatthecove]

What condition is/are the 1960s prestressed beam? Spalling, cracks, corrosion, etc... I do not recall, while glancing over the code, and variables associated with wear and tear or aging. Some time ago, I did some code optimization for a highway simulation program used by South African National Roads Agency. Traffic the makeup of traversing the highway and environmental factors (vehicle weights, number of axles, frequency, time of day, rain/no rain, and several other factors that could affect stress/strain/ageing of the materials. The code would handle up to 20-some different layers of roadbed materials. The traffic and environmental factors would contribute to the formation of microfractures and propagation of these into full fractures of the roadbed. I would imagine that a bridge beam could experience wear and tear over 80 years. 

>>I am going to use scan reader and put code in

I recommend you use Acrobat reader and copy and paste. E.g:

SUBROUTINE ALLOW
COMMON/ALL/ FBII,ACOMPR,TTEN;FTP,PLOSS,PPERST
COMMON/ILL/ REQULT,ULTMO~,FPC,FPCI,NSTATE
COMMON/KI/ ASL,IBSL,INA,VTC,YBC,YTCSL,ZTSL,VBCSL,ZBSL,AREAC,F.CCL,
lENOMAX,TENIN,SPANL,BSPAC,~TVPE,TS, F.F~ ,UWB,UWS,EC,ECSL,ES,~STRN,
2F,S,NCOL,ZTR,ZBB,VT,AREA,O,I~,Z~6C,STRNS,ECAL,VB,ZT~C,WTF,6P,AV
3oFPV,LTVPE,KASF,KOOEoRROAO,SFPC,OFACT,DIA
DETERMINE ALLOWABLE STRESSES
FBII = 0.6*FPCI
AC0'1PR = 0.4*FPC
TTEN =-7.5*SQRTIFPCII
FTP =-3.*SQRTIFPC I
IFIFTP.LT.I-250.11 FTP : -250.
TENIN : 0.7*FPS*AST~N
PLOSS : 0.20
PPERST : TENIN*I1. - PLOSS I
RETU~N
END

Not perfect, indentation missing, C on comment (line 8), missing C-only lines before and after line 8, some letters botched (substitued of ~ for questionable character), comma seen as o, and a few more.

This said, printing the image (or screenshot) might degrade the image and introduce additional errors. It would be worth a try to do some tests as improved AI converters could do a better job. You would have to perform a visual side-by-side review and edit.

Good luck.

Jim Dempsey

[JohnNichols]

I have not used a card reader in decades, just out of interest the description array is char*4 over 40 elements, how would they have put this on a 72 column card?  

I have the first main unit running, once I have a data file created I will upload it.  

The goto statements remind me of an Italian lunch table after eating the spaghetti. 

[jimdempseyatthecove]

I think you are experiencing a knee-jerk reaction/aversion about goto statements. As used in this program, they hardly amount to spaghetti.

After you have converted the program, you could re-write to eliminate the goto's. Though you may find it appealing to change the numbered labels to named statements:

    FindWaldo: DO i=1,WhereAbouts

         ...

        exit FindWaldo

       ...

Jim Dempsey

[JohnNichols]

Perhaps yes.  

The goto's are ok, I just got tired of typing them and getting the numbers correct.  

I am sure they will become simpler.  

Waldo died last week. 

[JohnNichols]

1>C:\Users\macne\Documents\Visual Studio 2017\Projects\Program117 - Damping\PrestressBridge\PrestressBridge\PrestressBridge.f90(74): remark #6375: Because of COMMON, the alignment of object is inconsistent with its type - potential performance impact. [TS]

I have never seen this before?  I do not often use commons.  

[John_Campbell]

Interested to know if the 60 year old tendons are bonded ?

With that vintage code, I would try to move all common to include files and check for "equivalencing" with change of variable lists, especially with odd length integer lists. It was a typical way to addres memory limits, by adding local variables to the end of a nominated "scratch" common or when trying to minimise argument lists for subroutines. If you can identify local variables added to common in this way, it may save some work to remove them, although check for assumed save issues.

I would create a file for each common occurrance and do an fc comparison.

Alignment was not an issue back then, when there was little thought of portability. The modern approach of "padding" could have be addressed in a more robust way.

It can't be too old if character*4 is used ? Not many card input by then.

[JohnNichols]

That is the key problem, what is happening inside the old bridges.  But once we have the acceleration and analysis data then you need to compare to a model and do Monte Carlo analysis in the end.  

First I will get the program running and answering questions and then make changes.  

Debonded tendons can destroy the bridge 

[JohnNichols]

I have been adding format statements, occasionally you forget the last ). 

You get these errors:

Why does the compiler try and tell me there is something wrong with the subroutine, before the one with the missing ). 

You just have to learn to ignore the error and see the 5082 error. 

[JohnNichols]

Jim:

The program has a block data subroutine.  

Does the block data load before the program executes?  

Never used one before. 

JMN

[jimdempseyatthecove]

BLOCK DATA (intel.com)

The short answer is yes.

The object code, as used by the linker, has different "segment" types. Two of which are:

data: initialized data (data with preset initial values)

bss: uninitialized data (data without preset initial values)

It would be an implementation issue as to if:

a) The runtime location of the variable resides in the data segment

b) The runtime location of the variable resides in bss segment ... however the initialization data resides in the data segment .AND. the startup code copies the initial values from the data segment load location into the data load location in the bss segment. This would be relatively low overhead block copy.

c) similar to b except the runtime location is in the bss segment.

Steve may be able to answer as to how the implementation is performed with the Intel version (at least the ifort version as of the time he was employed).

Note, some systems (e.g. embedded) contain read-only memory. These systems generally have two types of data segments. One loads the preinitialized variables into read-only memory, and the other loads into read/write memory. r/w memory can potentially be RAM (fast) or Flash (slower access writes).

Jim Dempsey

[JohnNichols]

Jim:

I got the common data into the program, it makes sense - thanks for the explanation. 

I am only part of the way through but I enclose the file for you.  

Once I have it running, I will need to check all the equations, but there are several results sets so that is good.

In the common data, the author included words(40) which is character*4 in a data block and tried to set the values to zero.  The compiler complained at that point.

I had lunch with a former student today and was told, FORTRAN is dead.  She also told me of a design that had all the light switches behind the doors.  

I did not try and explain. 

Thanks for your help.

John  

[jimdempseyatthecove]

>>words(40) which is character*4

Look at the code to see if the array words is equivalenced to an array of (or list of) REALs. In old-hand Fortran, one had to resort to reading/writing in/out binary data as character format via an equivalence.

Jim Dempsey

[DavidWhite]

Jim and John,

I just want to say what in interesting discussion this is regarding both the old programs and how we manage aging infrastructure.

The rest of us just keep going around assuming everything under the surface is still good enough for us to keep on using the bridges, etc.

Regards,

David

[JohnNichols]

1. Do you still have your Fortran mug.  I should make caps?

2. A day in the life of a infrastructure boffin:

Thought 1  -- I should ask Jim

Email 1 -- did you do the bridge in ?? yet?

Thought 2 -   censored

Email 2 --- the ten span one

Thought 3 -- rewriting the code to do the 10 span bridge is not fun - let us lose 2 weeks to coding to fix the code error you found 

Email 3 _ out -- yes, the fourth span is showing a torsional failure  from the FEM model, sorry I did a straight one - to hard to curve, and it matches the FFT patterns, due to the 7th mode.   Put some sensors on it, observe the cracking and worry about it in 100 years (after I am dead is the best thought of the day)

Thought 4 - I hope Jim has replied, ----------------  checking --------------- yes, great -- good idea --- back to coding

Thought 5 - I wonder where mecej4 has gone, he has no messaged for a while, hope he is ok

Email 4  --   why Fortran?

Thought 6 -  Impure thoughts

Fun1 -- read Fortran forum, get a good laugh at Steve,  who drinks coffee these days?

Fun2 - read Guardian - remember to take old age medicine --- Guardian is cheerfully depressing 

Back to coding,  there is a minor anomaly in the  center of gravity method in the TXDOT code, it appears to also show up in their modern copy of the 1970 code - but one cannot be certain?

Thought 6 - remember do not tell people there is an anomaly - they  do not like being told things

Thought 7 - mecej4 could solve it, but it is better to rewrite the code to follow the Hall method - put into future list

Coding in Fortran on an DXF writer to draw the beams -- Fortran draws beautifully 

Thought 8 on looking at dxf file in AutoCAD, I hate that colour - cyan -- why do engineers always pick cyan?

Thought 9 I should ask Jim that question

Email 5 --  you have got to be joking - 

It is now 9:11 and I have been at it for an hour, the things all occurred in the last two weeks - 

Final thought - email Mary at Intel - she is always good to cheer you up.