Customizing UPP output - Githubissues

fossell commented 4 years ago

UPP team now has procedures for adding/modifying the requested output fields from UPP within the MRW app. @hertneky is leading this effort and plans to present this information in the upcoming training for MRW this fall. As such, we'd like to include this info in the v1.1 documentation.

The content itself for app documentation will be minimal since the bulk of the procedures are in the general UPP Users Guide and we will direct the user to those sections.

We are under the impression that this content will likely go in section 4.2.3 of the MRW app users guide, but would welcome opinions. @hertneky will provide a sample of the new content for the team to review and suggest best place to include.

Also need to update Section 7.11 to modify the FAQ regarding this feature to point to section with this information.

hertneky commented 4 years ago

I think section 4.2.3 would be a good spot for this type of information. I have only tested modifying the UPP parameter files for use in MRW on a pre-configured machine. These are the instruction that I have put together. This is done manually and does not have a handy command/script within cime to perform this change.

If on a pre-configured machine, where EMC_post is in a pre-built, centralized location, the user will need to clone EMC_post on there own, where they will then have access to the necessary scripts for modifying the flat text file (postxconfig-NT-GFS.txt/postxconfig-NT-GFS-F00.txt).
The user will then follow the directions in the UPP Users' Guide (https://upp.readthedocs.io/en/latest/InputsOutputs.html#control-file) to modify the user-friendly xml file (postcntrl_gfs.xml/postcntrl_gfs_f00.xml) to add/remove fields/levels and then remake the flat text file.
Assuming the user has already cloned the UFS MRW code and scripts, they will need to edit the path(s) pointing to the location of the new flat text files. In the configuration script:

my_ufs_sandbox/src/model/FV3/cime/cime_config/buildnml

search postxconfig1/postxconfig2, which are paths pointing to the postxconfig-NT-GFS.txt/postxconfig-NT-GFS-F00.txt, respectively. Only modify the path pointing to your modified flat text file. For example, change:

input_files["postxconfig1"] = [os.path.join(NCEPLIBS_DIR,"share","postxconfig-NT-GFS.txt"), "ln", "postxconfig-NT-GFS.txt"]

to

input_files["postxconfig1"] = ["/path/to/user/postxconfig-NT-GFS.txt", "ln", "postxconfig-NT-GFS.txt"]

The user may then create/setup/build/run their case as usual and post will use the new *.txt files.

ligiabernardet commented 4 years ago

@arunchawla-NOAA @mvertens Pls review this proposed enhancement. With this addition the user will be able to customize output files (which was feedback we received via Graduate Student Test). The only con is that modifications are outside of CIME and, in preconfigured platforms, require that the user clone the post cone.

arunchawla-NOAA commented 4 years ago

@hertneky can EMC-Post read the xml file as an input file (I understand that it is slower) but for public release speed is not that major a concern so instead of following this convolutes step to create flat files, it may be better to just be able to use the xml files

fossell commented 4 years ago

@arunchawla-NOAA - It's not that simple, the read routines has been reconfigured to read in the flat text file. I don't think the xml read routine has been kept up to date. Actually I don't think it even exists in the code anymore. So unfortunately we're stuck with the convoluted steps to create flat files. Though, once you pull the EMC_post repo and have the scripts and are familiar, it is relatively simple to create a new flat file.

uturuncoglu commented 4 years ago

@ligiabernardet @arunchawla-NOAA @hertneky I implemented a way in CIME interface to use user custom generated flat files in the post. Simply, user need to place his/her custom flat files (postxconfig-NT-GFS-F00.txt , postxconfig-NT-GFS.txt) to CaseDocs directory under CIME case directory. CIME will look those files and if they exist, it will comply to run directory rather than linking files form NCEPLIBS. Is this approach fine for you? I also modify the External.cfg file to checkout EMC_post 1.1.0 tag to src/post directory. Let me know if you need any other changes or suggestions.

ligiabernardet commented 4 years ago

Works for me. I assume the flat file in CaseDocs directory can be a link to somewhere else where the user has the actual file.

On Tue, Aug 25, 2020 at 11:50 AM Ufuk Turunçoğlu notifications@github.com wrote:

@ligiabernardet https://github.com/ligiabernardet @arunchawla-NOAA https://github.com/arunchawla-NOAA i implemented a way in CIME interface to use user custom generated flat files in the post. Simply, user need to place his/her custom flat files (postxconfig-NT-GFS-F00.txt , postxconfig-NT-GFS.txt) to CaseDocs directory under CIME case directory. CIME will look those files and if they exist, it will comply to run directory rather than linking files form NCEPLIBS. Is this approach fine for you? I also modify the External.cfg file to checkout EMC_post 1.1.0 tag to src/post directory. Let me know if you need any other changes or suggestions.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ufs-community/ufs-mrweather-app/issues/174#issuecomment-680177208, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE7WQAXKBIYISRKL7RYBR4TSCP2WPANCNFSM4QGLUBMQ .

