blow up when nudging SST and SSS

[goodboy]

Hello,
In my application, I can run it successfully without nudging anything just like this:

Code: Select all

LsshCLM == F                          ! sea-surface height
Lm2CLM == F                          ! 2D momentum
Lm3CLM == F                          ! 3D momentum
LtracerCLM == F F                   ! temperature, salinity, inert
LnudgeM2CLM == F                ! 2D momentum
LnudgeM3CLM == F                ! 3D momentum
LnudgeTCLM == F F                 ! temperature, salinity, inert

Now I open the nudging about the variable temperature and salinity, and I also give it the monthly SST and SSS from ERSST and SMAP_SSS in the forcing input filename,

Code: Select all

LsshCLM == F                          ! sea-surface height
Lm2CLM == F                          ! 2D momentum
Lm3CLM == F                          ! 3D momentum
LtracerCLM == T T                   ! temperature, salinity, inert
LnudgeM2CLM == F                ! 2D momentum
LnudgeM3CLM == F                ! 3D momentum
LnudgeTCLM == T T                 ! temperature, salinity, inert

while there is errors information just like following.

Code: Select all

 SET_3DFLD  - current model time exceeds ending value for variable: temp
              TDAYS     =      16801.0000
              Data Tmin =      16801.0000  Data Tmax =      17166.0000
              Data Tstr =      17166.0000  Data Tend =      16801.0000
              TINTRP1   =      16801.0000  TINTRP2   =      16801.0000
              FAC1      =          0.0000  FAC2      =          0.0000
 Found Error: 02   Line: 2149     Source: ROMS/Nonlinear/set_data.F
 Found Error: 02   Line: 251      Source: ROMS/Nonlinear/main3d.F
 Found Error: 02   Line: 303      Source: ROMS/Drivers/nl_ocean.h

Besides, I attached my nudging netcdf file and input file in the end. Is there anything wrong with the nudging netcdf file?
Could anyone tell me how to do the variable nudging correctly?

[wilkin]

I suspect the problem is in your climatology file
CLMNAME == /public/home/rengz/roms/Apps/Lagrangian/input/ECS_clm_2016.nc

The error message ...

SET_3DFLD - current model time exceeds ending value for variable: temp
TDAYS = 16801.0000

is saying that on checking your inputs before the run starts the time coordinate variable associated with temp does not match up with the time period you are trying to simulate.

It flags line 2149 in set_data.F,

Found Error: 02 Line: 2149 Source: ROMS/Nonlinear/set_data.F

so look to see what it was reading there so you know what to fix. An easy mistake would be to have written the time in days but the units attribute says seconds.

My set_data.F doesn't have 2149 lines so you are using some code other than myroms.org so I can't be any more help. In your next post declare whose code you are using and you might get a knowledgeable user to respond.

[goodboy]

CLMNAME == /public/home/rengz/roms/Apps/Lagrangian/input/ECS_clm_2016.nc

In my climatology file, the time variable is as follows:

Code: Select all

        double ocean_time(ocean_time) ;
                ocean_time:long_name = "time since intialization" ;
                ocean_time:units = "days since 1970-01-01 00:00:00" ;
                ocean_time:calendar = "365_day" ;
                ocean_time:cycle_length = 365. ;

And after

Code: Select all

ncdump -v ocean_time ECS_clm_2016.nc

, the ocean_time data is as follows:

