netcdf_close with BIOLOGY and multi-file BRY files

[stlaur]

I'm running ROMS with the trunk version, BIOLOGY activated, and I have "multi-file" BRY files (one BRY file per calendar year).
The code is compiled in serial mode with ifort, USE_DEBUG and USE_NETCDF4.
At the end of the year, when ROMS is ready to switch to the next BRY file, it enters this block of inquiry.F:

Code: Select all

!
!  If multi-files, increase (decrease if backward logic) file counter
!  and set new file names.
!
      IF (Lmulti) THEN
        DO ifile=1,nfiles
          IF (TRIM(Cinfo(ifield,ng)).eq.TRIM(S(ifile)%name)) THEN
            IF (job.gt.0) THEN
              Fcount=S(ifile)%Fcount+1
            ELSE
              Fcount=S(ifile)%Fcount-1
            END IF
            IF ((1.gt.Fcount).and.(Fcount.gt.S(ifile)%Nfiles)) THEN
              IF (Master) THEN
                WRITE (stdout,10) TRIM(Vname(1,ifield)),                &
     &                            Fcount, S(ifile)%Nfiles
              END IF
              exit_flag=4
              IF (FoundError(exit_flag, NoError,                        &
     &                       __LINE__, MyFile)) RETURN
            END IF
            S(ifile)%Fcount=Fcount
            S(ifile)%name=TRIM(S(ifile)%files(Fcount))
            CALL netcdf_close (ng, model, ncid)

In the last line, we see that netcdf_close is called with 3 arguments (the 4th and 5th are optional).
The 5th argument (not present here) is a logical variable called "Lupdate".
The call to netcdf_close leads to the following block of mod_netcdf.F:

Code: Select all

#ifdef BIOLOGY
!
!  Determine updating value of biology header files global attribute.
!  This is only possible in output files. An error occurs in input
!  files open for reading only. This allows to use ROMS input files
!  with the "bio_file" attribute.
!
        IF (.not.PRESENT(Lupdate)) THEN
          my_Lupdate=.TRUE.
        ELSE
          my_Lupdate=Lupdate
        END IF
!
!  Update global attribute with the biology header files used.
!
        IF (my_Lupdate) THEN
          is=1
          DO i=1,512
            bio_file(i:i)=' '
          END DO
          DO i=1,4
            lstr=LEN_TRIM(BIONAME(i))
            IF (lstr.gt.0) THEN
              ie=is+lstr-1
              bio_file(is:ie)=TRIM(BIONAME(i))
              is=ie+1
              bio_file(is:is)=','
              is=is+2
            END IF
          END DO
          lstr=LEN_TRIM(bio_file)-1
          IF (lstr.gt.0) THEN
            status=nf90_put_att(ncid, nf90_global, 'bio_file',          &
     &                          bio_file(1:lstr))

Because Lupdate (i.e. the 5th argument of netcdf_close) was not PRESENT in the call to netcdf_close, my_Lupdate will be set to .TRUE., and ROMS will attempt to "put" (write) the name of the user's biological module inside the BRY file. ROMS then stops itself with:

Code: Select all

 NETCDF_CLOSE - error while writing global attribute:  bio_file
                file:
                call from:  ROMS/Utility/inquiry.F, inquiry_nf90
                NetCDF: Write to read only

Maybe I'm misinterpreting the code. But if I'm not, would it make sense to include:
Lupdate=.FALSE.
in the call to netcdf_close? It would prevent ROMS from trying to modify the BRY file when BIOLOGY is activated.

[gen3]

I am also facing identical issue... but my case is for multiple FRC files. I am using latest version of trunk (subversion 1112). It seems like that identical error is appeared when ROMS switch to next FRC file.

I did not experience this issue when I used past version (subversion 1053), but the latest version feels like something wrong.

[arango]

Hi Pierre, great catch! Thank you for reporting this problem. I updated the repositories.

[gen3]

Thank you for quick update. But, these is even worse issue for me... When I run compiled romsM (either romsS too) using the latest trunk, it shows error below;

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

This error is appeared even when I run upwelling test case... Am I only one suffering this issue?