hertneky commented 4 years ago

This will work as well. Just to be clear, this method requires the user to have created the case workflow. Then they would place the new parm file in the CaseDocs dir in the workflow directory. Then the user would setup/build/run the case as usual and it would use that new parm file? Correct?

uturuncoglu commented 4 years ago

@ligiabernardet I did not test with link but in theory it must work. It just copy the file to the run directory.

@hertneky yes, the CIME case need to be defined by including post step (--workflow ufs-mrweather). Then, user could use the regular steps to build and submit the case. If the flat file is okay, then post will use the custom flat files and create desired output.

Once, the app is ready, I'll update the issue page and you could try.

hertneky commented 4 years ago

@uturuncoglu thanks. Assuming the user would need to keep the name of the files the same (postxconfig-NT-GFS-F00.txt and postxconfig-NT-GF.txt) and that if they altered the names, it would then grab these from the pre-installed library location? Is this of any concern? Is there a place in a log file stating path of the parm files used. It was also clear to me when I was testing this that, depending on the forecast hour (f00 or not), it would link the appropriate parameter file into the workflow run directory as postxconfig-NT.txt, where post is run. So, it would still do this same thing just linking from the new CaseDocs location?

uturuncoglu commented 4 years ago

@hertneky yes, you need to use same convention. So, you need to name files as postxconfig-NT-GFS-F00.txt and postxconfig-NT-GF.txt. I could add the log to CIME side and when you build or submit the case, you could see the files that are placed in the run directory. Yes, in run directory the used file is lined as postxconfig-NT.txt. This is a part of post script implemented in CIME workflow. So, just place the postxconfig-NT-GFS-F00.txt and postxconfig-NT-GF.txt files to CaseDocs then everything will work.

hertneky commented 4 years ago

@uturuncoglu thanks for the confirmation - this all sounds good. I think a simple statement in the log stating the path of the config being used is good to have, that way the user can confirm it is getting their modified config.

uturuncoglu commented 4 years ago

@hertneky sure, I'll add the log.

hertneky commented 4 years ago

@uturuncoglu Quick question for clarification. When CIME looks for the new flat text files, does it look for both the postxconfig-NT-GFS.txt AND postxconfig-NT-GFS-F00.txt at the same time at the beginning or does it look individually for the appropriate one, based on forecast lead time, over the course of the run. For example, do both need to be present in CaseDocs in order for this to work properly OR if the user only modifies one and places only that one in CaseDocs, say the postxconfig-NT-GFS.txt, will CIME use the one placed in CaseDocs and the other, in this case postxconfig-NT-GFS-F00.txt, from NCEPlibs, or will it do something else?

uturuncoglu commented 4 years ago

@hertneky CIME looks them and replaces with the default one. In theory, you could use the default one for postxconfig-NT-GFS-F00.txt and custom one for postxconfig-NT-GFS.txt or vice versa but I did not try by myself. The post template script handles which one will be used for the current time step. So, the first time step uses the one with F00 suffix.

fossell commented 4 years ago

@uturuncoglu Thanks for the clarification. I think we can test some of this just to see what the behavior is. As long as there is log output somewhere to know exactly which path/file was used for each forecast hour (or at least one output for F00 and one for the others), then that will help the user and our team to troubleshoot when things go wrong or the user fails to put their new custom files in the appropriate place. Let us know when we can clone the app and test this new feature, thanks!

uturuncoglu commented 4 years ago

@fossell sure. I am waiting for @climbfuji to update the modules in the model and I just want to test one more thing. Then, I'll update the app and you could try to test it.

uturuncoglu commented 4 years ago

@ligiabernardet @fossell @hertneky We decided to change the directory for custom flat files. It was CaseDocs before but that is for output files for case not input and now we are using SourceMods/src.ufsatm for this purpose. Please let me know what do you think?

ligiabernardet commented 4 years ago

Sounds good to me.

On Fri, Aug 28, 2020 at 12:13 AM Ufuk Turunçoğlu notifications@github.com wrote:

@ligiabernardet https://github.com/ligiabernardet @fossell https://github.com/fossell @hertneky https://github.com/hertneky We decided to change the directory for custom flat files. It was CaseDocs before but that is for output files for case not input and now we are using SourceMods/src.ufsatm for this purpose. Please let me know what do you think?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ufs-community/ufs-mrweather-app/issues/174#issuecomment-682346187, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE7WQARA6OKFC67IF2XELNLSC5DE7ANCNFSM4QGLUBMQ .

hertneky commented 4 years ago

