Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Simplified UFS_case_gen.py #461

Conversation

grantfirl
Copy link
Collaborator

@dustinswales @scrasmussen @hertneky @ligiabernardet

This is a PR to add a new, simplified version of UFS_IC_generator.py. Rather than modify the existing UFS_IC_generator.py, I've just created a new script named UFS_case_gen.py. We can change this if necessary.

The script pulls both the initial condition profiles and forcing from UFS history files. The only reliance on the "true" initial conditions is for the surface and oro variables. This means a couple of things:

  1. The case is created for the column on the diagnostic, Gaussian grid point, not the actual, native FV3 grid point. This eliminates any need for regridding in the horizontal, but it immediately creates a difference between the UFS and SCM runs. This should be acceptable, IMO.
  2. The SCM initial conditions are taken from the first UFS history file, which is after the first time step. This should also be an acceptable compromise, given differences already coming from point 1.

The forcing section is technically split by "method". I have placeholder logic for calculating forcing using the original "gold standard" method and the existing method, that I call the "total time tendency" method. Right now, the new forcing method is the only one implemented in the script to show us how much simpler it can be.

The advective forcing is calculated using centered differences in the horizontal (using either 1 or 2 halo points (i.e. a 3x3 or 5x5 grid with the column of interest in the center). The vertical differences are calculated using upstream differences, using a moving-averaged smoothed vertical velocity. Right now, the script is still outputting the "total" advective tendencies like the old UFS forcing, but it should be possible to output the horizontal advective tendencies and the smoothed vertical velocity profile for forcing, which is a preferable way to force SCMs.

I've tested this script using the same (global) data that was staged for testing the old script. I'm sure that more testing needs to be done, especially with output from a regional configuration, but I've chosen many random points and run the SCM for 24h cases. I only ran it for 24h because the UFS data that was used only has 12-hourly data for 1 day. Comparing only mean profiles of the state variables, the agreement is reasonably good. This is encouraging since we only have 12-hourly data! This method should be more accurate with better time resolution of the UFS data.

Known problems:
The forcing method is not supported very close to the poles.

@dustinswales
Copy link
Collaborator

@grantfirl Thanks for creating this. I will fold my work on using the dynamic tendencies into this script.
One thing, it looks like the CI test for the replay is failing:
https://github.com/NCAR/ccpp-scm/actions/runs/8822685081/job/24221443644?pr=461
You need to update the environment file, environment-ufsreplay.yml, to have the new dependencies in your new script.

@grantfirl
Copy link
Collaborator Author

@grantfirl Thanks for creating this. I will fold my work on using the dynamic tendencies into this script. One thing, it looks like the CI test for the replay is failing: https://github.com/NCAR/ccpp-scm/actions/runs/8822685081/job/24221443644?pr=461 You need to update the environment file, environment-ufsreplay.yml, to have the new dependencies in your new script.

@dustinswales Sure, I can do this, although the purpose of this PR was to really just "check in" or show you guys this implementation. I think that the plan is still to compare the 1) dynamics tendencies vs. 2) total time tendency from history files (current method in the main repo) vs. 3) advective tendency from history files (what is in this new script) using the testing harness that you guys have created (or are creating). Now that we have methods 2 and 3 working in some form, should we try to run this through the test harness somehow? @scrasmussen @hertneky

Like I said in the description, it's easy enough to fold this new script back into UFS_IC_generator.py if necessary for the test harness.

@dustinswales
Copy link
Collaborator

@grantfirl Thanks for creating this. I will fold my work on using the dynamic tendencies into this script. One thing, it looks like the CI test for the replay is failing: https://github.com/NCAR/ccpp-scm/actions/runs/8822685081/job/24221443644?pr=461 You need to update the environment file, environment-ufsreplay.yml, to have the new dependencies in your new script.

@dustinswales Sure, I can do this, although the purpose of this PR was to really just "check in" or show you guys this implementation. I think that the plan is still to compare the 1) dynamics tendencies vs. 2) total time tendency from history files (current method in the main repo) vs. 3) advective tendency from history files (what is in this new script) using the testing harness that you guys have created (or are creating). Now that we have methods 2 and 3 working in some form, should we try to run this through the test harness somehow? @scrasmussen @hertneky

Like I said in the description, it's easy enough to fold this new script back into UFS_IC_generator.py if necessary for the test harness.

@grantfirl Gotcha. Then yes, let's run this through the harness. @hertneky @scrasmussen I will tag you in the google doc where you need to make changes.

@grantfirl
Copy link
Collaborator Author

Combined into #473

@grantfirl grantfirl closed this May 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants