SBC fldread additions

[ed.blockley]

I have some additions to the SBC/fldread module designed for daily operational usage as follows:

1. Addition of the 'Daily' class of input file:

All these changes can be found in the file fldread.F90 attached.

2. The ability to check the number of input fields as well as the time axis attributes by way of an extra logical in the FLD_N input structure:

The checking is done in the fld_clopn() routine (in fldread.F90 attached). Although as the FLD_N has changed the hard-wired default values in the files sbcblk_core.F90, sbcice_if.F90, sbcssr.F90,
sbcblk_clio.F90, sbcflx.F90 and sbcrnf.F90 have been updated (see attached).

As this checking uses the same process as we adopted for the BDY routine bdydta (lines 733-748), I have removed the time offset calculation from bdydta.F90 and placed it into the iom_gettime routine. (see iom.F90 and bdydta.F90 attached)

This makes sense as the medium-term plan for BDY is to be updated to use fldread in the same was as the SBC also with 'daily' files. We also have other updates (due to come back to the central Trac soon) that require this functionality.

Finally I have generalised the time checking so that the format used to extract the date/time can be specified in the namelist where previously it was hard-wired in (see in_out_manager.F90, domain.F90 attached).

We are currently running using these changes with NEMO vn3.0 and have tested them fairly well. Subsequently I have merged these changes in with the vn3.1 changes locally to run through the NVTK.
I ran the NVTK for the GYRE and ORCA2-LIM configurations and all proved fine with the solver.stat and ocean.output files being identical svae for write-outs in the latter relating to the time checking.

[ed.blockley]

'daily' and time checking changes in fldread.F90

[ed.blockley]

time offset calculation added to iom_gettime

[ed.blockley]

time offset calculation removed from bdydta.F90

[ed.blockley]

modifications to FLD_N default values

[ed.blockley]

modifications to FLD_N default values

[ed.blockley]

modifications to FLD_N default values

[ed.blockley]

modifications to FLD_N default values

[ed.blockley]

modifications to FLD_N default values

[ed.blockley]

modifications to FLD_N default values

[ed.blockley]

addition of time:units format to namrun namelist

[ed.blockley]

addition of time:units format to namrun namelist

[smasson]

could we also have the namalist modifications you done?

[smasson]

There is several additional points I would like to clarify:

• Could you also send us the namelist modifications you done?
  
• in iom.F90, I don't really see the interest to specify the format of the units through the variable tunitfmt. You assume in the code that units are seconds that can be read lke this
  

  READ(zunits,tunitfmt) year0, month0, day0, hours0, minutes0, sec0
  

so is it almost necessary that units format is

FORMAT('seconds since ', I4.4,'-',I2.2,'-',I2.2,' ',I2.2,':',I2.2,':',I2.2)

• in fldread, I think
  

           IF( .NOT. PRESENT(ldstop) .OR. .NOT. ldstop ) THEN
  

is not working if ldstop is not present

• in fldread, the test
  

              IF( zoffset /= 0 )  CALL ctl_stop( 'The flux input file '//TRIM(sdjf%clname)//                           &
  

doesn't take into account the values included in the time variable. It is only testing the date given in the units as a reference date for the relative calendar.

[ed.blockley]

Sorry for the delay but I have not been able to login to the trac only the website for some months. I'll address your points one at a time.

Point 1 see attached our orca025 namelist.

Point 2 (READ time units):
This is originally what I had done but made this change later to make it more portable. If you are happy to have this hard-coded then I'm fine with that.

Point 3 (IF...THEN):
I had actually found this bug a while ago but have been unable to access the trac to make the change. The problem is that the NEMO vn3.0 base code uses ldstop inconsistently when searching for fields before the start of the run and after the end of the run.
Please see the attached fldread.F90 file for the modifications.

Point 4 (zoffset test):
You are correct that I haven't tested the time variable. This was because I didn't see any need to do so. There are enough tests without this I think because if it is a daily file we check that the correct number of fields exist (for the given frequency) and check the day is correct.
I think it would actually cause us problems to explicitly check the time too because the file time wouldn't match the model time.

Ed

[ed.blockley]

NEMO ORCA025 namelist

[ed.blockley]

New updated fldread.F90 file accounting for a bug fix in the ldstop usage

[smasson]

1) ok

