Problems with river input forcing when using NEMURO

Discussion about coupled ecosystem models

Moderators: arango, robertson

Post Reply
Message
Author
lcbernardo
Posts: 85
Joined: Wed Oct 01, 2014 8:57 pm
Location: Hokkaido University

Problems with river input forcing when using NEMURO

#1 Post by lcbernardo »

Dear ROMS users,

Although I have been using ROMS (particularly through the COAWST modelling system) for some years now, I recently attempted to start using the Nemuro ecosystem model. So far I have been able to get it to run using test values for the 11 biological tracers used in the model for both the initial and boundary conditions. However, when try to activate river forcing, it could not seem to recognize some of the tracer variables in my river input file, even if I have properly added them to my river input netcdf file. In particular, from the glossary in nemuro.in, the 11 tracers are defined as:

! idbio( 1) nanophytoplankton Nanophytoplankton biomass
! idbio( 2) diatom Diatom biomass
! idbio( 3) microzooplankton Microzooplankton biomass
! idbio( 4) mesozooplankton Mesozooplankton biomass
! idbio( 5) Pzooplankton Predactor zooplankton biomass
! idbio( 6) NO3 Nitrate concentration
! idbio( 7) NH4 Ammonium concentration
! idbio( 8) PON Particulate Organic Nitrogen concentration
! idbio( 9) DON Dissolved Organic Nitrogen concentration
! idbio(10) SiOH4 Silicate concentration
! idbio(11) opal Particulate organic silica concentration

and when I set:

LtracerSrc == F F F F F T T T T F F

the model is able to run. However, If I set any of the other tracers as 'T', I get a netcdf input error when I try to run the model:

GET_NGFLD - river runoff potential temperature, 2020-07-02 08:00:00.00
(Grid= 01, Rec=0000033, Index=2, File: innerbay_river_Nz24_2020nemuro.nc)
(Tmin= 7487.0000 Tmax= 7546.9583) t = 7488.3333
(Min = 2.70000000E+01 Max = 2.70000000E+01)
GET_NGFLD - river runoff salinity, 2020-07-02 08:00:00.00
(Grid= 01, Rec=0000033, Index=2, File: innerbay_river_Nz24_2020nemuro.nc)
(Tmin= 7487.0000 Tmax= 7546.9583) t = 7488.3333
(Min = 3.00000000E+00 Max = 3.00000000E+00)

INQUIRY - unable to find requested variable:
in file:
innerbay_river_Nz24_2020nemuro.nc
Found Error: 02 Line: 382 Source: ROMS/Utility/inquiry.F
Found Error: 02 Line: 121 Source: ROMS/Utility/get_ngfld.F
Found Error: 02 Line: 121 Source: ROMS/Nonlinear/get_data.F
Found Error: 02 Line: 874 Source: ROMS/Nonlinear/initial.F
Found Error: 02 Line: 200 Source: ROMS/Drivers/nl_ocean.h

Elapsed CPU time (seconds):

Node # 0 CPU: 0.656
Node # 3 CPU: 0.672
Node # 1 CPU: 0.672
Node # 2 CPU: 0.673
Total: 2.673

Nonlinear model elapsed CPU time profile, Grid: 01

Allocation and array initialization .............. 0.815 (30.4901 %)
Reading of input data ............................ 0.062 ( 2.3195 %)
Equation of state for seawater ................... 0.125 ( 4.6764 %)
Reading model state vector ....................... 1.000 (37.4111 %)
Total: 2.002 74.8971

Nonlinear model message Passage profile, Grid: 01

Message Passage: 2D halo exchanges ............... 0.094 ( 3.5166 %)
Message Passage: data broadcast .................. 0.484 (18.1070 %)
Message Passage: data reduction .................. 0.046 ( 1.7209 %)
Message Passage: data scattering.................. 0.437 (16.3487 %)
Message Passage: synchronization barrier ......... 0.046 ( 1.7209 %)
Total: 1.107 41.4141

Unique code regions profiled ..................... 2.002 74.8971 %
Residual, non-profiled code ...................... 0.671 25.1029 %


All percentages are with respect to total time = 2.673


ROMS/TOMS - Output NetCDF summary for Grid 01:

Analytical header files used:

ROMS/Functionals/ana_biology.h
Found Error: 02 Line: 456 Source: ROMS/Utility/close_io.F

ROMS/TOMS - Input error ............. exit_flag: 2


ERROR: Abnormal termination: NetCDF INPUT.
REASON: No error


Also, unlike in some instances where the missing variable is clearly indicated in the error message to point me to which input forcing variable may have a problem, in this case it is blank. I've checked my varinfo.dat and the corresponding river forcing entries are there for nanophytoplankton, diatom, and so on, so I am quite stuck regarding where to look to help me resolve this issue. I would greatly appreciate any help or guidance.

Lawrence

User avatar
kate
Posts: 3936
Joined: Wed Jul 02, 2003 5:29 pm
Location: CFOS/UAF, USA

