Initialisation of ANANAME

Bug reports, work arounds and fixes

Moderators: arango, robertson

Post Reply
Message
Author
User avatar
m.hadfield
Posts: 521
Joined: Tue Jul 01, 2003 4:12 am
Location: NIWA

Initialisation of ANANAME

#1 Unread post by m.hadfield »

In ROMS/Modules/mod_ncparam.F at line 487, ANANAME is declared with dimension 39

Code: Select all

        character (len=256), dimension(39) :: ANANAME
but at lines 715-719 only the first 38 elements are initialised:

Code: Select all

      DO i=1,38
        DO j=1,LEN(ANANAME(1))
          ANANAME(i)(j:j)=' '
        END DO
      END DO
This can lead to platform-dependent problems when ANANAME is written to stdout at the end of the run (in close_io.F).

The 39th element of ANANAME is used by ana_wtype, so I presume this bug was introduced with the recent revision to the water-type code.

Incidentally, the initialisation of ANANAME and BIONAME in lines 711-731 is unnecessarily complex:

Code: Select all

!
!  Analytical files switch and names.
!
      Lanafile=.TRUE.
      DO i=1,38
        DO j=1,LEN(ANANAME(1))
          ANANAME(i)(j:j)=' '
        END DO
      END DO

#ifdef BIOLOGY
!
!  Biology model header names.
!
      DO i=1,4
        Lbiofile(i)=.TRUE.
        DO j=1,LEN(BIONAME(1))
          BIONAME(i)(j:j)=' '
        END DO
      END DO
#endif
This can be replaced with the following:

Code: Select all

!
!  Analytical files switch and names.
!
      Lanafile=.TRUE.
      DO i=1,39
        ANANAME(i)=''
      END DO

#ifdef BIOLOGY
!
!  Biology model header names.
!
      DO i=1,4
        Lbiofile(i)=.TRUE.
        BIONAME(i)=''
      END DO
#endif
The reason is that when a character assignment involves an expression or constant (on the RHS) that is shorter in length than the variable (on the LHS) then the RHS value is padded with blanks.

User avatar
arango
Site Admin
Posts: 1361
Joined: Wed Feb 26, 2003 4:41 pm
Location: DMCS, Rutgers University
Contact:

Re: Initialisation of ANANAME

#2 Unread post by arango »

Yes, thank you.
m.hadfield wrote: The reason is that when a character assignment involves an expression or constant (on the RHS) that is shorter in length than the variable (on the LHS) then the RHS value is padded with blanks.
Indeed but various compilers behave not the same in different computers. Therefore, I initialize it like this because debuggers will add junk characters if it is not initialized. This is primarily done as a safeguard to insure that file names are not padded with non blank characters. I have very bad experiences with this in my debugging sessions. There is a lot of string manipulations with file names in ROMS.

User avatar
m.hadfield
Posts: 521
Joined: Tue Jul 01, 2003 4:12 am
Location: NIWA

Re: Initialisation of ANANAME

#3 Unread post by m.hadfield »

arango wrote:Indeed but various compilers behave not the same in different computers. Therefore, I initialize it like this because debuggers will add junk characters if it is not initialized. This is primarily done as a safeguard to insure that file names are not padded with non blank characters. I have very bad experiences with this in my debugging sessions. There is a lot of string manipulations with file names in ROMS.
It's my understanding that the behaviour I described is mandated by the Fortran standard. Not that I can cite any authoritative document to support that, but in the Digital Fortran manual it's written in black (standard) rather than red (language extension). Still, maybe you can't rely on the standard being followed by all compilers in all cases.

User avatar
arango
Site Admin
Posts: 1361
Joined: Wed Feb 26, 2003 4:41 pm
Location: DMCS, Rutgers University
Contact:

Re: Initialisation of ANANAME

#4 Unread post by arango »

I updated the svn repository. See following :arrow: ticket for more information.

Post Reply