You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed a minor blemish in the GEOSldas job script (lenkf.j). When running Catchment, or when running CatchmentCN with fixed atmospheric CO2 concentration, the config parameter CO2_YEAR (from GEOS_SurfaceGridComp.rc) is set to a no-data value of -9999 initially.
The following block in lenkf.j then always changes CO2_YEAR whenever the simulation year changes:
This only makes sense when CO2_YEAR is not a no-data value. When CO2_YEAR is no-data, the above block should not change CO2_YEAR.
I suppose an if statement that checks the value of CO2_YEAR could be added inside the above block. If CO2_YEAR==-9999, then do not change the value of CO2_YEAR.
It looks like any value of CO2_YEAR<=0 is interpreted as no-data:
For Catchment ("MODEL=catch"), maybe it would be cleaner to remove the CO2_YEAR line from LDAS.rc during setup.
So far, I don't think this results in any errors in the simulations, but I think an error may eventually be made in the very long CatchCN spinup runs, which need to run for 1000s of years.
@gmao-jkolassa, does the above make sense to you? Do we still need the CO2_YEAR functionality? @weiyuan-jiang, assuming this makes sense to you and @gmao-jkolassa, please implement a fix.
Thanks!
The text was updated successfully, but these errors were encountered:
@gmao-rreichle Thanks for pointing this out! The suggested addition of an if-statement that checks the CO2_YEAR value makes sense to me.
Do we still need the CO2_YEAR functionality?
Yes, that is still needed for when we run simulations with transient CO2.
So far, I don't think this results in any errors in the simulations, but I think an error may eventually be made in the very long CatchCN spinup runs, which need to run for 1000s of years.
I am not sure this would lead to an error in the spinup simulations, since they are run with fixed CO2, but it cannot hurt to safeguard against this just in case.
I am not sure this would lead to an error in the spinup simulations, since they are run with fixed CO2, but it cannot hurt to safeguard against this just in case.
Thanks, @gmao-jkolassa. I now see that CO2_YEAR is not used when ATM_CO2=0 (fixed CO2), so there could not be an error during CatchCN spinup if you use ATM_CO2=0 then. But it's still ugly and confusing to keep changing CO2_YEAR during simulations when it's not even used.
Please add the if condition to lenkf_j_template.py so CO2_YEAR remains at -9999 if that's the initial value.
Also, for Catchment simulations, why not during setup remove all CatchCN-related rc parameters from LDAS.rc for clarity? (CO2_YEAR, ATM_CO2, DTCN, CO2, PRESCRIBE_DVG)
@weiyuan-jiang, @gmao-jkolassa:
I noticed a minor blemish in the GEOSldas job script (lenkf.j). When running Catchment, or when running CatchmentCN with fixed atmospheric CO2 concentration, the config parameter CO2_YEAR (from GEOS_SurfaceGridComp.rc) is set to a no-data value of -9999 initially.
The following block in lenkf.j then always changes CO2_YEAR whenever the simulation year changes:
GEOSldas_GridComp/GEOSldas_App/lenkf_j_template.py
Line 793 in 9d6d699
This only makes sense when CO2_YEAR is not a no-data value. When CO2_YEAR is no-data, the above block should not change CO2_YEAR.
I suppose an if statement that checks the value of CO2_YEAR could be added inside the above block. If CO2_YEAR==-9999, then do not change the value of CO2_YEAR.
It looks like any value of CO2_YEAR<=0 is interpreted as no-data:
https://github.com/GEOS-ESM/GEOSgcm_GridComp/blob/26d5600da3506bf257ba95d4a6d49a1b8f77c464/GEOSagcm_GridComp/GEOSphysics_GridComp/GEOSsurface_GridComp/GEOSland_GridComp/GEOScatchCN_GridComp/GEOScatchCNCLM40_GridComp/GEOS_CatchCNCLM40GridComp.F90#L6522
For Catchment ("MODEL=catch"), maybe it would be cleaner to remove the CO2_YEAR line from LDAS.rc during setup.
So far, I don't think this results in any errors in the simulations, but I think an error may eventually be made in the very long CatchCN spinup runs, which need to run for 1000s of years.
@gmao-jkolassa, does the above make sense to you? Do we still need the CO2_YEAR functionality?
@weiyuan-jiang, assuming this makes sense to you and @gmao-jkolassa, please implement a fix.
Thanks!
The text was updated successfully, but these errors were encountered: