topic I just ran the program with a in Intel® Fortran Compiler

Unrecognized tokens

JohnNichols — Thu, 23 Jun 2016 17:48:52 GMT

MODULE ROT
    

!-----------------------------------------------------------------------
! euler rotation of model geometry
!-----------------------------------------------------------------------
!
! C_ALPHA : rotation about z-axis
! C_BETA  : rotation about new y-axis 
! C_GAMMA : rotation about new z-axis 
!
! C_FORWARD : rotation matricies to geographic coordinates
! C_REVERSE : rotation matricies to model coordinates
!
!-----------------------------------------------------------------------
    INTEGER, PARAMETER :: dp = selected_real_kind(15, 307)
    INTEGER, PARAMETER :: sw = 2                    !   Output file
    REAL (KIND=dp), PARAMETER :: gr = 9.806, pi = 3.14159265D0  !   Standard parameters
    REAL(KIND=dp) CALPHA
    REAL(KIND=dp) CBETA
    REAL(KIND=dp) CGAMMA

      REAL (KIND=dp)  FORWARD(3,3)

      REAL (KIND=dp) REVERSE(3,3)

     CALPHA = 0.0D0
     CBETA = 0.0D0  
     CGAMMA = 0.0D0
     FORWARD = 0.0D0
     REVERSE = 0.0D0
!-----------------------------------------------------------------------
contains
!Euler Matrix

SUBROUTINE Rotate()

!-----------------------------------------------------------------------
! purpose: compute euler rotation matrix 
!-----------------------------------------------------------------------
!
! C_ALPHA   : rotation about z-axis  
! C_BETA    : rotation about new y-axis  
! C_GAMMA   : rotation about new z-axis      
! C_REVERSE : rotation to model coordinates 
! C_FORWARD : rotation to geographic coordinates
!
!-----------------------------------------------------------------------

      !local vars
      REAL (KIND=dp) COSA
      REAL (KIND=dp) SINA
      REAL (KIND=dp) COSB
      REAL (KIND=dp) SINB
      REAL (KIND=dp) COSG
      REAL (KIND=dp) SING

!-----------------------------------------------------------------------

      !compute sin and cos of all angles in degrees
      COSA  = C_COSD (CALPHA )
      SINA  = C_SIND (CALPHA )
      COSB  = C_COSD (CBETA  )
      SINB  = C_SIND (CBETA  )
      COSG  = C_COSD (CGAMMA )
      SING  = C_SIND (CGAMMA )
 
      !compute rotation matrix into model coordinates
      REVERSE (1,1) =   COSA * COSB * COSG  -  SINA * SING
      REVERSE (1,2) =   SINA * COSB * COSG  +  COSA * SING
      REVERSE (1,3) =        - SINB * COSG
      REVERSE (2,1) = - COSA * COSB * SING  -  SINA * COSG
      REVERSE (2,2) = - SINA * COSB * SING  +  COSA * COSG
      REVERSE (2,3) =          SINB * SING
      REVERSE (3,1) =   COSA * SINB
      REVERSE (3,2) =   SINA * SINB
      REVERSE (3,3) =          COSB
    
      !compute rotation matrix into geographical coordinates
      FORWARD (1,1) =   COSG * COSB * COSA  -  SING * SINA
      FORWARD (1,2) = - SING * COSB * COSA  -  COSG * SINA
      FORWARD (1,3) =          SINB * COSA
      FORWARD (2,1) =   COSG * COSB * SINA  +  SING * COSA
      FORWARD (2,2) = - SING * COSB * SINA  +  COSG * COSA
      FORWARD (2,3) =          SINB * SINA
      FORWARD (3,1) = - COSG * SINB
      FORWARD (3,2) =   SING * SINB
      FORWARD (3,3) =          COSB
   
!-----------------------------------------------------------------------

      END SUBROUTINE ROTATE

END MODULE ROT

I get unrecognized tokens with this code -- I have played with it and cannot seem to understand how to fix it

There are nonprinting

Steven_L_Intel1 — Thu, 23 Jun 2016 19:07:00 GMT

There are nonprinting characters on some of these lines. For example, in line 19 of rotate.f90 (not the excerpt you posted) what should be five blanks at the beginning of the line are in fact hex A0 characters. You'll have to go through and fix these up.

Steve:

JohnNichols — Fri, 24 Jun 2016 00:43:55 GMT

Steve:

Thanks

I thought I would have to use a new routine for the transformations, but luckily a long day provided the solution to the Harrison code.

I now have the Harrison program (heavily modified) running alongside the Felippa Shell program - so hopefully I will be able to add beams to the shells and study some old bridges. Bridge construction methods are interesting, but weird to model in a strict topological sense.