Seems okay to me as well - I will change it in the documentation.

hertneky commented 4 years ago

Testing v1.1 update complete for customizing UPP on Cheyenne

Steps

followed Ufuks steps to clone, checkout, get externals, create case for v1.1
for UPP param file customization
- cd to src/post/parm directory
- make copies of original postcntrl_gfs(_f00).xml and postxconfig-NT-GFS(-F00).txt
- modify both xmls (removed all cape/cin fields in both)
- type 'make' - remakes both txt files (takes about 10 secs)
- copy both new txt files to $caseDir/SourceMods/src.ufsatm
setup/build/run case

Log shows path where it is getting the modified parm files correctly. UPP output does not include CAPE/CIN variables and therefore the test was a success!

Additional test - Successful:

Placed only the modified postxconfig-NT-GFS-F00.txt in the /SourceMods/src.ufsatm directory. Workflow used that file for F00 and the default NCEPlibs parm for all other forecast hours - output reflects this as well. F00 did not have CAPE/CIN vars, while all other lead times contained CAPE/CIN vars (default). Log also reflected the paths used appropriately:

Using /glade/p/ral/jntp/GMTB/tools/NCEPLIBS-ufs-v1.1.0/intel-19.0.5/mpt-2.19/share/postxconfig-NT-GFS.txt for post-processing Using /glade/scratch/hertneky/ufs-mrweather-app/cime/scripts/ufs-mrweather-app-workflow.c96_v1.1/SourceMods/src.ufsatm/postxconfig-NT-GFS-F00.txt for post-processing

Please advise if additional tests are desired.

fossell commented 4 years ago

@hertneky - Thanks for running the tests. It sounds like everything is working as we expect and is ready go. I don't think any other tests are necessary.

uturuncoglu commented 4 years ago

@fossell @hertneky @ligiabernardet I think it might be nice to run full test suite on Cheyenne and maybe Orion to be sure that restart test is passing. I was running on Cheyenne before but it was giving build error. I could test it again.

uturuncoglu commented 4 years ago

After my initial attempt to run full test suite on Cheyenne, I have only three tests that fails with build issue.

  SMS_Lh3_D.C192.GFSv16beta.cheyenne_intel (Overall: FAIL) details:
    FAIL SMS_Lh3_D.C192.GFSv16beta.cheyenne_intel MODEL_BUILD time=75
  SMS_Lh3_D.C384.GFSv16beta.cheyenne_intel (Overall: FAIL) details:
    FAIL SMS_Lh3_D.C384.GFSv16beta.cheyenne_intel MODEL_BUILD time=71
  SMS_Lh3_D.C768.GFSv16beta.cheyenne_intel (Overall: FAIL) details:
    FAIL SMS_Lh3_D.C768.GFSv16beta.cheyenne_intel MODEL_BUILD time=77

I'll trigger them manually by building model again. The good news is that ERS (exact restart test) and PET (threading test) are passed without any problem.

ligiabernardet commented 4 years ago

@Ufuk Turuncoglu - NOAA Affiliate ufuk.turuncoglu@noaa.gov Thanks for working on figuring out the problem. Do you have any reason to believe this is related to UPP output? I am asking because this is the topic of this issue.

On Mon, Aug 31, 2020 at 2:58 PM Ufuk Turunçoğlu notifications@github.com wrote:

After my initial attempt to run full test suite on Cheyenne, I have only three tests that fails with build issue.

SMS_Lh3_D.C192.GFSv16beta.cheyenne_intel (Overall: FAIL) details: FAIL SMS_Lh3_D.C192.GFSv16beta.cheyenne_intel MODEL_BUILD time=75 SMS_Lh3_D.C384.GFSv16beta.cheyenne_intel (Overall: FAIL) details: FAIL SMS_Lh3_D.C384.GFSv16beta.cheyenne_intel MODEL_BUILD time=71 SMS_Lh3_D.C768.GFSv16beta.cheyenne_intel (Overall: FAIL) details: FAIL SMS_Lh3_D.C768.GFSv16beta.cheyenne_intel MODEL_BUILD time=77

I'll trigger them manually by building model again. The good news is that ERS (exact restart test) and PET (threading test) are passed without any problem.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ufs-community/ufs-mrweather-app/issues/174#issuecomment-684036352, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE7WQARJS66N7Q2NZTXV4EDSDQFIFANCNFSM4QGLUBMQ .

uturuncoglu commented 4 years ago

@ligiabernardet I think this is related with the model build specifically https://github.com/ufs-community/ufs-mrweather-app/issues/169. We could close this issue if you want.

ligiabernardet commented 4 years ago

This work is complete and ready for further testing.

ufs-community / ufs-mrweather-app

Customizing UPP output #174