smwesten-usgs / swb2 Goto Github PK

Is this problem caused by the presence of -9999 values ( no data) within the file?

** FATAL ERROR - HALTING SWB **

Illegal or missing values in integer grid file: input\flow_direction.asc

Needed to ensure compatibility with previous versions.

As of commit ffa43e7, FIRST_DAY_OF_GROWING_SEASON and LAST_DAY_OF_GROWING_SEASON are handled in module 'growing_season.F90'. These variables are still declared in 'interception_bucket.F90' and should be removed.

Glen Champion writes:

Based on what I can tell, I don’t think there are differences in the routing between different versions of SWB2. I think there is the same bug in the routing in all versions. I got the same results using the executable provided with the swb2_examples (which you updated on 2/2/2018), version 2.0.2, version 2.2.0, and my own compilation of version 2.3. I provided examples of errors in the output from the simple routing example in the email. Since the example is so small, you can also just extract ASCII grids of runoff and runon, look at them side by side with the D8 grid, and see, for example, that there are cells that should have runon that have none.

There is no problem with the information in the routing table, the problem is that the routing isn’t sequenced according to the sort order (See key code snippets below).

        Module daily_calculation

28  subroutine perform_daily_calculation(cells)
. . .
82    do jndx=1, ubound( cells%sort_order, 1 )
. . .
86      indx = cells%sort_order( jndx )
. . .
222       ! rejected net_infiltration + runoff will be routed downslope if routing option is turned on
223        call cells%calc_routing( index=indx )

Ok, the index passed to the calc_routing process is the cell_index that corresponds to jndx sort order.

        Module model_domain

1736  subroutine model_calculate_routing_D8( this, indx )
. . .
1750    cell_index    = get_cell_index( indx )
1751    target_index  = get_target_index( indx )

This is looking up the cell_index and target_index using the cell_index, but the sort-order index is what these procedures should use (i.e., jndx in perform_daily_calculation). So, the cell_index and target_index variables will not be the cells that you want to be computing right now, except if the cell_index is a headwater cell or other special circumstances in the routing table. Now, when calculating the runon to the target index, the runoff and rejected infiltration may not have yet been computed for the cell_index.

1765           this%runon( target_index ) =                                               &
1766              this%runon( target_index )                                          &
1767            + this%runoff( cell_index )                                           &
1768            + this%rejected_net_infiltration( cell_index )

The fix is to change indx to jndx in line 223 of the daily_calculation module. When I made that change, the runon for each cell is what it should be.

Root growth code is currently commented out. Needs to be included and tested.

Hi, I have some issues about No Data, I'm using SWB CODE 1.0:

• In my study area there are No Data pixel, If i put -99999 as No Data in the .asc files (Soil Group, Land Use, Available water capacity, flow direction), the SWB code returns always Error.

• Same problem if I work with climate at single station. I have not the value of relative humidity, so if i put -99999 in that cells, the SWB code returns an Error.

• If I work with multiple grid climate stations, how should i write this parameter in the SWB code?

• I'm working with mm and °C data. So, how can i convert these in inch and F directly writing it in the code?

The image is an example of the -99999 error with the .asc files.

Thank you.

This is pretty low priority, as I'd like to eliminate CMake altogether and use Meson. Appears to be triggered because CMake doesn't know where to find module files...

---------------------
compilation aborted for F:\projects\swb_development\git\swb2\test\unit_tests\test_FAO56_functions.F90 (code 1)
NMAKE : fatal error U1077: 'C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin\intel64\ifort.exe' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\bin\HostX64\x64\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\bin\HostX64\x64\nmake.exe"' : return code '0x2'
Stop.

A recently encountered netCDF file revealed a weakness in the algorithm used to tie row and column numbers to real-world coordinates. The original code was from the days before netCDF was even an input option in SWB. When using Arc ASCII grids as input, it is safe to assume that one can calculate the coordinate value of a cell from the row/column number and the cell size, along with the coordinates of the origin.

The netCDF file encountered features continuously varied grid cell sizes from north to south; this caused the simple coordinate calculation method to fail spectacularly. The solution was to use the coordinates from the netCDF file lon and lat variables directly, rather than assuming that the coordinates can be calculated. As a bonus, this seems to ripple through the code in such a way that the grids no longer need to be 'flipped' on input, but can be read as is. This needs to be tested and verified with a sample of in-the-wild netCDF files.

I have two questions about the land use table:-
First, is the assumed value of the impervious area entering in the calculations? If not, then what is the alternative?
Second, what is the interception unit which will be filled in the land use table? and is there a reference for interceptions values?