I spent a lot of time comparing all the published results with the output from the modified program. I have identical numbers in everything down to about 0.1% until it passes into the PARDISO solver and then the

 INTEGER, PARAMETER :: dp = selected_real_kind(15, 307)

    INTEGER, PARAMETER :: sw = 2                    !   Output file
    INTEGER, PARAMETER :: srA = 15                  !   output.txt file
    INTEGER, PARAMETER :: st = 14
    INTEGER, PARAMETER :: sa = 3                    !   Output file
    INTEGER, PARAMETER :: smWrite = 4
    INTEGER, PARAMETER :: si = 1
    Integer, parameter :: slog = 9                  !   Log file
    Integer, parameter :: nta = 100                  !   Log file
    Integer, parameter :: outNode = 63                  !   Log file
    Integer, parameter :: inNode = 0                  !   Log file

    REAL (KIND=dp), PARAMETER :: gr = 9.806, pi = 3.14159265D0  !   Standard parameters

and numbers come out about 1% different. I have compared every single input element and they are the same -- took a while to work out the gamma error between the writing in the book and the example data files. Gamma is the z angle in a Cartesian coordinate transformation, in the book as shown in the figure the gamma is 90 , but the beam is parallel to the -z axis so gamma should be -90. Changes the transformation matrix - took a while to work out.

So do you think an old computer running Fortran 66 will likely invert slightly differently to the modern pardiso using double precision.

John

There are uncountable reasons

Steven_L_Intel1 — Fri, 24 Jun 2016 01:09:56 GMT

There are uncountable reasons why numeric results might differ from something run on an unspecified computer decades ago. FP format differences, rounding techniques, vectorization, accuracy of math library, use of extended precision for intermediate results, order of operations, ... - the list is endless.

Why is your double precision value of pi specified only to 11 digits?

I just ran the program with a

JohnNichols — Fri, 24 Jun 2016 01:20:26 GMT

I just ran the program with a shell and beam sample and it worked all the way through the eignevectors first time - darn this great - got to check the answers - but it is good.

Thanks for all the help - I really appreciate the assistance.

The challenge is the bridge with standard beams that are then concreted together - makes the analysis a conceptual challenge - we know they work, but a bit like we know a Roman legion is going to wipe out a small group of Celts in a frontal assault. Still wondering about the 9th.

3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679  
  8214808651328230664709384460955058223172535940812848111745028410270193852110555964462294895493038196  
  4428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273  
  724587006606315588174881520920962829254091715364367892590360011330530548820466521384146951941511609

Steve:

How many places can I make pi

John

JohnNichols — Fri, 24 Jun 2016 01:27:43 GMT

Steve:

Can I read in a single character at a time from a file of endless data? Like this

PROGRAM test_fgetc
            INTEGER :: fd = 42, status
            CHARACTER :: c
          
            OPEN(UNIT=fd, FILE="/etc/passwd", ACTION="READ", STATUS = "OLD")
            DO
              CALL fgetc(fd, c, status)
              IF (status /= 0) EXIT
              call fput(c)
            END DO
            CLOSE(UNIT=fd)
          END PROGRAM

John

To read a stream of data from

IanH — Fri, 24 Jun 2016 02:52:40 GMT

To read a stream of data from a file, use stream access.

Quote:John Nichols wrote:

jimdempseyatthecove — Fri, 24 Jun 2016 12:09:29 GMT

John Nichols wrote:

3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679  
  8214808651328230664709384460955058223172535940812848111745028410270193852110555964462294895493038196  
  4428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273  
  724587006606315588174881520920962829254091715364367892590360011330530548820466521384146951941511609

Steve:

How many places can I make pi

As written above, you have a single precision literal. Fortran does not auto-promote literals to left hand side variable precision. IOW you must append "_8", or in your case alternately "_dp" because you had defined dp.

Do I need to suggest that you

jimdempseyatthecove — Fri, 24 Jun 2016 12:12:27 GMT

Do I need to suggest that you check for other instances where a literal needs to be tagged as _8/_dp?

Jim Dempsey

1. Does not D0 make the

JohnNichols — Fri, 24 Jun 2016 13:52:18 GMT

1. Does not D0 make the number a real 8? (Post 3)

2. The post 8 number was stolen from a lady at google who had it on her website. ANy engineer in one of my classes who used pi to that level of accuracy would fail for lacking the intelligence to consider context and accuracy of the results.

A bit like the surgeon who says - we saved your finger sorry about the fatal heart attack we missed during the surgery you did not say you were having chest pain

The D0 is fine but you didn't

Steven_L_Intel1 — Fri, 24 Jun 2016 13:59:27 GMT

The D0 is fine but you didn't include it in post 8. The _dp form would be my preference, though.

Sorry that was a joke, I took

JohnNichols — Fri, 24 Jun 2016 14:44:16 GMT

Sorry that was a joke, I took that number from a Google executive's web site -- it was in response to your comment - although I have given some definite thought to a FFT for the pi digits, one could take the mean about 4.5 so the zero frequency goes to zero, I need 880,000 digits to get a nice picture, which was the reason for the question about reading individual numbers.

I will sue _dp from now on.

Is there any point even with dp of having more than 15 digits?

John

use _dp not sue

JohnNichols — Fri, 24 Jun 2016 14:45:06 GMT

use _dp not sue

The general rule is to use

Steven_L_Intel1 — Fri, 24 Jun 2016 16:15:18 GMT

The general rule is to use three more digits than the precision of the data type, so 18 digits should do it here. This ensures that you will have the correctly rounded value.