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]

My first step and I just finished was to input all of the code, it was a hand type job as the machine reading was a mess. 

The second step was to get the code running and outputting the answers that are in the manual.  These are beams that have been in service for 50 yrs and so it is likely they are ok in terms of "not likely to fall down" this week.   And checking that the answers made some sense in terms of design. 

The third step was to put enough write statements in that I could start to make sense of their logic.  

It appears that two people worked on the program, there is some interesting duplication. 

It does however provide a nice starting point in Fortran to look at the capacity of the beams now.  

I assumed the variable type as I typed in the code, now I have a full printout I can go back add comments, understand the code and clean it up a bit and fix the variables. The big one is the number of strands. 

I can download the current program and compare the answers.  

it will form part of a monitoring system, eventually. 

[jimdempseyatthecove]

JN>>It appears that two people worked on the program, there is some interesting duplication. 

cryptogram>>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 appears that someone was sloppy/careless and made NSTNR, NNSTNR, NMSTNR real variables.

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

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

!Case 1: RSTRNS = 11.5
NSTNR = RSTRNS          ! 11
NNSTNR = NSTNR / 2 + 1  ! 6
NMSTNR = NNSTNR * 2.0   ! 12
RSTRNS = NMSTNR         ! 12.0

! Case 2: RSTRNS = 12.5
NSTNR = RSTRNS          ! 12
NNSTNR = NSTNR / 2 + 1  ! 7
NMSTNR = NNSTNR * 2.0   ! 14
RSTRNS = NMSTNR         ! 14.0

The as integer produced the closest multiple of 2 strands .GE.  the minimal (with fractions) to meet the load requirements.

This was the requirement as described by JN.

JN, caution, the programmer making one or more of NSTNR, NNSTNR, NMSTNR real may have been necessary to fix some other section of code without regard to the effect it has on the above section of code. So... please review all other places in the code where these variables are used. IOW fixing the above section of code may break a different section of code.

Jim Dempsey

[JohnNichols]

Yes the last errors to fix are the reals and integers.   

But it has been interesting to do.  The real challenge was the poor quality of the copy and the PDF, so just getting it running has been a long slow jigsaw puzzle.  The next step was getting the book answers and now the real QA check can begin, but at least I have an approximate copy of the original and some people here who have keen eyes and are friendly.   Good rule, make one small change and check the answers. 

The real challenge is the statistical overload been thrown at the world, this is just a part of the long term solution. 

[JohnNichols]

Having followed Jim's thoughts, it was reasonably easy to fix this integer issue, aside from a few format statements it had no impact, same answers.  

Here is the latest. 

The only answer issue is the stress due to external loads, there is a consistent difference , about 20, between the current answers and the book answers.  

FTI(I) = (FO/AREA - FO*E/ZTB)
        FBI(I) = (FO/AREA + FO*E/ZBB)

from the subroutine PSTRES.  The example is :

They are all off by about 20, and the only two variables in those equations are FO and E.   The error is in End Eccentricty, got to find the problem.  If I use the book E of 10.6 instead of the programs 10.7 I get the right answers. 

[JohnNichols]

  X = 0.0
    SUMD1 = 0.0
    SUMD2 = 0.0
    SUMDW1 = 0.0
    SUMDW2 = 0.0

    Do 2 I = 1, NROW

        X = X + SPACE
        SUMD1 = SUMD1 + SROW(I)
        SUMDW1 = SUMDW1 + SROW(I)*X
        SUMD2 = SUMD2 + DROW(I)
        SUMDW2 = SUMDW2 + DROW(I)* X
2   CONTINUE
    XBAR1 = SUMDW1/SUMD1
    XBAR2 = SUMDW2/SUMD2
    XBAR22 = XBAR2
3   CGT = (SUMDW1 + SUMD2*XBAR22)/STRNS
    CGTLMT = YB - ENDMAX

This code calculates the CGT - it is a simple moment calculation really.  The STRNS are 30.  

The bars are spaced at 2 inch centers and they slowly move 2 drapped bars up wards in 2 inch increments to determine the CG. 

If I plot the slow increase based on these rules I get the following graph,  teh CGT of 14.8 gives us 25.53 - 14.8 = 10.73, unless my math is wrong then the book answer is a strange.  The graph shows the change in CGT as you move up the bars looking for the solution.  

This is the brilliant bit of engineering and coding for the authors,  step through all the valid solutions till you find one that carries the load.  Saves a lot of hand work.  

So either their strns is not 30 or their sumdw1 + ... calculation is 447, which is not possible as the moment addition has to be even as everything is units of 2. 

[mecej4]

Given that a more recent version of the PSTRS14 software is available from TXDOT, I do not know why you are struggling with a bug-filled Fortran IV version of the source code. The attempts to add type declarations to the source code in the "149-1F" report, while well-intentioned, have introduced major errors into the program.