The following segfault is triggered when the 'ROOTING_DEPTH_METHOD' is set to 'DYNAMIC' but the 'CROP_COEFFICIENT_METHOD' is set to 'NONE'. The reason for the segfault is that the FAO-56 crop coefficients must have been read in and processed in order for the code in 'rooting_depth__FAO56' to function correctly.

==> need to add guard code to ensure that this incompatible set of options bombs with an actual informative error message.

Transforming gridded data in file: "climate_ncfile/tmax_EOBS_2014.nc"
 FROM: '+proj=utm +zone=32 +datum=WGS84 +units=m +no_defs'
 TO:   '+proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=1500000 +y_0=0 +ellps=intl +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 +units=m +no_defs'
At line 46 of file /mnt/f/projects/swb_development/git/swb2/src/rooting_depth__FAO56.F90
Fortran runtime error: Index '45' of dimension 1 of array 'kcb_method' above upper bound of 0

Error termination. Backtrace:
#0  0x7fb2ad311d1d in ???
#1  0x7fb2ad312825 in ???
#2  0x7fb2ad312bca in ???
#3  0x558d9a47c083 in __rooting_depth__fao56_MOD_update_rooting_depth
        at /mnt/f/projects/swb_development/git/swb2/src/rooting_depth__FAO56.F90:46
#4  0x558d9a401988 in __model_domain_MOD_model_update_rooting_depth_fao56
        at /mnt/f/projects/swb_development/git/swb2/src/model_domain.F90:3268
#5  0x558d9a4b3115 in __daily_calculation_MOD_perform_daily_calculation
        at /mnt/f/projects/swb_development/git/swb2/src/daily_calculation.F90:42
#6  0x558d9a452afa in __model_iterate_MOD_iterate_over_simulation_days
        at /mnt/f/projects/swb_development/git/swb2/src/model_iterate.F90:41
#7  0x558d9a3d94f4 in MAIN__
        at /mnt/f/projects/swb_development/git/swb2/src/main.F90:280
#8  0x558d9a3d98d0 in main
        at /mnt/f/projects/swb_development/git/swb2/src/main.F90:12

SWB 1.0 has separate irrigation application efficiencies for surface water and groundwater fractions; SWB 2.0 has only a single irrigation application efficiency value.

The program will continue to process a single-point weather data file even if the required header labels are not found. This results in phantom data values being fed into SWB, essentially whatever nonsense values happen to be in the memory space that was allocated for the precip or temperature data.

Failure example:
A file with
date precip tmin tmax
for the header was fed into the program. The run continued, although no precipitation data were read in (it was looking for a column of data labeled 'prcp').

How do I solve this problem?

** FATAL ERROR - HALTING SWB **

Grid cell size entered in the control file (227.7)
does not match calculated grid cell size (227.7).
Check the control file.

fortran module: D:\SMWData\Source_Code\swb\src\control.F90
module line number: 211

A user reports:

I would like to use the Horton interception method, but for some reason more water is added to the system when I use this method. When I use the github version of swb2, total ET exceeds gross precipitation regardless of whether the initial soil moisture is 0 or 100%. When I use the version of swb2 you sent *****, annual ET still exceeds precipitation across about 1/3 of the model area (mostly in uplands) when initial soil moisture is 0%. I also tried running the same models using the Bucket Interception method and got much lower and more reasonable ET values, but they still differ slightly between the two swb2 versions, and ET from swb2 is notably higher than the same model run with the original swb.

A user writes:

When I run the model if I do not have a column in the irrigation lookup table that specifies the 'fraction of irrigation from groundwater' it will not run. However, I cannot find any documentation describing this attribute. So I am wondering how the model uses the fraction of irrigation from groundwater and the irrigation efficiency columns to calculate an overall irrigation efficiency for each grid cell, and what it assumes the efficiency is for surface water irrigation?

This parameter was active and used in SWB version 1.0, but is inactive in SWB 2.0. In other words, although the code looks for fraction_of_irrigation_from_groundwater, these parameter values are as yet unused.

==> Need to port SWB 1.0 code for tracking irrigation water source to SWB version 2.0.

A user reports:

I’m trying to run SWB[2] as simply as possible providing just a table of precipitation and minimum and maximum temperature. However, I’m encountering errors. Is there an example of using SWB version 2 with tabular climate inputs? The only two examples I have seen both use gridded datasets.

Somewhere along the way, 'L-shift' was introduced as a parameter in order to allow parameter estimation to take place by 'shifting' the Kcb curve relative to the planting date. While this is potentially nice, there is no real reason to have it, since this can be done external to the model without introducing a 'shift' parameter. Confusing and potentially undocumented?

Certain netCDF files found in the wild, perhaps written/munged by the Python xarray package, end up with time being encoded as a 64-bit integer. Not sure what the use case is for a 64-bit integer time value, but there you have it. SWB currently handles time encoded as short, int (int32), float (32-bit real), and double (64-bit real) values.

A recent encounter with CONUS404 data processed with xarray resulted in the following CDL:

netcdf ilrb_CONUS404_T2MIN_20200101_to_20200131__compressed { dimensions: time = 31 ; x = 487 ; y = 516 ; variables: int64 time(time) ; string time:units = "days since 1979-10-01" ; string time:calendar = "proleptic_gregorian" ; double x(x) ; x:_FillValue = NaN ; string x:_CoordinateAxisType = "GeoX" ; string x:long_name = "x coordinate of projection" ; x:resolution = 1000. ; string x:standard_name = "projection_x_coordinate" ; string x:units = "metre" ; string x:axis = "X" ; double y(y) ; y:_FillValue = NaN ; string y:_CoordinateAxisType = "GeoY" ; string y:long_name = "y coordinate of projection" ; y:resolution = 1000. ; string y:standard_name = "projection_y_coordinate" ; string y:units = "metre" ; string y:axis = "Y" ; int crs ; string crs:crs_wkt = "PROJCS[\"unknown\",GEOGCS[\"unknown\",DATUM[\"unknown\",SPHEROID[\"unknown\",6370000,0]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.0174532925199433]],PROJECTION[\"Lambert_Conformal_Conic_2SP\"],PARAMETER[\"latitude_of_origin\",40],PARAMETER[\"central_meridian\",-97],PARAMETER[\"standard_parallel_1\",30],PARAMETER[\"standard_parallel_2\",60],PARAMETER[\"false_easting\",0],PARAMETER[\"false_northing\",0],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]" ; crs:semi_major_axis = 6370000. ; crs:semi_minor_axis = 6370000. ; crs:inverse_flattening = 0. ; string crs:reference_ellipsoid_name = "unknown" ; crs:longitude_of_prime_meridian = 0. ; string crs:prime_meridian_name = "Greenwich" ; string crs:geographic_crs_name = "unknown" ; string crs:horizontal_datum_name = "unknown" ; string crs:projected_crs_name = "unknown" ; string crs:grid_mapping_name = "lambert_conformal_conic" ; crs:standard_parallel = 30., 60. ; crs:latitude_of_projection_origin = 40. ; crs:longitude_of_central_meridian = -97. ; crs:false_easting = 0. ; crs:false_northing = 0. ; string crs:spatial_ref = "PROJCS[\"unknown\",GEOGCS[\"unknown\",DATUM[\"unknown\",SPHEROID[\"unknown\",6370000,0]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.0174532925199433]],PROJECTION[\"Lambert_Conformal_Conic_2SP\"],PARAMETER[\"latitude_of_origin\",40],PARAMETER[\"central_meridian\",-97],PARAMETER[\"standard_parallel_1\",30],PARAMETER[\"standard_parallel_2\",60],PARAMETER[\"false_easting\",0],PARAMETER[\"false_northing\",0],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]" ; double T2MIN(time, y, x) ; T2MIN:_FillValue = NaN ; string T2MIN:cell_methods = "time: point" ; string T2MIN:grid_mapping = "crs" ; string T2MIN:long_name = "Daily minimum temperature at 2 meters" ; string T2MIN:standard_name = "air_temperature" ; string T2MIN:units = "K" ; string T2MIN:coordinates = "x y" ; }

Running SWB with this file results in a crash at about line 2892 owing to the fact that there is no code to handle a int64 variable in this manner.

Commit 01596a0 added code in an attempt to prevent data changing on a monthly basis from having ADD_OFFSET and SCALE_FACTOR applied daily. Unfortunately, this has broken proper operation when using daily data.

SWB 1.0 cached a copy of the downhill flow routing solution; the downhill solution was then read from the cached copy for subsequent runs. SWB 2.0 still recalculates this each time the code is executed.

How do I solve this problem?
Is there an example with full data for multiple stations?

** FATAL ERROR - HALTING SWB **

Cannot read integer data value for ending year of simulation

Need to reconcile the terminology for this grid between SWB 1.0 and SWB 2.0

A user writes:

About the table vs grid, I also tried PERCENT_PERVIOUS_COVER TABLE and PERCENT_PERVIOUS_COVER_METHOD TABLE
while supplying the info with the lookup table. (Column: Percent_Pervious_Cover), but none seems to work. I could also use FRACTION_CANOPY_COVER as input from the table, but same result as for pervious cover. No worries, I have a script that generates the pervious_cover and canopy_cover grid using the landcover grid, so I am flexible to change both. However, it probably would be more user friendly if the option exists that all these things could be supplied from the table.