GerritHoogenboom
commented
4 years ago Phil,
I can see where potential T is not calculated correctly. However, root water uptake = 0 so actual T should be 0 as well. Do you have an example in which the model showed a value for T prior to planting?
I just looked at the Plant routine and it is not handled well for the different crop modules. Maybe it should be handled up front for all crop modules.
Gerrit
On 10/10/2020 12:57 PM, palderman wrote:
[External Email]
When running DSSAT-CSM-CROPSIM-CERES-Wheat in seasonal mode, the XHLAI value is not reset when |DYNAMIC .EQ. SEASINIT|:
https://github.com/DSSAT/dssat-csm-os/blob/e4470f7113d91a11ef6c34b6f554b83248f8d4a7/Plant/plant.for#L332-L347 https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_DSSAT_dssat-2Dcsm-2Dos_blob_e4470f7113d91a11ef6c34b6f554b83248f8d4a7_Plant_plant.for-23L332-2DL347&d=DwMCaQ&c=sJ6xIWYx-zLMB3EPkvcnVg&r=t3kDP14kBwiCg5T0dTAewQ&m=sea8imAN1c79cQvjbsn213J8LM3TQD6VTfCqe8Esckg&s=6hqkb65yrF_e0tScjgvzTIZxxlMESFj-6SSXA96H6oQ&e=
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 https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_chporter&d=DwMCaQ&c=sJ6xIWYx-zLMB3EPkvcnVg&r=t3kDP14kBwiCg5T0dTAewQ&m=sea8imAN1c79cQvjbsn213J8LM3TQD6VTfCqe8Esckg&s=PiUuDt4ZA9HHnJIzA3-k9a1min0sKhw8eKW41vHzd20&e= @GerritHoogenboom https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_GerritHoogenboom&d=DwMCaQ&c=sJ6xIWYx-zLMB3EPkvcnVg&r=t3kDP14kBwiCg5T0dTAewQ&m=sea8imAN1c79cQvjbsn213J8LM3TQD6VTfCqe8Esckg&s=grwRcVxVENM-ArNQW_MPxCh9VZpwGCiwSNrQGAqwP_E&e=, any thoughts?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_DSSAT_dssat-2Dcsm-2Dos_issues_41&d=DwMCaQ&c=sJ6xIWYx-zLMB3EPkvcnVg&r=t3kDP14kBwiCg5T0dTAewQ&m=sea8imAN1c79cQvjbsn213J8LM3TQD6VTfCqe8Esckg&s=wo9L-WfzXFQ9zzmT-phrr5CzZb9yJFRJtrr8ebNr84I&e=, or unsubscribe https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AA774W6T65A4CAEAGHLG3HDSKCG7NANCNFSM4SLFWI7Q&d=DwMCaQ&c=sJ6xIWYx-zLMB3EPkvcnVg&r=t3kDP14kBwiCg5T0dTAewQ&m=sea8imAN1c79cQvjbsn213J8LM3TQD6VTfCqe8Esckg&s=Ad0r6YXe4sQMH7OYucnarX_Eh4zQyUApaVXIG_DlDso&e=.
--
Gerrit Hoogenboom Preeminent Scholar, Institute for Sustainable Food Systems Professor, Agricultural and Biological Engineering
184 Frazier Rogers Hall PO Box 110570 University of Florida Gainesville, Florida 32611-0570, USA +1 352-294-1036; Fax: +1 352-392-4092 gerrit@ufl.edu www.GerritHoogenboom.com http://isfs.institute.ifas.ufl.edu
When running DSSAT-CSM-CROPSIM-CERES-Wheat in seasonal mode, the XHLAI value is not reset when
DYNAMIC .EQ. SEASINIT:https://github.com/DSSAT/dssat-csm-os/blob/e4470f7113d91a11ef6c34b6f554b83248f8d4a7/Plant/plant.for#L332-L347
When SEASINIT matches PDATE, then this is not a big problem because the
DYNAMIC .EQ. INTEGRwill 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: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?