Fixed gross errors for 2m q and T obs

[ClaraDraper-NOAA]

Resolves issue g-w issue #.

[ClaraDraper-NOAA]

@jswhit2 @RussTreadon-NOAA Can one of you please confirm which files I need to update to have the changes go through to v17 workflow?

I updated the merged_convinfo file in the main branch. However, in v17 we're calling the buildinfo program with a date argument. Should I then be updating the date-name files too? Or are they re-generated from the merged_convinfo?

I'm confused by the branches and date-name files in general, as the comments say:

• the gfsv17_historical branch reproduces the operational GSI info files for 20220527 to the present.
• main uses all the instruments as soon as they are usable (sooner than was done in ops) and also uses some re-processed data.

Above is consistent with the files I see in the repo in each branch (i.e., main branch only has one file; gfsv17_historical branch has a bunch of files named by date). However global_workflow (default, and those used in v17) is using the main branch, yet I'm seeing the files with the date-names - so I'm not sure how these are generated/cloned.

[ClaraDraper-NOAA]

@jswhit2 @RussTreadon-NOAA Can one of you please confirm which files I need to update to have the changes go through to v17 workflow?

I updated the merged_convinfo file in the main branch. However, in v17 we're calling the buildinfo program with a date argument. Should I then be updating the date-name files too? Or are they re-generated from the merged_convinfo?

I'm confused by the branches and date-name files in general, as the comments say:

• the gfsv17_historical branch reproduces the operational GSI info files for 20220527 to the present.
• main uses all the instruments as soon as they are usable (sooner than was done in ops) and also uses some re-processed data.

Above is consistent with the files I see in the repo in each branch (i.e., main branch only has one file; gfsv17_historical branch has a bunch of files named by date). However global_workflow (default, and those used in v17) is using the main branch, yet I'm seeing the files with the date-names - so I'm not sure how these are generated/cloned.

@jswhit

[RussTreadon-NOAA]

Great question @ClaraDraper-NOAA . I am not familiar enough with build_gsinfo to answer your question. Adding @CatherineThomas-NOAA and @ADCollard to see if then can answer your question.

[RussTreadon-NOAA]

Now I'm confused.

It seems GSI-fix points at gfsv17_historical, not main.

To which branch or branches should our recent set of GFS v17 related PRs be going? main, gfsv17_historical, both?

[jswhit]

@RussTreadon-NOAA and @ClaraDraper-NOAA: The parallels use the gfsv17_historical branch, which aims to reproduce the operational configs back to 20220527. The main branch aims to use obs as soon as possible (earlier than the operational choices in most cases).

I can merge this PR (to update the merged_convinfo file), and then propagate that change to the date-versioned files in the gfsv17_historical branch (and then create another PR for GSI-fix to update the hash).

[ClaraDraper-NOAA]

@RussTreadon-NOAA and @ClaraDraper-NOAA: The parallels use the gfsv17_historical branch, which aims to reproduce the operational configs back to 20220527. The main branch aims to use obs as soon as possible (earlier than the operational choices in most cases).

I can merge this PR (to update the merged_convinfo file), and then propagate that change to the date-versioned files in the gfsv17_historical branch (and then create another PR for GSI-fix to update the hash).

Thanks Jeff - is this the usual process? In that, to make an update we update the merged file, and you propagate it?

[RussTreadon-NOAA]

Thank you @jswhit for explaining the difference between main and gfsv17_historical. GSI-fix/build_gsinfo-fix should point at gfsv17_historical ... as it currently does. Whatever way most easily gets the changes we want into GFS v17 works for me.

[RussTreadon-NOAA]

Approve. These changes are needed in main and in gfsv17_historical.