Building a sandbox example from UFS in order to implement passive GHG tracers

[aschuh]

To whom it might concern(hopefully somebody),

I've been tasked with trying to incorporate new GHGs into UFS as passive tracers that will need to be advected around the atmosphere. i'm unfamiliar with UFS but have downloaded the ufs_weather_model and I'm trying to use the RT tests to help w/ some kind of "sandbox" creation, or starting point. I'm running on ORION. The only test I've gotten to run is control_c48 for 24 hours with the default FV3_GFS_v16 phsyics option. My assumption is that if I use RT.CONF to run this case (./rt.sh -k -n control_c48), the compilation appears to include several physics options which I'm assuming will be available at run time so I can simply change the physics in the namelist. Is this correct? For example, if take the RT temp folder w/ the compile and run directories for control_c48 and edit the input.nml line:

ccpp_suite = 'FV3_GFS_v16'

to read:

ccpp_suite = 'FV3_GFS_v17_p8'

it seems like it should run, but I have yet to get to be able to get it to run. Seems to crash often w/ an error that looks like:

...atmosphere_dynamics: error in ccpp_physics_init for group fast_physics: Group fast_physics not found

Furthermore, even if I change the physics option in the "control_c48" file in tests/tests (as opposed to in the input.nml in one fo the tmp RT directories) to read 'FV3_GFS_v17_p8', and try to launch rt.sh to COMPILE and RUN, I still get an error. Would seem that for some reason control_c48 depends on some weird way on FV3_GFS_v16 physics and can't generally run w/ any physics? I can't imagine that as it seems that this is the point of the UFS?

I'm unsure if this is even the best way to proceed. The "Apps" seem fine (short, medium, etc) but I need to alter, i.e. add new, tracers and try to mimic the smoke approach but with GHGs instead of aerosols. This means that I need to "be in " the physics code and my work will depend upon which physics I'm running. What I need is to nail down one "serial implementation" of the model using one physics routine, e.g. FV3_GFS_v17_p8 to start with. The physics routine is critical as each will likely move passive tracers differently (which is sort of what we're concerned about). Not sure best way to get to what I need.

If anybody can get a feeling for what I want to do from this request, I'd be happy to take advice.

thanks,

andrew

[aschuh]

Just an update here. I've noticed that it seems that rt.conf regression test runs seem very particular, in that there is a namelist with a specific physics options and that what physics options might run with it, is unknown. Its only likely that the one listed WILL run. Hence if I'm interested in looking for a test case/sandbox case, I should probably grep the physics options out of tests/tests to find a combination that does use the one I'm interested in and is being run at coarse enough resolution to ensure speed necessary for testing/debugging. Still, any other advice/comments would be appreciated, thanks.

[DeniseWorthen]

Andrew--

Could you point me to your run directory on orion? And, just to be sure, when you replace the SDF in the input.nml, you use the single quotes around the SDF name (they are actually required)?

[grantfirl]

Hi Andrew,

I'm probably not the best person to answer this, but I can try to explain why you're seeing the error that you are to maybe get you a little further along.

My assumption is that if I use RT.CONF to run this case (./rt.sh -k -n control_c48), the compilation appears to include several physics options which I'm assuming will be available at run time so I can simply change the physics in the namelist. Is this correct?

This isn't exactly correct. It is correct that running a single test with rt.sh will find the compile and run configurations in rt.conf that are used for that one test. Like you said, for the control_c48 test, it is building/compiling several physics suites. However, changing suites isn't necessarily as simple as changing the ccpp_suite namelist parameter. There are other namelist parameters that are expected to be changed along with the change in the ccpp_suite. You listed trying to run with FV3_GFS_v17_p8. For example, this suite expects that the do_sat_adj namelist parameter is set to false. The namelist parameters for the RTs are constructed by starting with the namelist that is specified by the INPUT_NML environment variable. For the control_c48 test, this is control.nml.IN found in tests/parm. If you read through this, you'll notice that some namelist parameters are hard-coded and others are expected from environment variables. The default values of environment variables are listed in tests/default_vars.sh. Those defaults are overridden by whatever environment variables are set in the test file (control_c48).

So, for your example, control_c48 is starting from control.nml.IN that sets the do_sat_adj variable to T. When this variable is set to T, FV3 expects that the CCPP suite that you're trying to run with has a "fast_physics" group in the suite definition file. So, even though you set the ccpp_suite to FV3_GFS_v17_p8 (which doesn't have a fast_physics group), FV3 is trying to call/initialize this physics group due to the do_sat_adj namelist variable being set to T, hence the error you're seeing.

You can get a set of namelist parameters that work with the FV3_GFS_v17_p8 suite by looking through the files in tests/tests for one that has ccpp_suite = FV3_GFS_v17_p8 and seeing which namelist it starts with (what is listed in the INPUT_NML parameter) and what additional environment variables it sets for the test.

[grantfirl]

A TL;DR version of my answer is that what physics is run (what suite you're using) is a combination of what is in the suite definition file (in FV3/ccpp/suites) that says what schemes are run and how they're organized into groups and in what order PLUS a set of namelist parameters that further configures the set of schemes that is specified in the suite definition file. You effectively changed the suite definition file, but did not have a set of namelist parameters compatible with your changed suite.

[junwang-noaa]

Hi, Andrew,

I second what Grant said. In general each physics package requires its own prognostic fields, input fields and climatology files. It might be OK if a develop works on other part of the model and treat physics as a black box, but it mostly likely won't work if they change physics package without considering the items associated with the package. In your case, I think it's better to run the control_p8 test case, not sure why you won't be able to run that case. If it is resource issue, then it's possible the resources still could be an issue if you incorporate new GHGs into UFS as passive tracers. Just my two cents.

[yangfanglin]

Andrew, I have a couple of science questions for this work. If you include GHG as a tracer, that means CO2 will be a prognostic variable. Will you also include CO2 source and sinks from the land and ocean components (the carbon cycle) ? Will this only work in a coupled model framework ? Is this project aimed to use the UFS for climate change studies ?

[aschuh]

Fanglin, currently we are targeting just putting them to assist with GHG forecasting. That's of a limited value admittedly, but the next step will likely a simple DA/surface flux optimization model to mimic what CarbonTracker (GML-NOAA) has been doing with the CTM TM5/ERA5 for both CH4 and CO2. Relative to your question, I've done fully coupled work, i.e. prognostic as you say. That is significantly off in the horizon but would be interesting. Most of our work here at Colorado State U. has been with SiB that was developed by Piers Sellers at Goddard in the 80s and is used as a full blow land surface model. There definitely are the pieces and experience, including SiB, to do this but it would depend upon NOAA resources/priorities.

Currently, I'm only working on the GHGs as super simple passive tracers coming from "fixed" time-varying (noncoupled) emission fields (offline bio, offlilne ocean exchange, etc). Initial target is CO, CH4, CO2 and SF6.. Under the resources and priorities of GML, this will likely feed into the chemistry before it expands in the coupled land surface direction (my guess). The pieces that I'm (personally) most concerned about are global tracer mass conservation and conservation of local tracer gradients. A simple test of the latter is whether a uniform dry mix ratio field can be maintained through a forecast. This usually requires dry mass advection and careful accounting of tracer/dry mass mixing in the physics. I've only seen a couple models that I could conform did this correctly (OLAM/UMiami and likely MPAS). We'll see what we get : ). Happy to discuss further if you are interested, you can email me offline at [email protected] .

[yangfanglin]

Andrew, thank you for the detailed reply. A very fascinating project. In terms of mass conservation, I will share with you offline some tests I did a few years ago on the FV3-based GFS dry mass conservation