Irrigation Module #959
Irrigation Module #959
Conversation
stefanocasirati
added
0 diff
|
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.
@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.
@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
...dComp/GEOSphysics_GridComp/GEOSsurface_GridComp/Utils/Raster/makebcs/make_bcs_questionary.py
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
@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.
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)
...cs_GridComp/GEOSsurface_GridComp/GEOSland_GridComp/GEOScatch_GridComp/GEOS_CatchGridComp.F90
Outdated
Show resolved
Hide resolved
| ! Add irrigation model imports | ||
| ! -------------------------------------------------------------------------- | ||
|
|
||
| if(CATCH_INTERNAL_STATE%RUN_IRRIG /= 0) then |
There was a problem hiding this comment.
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.
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
|
Note: GNU seems unhappy with some of the OpenMP pragmas, see: |
Thanks, Matt, for pointing this out. We'll have to sort it out. Not sure if it worked before I merged develop into the branch. Since the failure is fully with the irrigation module, the GNU error may have been there all along. |
…lid after application of irrigation water (GEOS_CatchGridComp.F90)
…rnal_specs) for clarity and consistency
|
@stefanocasirati : I just pushed several commits: Primarily, it's an attempt to make the names of the internals (irrigation model prognostics and parameters) clearer and more consistent. Prefacing each name with I think there was a bug in the handling of MIDS_LENGTH, see 43167ab I recognize that the renaming of the internals will create havoc with the bcs. To test these changes, we'd either need to regenerate the bcs or create a copy of the current ones and then surgically rename the impacted, irrigation-related nc4 variables. For now, though, this is probably premature. I haven't got to al the variables yet, and I still have questions re. the meaning of some variables. As of right now, I just pushed my commits, and I don't even know if everything builds ok. I'll keep working as time permits |
…lly resolved conflicts in make_bcs_questionary.py and mkCatchParam.F90; manually edited rmTinyCatchParaMod.F90 to fix merge conflict not detected by git auto-merge
Overview:
Repositories affected by updates:
_GEOSgcm_GridComp, GEOSldas_GridComp_
New Files:
Brief description:
New land BCs version:
v14 : v13 (i.e., NL3 + JPL veg height + PEATMAP + MODIS snow alb v2 + mean land elevation fix) + 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_modelThe 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