Skip to content
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

XHLAI not reset when DYNAMIC .EQ. SEASINIT in plant.for #41

Open
palderman opened this issue Oct 10, 2020 · 1 comment
Open

XHLAI not reset when DYNAMIC .EQ. SEASINIT in plant.for #41

palderman opened this issue Oct 10, 2020 · 1 comment
Projects

Comments

@palderman
Copy link
Contributor

When running DSSAT-CSM-CROPSIM-CERES-Wheat in seasonal mode, the XHLAI value is not reset when DYNAMIC .EQ. SEASINIT:

! -------------------------------------------------
! Wheat and Barley CSCER
CASE('CSCER')
CALL CSCERES_Interface (CONTROL, ISWITCH, !Input
& EOP, YREND, NH4, NO3, SNOW, SOILPROP, !Input
& SRFTEMP, ST, SW, TRWUP, WEATHER, YRPLT, HARVFRAC,!Input
& CANHT, HARVRES, KCAN, KEP, MDATE, NSTRES,PORMIN,!Output
& RLV, RWUMX, SENESCE, STGDOY, UNH4, UNO3, XLAI) !Output
IF (DYNAMIC .EQ. SEASINIT) THEN
KTRANS = KEP
KSEVAP = KEP
ELSEIF (DYNAMIC .EQ. INTEGR) THEN
XHLAI = XLAI
ENDIF

When SEASINIT matches PDATE, then this is not a big problem because the DYNAMIC .EQ. INTEGR will reset XHLAI to XLAI soon after simulation starts. However, if final XHLAI from a previous run is not small and SEASINIT is substantially before PDATE (e.g. 3 month spinup), then ET will be simulated much higher than it should be. I believe that this will be a potential problem for any model that (unlike CROPGRO, N-wheat, etc) does not directly calculate XHLAI. One solution that should work would be to modify the code for those models a la:

       IF (DYNAMIC .EQ. SEASINIT) THEN
          KTRANS = KEP
          KSEVAP = KEP
          XHLAI = XLAI
        ELSEIF (DYNAMIC .EQ. INTEGR) THEN
          XHLAI = XLAI
        ENDIF

This way the XHLAI gets reset to whatever the pre-planting value for that crop should be. Presumably the value would usually (always?) be 0 and we could code it up with that assumption, but allowing each model to set this seems like a more flexible option. @chporter @GerritHoogenboom, any thoughts?

@GerritHoogenboom
Copy link
Contributor

GerritHoogenboom commented Oct 11, 2020 via email

@chporter chporter added this to Needs triage in develop Jan 29, 2021
@chporter chporter moved this from Needs triage to MediumPriority in develop Jan 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
develop
  
MediumPriority
Development

No branches or pull requests

2 participants