Hello all,
I got an odd problem with hc. Actually, the probelm is NETCDF_CHECK_VAR-inconsistent value of variable:hc 3.000000E+00 2.999994E+00 in/users/leon/nest-init.nc.
But I check the init file and grid file, the value of hc are all equal 3. What's the problem? By the way, I just update my ROMS version.
Thanks~
odd problem with hc
- m.hadfield
- Posts: 521
- Joined: Tue Jul 01, 2003 4:12 am
- Location: NIWA
Re: odd problem with hc
The value of hc in your grid file is different from the value specified in the ROMS input file, even though they look the same when printed with a limited number of decimal points.
NETCDF_CHECK_VAR checks for equality within a tolerance specified by parameter RoundOff, to which it assigns a value 1.0E-7. Your discrepancy is a bit larger than this. The most likely reason is that hc in your grid file is a netCDF FLOAT variable, or if it's a DOUBLE variable, it was assigned a single-precision value. Your options are: a) increase RoundOff in your copy of the ROMS source; b) rewrite your grid file. I suggest (b) is preferable.
NETCDF_CHECK_VAR checks for equality within a tolerance specified by parameter RoundOff, to which it assigns a value 1.0E-7. Your discrepancy is a bit larger than this. The most likely reason is that hc in your grid file is a netCDF FLOAT variable, or if it's a DOUBLE variable, it was assigned a single-precision value. Your options are: a) increase RoundOff in your copy of the ROMS source; b) rewrite your grid file. I suggest (b) is preferable.
-
- Posts: 128
- Joined: Tue Feb 01, 2005 8:21 pm
- Location: Istanbul Technical University (ITU)
- Contact:
Re: odd problem with hc
Hi,
i have almost same problem. Model gives error as,
NETCDF_CHECK_VAR - inconsistent value of variable: hc 1.000000E+01 1.000000E+00
in file: Data/roms_ini_SODA_Y1997M7.nc
i check the all files and value is same in all input netcdf files (10). I found that it causes from ROMS/Modules/mod_netcdf.F file and "CASE ('hc')" part and hc(ng) value returns 1.0 . I also set the TCLINE parameter as
TCLINE == 10.0d0
The hc variable is double data type in each input netcdf file. Is there any other configuration parameter that controls the hc value?
I set the land point depth as 1.0 and the definition of hc is min(hmin,Tcline). I think this causes problem. What is the reasonable value of depth in land points?
Thanks,
--ufuk
i have almost same problem. Model gives error as,
NETCDF_CHECK_VAR - inconsistent value of variable: hc 1.000000E+01 1.000000E+00
in file: Data/roms_ini_SODA_Y1997M7.nc
i check the all files and value is same in all input netcdf files (10). I found that it causes from ROMS/Modules/mod_netcdf.F file and "CASE ('hc')" part and hc(ng) value returns 1.0 . I also set the TCLINE parameter as
TCLINE == 10.0d0
The hc variable is double data type in each input netcdf file. Is there any other configuration parameter that controls the hc value?
I set the land point depth as 1.0 and the definition of hc is min(hmin,Tcline). I think this causes problem. What is the reasonable value of depth in land points?
Thanks,
--ufuk
- m.hadfield
- Posts: 521
- Joined: Tue Jul 01, 2003 4:12 am
- Location: NIWA
Re: odd problem with hc
The same as the minimum value of depth in the sea points. You shouldn't assign a special value to the land depth; just smooth the bathymetry through the land.turuncu wrote:I set the land point depth as 1.0 and the definition of hc is min(hmin,Tcline). I think this causes problem. What is the reasonable value of depth in land points?
- arango
- Site Admin
- Posts: 1367
- Joined: Wed Feb 26, 2003 4:41 pm
- Location: DMCS, Rutgers University
- Contact:
Re: odd problem with hc
Notice that when Vtransform=2, no longer there is a constraint on hc. Check the following wiki page for details. The definition of hc=MIN(hmin,Tcline) is only valid for Vtransform=1.
This is starting to sound like an old record. There is plenty information about this in this forum and wiki. Check for example the following message. Users have ignored the issue with Tcline in the past and had set-up its value to one that is inconsistent with the minimum value of input bathymetry. The internal check of hc=MIN(hmin,Tcline) is to insure a well posed transformation which apparently many ignored and violated. Now ROMS is checking for this value to make sure that your configuration is consistent. This is a very trivial issue to solve.
This is starting to sound like an old record. There is plenty information about this in this forum and wiki. Check for example the following message. Users have ignored the issue with Tcline in the past and had set-up its value to one that is inconsistent with the minimum value of input bathymetry. The internal check of hc=MIN(hmin,Tcline) is to insure a well posed transformation which apparently many ignored and violated. Now ROMS is checking for this value to make sure that your configuration is consistent. This is a very trivial issue to solve.