writing to nonexisting history files

[jpm]

This concerns a fairly technical bug that only few ROMS users might encounter, it affects the current version (Version 403 2009-10-01 21:17:45Z) and maybe older versions. To reproduce this error a restart from a previous file is required. Then, for example, a change in the variable ndefHIS (in between the previous run and the current) may cause it. In summary what happens is that ROMS tries to write to a nonexisting history file, right after a restart from an initial file.

The error message I get is

Code: Select all

      DEF_HIS   - inquiring history file: mypath/his_esp_srespresso_0010.nc

 NETCDF_OPEN - unable to open existing NetCDF file:
               mypath/his_esp_srespresso_0010.nc
               call from:  def_his.F

The cause of the error is in the file ROMS/Nonlinear/output.F line 69 ff:

Code: Select all

...
69!
70!  Create output history NetCDF file or prepare existing file to
71!  append new data to it.  Also,  notice that it is possible to
72!  create several files during a single model run.
73!
74      IF (LdefHIS(ng)) THEN
75        IF (ndefHIS(ng).gt.0) THEN
76          IF (idefHIS(ng).lt.0) THEN
77            idefHIS(ng)=((ntstart(ng)-1)/ndefHIS(ng))*ndefHIS(ng)
78            IF (idefHIS(ng).lt.iic(ng)-1) THEN
79              idefHIS(ng)=idefHIS(ng)+ndefHIS(ng)
80            END IF
81          END IF
82          IF ((nrrec(ng).ne.0).and.(iic(ng).eq.ntstart(ng))) THEN
83            IF ((iic(ng)-1).eq.idefHIS(ng)) THEN
84              Ldefine=.FALSE.                 ! finished file, delay
85            ELSE                              ! creation of next file
86              Ldefine=.TRUE.
87              NewFile=.FALSE.                 ! unfinished file, inquire
88            END IF                            ! content for appending
89            idefHIS(ng)=idefHIS(ng)+nHIS(ng)  ! restart offset
90          ELSE IF ((iic(ng)-1).eq.idefHIS(ng)) THEN
...

In my scenario (right after a restart from an initial file) the relevant variables are initially set to these values:

Code: Select all

idefHIS = -1
iic =     11041
LdefHIS = .true.
ndefHIS = 1200
NrecHIS = 1
nrrec =   1
ntstart = 11041

In this scenario ROMS passes through all if clauses in line 74 to 76 and initializes idefHIS in line 77. The exact result of (ntstart(ng)-1)/ndefHIS(ng) is 9.2, due to integer division it is rounded down to 9 and idefHIS is set to 10800. 10800 < iic-1 = 11040 and thus ndefHIS is added to idefHIS in line 79, now idefHIS = 12000 (> iic). The condition in line 82 is true but not the one in line 83 which causes the NewFile=.FALSE. assignment in line 87.
Because the simulation just started, there are no files present in the output folder and a new file is required.

Very likely, this bug not only affects history but also average, etc files but I did not investigate any further in that direction.

[arango]

No, ROMS is not designed to do this. It will break all logic. You cannot change any of the I/O parameters. These operations are exact! You may use the restart as initial file using nrrec=0 and no appending to previous NetCDF files. That is, a new run. You optionally may create a single file per output record ndefHIS=nHIS.

The I/O in ROMS is not designed to do what you want. In addition, when restarting you should not change running parameters neither C-preprocessing options. If you do so, it is not a restart. It is a new run.

[jpm]

It seems to me that the error occurs whenever multiple snapshots are being written into one file and the starting time of the model is not a multiple of ndefhis. This was not a problem in older versions (e.g. Version 126 2007-11-08 01:44:08Z).

Setting nrrec=0 results in a similar, seemingly related error:

Code: Select all

     NETCDF_PUT_FVAR_1D - error while inquiring ID for variable:  ocean_time
                          in input file:  mypath/his_esp_srespresso.nc
                          call from:  wrt_his.F

Setting ndefHIS=nHIS, as you suggested, produces the same error as in my first post. By setting ndefHIS=0 I can avoid the problem but everything gets written into the same file.

I see your point that it is not a good idea to constantly change ndefHIS in between two runs and in I don't really want to do that, it was just meant to be an example of how this error may occur. All I am trying to do is to start ROMS from an initial file using the settings (in the ocean.in file).

Code: Select all

         LDEFOUT == T
           NRREC == 1
            NHIS == 240
         NDEFHIS == 1200

The initial file I am using happens to be a history file. It could also be a restart file. In that case it has to to with my current ndefHIS not "lining up" with the nRST of the run that produced the restart file.

[m.hadfield]

Well, jpm, if you can propose a patch that would make it do what you want without breaking any other functionality , then it might be accepted. The output file logic is pretty gnarly and it has changed a few times in the past to cope with new requirements, becoming less robust for simple forward runs in the process. In the past I successfully proposed a few changes, but these days I live with it.

[kate]

I too have proposed changes to that mess, most recently forcing Hernan to put in some hybrid of my changes and his changes. I've still got how I thought it should be.

[jpm]

If I am not mistaken, it seems like the code needs to check if the file it is supposed to write to exists to distinguish between the case where one simply wants to continue a run and has already got some (potentially unfinished) output files present in the output directory and the case where one wants to use a netcdf file from some other directory as initial conditions for a new run.

Kate, would you mind showing us how your updated code looks like?

Thanks,
Paul

[arango]

Well, you guys cannot image how much time I have spent in the debugger to make this logic robust. It is very difficult to satisfy everybody. I think that the current logic is flexible enough to allow you to manipulate the I/O in a satisfactory way.

The issue about this logic is delicate because you need to have a full knowledge of ROMS I/O, including adjoint-based algorithms. You may want to code a logic that work for your particular application at the expense of breaking the logic for other applications. You can do this on your own private copy of the code. On the other hand, I need to have a logic that works for the totality of the code.

As I mentioned earlier, changing the input parameters or C-preprocessing options it is not recommended if you want to restart and manipulate multiple output NetCDF files. I can revise this logic again if this is actually a bug. I think that the problem here is usage. As far as I know, this logic works very well if you do not change the input parameters.

[hetland]

I think that the current logic is flexible enough to allow you to manipulate the I/O in a satisfactory way.

The code is not flexible, it is broken. It does not do what is expected for the obvious cases. There is absolutely no reason that this simple subroutine should be so complicated that it depends on "a full knowledge of ROMS I/O, including adjoint-based algorithms". In fact, it seems many other people who have a pretty good understanding of ROMS I/O also think this is broken.

Perhaps Kate can post what she had written, and we can test that out.