2) yes I prefer to have a solution fully hard coded than something half hard-coded. We will improve this part someday if somebody needs something better.

3) you are right, there is a bug in the use of ldstop. I corrected it. see ticket:472
However, I am still thinking that you cannot use

      IF( .NOT. PRESENT(ldstop) .OR. ldstop ) THEN

if ldstop is not present and therefore not defined (but this is a small detail).

By the way, thank you for all the corrections you done in the comments.

4) I don't understand. you are testing the date contained in the attribute units. However this attribute contains a reference date used to get back a real calendar from a number of seconds since the reference date. The value of this reference date is defined arbitrary and can be any date. Therefore I don't understand how you can use this information by itself. It has to be combined with the time variable to refer to some useful date.

[ed.blockley]

3) I think .NOT. PRESENT(ldstop) is allowable and will be .true. if ldstop is not present/defined (but as you say this is a minor point).

4) I see what you mean now. The check doesn't take into account that you might want all your flux files referenced to some arbitrary date not necessarily the validity date (ie. 1/1/1981).
I have therefore changed the necessary line (453/4/5) in the fldread.F90 module and attach the new file as fldread_3.F90.
Additionally I have changed the time/date axis testing conditional so that this is skipped if sdjf%freqh < 0 (as it's not really relevant there) and changed one of the comments in iom.F90 (also attached as iom_3.F90).

[ed.blockley]

updated iom.F90 module (only comment changed)

[ed.blockley]

updated fldread.F90 module (including changes to date/time checking)

[smasson]

introduce daily type of forcing file (based on fldread_3.F90), see changeset:1628

[smasson]

Hello,

I am sorry but I still have problems with your ln_check functionality. In fld_clopn of fldread_3.F90, you introduced the following test:
IF( zoffset + ztime(1) /= rday * sdjf%freqh / 24. / 2. ) THEN
but:

• zoffset + ztime(1): but when you open the file, you are not necessary looking for the first record of the file (for example if you start your run in June with a yearly file). => you cannot arbitrary pick-up the first element of ztime.
  
• rday * sdjf%freqh / 24. / 2.: here, you are supposing that your try to read data that is located in the middle of the forcing period but this is not always the case. For example, if you sdjf%ln_tint = .false., you read the data at the beginning of the forcing period. If you have monthly forcing (sdjf%freqh = -1) your test is not good.
  

To me, if we decide to introduce a check of the calendar, we have to do a simple and real check: every time you read a record you check its date. In fact it is not so difficult to do as in sd(jf)%rec_a/b we have the record number (first element) and its date value (second element) according to all options and forcing frequency cases (see fld_rec).
If we add in iom something like iom_getcal that gives you back the calendar value (for example in second since Jan. 1st 00h of nit000 year) for a given record, you compare this value with sd(jf)%rec_a(2) and your check is done. It is clean and is easier to understand (I dislike variable offset computed in iom.F90 that is not very easy to understand and manipulate).

A small last point: in iom, you are supposing that the variable that contains the time axis has the same name as the unlimited dimension...

Tell me what you think about this...

Sebastien

-

[ed.blockley]

To answer the comments about
IF( zoffset + ztime(1) /= rday * sdjf%freqh / 24. / 2. ) THEN
not being valid for 'yearly' files with monthly fields:

You will notice that I have a condition on the time checking (sdjf%freqh > 0.0) so that this operation is only valid for 'daily' or 'month;y' files.

The whole point of this checking is so that people like us who run operational models and generate a new flux forcing file for each day have a check in place to make sure that the file is being updated. I really don't think it's needed for 'yearly' or climatological files.

[ed.blockley]

Of course we could change this functionality to use rec_a/b and effectively check each field when it gets read in (although we would have to add the functionality to read the date in).

In many ways this would be more sensible. The reason I did it with time offsets was to re-use/combine with another existing piece of code (the BDY time offset calculations) and because all we required here was a quick check that the date in the file was what we expected.

[smasson]

to sum up:

• daily files have been integrated
• additional checks on the number of input fields as well as the time axis attributes are not really fitting with general philosophy of the rest of the code related to inputs. this should be reviewed in the frame of the merge of OBC/BDY in 2011.