Updates for public release v2 - SRW App V1.0.0

[fossell]

This Issue will serve as place to address all needs/updates/issues with the upcoming public-v2/SRWv1.0.0 release branch. The branch "release/public-v2" was created 17 July 2020. All development/updates for this release should be done in this branch, not develop.

Tasks & Merges to develop to be considered for merge into release/public-v2:

1. Fix bug in MDL2STD_P.f. Use ampersand as line continuation character #153 (Bug/syntax fix)
2. update pointer to CMakeModules #156 (Update to cmake pointer)
3. Updates from release/gefs_v16: UPP WAFS update #111, Post ceilling #136, 1)Add changes of total cloud fraction for FV3 GFS; 2)Tweak DBZI. #142, Set 1 mb upper bound for searching EQ level in CAPE computation from … #149, and Add the wafs fix from Yali. #150. -- These will no impact on fv3sar and will not change results.
4. Replace cld_amt, the 3D cloud fraction from the GFDL mp with the same… #170 -- Instantaneous cloud fraction fix for FV3SAR needs to be added. - COMPLETE
5. Change version number/filename of modulefiles Odin and Stampede to v9.0.0 since they were updated? - dependent on implementation of upp versioning. Unify the public-v2 executable name #197
6. Will SRW use cmake or compile for UPP - Yes, eventually. (See conversation from Updated support on Odin & Stampede to use NCEPLIBS public-v2 release #194 )

[hertneky]

Posing a couple questions and I bug related to the control file for the UPP SRW release

1. Is the postxconfig-NT-fv3sar.txt the control file that the SRW will use?

2. If so what postcntrl.xml is used to create the above postxconfig?

3. There is an issue with the postxconfig-NT-fv3sar.txt for outputting the cloud fraction fields (e.g. low/mid/high) that needs to be fixed. The correct cloud fraction fields need to be switched in to output these correctly. These are correct in the postxconfig-NT-GFS.txt used in the MRW release.

[WenMeng-NOAA]

@hertneky The postxconfig-NT-fv3sar.txt is used by FV3SAR. The corresponding xml file is fv3sar.xml.

[fossell]

@mkavulich @jwolff-ncar @JeffBeck-NOAA - Can any of you address Tracy's (1)? Does SRW workflow use the postxconfig-NT-fv3sar.txt file in UPP repo release/public-v2 branch or is that file stored elsewhere in the workflow/app? We had an issue with this for MRW release, they grabbed a copy and stored it as a static file elsewhere, which caused confusion. Please let us know where the workflow for SRW will be obtaining the config file for product outputs. Thanks!

[JeffBeck-NOAA]

@fossell The SRW App workflow uses a fixed file version of postxconfig-NT-fv3sar.txt in regional_workflow/fix/fix_upp. It has been kept up to date with what's in EMC_post (I see we are currently one change behind, for line 4120).

[fossell]

@JeffBeck-NOAA - Thanks for the info, very helpful! So one thing we should be make sure we communicate moving forward is when that file changes on either of our ends. Tracy has a bug fix for that file that she's working on, for example, and we'll notify you when that update occurs. And if your team ends up changing products in the fix file as part of your workflow, we'd like those to get fed back into the repo too (this helps us keep documentation up to date as well).

[JeffBeck-NOAA]

@fossell We should probably just source it from EMC_post after we clone the repository, during the "generate" step of the workflow. That would make it much easier, since all changes would be required to occur in EMC_post. I can make a GitHub issue in regional_workflow to request this change.

[fossell]

@JeffBeck-NOAA - That sounds good, keeps us posted if there is anything we can help with on our end.

[jwolff-ncar]

@fossell @JeffBeck-NOAA We discussed if a user wants to modify UPP to output different fields/levels/etc. today in our SRW app release documentation focus meeting. It is generally straight forward for this to happen but the user would need to use the xml file to generate a new flat txt file. In that case the user would want to use the new file they created, not the one from the repo. We would need to support this in the workflow. Is that possible?

Also adding @hertneky and @gsketefian so they see the response as they were on the call where this came up and need to know the discuss/decision.

[fossell]

@jwolff-ncar - Agreed, this is definitely a feature we'd like users to be able to leverage and UPP team intends to support it as well...this should be included eventually in documentation as well as for future trainings. It's definitely doable, but the user needs to use a scripts available in the UPP repo to create the text file from their modified xml file, and then place that new text file in the proper SRW workflow location. I'm not sure if it'd be worthwhile to make copies or sync those scripts in a certain part of your workflow (like you already do with the default flat text file) or if they should remain in UPP repo. There are definitely pros/cons to both. We can discuss more as a group if you want?

[JeffBeck-NOAA]

@jwolff-ncar My latest PR removes the UPP fixed files that we had in regional_workflow and sources the XML/text file from EMC_post for the FV3-LAM. If we want to allow users to modify the XML and create their own flat files, I wonder if the best way to handle that is from within the cloned EMC_post directory? If there are plans for the UPP team to support this feature, I think it would make sense to do it that way.

[jwolff-ncar]

My biggest concerns are:

1. We may not want users to overwrite the default and it would be nice if they could point to a new file when the workflow is generated
2. We need to figure out where to document how to do this and carefully consider this given it is different for the SRW and MRW applications
3. Other concerns that are not obvious to me at this point!

[hertneky]

1. Agreed - there should be a way to specify the name of the txt flat file somewhere. Note that when creating a new flat file, the user can specify the name of it in the makefile, therefor avoiding overwriting the default.

2. I think the instructions should be in their respective app documentations (e.g. where the file/path pointing to the file lives - will depend on app). The UPP documentation includes a generic how-to for creating a new flat file and can be referenced for those particular instructions.

[fossell]

I agree with @hertneky's points, we've talked about this a lot recently and @hertneky has a good feel for how to handle this feature for both and future apps.

[jwolff-ncar]

I have no problem with this. I just want to make sure that the regional workflow can point to a user specified (generated) file. We can make a new issue in that repository to cover this point.

[JeffBeck-NOAA]

@jwolff-ncar I think a good option would be to create a user-definable variable in config_defaults.sh, maybe a path to the user's new flat file, telling the workflow to use that instead of sourcing from EMC_post.

[fossell]

SRW v1.0.0 has been released using branch release/public-v2 of UPP.