Closes #70. Commit changes for PBL height #71
Conversation
mathomp4
added
Needs Lead Approval
There was a problem hiding this comment.
Yanqiu,
It seems to me you placed the pblh field in the less desirable place. it seems to me you added the field to the bkg.eta files instead of the bkg.sfc file. For one thing, PBLH is a 2d field that fits better w/in the context of bkg.sfc ... but more importantly is the fact that changing the bkg.eta has consequences that are too complex and long to explain here.
I suggest you revise all your changes and move PBLH from bkg.eta to bkg.sfc ...
in the context of this particular file (GSI_GridComp.rc.tmpl it means moving it from vars_bkgeta_file and vars_anaeta_file to vars_bkgsfc_file ... and we'll need to think (and add) a vars_anasfc_file; presently GSI does not produce such an output but it should be possible to come up w/ that. I can help you do this part since it will be not so straightforward.
|
Yanqiu, |
|
Ricardo,
Thanks for your emails. I just saw them. I didn’t receive an email from github or maybe I missed it, I will check my email.
I didn’t have a particular preference for pblh to be either in bkg.eta or bkg.sfc. But since ps and ts control variables are in bkg.eta (and many other surface variables which are not control variables in bkg.sfc), bkg.eta seems to be a better place to me. Are there any particular reasons that you think bkg.eta is less preferred for pblh? Also, Amal went with bkg.eta, she prepared initial restart files and ensemble files with pblh being stored in pbkg.eta. So, at first, I had thought that Amal wanted to separate the cases that have (pbkg.eta) or have no (bkg.eta) pblh for the DAS, and I changed accordingly more codes that hardwired “.bkg.eta” file names in the codes. Later, I simply used .bkg.eta for both cases.
If we need to move pblh from bkg.eta to bkg.sfc for the git version, in addition to GSI_GridComp.rc.tmpl you mentioned in your email, I will need to read the codes to see what other codes I will need to change.
Thanks,
Yanqiu
|
|
I will check why only two files changes were shown. Thanks Ricardo. |
|
hum, I am not sure what happened. It is shown the following when I did "mepo status": After I typed "mepo push GEOSadas GMAO_Shared GEOSana_GridComp", it is shown the followingPushed: GEOSadasBranch 'feature/yzhu/PBL_height' set up to track remote branch 'feature/yzhu/PBL_height' from '[email protected]:GEOS-ESM/GEOSadas.git'.
|
|
Ricardo, Please see below Matt's email. He confirmed that all my commits. have been pushed to GitHub. I need to make pull request for GEOSadas, GEOSana_Gridcomp and GMAO_Shared respectively. PS Matt's email: As far as I can see, all your commits have been pushed to GitHub. There is this PR: and then on GMAO_Shared I see this: GEOS-ESM/GMAO_Shared@release/cvs/GEOSadas-5_27_1_p2...feature/yzhu/PBL_height and GEOSana_Gridcomp there is: GEOS-ESM/GEOSana_GridComp@develop...feature/yzhu/PBL_height It's up to you to make the Pull Requests on all repositories where you want code to be merged. Mepo will only push, but it can't really do anything "fancy" on GitHub, just push/pull code. Matt |
|
Yanqiu, Unfortunately, PBLH will need to move the bkg.sfc. Only I know the complexity and the can of worms that adding to bkg.eta will be. I will look at the full PR - on all repos in consideration - when the above has been addressed. The change above will sip through the various repos related to this PR. Ricardo |
|
OK, thanks Ricardo, it is fine with me to move PBLH from bkg.eta to bkg.sfc in order to avoid any possible issues/complications. Please help with the part you mentioned above. Thanks in advance. |
|
Yanqiu, I have looked a little more closely about the suggestion to have PBLH moved to bkg.sfc ... indeed, quite sometime back I had already added PBLH to the bkg.sfc files (if you look at the output of x0042/43/44 all have PBLH in the file. But as I look more closely I am finding there will be some considerable challenges having the field in the the bkg.sfc files; one of which related to having to read the sfc fields in the ensemble part in GSI. So let me look again at what you have - with the field placed in the bkg.eta files ... I will look into what needs to be done to preserve some level of backward compatibility, I imagine (hope) you haven't done too much yet in trying to handle things from the bkg.sfc side. Sorry for flipping my mind. |
|
Ricardo, Thank you very much for looking into this closely. I haven't done anything with bkg.sfc, so no worries. You know GEOS better than me, so I will rely on your judgement for the bkg.eta/bkg.sfc decision. Yanqiu |
I pushed changes for the PBL height assimilation. Please help to review the code changes, and let me know if I need to make any modifications. Thanks in advance.