Old Punch Cards

[JohnNichols]

33  IF( NS .eq. 4) GOTO 34
    IF(NS .EQ. 6) GOTO 34
    IF(NS .eq.  GOTO 34
    IF(NS .eq. 10) GOTO 34

Is there a reason to do this when typing cards? 

[JohnNichols]

The (NS .eq. did not copy across correctly and I edited it once.  Interesting that it did not fix it. 

For some reason your site is dropping the number eight from the posts, it has now happened three times. 

[Steve_Lionel]

It thinks you're typing an emoji, and then failing to display it. I complained about this earlier. Add a space between the 8 and the ).

I have seen code like that, often when the source has been modified and extended over the years. Nowadays there are better ways to write that, but if you think about it, the instructions to execute it are about the same. (If there were a lot of these I'd build a dispatch table instead.)

[JohnNichols]

Thanks.  I remember now you have been talking about emoji issues, just did not pay attention. 

It is like being at University and taking an old Fortran problem and just playing with it.  True fun. 

One thing, the Intel addon to the VS allows for five different file type creations, it would be nice to include an *.inc type. 

The include command has simplified the copying of the Prestress program as Jim noted with the common files.  Thanks Jim. 

Some one was commenting on the Fortran discourse site that there are not a lot of places to get Fortran advice.  I chuckled. 

[JohnNichols]

IF(RROAD .ne. 0.0) GOTO 480
2   REQULT = 1.5* (BMDL(6) + BMNCDL(6) + 2.5*BMMA(6)
    IF(TS .gt. FLCEK) GOTO 460
    ULTMON = ASR*FSU*DEPTH(1.0 - (0.6*ASR*FSU/(BP*DEPTH*PC))) + 0.85 FPC*(EFW - BP)*TS*(DEPTH-0.5TS)
    IF(FCHECK .gt. 0.3) goto 467
    NSTATE = 1
    GOTO 461
467 ULTMOM = 0.25*BP*DEPTH*FPC + 0.85 * FPC*(EFW-BP)*TS*(DEPTH-0.5*TS)
    NSTATE = 2
    GOTO 461
460 ULTMOM = ASTEEL*FSU*DEPTH*(1.0 - 0.6*SRATIO*FSU/FPC)
    NSTATE = 3
461 Continue
463 ULTMOM = 0.25*FPC*EFW*DEPTH*DEPTH
    NSTATE = 4
480 Continue

I started writing Fortran in 1978, so I was never into Fortran 66. 

As I typed in this little lot, it struck me, Fortran 66 did not have then and else.  The goto makes up for the then and else deficit. 

A quick look confirms my thought. 

[cryptogram]

It could have been worse.  I got my start using FORTRAN II on the IBM 1620, which didn't have logical 'IF' statements.

You could have written lines 5-7 in your code using something like this:

      NSTATE = 1

      IF(FCHECK - 0.3)  461,461,467

[JohnNichols]

We forget how far we have progressed in one long lifetime.  

[JohnNichols]

I have the Prestressed Program running and am now checking the answers against the published answers.  

The code is convoluted in parts, but it is really a sophisticated and logical design method.  I dragged out my old circa 1995 Concrete Design Book, by four world experts, there is nothing this good in the text book, not even mentioned.   I taught with one of them, so they knew their stuff.  

One observation, the team used Fortran IV and a IBM360/50 and 360/65 computers, sometimes there is a consistent 1% difference in sets of answers.  I am only using reals at this stage, but would you expect a difference between the two systems.  

[cryptogram]

The whole family of 360 computers used the same instruction architecture.  Per wikipedia, the model 65 was about 3 times

faster and supported a larger maximum core memory than the model 50.   So I would not expect differences in results based on the architecture of the machines.   More likely to be caused by differences in Fortran compilers, I'd guess.  Couldn't tell you the model number, but I'm pretty sure I was using an IBM 360 mainframe in the mid 70's that had 3 different Fortran compilers to choose from  (G and H for batch jobs, and G1 that you could use from TSO).

[AlHill]

@cryptogram TSO was old, but it sure was slow....

Doc (not an Intel employee or contractor)
[Maybe Windows 12 will be better]

[cryptogram]

Yeah, and when you tried to connect, there was always some guy named "MAX USERS"  on TSO, so you'd have to "TRY LATER".

But it was better than putting a card deck in a bin to be carted over to the computer room, and waiting for it to return with your

printout.  Only got about 1 run per day that way.

[jimdempseyatthecove]

If your "printed" answers were to two decimal places, then any round off differences would show up as +/- 0.01 (but not 1% of magnitude of result).

Note, the round off difference is amplified during formatted writes (the +/- 0.01 may reflect a change in the internal floating point value of significantly lesser magnitude).

Jim Dempsey

[JohnNichols]

IF(REPCI .lt. FPCI) GOTO 1
    FPCI = REPCI
    If(FPC .lt. FPCI) FCP = FPCI
    GOTO 101
1   Continue

This is the controlling statement for the end of the design stage.   From the printouts in the original manual it worked in the 360, but in IFORT, the REPCI and FPCI are exactly equal according to the VS Inspector, but the first if statement never triggers.  I need to put in a delta.  

[cryptogram]

The IBM 360 series also used a different floating point representation than the IEEE standard that is mostly used today.

So slightly different results can come from that.

The delta might be a good idea, so long as you know far above FPCI you can be and still be allowed to branch.

[JohnNichols]

The delta is one part in a million, so if two numbers are that close they are the same.   I have printed out the convergence on the design and it is usually about 4 to 5 steps.  

The main thing you are after for real design purposes is the number and the location of the strands.  The developers calculated a real number of strands and then rounded up to the nearest 2 - for beam balance, except in one case and that is not relevant. 

They list the placement of 32 strands in the answer, but the No of strands above the printout of the rows is 30.  

The answer I get is 31.1.   Using their format statement it printed to 31,  I fixed it to avoid confusion using ceiling and then checking the count.  31.1 to 30 is a long way. 

[JohnNichols]

Although we are all Fortran geeks, if you have never been to Vicksburg, then the battlefield is worth a trip, to see the scale and read about the differences 150 years makes in communication to the battles, but humans will always be humans.  Coming back it was 110 F in the sun according to the Weather people and the excellent thermometer in the car.  The battle was fought in that sort of weather.  Five minutes in the sun on top of the hill was enough for me. 

Next to the battlefield is the Coca Cola museum,  if you grew up on coke from the 60's you will love it, memories of your mother getting you a coke.   And an incredible bookstore, think Notting Hill and Hugh Grant run by a Nuclear Specialist.  

The drive gave me a long time to think about the prestress program and Fortran IV.  The original program uses the variable STRNS to determine the number of strands, it has several constraints,  it has to be an integer and usually a multiple of two - for the mirror image on the section to be true.   Will ignore the three case, it is not relevant.  

The following equation tells you the theoretical peak load in the strands, but  the original IV code does not round the STRNS to meet the requirements, or so it appears in just looking at the code.  The answers in the book for a standard problem provide a centre of gravity of 10.4 inches.  I have now fixed the bugs I introduced in typing in the cards, and I get all the answers correct, but the CG was coming out at 11.3 inches.   This is not correct. 

The IV equation was 

 FO = TENIN*STRNS

and it gives the correct  answer from rounding STRNS as if I had taken the floor command.   After a lot of playing, the simple solution is just using the floor function. 

 FO = TENIN*floor(STRNS)

It gives the exact answers in the book and it is conceptually correct from the engineering perspective. 

I checked the equations numerically in EXCEL,  if I had not had the answers it would have been easy to miss the issue if you were in a hurry.  

Interesting, no idea why IV gives this answer, the correct one, but why?  We do not declare the variables, but IV is clearly treating STRNS as an integer. 

Here is the program, I am still tiding up the output, but the good part is now understanding how they engineered these bridges, I found a good explanation in a standard engineering book from the 1960's by Leonhardt.   In terms of programming skills the code is advanced engineering, would have saved them weeks of hand calculations.  

[jimdempseyatthecove]

>>The following equation tells you the theoretical peak load in the strands, but the original IV code does not round the STRNS to meet the requirements, or so it appears in just looking at the code. The answers in the book for a standard problem provide a centre of gravity of 10.4 inches. I have now fixed the bugs I introduced in typing in the cards, and I get all the answers correct, but the CG was coming out at 11.3 inches. This is not correct. 

This, together with your adding floor for correction, leads one to conclude that either:

a) The card deck had the missing floor function, but the correction was installed to produce the provided results data.

b) The card deck was correct, but the provided results data were proofed (by hand, possibly with slide rule).

>>and it gives the correct answer from rounding STRNS as if I had taken the floor command. 

STRNS presumably contains the approximation within the precision of the floating point calculations used, but from a civil engineering point, fractional values may be required to be removed. e.g. "Maximum load capacity 12,000lbs" where you discard any 100's weights where the physics determined 12,987lbs for the capacity..

While the floor fixes the sample data case, I would advise being careful not to assume that this is the correct solution.

Jim Dempsey

[JohnNichols]

I checked the engineering, the floor function is required for modern Fortran. 

I am sure the results were checked with a slide rule, but the IV card deck is doing one or two strange things when compared to modern Fortran.  

The authors quite casually mix integer arithmetic with real arithmetic and assume the answer is a correct integer or real.  

I will have to check all the logic and the functions now it is working, but at least I get their answers.  I have several samples to check, so we shall see.  

1970 - they were probably not taught Numerical methods at university.  

Have you heard of the Fortran REREAD statement.  

There is one glaring error,  they have a center of gravity limit, and instead of using it as a true limit, they stop once they are passed it, in this case by more than 0.5 inches which with prestressing forces is a lot.   But the problem is compounded by the strict placement rules for the cables, so I will need to check this carefully. 

The real question is - can we overload the bridges now? 

IF(CGT .ge. CGTLMT) GOTO 4
XBAR22 = XBAR22 + SPACE
KS = KS + 1
X1 = (NROW + KS) * 2
If(X1 .ge. (D - 2.0)) GOTO 5
GOTO 3
5 IWCH = 2
4 Continue
NSTRNS = TDS
KGRID = X1
ENDECC = YB - CGT

 

[jimdempseyatthecove]

Sorry, unable to help. Too little understanding of the problem, too little information provided.

Jim

[JohnNichols]

My apologies.  The line 

IF(CGT .ge. CGTLMT) GOTO 4

is the numerical analysis problem.  CGTLMT is supposed to be the upper limit on the center of gravity.  I would expect that they should check and then set the values for the different strands to make CGT almost equal to CGTLMT, but they just run past it and say ok. Even though they are 0.5 inches passed the limit, so is it a real limit?  

Not enough information in the manual, so I will have to go check the original books.  

Fortran IV is not the best language to do what they were doing, but they did an excellent job with the tools, just not quite enough info in the manual.  No one could run the program except the main frame people, I suspect so it is not an engineering issue.  And it is much better than a hand analysis.  

UCB at the same time was writing AXISHELL, ten years later we were using it to cut the steel mass of coal bins in half from the hand design, the only issue was what was the maximum allowable stress in the mild steel, so I assumed 200 MPa and just ran with it, no coal bin codes at the time and the loads were astronomical.  These guys have similar problems, things are a bit unknown, + a good designer could look at it and say it is ok. 

I had a draughtsperson who could draw up a steel structure and then I would check it, he never made a size mistake, I was just a signing pen and a sanity check.   

We had switch loads of 4000 tonnes in a dynamic movement.  

[cryptogram]

Looking over the the code, there's some fishy things going on with STRNS:

401 STRNS = TEMPP/TENIN
NSTN = STRNS
NNSTN = NSTN/2
NMSTN = NNSTN*2.0
STRNS = NMSTN
RSTRNS = (0.003* AREA) /ASTRN
NSTNR = RSTRNS
NNSTNR = NSTNR / 2 + 1
NMSTNR = NNSTNR * 2.0
RSTRNS = NMSTNR
If(RSTRNS .gt. STRNS) STRNS = RSTRNS

I can see in the declarations, that all the variables starting with N are declared REAL, when their default type would have been

INTEGER.   It's hard to see what this code would do, if at least some of the variables were not INTEGER.

This sequence, when everything is REAL doesn't do anything at all

NSTN = STRNS
NNSTN = NSTN/2
NMSTN = NNSTN*2.0
STRNS = NMSTN

But in NSTN had been INTEGER it looks like STRNS would come out of this section with an even integer value

<= the original value of STRNS.

This 2nd bit, when NSTNR is REAL looks like it would just be an extremely roundabout way adding 2 to RSTRNS

NSTNR = RSTRNS
NNSTNR = NSTNR / 2 + 1
NMSTNR = NNSTNR * 2.0
RSTRNS = NMSTNR

But if NSTNR were INTEGER, it looks like you'd end up with an even integer >= the starting value of RSTRNS.