search

GEOS-ESM / GEOSana_GridComp

Repository containing code for data analysis for the GEOS Earth System Model data assimilation
Apache License 2.0
1 stars 3 forks source link

fix cris-npp outage of 2021; add GEOS-IT support (zero-diff) #71

Closed rtodling closed 2 years ago

rtodling commented 2 years ago

Fix for cris-npp shutoff/on 2021 case.

rtodling commented 2 years ago

This is zero-diff for cases before Oct 2021

rtodling commented 2 years ago

Thanks for checking Tom.

gmao-msienkie commented 2 years ago

I wouldn't say that this will "fix" the issue with CrIS-FSR NPP as your solution also will likely require a transfusion of bias coefficients.

rtodling commented 2 years ago

Thanks Jing

gmao-msienkie commented 2 years ago

For configuration file(s) for a specific system configuration, for example MERRA2 or in this case GEOSIT, I have always been wondering. Would it be easier for maintenance by adding a branch than adding a subdirectory? For example, we can have branches in parallel to develop, as parallel_develop/MERRA2_config, parallel_develop/GEOSIT_config, etc., where _config suggests that only a small collection of configuration files are (expected to be) different.

Just a thought.

In the case of MERRA2 the decision to use the regular DAS configuration or the MERRA2 configuration is done when the user runs 'fvsetup'. It may be too much of an inconvenience to have the user need to check out a new branch and possibly rebuild if they wish to switch between running a historical run versus running near real time. For the GEOSIT I think it is configured appropriately for a 3-D Var experiment and there may be some interest in being able to switch to that configuration via 'fvsetup' as well rather than having a separate build.

jing-guo commented 2 years ago

In the case of MERRA2 the decision to use the regular DAS configuration or the MERRA2 configuration is done when the user runs 'fvsetup'. It may be too much of an inconvenience to have the user need to check out a new branch and possibly rebuild if they wish to switch between running a historical run versus running near real time. ...

Indeed, if switching between configs after a build is a requirement, creating another config object would be a reasonable solution for the problem. I agree.