-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Irrigation Module #959
base: develop
Are you sure you want to change the base?
Irrigation Module #959
Conversation
The latest commits updated flood irrigation by differentiating it between furrow irrigation (now applied only to irrigated fractions) and flood irrigation (now applied only to paddy fractions). Output Variables: each variable is weighted based on the specific irrigated fractions: |
…lly resolved conflict in GEOS_CatchGridComp.F90)
…evelop (GEOS_CatchGridComp.F90)
allocate (IRRIGATION(NUM_CATCH), stat=status) | ||
VERIFY_(STATUS) | ||
if (NUM_CATCH == 1) then | ||
IRRIGATION(1) = MAPL_AddChild(GC, NAME='IRRIGATION'//trim(tmp), SS=IrrigationSetServices, RC=STATUS) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stefanocasirati: Note the addition of //trim(tmp)
here. Not sure if this is needed, but it's done for Catch and CatchCN, so probably better to add it for Irrigation as well
! imports from the Catchment[CN] gridded component.\\ | ||
! | ||
! Temporally and spatially varying irrigation model parameters are | ||
! from a binary data file.\\ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stefanocasirati: We should think about avoiding the binary files and use an nc4 file instead (if the text here is indeed correct)
GEOSagcm_GridComp/GEOSphysics_GridComp/GEOSsurface_GridComp/Shared/GEOS_SurfaceGridComp.rc
Outdated
Show resolved
Hide resolved
@@ -195,6 +195,8 @@ def ask_questions(default_grid="Cubed-Sphere"): | |||
"v10 : NL3 + PEATMAP + MODIS snow alb v2", \ | |||
"v11 : NL3 + JPL veg height + PEATMAP + MODIS snow alb v2", \ | |||
"v12 : NL3 + JPL veg height + PEATMAP + MODIS snow alb v2 + Argentina peatland fix", \ | |||
"v13 : NL3 + JPL veg height + PEATMAP + MODIS snow alb v2 + Irrigation", \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the irrigation parameters are simply an addition to what is currently in the "v12" bcs, it may be better to add the irrigation parameters to "v12", rather than create a new bcs version. The "v12" bcs can still be used without running the irrigation model (much like they can be used without exercising the MODIS snow albedo data).
Also, we should include the "Argentina peatland fix" in any new set of bcs (that is, use SOILBCS = 'HWSD_b'
in the config of the bcs -- see LBCSV in rmTinyCatchParaMod.F90)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stefanocasirati: Sorry for the slow progress. I added another minor commit and a few more inline comments. These later comments are getting more at the heart of what still needs work.
! Call the children's RUN methods (PHASE=2) | ||
!------------------------------------------ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the block below, the code loops through all children GCs and explicitly excludes VEGDYN from running again. I think this means that IRRIGATION is run again, even though it only has one run method. This may not change anything and is probably only slowing down the run a bit. Or do we need to call IRRIGATION twice? Not sure how things are connected and sequenced. The edited comment block in Lines 17-24 above summarizes my understanding of how IRRIGATION should work in this regard (which may well be wrong)
PLS_IN = PLS_IN + SPRINKLERRATE | ||
end where | ||
where (DRIPRATE > 0) | ||
RZEXC = RZEXC + DRIPRATE *DT |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updating a Catchment soil moisture prognostic requires a consistency check for the entire set of soil moisture prognostics (CATDEF, RZEXC, SRFEXC). If this consistency check is missing, it's possible that subroutine catchment(), which is called soon after the application of irrigation, will crash because the input soil moisture prognostics can represent an unphysical state. To be safe, we should probably add a call to "catch_calc_soil_moist()" immediately after applying drip/furrow/flood irrigation here.
! Add irrigation model imports | ||
! -------------------------------------------------------------------------- | ||
|
||
if(CATCH_INTERNAL_STATE%RUN_IRRIG /= 0) then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Irrigation is applied before the soil moisture analysis increments (if any). I'm not sure if the sequencing here matters. Since irrigation is a bit more part of the model than the analysis increments, perhaps it makes more sense to apply the analysis increments first and then apply the irrigation. Having said that, I wonder if this doesn't mean that we should calculate the irrigation amounts (i.e., run the IRRIGATION GridComp) only after the analysis increments have been applied. This requires more thought and work.
|
||
integer, parameter :: NX_gripc = 86400 | ||
integer, parameter :: NY_gripc = 43200, NY_GripcData = 36000 | ||
character*300, parameter :: GRIPC_file = '/discover/nobackup/projects/gmao/bcs_shared/make_bcs_inputs/land/irrigation/crop_fraction_data/v1/irrigtype_salmon2013.flt' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to fix the hard-coded "discover" paths throughout this file. I forget how exactly we do this for the other makebcs elements, but what's done there should also be done for Irrigation. This also implies adding the irrigation parameter input files to the "bcs_shared" location in the Discover project/gmao disk space
Overview:
Repositories affected by updates:
_GEOSgcm_GridComp, GEOSldas_GridComp_
New Files:
Brief description:
New land BCs version:
v13 : NL3 + JPL veg height + PEATMAP + MODIS snow alb v2 + Irrigation
The bcs generation package reads different irrigated area datasets and generates a new file "irrigation_IMxJM_DL.dat" containing, for each tile, a static: irrigation fraction, Paddy fraction, Rainfed fraction, crop irrigation fraction, crop irrigation type, crop planting and harvest dates, sprinkler fractions, drip fractions, flood fractions, and minimum and maximum LAI.
Irrigation module:
Adapted from:
feature/SM_irrigation_model
The irrigation module computes irrigation rates by applying three different irrigation schemes: sprinkler, drip, and flood (furrow). Irrigation is triggered based on location, growing season (Implemented alternative options: LAI-based and Crop Calendar-based), and soil moisture.
New Output Variables: each variable is weighted based on the specific irrigated fractions:
SPRINKLERRATE: sprinkler_irrigation_rate (kg m-2 s-1)
DRIPRATE: drip_irrigation_rate (kg m-2 s-1)
FLOODRATE: flood_irrigation_rate (kg m-2 s-1)
IRRLAND: total irrigation rate (kg m-2 s-1) = SPRINKLERRATE + DRIPRATE + FLOODRATE
LDAS nightly test