ncar / wrf_hydro_nwm_public

WRF-Hydro model code

WRF-Hydro®

Description

This is the code repository for WRF-Hydro®.

WRF-Hydro is a community modeling system and framework for hydrologic modeling and model coupling. In 2016 a configuration of WRF-Hydro was implemented as the National Water Model (NWM) for the continental United States.

Documentation

Documentation and in-depth build instructions can be found on our project website. Quick build instructions for CMake are also available.

Resources and Support

For news and updates regarding the WRF-Hydro project please subscribe to our email list.

For user support and general inquiries please use our contact form.

If you have found a bug or would like to propose changes to the model code please refer to our contributing guidelines.

Contributions

For more information on how to contribute to this project please refer to our contributing guidelines.

License

The license and terms of use for this software can be found here. The Crocus snowpack module and related files are from the SURFEX surface model developed by Météo-France, the French national meteorological service. These files are under the CeCILL-C license.

Acknowledgements

Funding support for the development and application of the WRF-Hydro system has been provided by:

• The National Science Foundation and the National Center for Atmospheric Research
• The National Oceanic and Atmospheric Administration (NOAA) Office of Water Prediction (OWP)
• The U.S. National Weather Service (NWS)
• The U.S. Department of Energy (DOE)
• The Colorado Water Conservation Board
• Baron Advanced Meteorological Services
• National Aeronautics and Space Administration (NASA)

wrf_hydro_nwm_public's Issues

Filenames need to be syntactically correct

There are a number of files output by the model that are not syntactically correct, primarily the restart files with : in the filename. For example, HYDRO_RST.2011-08-26_00:00_DOMAIN1.

This is incredibly bad practice as they will be renamed or flat out rejected when passing through any system designed to handle diverse filesystem conventions, which is most modern systems or web servers.

All special characters should be removed and replaced with universally acceptable characters such as _ or debatably preferred -

hydro.namelist check inconsistent with selected options

The output options for
output_channelBucket_influx = 0 state that these are only active for UDMP_OPT=1, however, the following is noted:

Current Behavior

If UDMP_OPT=0 and output_channelBucket_influx = 2 with GWBASESWCRT = 0, the model crashes since these options are inconsistent. This is GOOD because GWBASESWCRT cannot be zero if a user wants 2=channel+bucket fluxes (qSfcLatRunoff, qBucket, qBtmVertRunoff_toBucket)

Expected Behavior

The comment in the hydro.namelist, ! Options to output channel & bucket influxes. Only active for UDMP_OPT=1. , makes it seem like this entire suite of options are ignored if UDMP=0, but in reality they are not being ignored.

Possible Solution

Remove this comment from the hydro.namelist:
! Options to output channel & bucket influxes. Only active for UDMP_OPT=1.

Your Environment

• Relevant settings for hydro.namelist: channel_option = 2, UDMP=0, output_channelBucket_influx != 0.
• Using v5 release tag hydro.namelist files with the v5 code tarball, commit: 49e705. Compiled on intel.

Feature_ids in Lakeout jumble when subsetted NWM domain includes partial lake

In the case of a cutout from the NWM domain, the Routelink is cutout to include only the links in the domain. In some cases, inflows/internal lake links can be included without the outlet link. This is causing an issue in LAKEOUT files, where the feature_id and other fields are non-sensical.

Expected Behavior

The model should crash with a message indicating that the lake outlet link was not found and therefore the level pool routine was unable to finish.
A check should be added to the subsetting tools to prevent partial lakes from being included in the domain.

##Settings
-UDMP = 1 with a domain extracted using the current NWM subsetting tools.
-Lakes on. outlake=1.

Develop a constants module

Currently there is overuse of "magic" or hard-coded numbers in the code base. This has many drawbacks (including variable precision) and is not flexible.

Possible Solution

The goal would be to develop a constants module available across all of the code so that there is a single point of reference for constants.

Checklist for code tags / releases

We should start a checklist for code tags / releases so that odds and ends don't get forgotten (e.g. model versions in file metadata, adding info NEWS.md, etc.). The repository wiki seems it like a good place for this (and similar things) to live.

Missing END FUNCTION in module_NWM_io.F

This is benign if your compiler can handle it, but function GetModelConfigType does not have an associated end function in module_NWM_io.F. My PGI compile handled it fine and didn't even report a warning. I suspect most compilers fix this automatically, but certain cases will not fix it.

I wrote a little toy program to test this. In my standard gfortran environment, there is not an issue if you do or do not use end function in this case. For example, this works:

gfortran -o test_function function_modules.f90 test_function.f90

However, if I compile with a set Fortran standard, like f95, for example, it will not compile, e.g., this compile line does not work:

gfortran -std=f95 -o test_function function_modules.f90 test_function.f90
function_modules.f90:12:3:

end
1
Error: Fortran 2008: END statement instead of END FUNCTION statement at (1)

A user has reported this in an environment (mpif90) that likely was set-up with something like this '-std=' option. It may be some other switch that is causing this but this one will repeat the issue.

This will likely cause more issues especially in environments where pre-set flags are being set by system admins.

This was introduced in commit a9d30fc on May 8.

Expected Behavior

Should compile.

Current Behavior

Compile is failing under certain compiler options.

Possible Solution

Add end function to function GetModelConfigType

Steps to Reproduce (for bugs)

1. add "-std=f95" to compile line

Your Environment

Latest commit does not compile with HYDRO_REALTIME=0

hydro-c1, configure option 2 (pgf)
It does compile for HYDRO_REALTIME=1.
make clean before building with HYDRO_REALTIME=0

jamesmcc@hydro-c1[604]:~/WRF_Hydro/upstream_wrf_hydro_model/trunk/NDHMS> makeCheck 
11:09:09
-- illegals --
PGF90-S-0084-Illegal use of symbol g_acclndrunoff - must be an allocatable array (module_HYDRO_io.f: 40734)
PGF90-S-0084-Illegal use of symbol g_accqlateral - must be an allocatable array (module_HYDRO_io.f: 40735)
PGF90-S-0084-Illegal use of symbol g_accstrmvolrt - must be an allocatable array (module_HYDRO_io.f: 40736)
PGF90-S-0084-Illegal use of symbol g_accbucket - must be an allocatable array (module_HYDRO_io.f: 40737)
PGF90-S-0084-Illegal use of symbol g_acclndrunoff - must be an allocatable array (../Routing/module_HYDRO_io.f: 40734)
PGF90-S-0084-Illegal use of symbol g_accqlateral - must be an allocatable array (../Routing/module_HYDRO_io.f: 40735)
PGF90-S-0084-Illegal use of symbol g_accstrmvolrt - must be an allocatable array (../Routing/module_HYDRO_io.f: 40736)
PGF90-S-0084-Illegal use of symbol g_accbucket - must be an allocatable array (../Routing/module_HYDRO_io.f: 40737)
++ warns ++
  0 inform,   0 warnings,   4 severes, 0 fatal for mpp_output_chrt2
  0 inform,   0 warnings,   4 severes, 0 fatal for mpp_output_chrt2
** errors **
make[2]: [module_HYDRO_io.o] Error 2 (ignored)
make[2]: [module_HYDRO_io.o] Error 1 (ignored)
make[2]: [../Routing/module_HYDRO_io.o] Error 2 (ignored)
make[2]: [../Routing/module_HYDRO_io.o] Error 1 (ignored)
make[2]: [hrldas.exe] Error 2 (ignored)
make: *** [all] Error 1

MODIS landuse data support

HYDRO_drv/module_HYDRO_drv.F subroutine lsm_input() does some reclassification of soiltype and vegtype fields where USGS classes are 16 for water. If one uses MODIS data instead, this reclassification is not taking care about MODIS data having different classes.
MMINLU information needs to be transferred to this subroutine to implement a conditional check whether USGS or MODIS classification is used.

            if(nlst_rt(did)%sys_cpl .eq. 2 ) then
              ! coupling with WRF
                if(present(soltyp0) ) then
                   where(soltyp0 == 14) VEGTYP0 = 16
                   where(VEGTYP0 == 16 ) soltyp0 = 14
                   soltyp = soltyp0
                   RT_DOMAIN(did)%VEGTYP = VEGTYP0
                endif
            endif

         where(soltyp == 14) RT_DOMAIN(did)%VEGTYP = 16
         where(RT_DOMAIN(did)%VEGTYP == 16 ) soltyp = 14

Incorrect variable types in routelink file result in inconsistent model behavior

Expected Behavior

If variable types are important, the model should check for them and notify the user

Current Behavior

The model is failing testing because of inconsistent behavior resulting from incorrect variable types in the new routelink file

Possible Solution

Add in checks for appropriate variable types and roll back testing to old model domain for the time being

@jmccreight has offered to add in checks for this

Testing: checks for data and metadata should be separated

Expected Behavior

For example, #45

In CI when metadata changes are applied to the CHRTOUT and CHANOBS files, the checks on those files fail and it is ambiguous if the failure is data or metadata. One can not tell and to be sure, should reproduce the test locally. I think it's better to be explicit about this rather than cause all that work

Deprecation cleanup: mpp_output_chrt

mpp_output_chrt is broken.

Currently this routine is only being used by Noah because NoahMP output routines use the module_NWM_io.F approach.

Do we fix it or do we move Noah to the NWM_io approach?