Code: Select all

 ocean_time = 16801, 16802, 16803, 16804, 16805, 16806, 16807, 16808, 16809,
    16810, 16811, 16812, 16813, 16814, 16815, 16816, 16817, 16818, 16819,
    16820, 16821, 16822, 16823, 16824, 16825, 16826, 16827, 16828, 16829,
    16830, 16831, 16832, 16833, 16834, 16835, 16836, 16837, 16838, 16839,
    16840, 16841, 16842, 16843, 16844, 16845, 16846, 16847, 16848, 16849,
    16850, 16851, 16852, 16853, 16854, 16855, 16856, 16857, 16858, 16859,
    16860, 16861, 16862, 16863, 16864, 16865, 16866, 16866.875, 16868, 16869,
    16870, 16871, 16872, 16873, 16874, 16875, 16876, 16877, 16878, 16879,
    16880, 16881, 16882, 16883, 16884, 16885, 16886, 16887, 16888, 16889,
    16890, 16891, 16892, 16893, 16894, 16895, 16896, 16897, 16898, 16899,
    16900, 16901, 16902, 16903, 16904, 16905, 16906, 16907, 16908, 16909,
    16910, 16911, 16912, 16913, 16914, 16915, 16916, 16917, 16918, 16919,
    16920, 16921, 16922, 16923, 16924, 16925, 16926, 16927, 16928, 16929,
    16930, 16931, 16932, 16933, 16934, 16935, 16936, 16937, 16938, 16939,
    16940, 16941, 16942, 16943, 16944, 16945, 16946, 16947, 16948, 16949,
    16950, 16951, 16952, 16953, 16954, 16955, 16956, 16957, 16958, 16959,
    16960, 16961, 16962, 16963, 16964, 16965, 16966, 16967, 16968, 16969,
    16970, 16971, 16972, 16973, 16974, 16975, 16976, 16977, 16978, 16979,
    16980, 16981, 16982, 16983, 16984, 16985, 16986, 16987, 16988, 16989,
    16990, 16991, 16992, 16993, 16994, 16995, 16996, 16997, 16998, 16999,
    17000, 17001, 17002, 17003, 17004, 17005, 17006, 17007, 17008, 17009,
    17010, 17011, 17012, 17013, 17014, 17015, 17016, 17017, 17018, 17019,
    17020, 17021, 17022, 17023, 17024, 17025, 17026, 17027, 17028, 17029,
    17030, 17031, 17032, 17033, 17034, 17035, 17036, 17037, 17038, 17039,
    17040, 17041, 17042, 17043, 17044, 17045, 17046, 17047, 17048, 17049,
    17050, 17051, 17052, 17053, 17054, 17055, 17056, 17057, 17058, 17059,
    17060, 17061, 17062, 17063, 17064, 17065, 17066, 17067, 17068, 17069,
    17070, 17071, 17072, 17073, 17074, 17075, 17076, 17077, 17078, 17079,
    17080, 17081, 17082, 17083, 17084, 17085, 17086, 17087, 17088, 17089,
    17090, 17091, 17092, 17093, 17094, 17095, 17096, 17097, 17098, 17099,
    17100, 17101, 17102, 17103, 17104, 17105, 17106, 17107, 17108, 17109,
    17110, 17111, 17112, 17113, 17114, 17115, 17116, 17117, 17118, 17119,
    17120, 17121, 17122, 17123, 17124, 17125, 17126, 17127, 17128, 17129,
    17130, 17131, 17132, 17133, 17134, 17135, 17136, 17137, 17138, 17139,
    17140, 17141, 17142, 17143, 17144, 17145, 17146, 17147, 17148, 17149,
    17150, 17151, 17152, 17153, 17154, 17155, 17156, 17157, 17158, 17159,
    17160, 17161, 17162, 17163, 17164, 17165, 17166 ;

Found Error: 02 Line: 2149 Source: ROMS/Nonlinear/set_data.F

In this set_data.F file, the associated codes maybe are something wrong in my netcdf file, is it right?

Code: Select all

2131 !-----------------------------------------------------------------------
2132 !  Set tracers climatology.
2133 !-----------------------------------------------------------------------
2134 !
2135 #  ifdef ANA_TCLIMA
2136       IF (ANY(LtracerCLM(:,ng))) THEN
2137         CALL ana_tclima (ng, tile, iNLM)
2138       END IF
2139 #  else
2140       ic=0
2141       DO itrc=1,NT(ng)
2142         IF (LtracerCLM(itrc,ng)) THEN
2143           ic=ic+1
2144           CALL set_3dfld_tile (ng, tile, iNLM, idTclm(itrc),            &
2145      &                         LBi, UBi, LBj, UBj, 1, N(ng),            &
2146      &                         CLIMA(ng)%tclmG(:,:,:,:,ic),             &
2147      &                         CLIMA(ng)%tclm (:,:,:,ic),               &
2148      &                         update)
2149           IF (FoundError(exit_flag, NoError, __LINE__,                  &
2150      &                   __FILE__)) RETURN
2151         END IF
2152       END DO

In my varinfo.dat, the units of ocean_time is actually second. Therefore shall I create a new time variable such as clm_time in my varinfo.dat and change the ocean_time to clm_time in my climatology netcdf file to make sure the nudging successfully?
However, the time unit in my all input netcdf file is day, Can I change the ocean_time unit from second to day in my varinfo.dat?

Code: Select all

'ocean_time'                                       ! Input/Output
  'time since initialization'
  'second'                                         ! [s]
  'time, scalar, series'
  'ocean_time'
  'idtime'
  'nulvar'
  1.0d0

The ROMS code what I used now is the version 3.9 from professor Kate Hedstrom https://github.com/kshedstrom/roms.
Other than the netcdf file problems, I want to know is there anything wrong in my input roms_LAGRANGIAN.in file? There are both nudging variable associated with boundary nudging? What's the difference between nudging netcdf file and TNUDG、ZNUDG、M2NUDG、M3NUDG ?

Code: Select all

       TNUDG == 1.0d0  1.0d0               ! days
       ZNUDG == 0.0d0                      ! days
      M2NUDG == 0.0d0                      ! days
      M3NUDG == 1.0d0                      ! days
      
      NUDNAME == /public/home/rengz/roms/Apps/Lagrangian/input/ECS_nud.nc

[wilkin]

The ocean_time in your climatology file ECS_clm_2016.nc is only relevant if the variables in the file (temp, salt etc.) are directed to ocean_time by their "time" attribute. This is not ocean_time that ROMS itself is using. Something like:

double temp(ocean_time, s_rho, eta_rho, xi_rho) ;
temp:long_name = "potential temperature" ;
temp:units = "Celsius" ;
temp:time = "ocean_time" ;
temp:coordinates = "lon_rho lat_rho s_rho ocean_time" ;

If there is no "time" attribute then ROMS looks for a time coordinate set in varinfo.dat for the data, i.e. temp. ocean_time in varinfo.dat is not related to your climatology variables.

All this said, I notice you have:

double ocean_time(ocean_time) ;
ocean_time:long_name = "time since intialization" ;
ocean_time:units = "days since 1970-01-01 00:00:00" ;
ocean_time:calendar = "365_day" ;
ocean_time:cycle_length = 365. ;

so you want to perpetually cycle the climatology on a 365 day year. That's fine, but your actual times are from

ocean_time = 16801, 16802, 16803, ......
17165, 17166 ;

I would have expected 0 to 365.

I suspect this is what is throwing ROMS off. It can't make sense at first of the range of times in the climatology file not bracketing the run time.

Regarding nudging setting, read this release note: https://www.myroms.org/projects/src/ticket/627

[goodboy]

I'm pretty grateful for your help!
It's the problem about the cycle length of the time.

ocean_time:cycle_length = 365. ;

After deleting this attribute of variable ocean_time in my climatology file, it can run successfully.

[vdu001]

Hello,

I have an issue that is similar to the one above. I am trying to run an idealized setup with daily time steps and a cycle of 360 days with ROMS 3.9. I have set TIMEREF=-1 and DSTART=1. For time-variable's metadata in the input-files I have assigned units 'day' and cycle_length=360.

When trying to run the model I get the following error which is similar to the error above:

ROMStimeerror.png (54.66 KiB) Viewed 17137 times