For instance, look at the console output of the program in your PrestressBridge(4).zip. The paragraph called "LANDLD Load Results for Bending Moment - termed BMLL" shows all the moments as zero! How did this come about? It is the result of splitting each of the COMMON block declarations in the original sources into two include files. Thus, your file JWM1.inc contains

    REAL VMA(20)
    REal VDL(20),XDIST(15),DEFK2,DEFL12,DEFK1,DEFL14,DNCDL2,DNCDL1

and JWM2.inc contains

    COMMON /JWM/ VMA,VDL,XDIST,DEFK2,DEFL12,DEFK1,DEFL14,DNCDL2,DNCDL1

However, in subroutine LANELD (file help.f90), you include JWM1.inc but not JWM2.inc. The unwanted effect of doing so is that inside subroutine LANELD  XDIST is a local array rather than the XDIST in /JWM/. The contents of the array are undefined, but with Intel Fortran (and other compilers, possibly) XDIST appears to be set to zero. This bug propagates into the output zero values for the BMLL moments.

There are also a few OCR errors, but they seem to have had no effect on the output results that are noticeable.  In subroutine RRLOAD, all instances of variable MU are there because of OCR errors; change all of them to WU. Similarly, there are instances of 'l','i' and '1' confusion; perhaps there should be a special place for people who publish program source code using fonts and semi-dry ink tape, causing these three letters to appear nearly identical in PDF or printed output.

[JohnNichols]

I am glad you are back.  

Thank you for the comments. 

The latest program is not available online.   The latest program if you do not have the code you cannot check it.  There are a few Fortran programmers I trust, they are almost all on this site.  

I want to use the code to do more advanced analysis on the bridge in real time, it is as good a starting point as any.  

Pulling in Leonhardt, 1960s standard manual on prestress, Concrete Structures - Warner - 1998 using the program is as quick away to relearn prestressed analysis and to look to do some extension stuff with reliability.  

We will fix the code, the TXDOT math is for Texas, I have bridges elsewhere and it is quicker than writing it from scratch.  

The special place is in Dante's inferno. 

I am glad you are still grumpy. 

[JohnNichols]

I fixed those things - thanks.  

I will change the inc files to halve the number, it was just easy in the beginning for the typing.  

[mecej4]

These discrepancies (3228 instead of 3210, etc.) are the result of yet another OCR error: in subroutine PSTRES, in the second of these two lines, the '*' should have been a '+':

304 Continue
    FTFDG = FTPR * FTBM(6)

The variable name got changed from FTFOG to FTFDG, but as long as such changes are propagated consistently, there is no harm caused.

Here is a scan of the pertinent lines of code in the PDF report that you used as the source of the program. In the good old days, of course, you would have pulled out the punched card for that line and "read" the holes in it. I used to be able to do that.

[JohnNichols]

@mecej4

Thanks for the note.  Jim, Steve and you are great.  

Reading the O and the D has been a hassle, I will correct the problem, I was trying to use Jim's idea of the single inc files to make sure the commons, were common.  

The issue, in the long run, is getting the equations into a form where :

f(x) = ax + by

where the equation form may come from several national standards and a and the b can be read from a file so they can be changed easily.  As well as making the program modern.  People on national standards tend to be idiosyncratic, which is ok until you develop international software.  A classic example is the different electric plugs around the world. 

The challenge is the development of programs that take real statistical data and make decisions about bridge safety.   The long-term 19th-century method is to develop safety factors, design for these factors and pray it is not overloaded.  We now have much more data and need to amend our method.  

This has been edited with grammerly, which is good. 

John

[cryptogram]

Thinking some more about integer and real variables.  Remember that the default type for variables starting with  I through N is integer, and everything else is real.

Programming style in the old days was a lot different than today.  Early Fortran had only a few variable types, a fairly short limit on variable names, and you had to deal with the logistics of getting your code onto punch cards, where the meaty bits of the code had to fit 

in columns 7-72.   Declaring variable names that would have defaulted to type you wanted would have required extra cards, and so you

usually didn't do it.  We were so used to the default types, that seeing a variable in code whose type had been changed from default with

a declaration kinda threw you off.   In fact, we usually did the opposite sort of thing.  If you had some formula in a book that used variables starting with I-N letters where the values of the variable were reals, we'd append an R to the front of the name when coding the formula.

[JohnNichols]

I have checked all of the default values and I hope made sure they are now correct.  

XBAR22 = XBAR22 + SPACE

This is the simple method they used to adjust the end eccentricity, just hid it at the bottom of the routine, I had to single step through to find it.  Very tricky little bit of coding in terms of brevity.  

I will have to add a drawing routine, unless you understand their strand location code, it is hard to follow.  The code is A-50, which means 50 inches from the bottom.  And then count backward for the layers in 2 inch increments. 

They add strands in blocks of 2,  so there are some interesting jumps when you are using a 11 block group and then a 3 block group in the web.  

[JohnNichols]

I added an old fashioned Fortran print out as a set of characters to get a look at the latest beam.  Here is the picture.