Some artifacts of the deprication are referenced in #10 in module_HYDRO_drv.F.

Include appropriate metadata in restart files

Include appropriate metadata (variable names, descriptions, units) in both hydro (HYDRO_RST*) and land surface model (RESTART*) restart files.

Note: Many of these are now described within the WRF-Hydro v5 Technical Description & User Guide.

Upgrades to CHANOBS

CHANOBS output file should include the nudge.
Should CHANOBS contain the channel-only fluxes as well? I think we could go either way, my penchant would be NO because the full channel is needed to drive channel-only.

Expected Behavior

It's expected that CHANOBS would be like a subset of CHRTOUT, but variables are missing in comparison.

Current Behavior

CHANOBS does not output the nudge.

Possible Solution

Put the nudge into CHANOBS.

Steps to Reproduce (for bugs)

Your Environment

• Version of the code used:
• Operating System and version:
• Compiler and version:
• Other relevant information:

Port over issues from wrf_hydro_model repo

Just a reminder that we need to either address these issues (https://github.com/NCAR/wrf_hydro_model/issues) or port them over to this repository.

Need checking the dimension of FORCING file

At the moment of this issue, the model does not provide enough descriptive information on what caused an error when the dimension of the forcing is not matching the model domain.

Expected Behavior

I would expect the model could provide enough information when supplying a wrong forcing file to it, and the dimension is not matching the model domain.

Current Behavior

It throws a seg fault with no description.

Steps to Reproduce (for bugs)

Just provide a forcing file with a smaller dimension than your domain.

Create a time module

Expected Behavior

It's reasonable that there would be a central location for calculating and managing time variables.

Current Behavior

Currently there are time calculations happening all over the place which is opaque and not maintainable.

Possible Solution

Make a time module that tracks time variables and performs desired transformations on them by request. Time calculations should never happen elsewhere.

Add citation information and/or guidance

It would be good to add some guidance regarding how to cite the model, etc. on the README.md and potentially a CITATION file.

Zenodo could also be helpful in this area. GitHub has some suggestions / instructions for this: https://guides.github.com/activities/citable-code/

Restart runs: internal times in CHANOBS and CHRTOUT_DOMAIN files are incorrect

(This is the case when model time matches the time in the restart file, not same as previous bug).

The times calculated for CHANOBS and CHRTOUT_DOMAIN share a common bug.

One "non-standard" detail: I run at 15minute timestep and output that frequently in both models.

In LSM times, these are the runs
Run 1: 2013-09-12 00:00 - 2013-09-16 00:00
Restart run: 2013-09-13 00:00 - 2013-09-13 06:00 (restarts at 2013-09-13 00:00)

Looking at the first CHANOBS output file

jamesmcc@hydro-c1[2109]> ncVarRng time_observation 201309130015.CHANOBS_DOMAIN2
time_observation : Range=( 23400 , 23400 )

jamesmcc@hydro-c1[2112]> ncdump -h 201309130015.CHANOBS_DOMAIN2
...
int time_observation(recNum) ;
        time_observation:units = "seconds since 2013-09-12 00:00 UTC" ;
        time_observation:long_name = "time of observation" ;
...

but (following in R):

as.POSIXct('2013-09-12 00:00:00',tz='UTC') + 23400
[1] "2013-09-12 06:30:00 UTC"

is not the timestamp on the file: 201309130015. The timestamp on the file is correct.

All the following output files are off by exactly the same shift.

If I print diagnostics on the following line in module_HYDRO_io.F:output_chrt() (~ line 2825)

seconds_since = int(dtrt_ch)*K

At the first output, I get

K:           26
dtrt_ch:    900.0000

Their product is the 23400.
The number should actually be 87300 = (24x60+15)x60

I believe there are issues with both:

1. K should be alot more because outputs were written 4x24 hours to get to this point, and 26 may be off somehow (i could understand 25)
2. dtrt_ch is actually 180 while DT is 900 (you can see that DT gets passed to dtrt_ch, so the name may just be misleading here).

The correct calculation might be something more like:

as.POSIXct('2013-09-12 00:00:00',tz='UTC') + (24*(60*60/900)+1)*900
[1] "2013-09-13 00:15:00 UTC"

But I dont want to tinker with this myself.

Reach-based channel flows not sensitive to perturbations in idealized forcing (FORC_TYP 4)

(This is for master branch.)

On the left, my editor shows that I multiply the idealized precip by 5. (I then compile and run a regression test against my Boulder Domain for 24 hours where there is just 1x idealized precip - standard master branch).
On the right, the results of the regression test show only differences with 1x precip are
accLndRunOff & accQLateral. The channel flows do not change (they are not reported, they are bfb matched).

I did note, however, this is apparently NOT the case for FORC_TYP=1. There are difference in many variables when that precip is multiplied (by a factor >1).

[BUG] infxswgt incorrectly exported to restart file

I found, on our Intel based system (compiler and hardware), that what is written to the restart netcdf file is not always identical with what's in the memory.
Thus, values in the surface routing weighting grid infxswgt become orders of magnitude larger than they should be.
I attached a netcdf file for illustration.
infxswgt.zip
It seems that at some point in the computations, the variable changes precision, although everywhere only REAL*4 is defined. When writing the field to the nc file, the values are not correctly converted to float (as required in the netcdf file). Reading the field subsequently imports the wrong values into the simulation, leading to much too high surface head.
Adding a cast to real() in
module_HYDRO_io.F
call w_rst_rt_nc2(ncid,rt_domain(did)%ixrt,rt_domain(did)%jxrt,real(rt_domain(did)%INFXSWGT), "infxswgt" )
solves the problem, at least on our system.
If the conversion is done later in the calling sequence, just before the netcdf variable is put into the file, the values are already corrupted. The problem seems to be connected with the MPI collection of the distributed infxswgt field into the global field.

Outputting of CHANOBS/FRXSTPTS With No Forecast Points Defined

This is an issue discovered by Laura when running gridded routing, attempting to output CHANOBS files with no forecast points defined in the Fulldom file.

Expected Behavior

The code should spit out a WARNING that no forecast points (or gage points for reach-based routing) have been found, even though the user requested to output CHANOBS and/or the fxstPts text file.

Current Behavior

The code simply grabs random points and outputs them to the CHANOBS and/or fxstPts file. The values appear to be random.

Possible Solution

Place a check for the number of forecast points or gage points prior to creating the output files. This will need to be put into the CHANOBS output routine and the fxstPts output routine.

Steps to Reproduce (for bugs)

Your Environment

• Version of the code used:
• Operating System and version:
• Compiler and version:
• Other relevant information:

basn_mask field in hires input file

The high resolution input file contains a basn_mask field. As far as I understand the code, the field is never used in the model though. Instead the coarse grid basin text file is imported and assigned also to the high resolution grid. Wouldn't it be better to use the basn_mask field and to derive the coarse grid field from it? The basin text file is very much prone to errors since it is not documented what's the storage order of these numbers. Are there any thoughts about this? I would vote for getting rid of the text file and to use the high resolution field from the netcdf file.

pytest metafunc parameters and conditional tests

This is a testing "bug" or at least "non-feature".

A consequence of some details of pytest and/or how we are using it means that test questions cannot be conditional to configurations (e.g. NWM, Reach, Gridded). In other words: all test questions are required for all configurations. Though they can be skipped conditionally at test time, all test questions are collected for all configurations at the beginning of pytest execution but subsequently skipped at test time and reported as such. The issue is that it makes testing overly verbose and that the problem is likely to grow so that noise is greater than signal in the test log/output. This is likely to happen soon.

The current case is specifically: For [NWM, Gridded, Reach] configurations the inclusion of new tests for channel-only with NWM results in 4 extra tests questions which should only be run with NWM configuration, but the tests must be included for all configurations in the collection. Currently this boosts the total number of questions collected per configuration from 9 to 13, resulting in 39 collected where as there are only 13+9+9=31 meaningful tests. This is a 20 percent bloat in test reporting due to how things are being done with pytest.

While this is tolerable at the moment, if we begin designing configuration-specific tests it's going to be untenable very quickly.

It's unclear if this is a current short coming of pytest or if we could restructure our tests to avoid this. Understanding this is a first step forward.

critical hydro-side restart issue for current master (84f4517)

When a HYDRO restart file is specified, all hydro output is missing except for GW*txt.
I do not have this issue when commenting RESTART_FILE from hydro.namelist.

Please see this directory (on hydro):
jamesmcc@hydro-c1[906]:~/WRF_Hydro/FRNG_NHD/RUN/prstTestFeb2016/run.masterRestart

rt_domain variables dist and dist_lsm are storing area in final array dimension

The variables:
rt_domain(did)%dist (rt_domain(did)%overland%properties%distance_to_neighbor)
rt_domain(did)%dist_lsm

are storing areas in the (:,:,9) position of the arrays. This is not clearly documented and the areas should probably be kept in separate arrays with appropriate names.

I would suggest changing the allocation of the arrays to only allocate 8 positions for the 3rd array dimensions for both arrays and creating arrays for storing area and area_lsm.

Are there any circumstances currently supported by wrf-hydro where both area and area_lsm would not be a single value?

Build .*F > *.f fails on osx native (non-case sensitive) file systems.

Legacy OS X filesystems are case insensitive. (Though there appears to be a case sensitive option with APFS now). Because we preprocess *F files to *f files, we can not compile on OS X filesystems (including using docker on a mounted OS X directory).

If change this convention to something that's not at odds with case-insensitive files systems, the model becomes much more usable via docker.

Having used the model extensively in docker on my desktop and laptops, this would be a tremendous benefit.

There are two work arounds:

1. in docker, copy the mounted repo to a non-mounted directory inside docker. Compile.
2. Put the code on a case-sensitive external drive and mount this into docker.

GWBUCKPARM.TBL template defaults

It turns out, that with the standard parameters given in GWBUCKPARM.TBL the bucket storage is so small that inflow virtually equals outflow and thus the pass-through option is emulated by the bucket model option. I'm not sure if the bucket model used m units in earlier times and that the default parameters are that small because of that. My suggestion for the next release would be to change the defaults of zinit and zmax to more reasonable values.

No Crash With DTRT in hydro.namelist

Ran the newest version of the code with the old "DTRT" option in the hydro.namelist file. While this was incorrect, the model failed to crash and ran to completion. It failed to write CHRTOUT_DOMAIN and CHRTOUT_GRID files. This may not be high priority, but may need to be addressed with a check for proper namelist variables at some point.

master :: forc_typ = 6 LDASIN issues

master branch
force_type = 6
I am not doing anything to fix this for now, but this needs to be discussed and documented.

The behavior when LDASIN files are missing is undesirable in several ways:

1. Apparently any file at t+12 hrs will be used if t is missing (My opinion is that this is bad and the user should be forced to fake these with symlinks and handle before run time at the system level. The potential cost of runs that look fine but read completely different LDASIN files than expected is too high to leave this as the default.)
2. Diagnostics barely reflect when this is happening unless you read all the image print statements for a given time: the filename actually read in is not communicated to the other images so the diagnostics are misleading.
3. No warning is produced when a different time is substituted for the current time. Given 1, this would not be necessary. But if somehow the current behavoir is desirable, then a warning should be printed at a minumum.

There seems to be a bug in the comparison of the Gridded/run_*/CHANOBS files: some of the files are not found.

https://travis-ci.com/NCAR/wrf_hydro_nwm/builds/74928143#L583

"None, None, None, None, None"

Expected Behavior

It should find the files, they are there. Running tests/take_test.sh on this PR will reveal the issue.

Current Behavior

It dosent find the files.

first order streams with NHD plus

With the FRNG test domain using NHD:

• over half of the reaches are 1st order (9552/18226=.524)
• 50 of these 1st order reaches have upstream (1st order reaches)

Right now, in the code:

• qlink1 (the upstream flow from each reach appears to be output to file)
• flow from upstream reaches is treated as zero.

1. Do we want to output so many zeros (is there something more informative than outputting qlink1?)
2. We should fix 1st order reaches with upstream reaches.

I also noted several 2+ order reaches (2,5,6) with zero flow, but this may have been a more pointed Route_Link.nc specification issue.

Input file (consistency) check

The model doesn't stop if input files are not found at the specified path. For example, if the hires input file is not found at the specified location, the model starts to print out many many invalid channel links.
The model also doesn't stop if the number of points in the basin mask (lsm grid) text file is inconsistent with the dimensions of the domain (nx*ny).

restart/ for binary restart not always created

This cause runs to crash. It seems that sometimes it is created and other times not. I confirmed that it was not created for a cold start run on the first of Jan 1 and the model crashes. I create restarts/ and it works fine.

NaNs in FRNG test case

This appears to be a domain issue with the front range Route_Link file.
There are 3 reaches with NaNs in the test case 4DAY/NHDPLUS run, for the entire length of the run. These are NOT first order reaches, but there are no points in the domain above them according to the Route_Link file. This is likely the issue.

Here's the analysis in R showing their comIds and the issue with a plot at the end.

> path <- "/d6/jamesmcc/WRF_Hydro/FRNG_NHD/4DAY/NHDPLUS/run.pmoOpenLoop/frxst_pts_out.txt"
> frxst <- ReadFrxstPts(path)
> rlFile <- '/d6/jamesmcc/WRF_Hydro/FRNG_NHD/4DAY/NHDPLUS/DOMAIN/Route_Link_2.gagesAllLinks.nc'
> rl <- as.data.frame(GetNcdfFile(rlFile, q=TRUE))
> naLinkNames <- unique(frxst$st_id[which(is.na(frxst$q_cms))])
> rlNa <- subset(rl, trimws(rl$gages) %in% trimws(naLinkNames))
> naLinks <- rlNa$link
> naLinks
[1] 2897845 2919687 2876787

Those are the comIds. Here's the rest of the associated information in Route_Link.

> rlNa
      BtmWdth  Qi      So    link from      to       lon      lat     alt type
10509       5 0.1 0.00797 2897845    0 2897865 -105.0422 40.93214 1821.80    0
10570       3 0.1 0.01391 2919687    0 2919697 -104.7983 40.92731 1738.39    0
12199       3 0.1 0.00256 2876787    0 2876807 -104.5269 40.93164 1641.92    0
      order MusK MusX Length     n ChSlp LkHZArea LkMxH WeirC WeirL OrificeC
10509     3 3600  0.2    552 0.035  0.05    -9999 -9999 -9999 -9999    -9999
10570     2 3600  0.2     92 0.035  0.05    -9999 -9999 -9999 -9999    -9999
12199     2 3600  0.2    156 0.035  0.05    -9999 -9999 -9999 -9999    -9999
      OrificeA OrificeE time           gages
10509    -9999    -9999    0        g2897845
10570    -9999    -9999    0        g2919687
12199    -9999    -9999    0        g2876787

and, lo, the likely problem:

> which(rl$to %in% naLinks)
integer(0)

There are no upstream reaches though these are 2nd and 3rd order streams.

To generate the plot, a few more steps

> library(rwrfhydro)
> VisRl <- VisualizeRouteLink(rlFile)
> visRlObj <- VisRl()
Map from URL : http://maps.googleapis.com/maps/api/staticmap?center=39.758913,-105.096191&zoom=8&size=640x640&scale=2&maptype=terrain&language=en-EN&sensor=false
> #names(visRlObj)
> #str(visRlObj$rl)
> #str(rl)
> rlNa <- subset(visRlObj$rl, trimws(visRlObj$rl$gages) %in% trimws(naLinkNames))
> visRlObj$ggObj+
+   ggplot2::geom_segment(data=rlNa,
+                         ## a little fudge factor necess since these reaches have no "from"
+                        ggplot2::aes(x=lon-.01, y=lat-.01, xend=to_lon, yend=to_lat), 
+                        color='cyan', size=9) 

The cyan bits at the top of the screen are the three links with Na values.

Single repo: update documentation

This is a reminder to update the documentation about the repos now that we only have one!

Prevent pollution of trunk/NDHMS directory with compile artifacts

See #17 for an example of the danger of polluting the source directory with artifacts.

All artifacts should be placed in the Run directory or cleaned up on compile script exit

Units for qin_gwsubbas inconsistent between model configurations

In module_GW_baseflow.F the units for qin_gwsubbas are inconsistent between NWM (UDMAP=1) and non-NWM configurations of WRF-Hydro. This term can only be output for NWM configurations of the model and the output units are correct for this configuration. However, it's potentially confusing.

Unit labels on some CHRTOUT_DOMAIN variables

In this file: https://ral.ucar.edu/sites/default/files/public/WRFHydroV5_OutputVariableMatrix_V5.pdf
qBtmVertRunoff is labeled as having units of m3 -- @mccreigh confirmed that it should be m3/s.

In the V1.2 retrospective output sourced from Amazon, we are also seeing m3 units on qSfcLatRunoff and qBucket.

See #76 for code fix of qBtmVertRunoff. It sounds like the others were already fixed in code (since the v1.2 retro was run).

The label in the pdf matrix linked above will also need attention.

Closure criteria, units on these three are correct in code and updated in documentation.

Note that I did not find the units for these variables in the wrf-hydro manual so -- probably no updated needed there.

Problem with symlink artifact produced by compile_offline_NoahMP.sh

compile_offline_NoahMP.sh produces two symlinks in the trunk/NDHMS source directory when run: LandModel and LandModel_cpl.

If the directory is copied without careful attention to these symlinks, they are copy as the target folders. The compile_offline_NoahMP.sh script attempts to delete these files when re-run, but if they exist as directories the script fails.

This may affect compile_offline_Noah.sh as well.

FIX

https://github.com/NCAR/wrf_hydro_nwm_public/blob/master/trunk/NDHMS/compile_offline_NoahMP.sh#L39

should be changed to rm -rf LandModel LandModel_cpl

ADDITIONAL ISSUES
Under no circumstances should artifacts be produced in the source directory. This issue is only one example of the dangers of polluting the source directory with artifacts. A new issue will be opened to address this

station_id inconsistencies

Station_id output variable differs between CHRTOUT_DOMAIN namelist options 1 and 2. Character in option 1 and int in option 2. Option 2 values appear to match linkids. Prefer to have linkids for both.

Allow for output from multiple timesteps to be stored in a single output file

Current Behavior

Currently WRF-Hydro output files contain data from only a single time. Depending upon the model configuration and workflow, the number of output files generated by the model can be very large.

Suggestion

Allowing for multiple output time steps to be stored (ideally with some flexibility for the user - WRF does this) in a single file could be very helpful in some situations.

Note: We do have a namelist option for this functionality, but it is currently not allowed (there is a namelist check ensuring the number of timesteps per file = 1)

Channel-only output files skipped in certain situations

Some restarts of the model with channel-only skip output of the output files (though the restart file is output). Some restarts of the model have the output files....

Expected Behavior

The output files should be there...

Current Behavior

Sometimes, the output files are not there.

Possible Solution

May be related to some time keeping flags with t0output or maybe something like his_out_counts which is not tracked properly in channel-only.

Steps to Reproduce (for bugs)

I'm running the 6mile domain on cheyenne. Run of the first and second hours produces no output files, the third hour does.
I should see if this is reproduced with croton.

Your Environment

• Version of the code used:
• Operating System and version:
• Compiler and version:
• Other relevant information:

when dt/dtrt_ch is not an integer

I dont know if this is important to flag or not.
I was running LSM DT = 900 sec and DTRT_CH = 120 sec. I'm not sure what the ouput files were really representing (I assume the channel state 1 minute later was being written to the file, because I didnt notice any correction of DTRT_CH, but I didnt look very hard).

For my branch I added this to Data_Rec/module_namelist.F

if(DT/nlst%DTRT_CH .ne. real(int(DT) / int(DTRT_CH)) ) &
     call hydro_stop("driveChannelRouting: DT not a multiple of DTRT_CH")

If you like it add it to master, otherwise, ignore it and close issue.

Move deprecated CHRTOUT=2 option to 1 to ease Noah support

Current Behavior

The new output routines are not setup to work with Noah. We therefore have to use the deprecated routines if running with Noah (io_form_outputs=0). I believe CHRTOUT_DOMAIN=1 under the deprecated routines is broken and only CHRTOUT_DOMAIN=2 works as expected.

Possible Solution

Propose switching CHRTOUT_DOMAIN=1 under io_form_outputs=0 to call the functional output_chrt2 routine and inactivate output_chrt completely. Less confusion for the user. Also update the hydro.namelist template to specify the io_form_outputs=0 option is for Noah only:

#! Flag to turn on/off new I/O routines:
! 0 = deprecated output routines (only use when running with the Noah LSM),
! 1 = with scale/offset/compression,
! 2 = with scale/offset/NO compression,
! 3 = compression only,
! 4 = no scale/offset/compression (default)
io_form_outputs = 1 <<-- Specify which output option to use (NOTE: option 0 is the only supported option when running with the Noah LSM).

Theia build broken

From: Rocky Dunlap

Expected Behavior

That it configures and compiles under intel.

Current Behavior

git clone [email protected]:NCAR/wrf_hydro_nwm.git
cd trunk/NDHMS
./configure

Please select from following supported linux compilers
using either the number or key (not case sensitive):

Number    Key  Description
--------------------------------------------
     1    pgi  PGI parallel
     2  gfort  gfortran parallel
     3  ifort  intel parallel (incl. Theia)
     4   luna  ifort parallel (WCOSS Luna)
     0   exit  exit

Enter selection: 3

cp: cannot stat ‘arc/macros.mpp.ifort.theia’: No such file or directory
Configured: ifort on Theia
No compiler selected. Exiting

Possible Solution

cd trunk/NDHMS/arc
cp macros.theia macros.mpp.ifort.theia
cd ../
./configure ifort

Steps to Reproduce (for bugs)

See above, specific to theia.

Your Environment

• Version of the code used:
• Operating System and version:
• Compiler and version:
• Other relevant information:

Compile issue with coupled model

Logging this from a user report so it's documented in the public repo

Expected Behavior

Coupled WRF | WRF-Hydro should build without error

Current Behavior

Coupled WRF | WRF-Hydro build fails with the following error message:
Unable to open MODULE file netcdf.mod (module_wrf_HYDRO.f: 28)

Possible Solution

Change line 21 in the Makefile from:
$(COMPILER90) -o $(@) $(F90FLAGS) $(MODFLAG) -I$(WRF_ROOT)/frame -I$(WRF_ROOT)/main -I$(WRF_ROOT)/external/esmf_time_f90 $(*).f
to:
$(COMPILER90) -o $(@) $(F90FLAGS) $(MODFLAG) -I$(WRF_ROOT)/frame -I$(WRF_ROOT)/main -I$(WRF_ROOT)/external/esmf_time_f90 -I$(NETCDFINC) $(*).f

Your Environment

• Version of the code used: WRF-Hydro v5.0.0
• Operating System and version:
• Compiler and version: PGI v17.5
• Other relevant information:

FATAL ERROR return code is 0

The job is stoped due to the FATAL ERROR: 
 failed to read the hydro restart file RESTARTS/HYDRO_RST.2015-05-01_00:00_DOMAI
 N1.23

but

echo $?
0

An easy fix, but I'm not up on the appropriate place to do it.

Channel output when restart time does not match model start time

There is a larger discussion of if/how/when/why to handle the situation when the namelist requests are restart file who's time does not match the specified model start time. Is this a bug or a feature?

However, there is a somewhat undesirable side-effect that should be handled: the RTOUT*DOMAIN (and CHANOBS) files are timestamped with the model time BUT the times in the files are based on the restart times: so they are actually consistent with the restart time. Meanwhile, the LSM is consistent with the model start time.

To me, this behavior implies that letting the model run when start time is not equal to restart time is a bug. I suppose this is debatable and everything is fine.... ?

Example

Model start time: 9-12-13_00:00:00
Requested restart: 9-15-13_00:00:00
KHOUR=6
LSM timestep = 900 seconds
IOC configuration (channel_option=2, UDMP_OPT=1, among others).

jamesmcc@hydro-c1[995]:~/WRF_Hydro/FRNG_NHD/4DAY/NHDPLUS/run.pmoTruth.6Hour> ls *RTOUT*DOMAIN*
201309120015.CHRTOUT_DOMAIN2  201309120215.CHRTOUT_DOMAIN2  201309120415.CHRTOUT_DOMAIN2
201309120030.CHRTOUT_DOMAIN2  201309120230.CHRTOUT_DOMAIN2  201309120430.CHRTOUT_DOMAIN2
201309120045.CHRTOUT_DOMAIN2  201309120245.CHRTOUT_DOMAIN2  201309120445.CHRTOUT_DOMAIN2
201309120100.CHRTOUT_DOMAIN2  201309120300.CHRTOUT_DOMAIN2  201309120500.CHRTOUT_DOMAIN2
201309120115.CHRTOUT_DOMAIN2  201309120315.CHRTOUT_DOMAIN2  201309120515.CHRTOUT_DOMAIN2
201309120130.CHRTOUT_DOMAIN2  201309120330.CHRTOUT_DOMAIN2  201309120530.CHRTOUT_DOMAIN2
201309120145.CHRTOUT_DOMAIN2  201309120345.CHRTOUT_DOMAIN2  201309120545.CHRTOUT_DOMAIN2
201309120200.CHRTOUT_DOMAIN2  201309120400.CHRTOUT_DOMAIN2  201309120600.CHRTOUT_DOMAIN2

So the files have the model start time.

jamesmcc@hydro-c1[1005]:~/WRF_Hydro/FRNG_NHD/4DAY/NHDPLUS/run.pmoTruth.6Hour> ncdump -v time_observation 201309120015.CHRTOUT_DOMAIN2  | head -70 
...
// global attributes:
        :Conventions = "Unidata Observation Dataset v1.0" ;
        :cdm_datatype = "Station" ;
        :geospatial_lat_max = "90.0" ;
        :geospatial_lat_min = "-90.0" ;
        :geospatial_lon_max = "180.0" ;
        :geospatial_lon_min = "-180.0" ;
        :time_coverage_start = "2013-09-12_00:00:00" ;
        :stationDimension = "station" ;
        :missing_value = -9.e+15f ;
        :stream\ order\ output = 1 ;
        :time_coverage_end = "2013-09-12_00:15:00" ;
data:

 time_observation = 261000, 261000, 261000, 261000, 261000, 261000, 261000, 
...

All the time_observations are equal 261000. And yes,

> as.POSIXct('2013-09-12 00:00:00')+261000
[1] "2013-09-15 00:30:00 MDT"

which corresponds to the difference of the model relative to the model RESTART time!
If all the hydro files are at this time... then OK, just fix the timestamps on the files. But the LSM is NOT at this time

jamesmcc@hydro-c1[1009]:~/WRF_Hydro/FRNG_NHD/4DAY/NHDPLUS/run.pmoTruth.6Hour> ncdump -v Times 201309120015.LDASOUT_DOMAIN3
...
 Times =
  "2013-09-12_00:15:00" ;

Add separate rtout frequency to hydro.namelist options

New feature request:
We have an internal rtout_factor in HYDRO_drv/module_HYDRO_drv.F that, for io_config_outputs=5, decreases the write frequency of RTOUT files. This is intended to save output file space for long runs, but is currently a bit of a hack and requires code changes to alter. The proper way to do this is really to add a separate write frequency in hydro.namelist for RTOUTs. In more general terms, could separate output frequency for 1d (smaller) vs. 2d (larger), or even add manual write frequency settings for each output file options.

Missing GW level in hydro restart

In gridded channel routing runs, z_gwsubbas is not being output in the HYDRO_RST file even when the bucket model is turned on.