After reading documentation on how to assign metadata for time variables and how to state TIMEREF and DSTART (e.g. this note on an update from ROMS 3.6 to 3.7: https://www.myroms.org/projects/src/ticket/771) I am unsure of what metadata is required for my case, and also which settings that conflict with each other. I also find that the documentation is not consistent, e.g. regarding the units that should be used when TIME_REF=-1 (from roms.in: 'time-units since 0000-12-30 00:00:00', while from the link above: 'time-units since 0000-01-01 00:00:00').

I try to run with clm/bry/frc_time = [1, 181], which should be within the range of times of TIMEREF=-1 and cycle_legth=360.

I have tried also including the metadata calendar=360_day Calendar which did not help.

I did not have this issue with ROMS 3.6.

Any input would be highly appreciated!

[wilkin]

Looks like your initial time is -389 days, which is not between 0 and 360.

It would probably make your time arithmetic easier to use DSTART = 0, and make the times in the forcing file [0, 180]. Make sure you spelled cycle_length correctly.

[vdu001]

Hello, thank you for your response!

I followed your suggestion and tried to change DSTART to 0, and the times in the forcing files (Frc/Bry/Clm) to [0,180]. I also changed the single time step in the init-file to 0.
Unfortunately, this did not change much (although the negative times are gone). The error now reads:

Screenshot 2021-12-10 163915.png (32.51 KiB) Viewed 17124 times

I wonder why the error now appears for the SSS field and not the SST field as before and why all values are now 0 (I would expect e.g. Data Tmax to be 180). Further up in the run log where the forcing fields are read, the SSS field appears to be skipped: surface u- and v-momentum, sst, and dQdSST is read, but then the code continues to reading the boundary file:

Screenshot 2021-12-10 164032.png (84.36 KiB) Viewed 17124 times

The C-preprocessing options ANA_SSFLUX, SALINITY, and SRELAXATION are activated. However, at the end of the run log the analytical header file "ROMS/Functionals/ana_ssflux.h" is not listed as activated.

If you have any additional input that would be very helpful!

[wilkin]

The error says Tmin and Tmax are both zero. So, you have not associated the correct time coordinate variable with the SSS variable in the netcdf file. This is done by the "time" attribute for variable SSS, or if that is absent, it uses the entry for SSS in varinfo.dat.

[wilkin]

These error messages are quite helpful if you read them closely:

If you inspect line 512 of set_data.F (last line of the code chunk below) you'll see it is the error condition triggered by a call to set_2dfld_tile to get surface salinity, which is code outside the block for #ifdef ANA_SSS

Code: Select all

!  Set surface salinity for freshwater flux correction.
!
#    ifdef ANA_SSS
      CALL ana_sss (ng, tile, iNLM)
#    else
      CALL set_2dfld_tile (ng, tile, iNLM, idSSSc,                      &
     &                     LBi, UBi, LBj, UBj,                          &
     &                     FORCES(ng)%sssG,                             &
     &                     FORCES(ng)%sss,                              &
     &                     update)
      IF (FoundError(exit_flag, NoError, __LINE__, MyFile)) RETURN
    

This suggests you have not defined ANA_SSS.

[vdu001]

Hello, thanks again for the response.

I have, however, set the time attribute for SSS (in the same way as for SST), so I do not think this should explain the error. The screenshot below is the section from my forcing file that describes sss_time and SSS. Originally I had one time dimension and three time variables, but based on an example I tried to include three time dimensions. This did not result in any change.

Screenshot 2021-12-13 103345.png (99.15 KiB) Viewed 16953 times

Regarding ANA_SSS, I do not wish to use analytical SSS, which is why I have not defined ANA_SSS. Also, I do not define e.g. ANA_SST either, but still, SST is read from the frc_file while SSS is not. My colleague has tried to investigate the .F files where the error happens, but unfortunately, this did not give us new hints as to why the difference between how SST and SSS are read occurs.