wrong file name in inquire.F error message

[jpm]

While attempting to start a 4DVAR data assimilation cycle I encountered the following error message:

Code: Select all

 INQUIRE     - unable to find requested variable: zeta
               in file: boundaryfile.nc

where boundaryfile.nc is the file containing the boundary conditions for the simulation.

The error message made me wonder why ROMS was looking for a non-boundary variable in the boundary file.

After some investigation it turned out that zeta was actually missing in the forward file but the error message would falsely show the boundary file name. (Some background information: I was using a new ocean.in file with "Hout(idFsur) == F", and changing the F to a T did eliminate the error).

This bug affects ROMS version 689 but should still be present in the current version since inquire.F has not changed significantly

How the bug occurs:

The wrong error message gets printed by the following lines (320-321) in inquire.F:

Code: Select all

          WRITE (stdout,50) TRIM(Vname(1,ifield)), 'file:'
          WRITE (stdout,'(15x,a)') TRIM(ncfile)

The problem is that ncfile has not been updated to the current file name and still contains the name of the previously inquired file. ncfile only gets updated in line 166 when a variable has been found:

Code: Select all

        IF (foundit) THEN
          got_var=.TRUE.
          ncfile=Fname
          ...

Since foundit is false in this case and zeta (the variable in question) is the first variable that is inquired in the current file, ncfile still contains the name of the previous file.
I should point out that "S(1)%name" does contain the correct file name but ncfile does not.

I realize this is a relatively obscure bug that only affects the text of an error message, yet it quite confusing and made me look for errors in all the wrong places.

[arango]

Yeah, inquire.F is a very tricky routine. It is very difficult to write this type of routine to check out for an application that is not set-up correctly. There are so many possibilities. In 4D-Var we need to save all the state variables. Otherwise, we will be in a lot of trouble. I will take a look to inquire.F to see how this can be fixed.