Changes for enabling GSD cloud analysis for ensemble runs#267
Conversation
chunhuazhou
requested review from
CurtisAlexander-NOAA,
JeffBeck-NOAA,
TrevorAlcott-NOAA,
christinaholtNOAA,
guoqing-noaa,
hu5970,
jaymes-kenyon and
terraladwig
as code owners
| l_conserve_thetaV=.true., | ||
| i_conserve_thetaV_iternum=3, | ||
| l_cld_bld=.true., | ||
| l_cld_bld=.false., |
There was a problem hiding this comment.
Do other applications need to turn off the cloud build?
There was a problem hiding this comment.
This commit is to save what I have for enabling the cloud analysis for the ensemble runs, where we were trying to have cloud clearing only (l_cld_bld=.false.). But the cloud analysis itself might not be ready yet, at least from my ensemble runs. So when it is really ready, we can always change this.
There was a problem hiding this comment.
@chunhuazhou We need try to avoid committing this kind of hardwired change only used for certain application. We will forgot it and other cloud analysis tests will use it for a while before someone notice difference. Please set up it up through the configuration step.
There was a problem hiding this comment.
This is in gsiparm.anl. I think it should be set in the config file instead of in the script.
There was a problem hiding this comment.
@chunhuazhou If you check ush/config.sh.3DRTMA_dev1, there is a section "GSI Namelist parameters configurable across differnt applications". You can follow those examples to make i_cld_bld configurable.
There was a problem hiding this comment.
Agreed. I overlooked this change when committing it.
And this is not the same as the gsiparm.anl as for the GSI analysis so it is a bit different here.
Should I open another PR to address this and that "ENS_TYPE" thing? I merged this PR too quickly.
There was a problem hiding this comment.
Opening a new PR works.
There was a problem hiding this comment.
Ok, will do. Thanks!
There was a problem hiding this comment.
@chunhuazhou We need try to avoid committing this kind of hardwired change only used for certain application. We will forgot it and other cloud analysis tests will use it for a while before someone notice difference. Please set up it up through the configuration step.
@hu5970 I have a similar concern on your potential manual changing "ln_vrfy" to "cp_vry" in realtime RRFS runs. Only you will remember that. It will lose change history track and will be easily ignored by others. My suggestion is to let this be configurable through the existed "do_nonvar_cldanal" option.
| cp_vrfy ${bkpath}/gfs_data.tile7.halo0.nc fv3_dynvars | ||
| cp_vrfy ${bkpath}/gfs_data.tile7.halo0.nc fv3_tracer | ||
| ln_vrfy -snf ${bkpath}/gfs_data.tile7.halo0.nc fv3_dynvars | ||
| ln_vrfy -snf ${bkpath}/gfs_data.tile7.halo0.nc fv3_tracer |
There was a problem hiding this comment.
The above 175-181 changes will apply to all applications, not only for ensemble runs. I think cloud analysis is not ready to run for the RRFS system as it degraded the short term forecasts. @hu5970 Am I correct?
I have a change to switch between ln_vrfy and cp_vrfy depending the "cloud analysis" option in the config file, but it is not contributed back yet. Maybe I can commit it back first.
There was a problem hiding this comment.
The cloud analysis is not ready for real-time test. I made lots of updates on both code and scripts recently.
But I think it is OK to make a link because the default assumption is we want cloud analysis to make impact on the forecast if we turn it on in configuration. We will manually turn it off for the further testing. I also suggest "do not add more option on cloud analysis". We should have usable cloud analysis soon.
There was a problem hiding this comment.
This is not turned on unless you have that option in config.sh. And currently it is turned off by default so it won't affect the other runs, I believe.
If you can have that option to switch between ln_vrfy and cp_vrfy in config.sh, that would be great!
In the original cloudanalysis script, it only copy over the files to the workdir but it doesn't copy the updated files back to INPUT/. This "ln_vrfy" option was to follow other DA set up.
There was a problem hiding this comment.
The cloud analysis is not ready for real-time test. I made lots of updates on both code and scripts recently. But I think it is OK to make a link because the default assumption is we want cloud analysis to make impact on the forecast if we turn it on in configuration. We will manually turn it off for the further testing. I also suggest "do not add more option on cloud analysis". We should have usable cloud analysis soon.
Looks fine to me if it will not bother real-time RRFS runs. So is the problem solved that a very short integration after cloud analysis will generate too much cloud conversion?
My original thought is add a kind of "yes_and_no" choice to the "do_nonvar_cldanal" option for those who wants to run cloud analysis but don't want to update the forecast IC. It will NOT add an extra option but utilize the existed "do_nonvar_cldanal" option. It works in my tests.
@hu5970
| analworkname="nonvar_cldanl" | ||
| fi | ||
| if [ ${ENS_TYPE} == "MEAN" ]; then | ||
| if [ ${RRFSENS_TYPE} == "MEAN" ]; then |
There was a problem hiding this comment.
A general question, why we would like to change "ENS_TYPE" to "RRFSENS_TYPE"? Is there a problem to continue using "ENS_TYPE"?
There was a problem hiding this comment.
There is another "ENS_TYPE" in the GSI analysis script, which was used for the ensemble for the hybrid analysis. Therefore I have to se a different name.
There was a problem hiding this comment.
Thanks. However, "rrfsens_type" and "ens_type" still look similar to me and I think it will also bring confusions to others. Would it be better to change "RRFSENS_TYPE" to "MEAN_OR_MEM", "MEM_TYPE" or "MEMBER_TYPE"? Just my 2 cents.
There was a problem hiding this comment.
We may want to change ENS_TYPE in GSI to ENS_TYPE4HYB and let real ensemble use ENS_TYPE.
There was a problem hiding this comment.
We may want to change ENS_TYPE in GSI to ENS_TYPE4HYB and let real ensemble use ENS_TYPE.
ENS_TYPE4HYB and RRFSENS_TYPE still look confusion to me. Another thought based on you idea is that we may simply change "ens_type" in GSI to "suffix" and let Chunhua keep using "ENS_TYPE" (or change to "MEM_TYPE").
There was a problem hiding this comment.
Now I think "MEM_TYPE" works better for this "MEAN" or "MEMBER" choice, than "ENS_TYPE".
What do we want to use for the "ENS_TYPE" in GSI run script?
There was a problem hiding this comment.
For GSI, I suggest to use "ftype" (i.e file_type)
…)" This reverts commit d2cbb58.
|
Sorry I approved everything so quickly, but this good discussion is making the changes better :) |
I appreciate your quick approval. Most of the time we need a quick action to move things forward. It was me making the merge too quickly. |
* Create rrfs.natlev-FAA130.params parameters used for PRDGEN process requested by FAA additional processes (subset, upscale) for IFI, GTG. and ATM requested by FAA * Update exrrfs_run_prdgen.sh subset & upscale of IFI, GTG, and ATM fields per FAA requests additional /fix/prdgen directory where parameters located for prdgen process needed by FAA
4 participants
DESCRIPTION OF CHANGES:
Changes for enabling GSD cloud analysis after EnKF analysis and before launching the forecast jobs, for ensemble runs.
TESTS CONDUCTED:
Tests done on Hera.
DEPENDENCIES:
DOCUMENTATION:
ISSUE (optional):
CONTRIBUTORS (optional):
Thanks to @hu5970 for his help on cloud analysis!