Re: Problems with river input forcing when using NEMURO

#2 Post by kate »

It has to be something in the varinfo.dat. I seem to have both:

Code: Select all

'river_fed'
  'fed river source'
  'mol.m-2.s-1'
  'river_fed, scalar, series'
  'runoff_time'
  'idriver_fed'
  'r2dvar'
  1.0d0
and

Code: Select all

'river_fed'
  'river runoff Dissolved Iron'
  'mol/kg'
  'fed, scalar, series'
  'ocean_time'
  'idRtrc(ifed)'
  'r3dvar'
  1.0d0
I'm not sure why, but check that you have the right idRtrc variables.

lcbernardo
Posts: 85
Joined: Wed Oct 01, 2014 8:57 pm
Location: Hokkaido University

Re: Problems with river input forcing when using NEMURO

#3 Post by lcbernardo »

Hi Kate,

Thank you for your reply. I'm trying to investigate the varinfo.dat entries, but now have come across more issues, this time even with the river sources turned off. For my test run with NEMURO activated, the 11 biological tracer variables are written to the output netcdf file, but when I try to check their values using Ncview by clicking on a point within the modelling domain, I get an popop message saying 'All values are missing!'. However, when I check basic variables such as temperature, salinity, u, and v, all the values seem to have the expected output. I'm trying to find out what I could be doing wrong, and would appreciate any additional help from anyone who might be familiar with the general usage. For reference, I have attached my cppdefs.h and nemuro.in files.
nemuro.in
(46.31 KiB) Downloaded 27 times
cppdefs.h
(3.17 KiB) Downloaded 24 times
Thanks,
Lawrence

User avatar
kate
Posts: 3936
Joined: Wed Jul 02, 2003 5:29 pm
Location: CFOS/UAF, USA

Re: Problems with river input forcing when using NEMURO

#4 Post by kate »

This is when you need to build up some debugging skills. You need to find out if the bio fields are sensible in the model, getting corrupted on output, or if they're just nuts everywhere. Feel free to add print statements at will.

lcbernardo
Posts: 85
Joined: Wed Oct 01, 2014 8:57 pm
Location: Hokkaido University

Re: Problems with river input forcing when using NEMURO

#5 Post by lcbernardo »

Hi Kate,

Thank you for your comments. To observe the output, I focused on the first hour or so of the calculation and set the output of the history files to print out data every timestep. What I observed is that while temperature and salinity look fine, all of the NEMURO related parameters were either monotonically increasing or decreasing and 'flatlined' at some specific value, all within the first hour or so of simulation. And the trend was that this 'flatlining' occurred sooner closer to the coastline and a bit longer towards the open boundaries. To be sure it wasn't my open boundary values causing this, I also tried to close all boundaries related to the tracers in nemuro.in but got a similar result. So right now, it's really confusing for me. In some posts regarding ecosystem models, there would be a blowup or segmentation fault, and there would be information as to which files to look for specific errors in. But in this case, the model compiles and runs.

I guess as a follow up, I'd like to clarify more about the use of varinfo.dat. In the varinfo.dat file I'm using, I noticed that some of the nemuro related variables are defined twice or more, and there is a difference in the time units definition ('bio_time' in one definition, and then 'NO3_time' in another), and I'm wondering how this is handled within the model and if duplicates can lead to errors. What would be the best practice for this? Must I ensure that only one definition per variable exists? As always, I would greatly appreciate any help or advice.

lcbernardo
Posts: 85
Joined: Wed Oct 01, 2014 8:57 pm
Location: Hokkaido University

Re: Problems with river input forcing when using NEMURO

#6 Post by lcbernardo »

lcbernardo wrote: Tue Jan 19, 2021 6:27 am Thank you for your comments. To observe the output, I focused on the first hour or so of the calculation and set the output of the history files to print out data every timestep. What I observed is that while temperature and salinity look fine, all of the NEMURO related parameters were either monotonically increasing or decreasing and 'flatlined' at some specific value, all within the first hour or so of simulation. And the trend was that this 'flatlining' occurred sooner closer to the coastline and a bit longer towards the open boundaries. To be sure it wasn't my open boundary values causing this, I also tried to close all boundaries related to the tracers in nemuro.in but got a similar result. So right now, it's really confusing for me. In some posts regarding ecosystem models, there would be a blowup or segmentation fault, and there would be information as to which files to look for specific errors in. But in this case, the model compiles and runs.
As an update to this part of my query, it turns out that the NEMURO parameters were not 'flatlining' to a specific numerical value but were actually becoming NaNs over time, if read out the variables in MATLAB. The biofields seem to be 'going nuts' over time (and over a very short time at that), and the trend is faster closer to the coast. If this is the case, which parts of the code might be good places to look at?

User avatar
kate
Posts: 3936
Joined: Wed Jul 02, 2003 5:29 pm
Location: CFOS/UAF, USA

Re: Problems with river input forcing when using NEMURO

#7 Post by kate »

Do you have coastal river sources? Are you providing values of the BGC tracers on them? They can easy go unstable if you don't provide values for all incoming tracers. Look at the global NEWS product for nutrient values.

Don't worry about varinfo.dat. Best practice is to have the name of the time variable encoded in the time attribute of the input file's variables. ROMS will read that over whatever is in varinfo.dat.

lcbernardo
Posts: 85
Joined: Wed Oct 01, 2014 8:57 pm
Location: Hokkaido University

Re: Problems with river input forcing when using NEMURO

#8 Post by lcbernardo »

Thanks for replying Kate. My original intent was to add coastal river sources, but even with these turned off, the model output values for the BGC tracers seem to be going bad quickly. I tried both with a boundary conditions netcdf file (with values for all incoming tracers), and also with the open boundaries closed for the BGC tracers. In all cases, analytical values are used for the BGC tracer initial conditions. To more clearly indicated the trend, I have provided a set of snapshots after viewing the resulting NO3 values for the shallowest layer after specific time intervals:

NO3_surface_trend.png

Thank you also for the comment regarding the varinfo.dat. I think the time variable names are properly encoded in my input netcdf files, but I'll double check.

lcbernardo
Posts: 85
Joined: Wed Oct 01, 2014 8:57 pm
Location: Hokkaido University

Re: Problems with river input forcing when using NEMURO

#9 Post by lcbernardo »

I finally got to work on this issue after focusing on other stuff. I had been using COAWST, but I then tried using the latest version of Rutgers ROMS and with this change somehow the issue I previously had did not occur (NaNs suddenly appearing in the outputs). I guess this question is off topic, but it led me to wonder about how closely the ROMS included in COAWST operates compared with the original Rutgers ROMS which is the focus of this forum. I used to study wave and flow coupling, and hydrodynamics during typhoons, and for this I found COAWST quite helpful. But if I were to focus more on the ecosystem models such as NEMURO or Fennel, are there advantages to using Rutgers ROMS rather than COAWST?

User avatar
wilkin
Posts: 623
Joined: Mon Apr 28, 2003 5:44 pm
Location: Rutgers University
Contact:

Re: Problems with river input forcing when using NEMURO

#10 Post by wilkin »

Generally speaking COAWST keeps pretty close to the myroms.org version for aspects of the forward model - a Herculean task by John Warner.

But if you have concerns with application modules like BIO_FENNEL or NEMURO, then it's prudent to check for differences - the unix 'diff' command will do that nicely.

You can also check for major tickets in the trac facility. For example, a simple search on the keyword "Fennel" shows ...
https://www.myroms.org/projects/src/search?q=Fennel
that several very significant enhancements were added 5 months ago. Since they include new state variables, there will be changes to varinfo.dat and bio_Fennel.in that flow from those.
John Wilkin: DMCS Rutgers University
71 Dudley Rd, New Brunswick, NJ 08901-8521, USA. ph: 609-630-0559 jwilkin@rutgers.edu

User avatar
wilkin
Posts: 623
Joined: Mon Apr 28, 2003 5:44 pm
Location: Rutgers University
Contact:

Re: Problems with river input forcing when using NEMURO

#11 Post by wilkin »

Regarding your river source problems specifically ... look closely at the logfile.

Are the river point source tracer concentrations being reported for all the variables you want to have inflow? The choice is controlled in the nemuro.in file.

Do the values look bio-physically reasonable? In particular, are any of them reported as NaN?
John Wilkin: DMCS Rutgers University
71 Dudley Rd, New Brunswick, NJ 08901-8521, USA. ph: 609-630-0559 jwilkin@rutgers.edu

lcbernardo
Posts: 85
Joined: Wed Oct 01, 2014 8:57 pm
Location: Hokkaido University

Re: Problems with river input forcing when using NEMURO

#12 Post by lcbernardo »

Thank you so much for your explanation and suggestions Dr. Wilkin. Indeed it must be quite a task for Dr. Warner, and I've really grateful for the times he's been able to reply to me regarding concerns with the COAWST model.

Now that my ROMS is up to date and I've been able to get it to work (sometimes compilation causes some headaches), I'll try to look more closely at the ecosystem model files and compare them with the ones from when I was using COAWST. I suspect my version of COAWST was not an updated one, as when I looked at the logfile from my older runs, not all of the NEMURO tracers are mentioned in the logfile at the start, unlike for my more recent results where they are all reported (whether as activated or not for climatology, river forcing, etc.). There were also other strange things about my older runs. For example, upon running, it was asking for the variable 'SiOH' as input, when it seems 'SiOH4' is the proper one for NEMURO. Also, NaNs appeared when I activated HOLLING_GRAZING, but it produced reasonable values when IVLEV_IMPLICIT was activated instead. In my current runs, the model seems to be working fine for both grazing options.

Post Reply