adding new fields/tracers to FV3

Hi,

I'm looking for documentation that describes how to add new fields to FV3.  The specific questions I'm interested in are listed below.  I looked here but did not find anything, although it's probable I missed something.

Dom Heinzeller gave partial answers to these questions in an email reply (see below) but also suggested posting it on this forum to see if there are additional suggestions.

Thanks,
Gerard

 

Note: The filenames in the following questions are from the regional FV3.

1) Assume I've added a new 2-D static field to sfc_data.nc.  From there, how do I:
  * Have FV3 read it in?
  * Make the field available to be used by a function in the CCPP suite?  It looks like this is described here.  If you have other suggestions, please let me know.

2) Assume I've added a new 3-D tracer to gfs_data.nc that I want to advect.  From there, how do I:
  * Have FV3 read it in?  Will just adding it to the field_table be enough?
  * Have FV3 advect it?
  * Make the field available to be used by a function in the CCPP suite?
  * Have FV3 write it to the write-component output files (e.g. phyf###.nc)?  

3) Assume I've added a new 3-D tracer to gfs_data.nc that I DON'T want to advect.  From there, how do I:
  * Have FV3 read it in?  Will just adding it to the field_table be enough?
  * Have FV3 NOT advect it?  I assume this involves the dnats variable in the namelist.
  * Make the field available to be used by a function in the CCPP suite?
  * Is this method of using a "fake" (i.e. unadvected) tracer the only way to get a 3-D static field into FV3?

 

On Fri, Dec 18, 2020 at 8:24 PM Dominikus Heinzeller - NOAA Affiliate <dom.heinzeller@noaa.gov> wrote:

Hi Gerard,

...

- the CCPP technical documentation covers how to get a field passed from the host model to the physics

- 2D fields in sfc_data are read in via FV3/io/FV3GFS_io.F90, or FV3/gfsphysics/GFS_layer/GFS_restart.F90 - have a look inside those two files for comparable cases (not straightforward, though; GFS_restart.F90 is a little easier I think). A good comparison for you could be nwfa2d (2d aerosol emissions for Thompson)

- 3D fields can be read in via FV3/gfsphysics/GFS_layer/GFS_restart.F90 unless they are tracers that should end up in the tracer arrays in the dycore and the physics

- for tracers, you need to more stuff

    - add to field_table

    - pull out the index in fv3atm (GFS_typedefs.F90) to know where in the tracer array it sits

    - you can pass that slice qgrs(:,:,myindex) to CCPP, see existing examples

    - if the dycore doesn't need to do any special stuff with it, this should be enough (in this case it gets advected)

    - if the dycore shouldn't advect it, add it to the end of the field_table and increase dnats by 1 (dnats is the number of tracers at the end of the tracer array that are not advected by the dycore)

    - thus be careful if you add it to a field_table that does already have a non-advected tracer at the end (e.g. cld_amt) - need to get the order and the value of dnats right

...

Dom

Hi Gerard,

Did Dom's answer suffice for now? Or do you need additional information? After you try what Dom suggested, let us know how it went and if you need anything else.

Ligia

Hi Ligia,

This question was from Ravan and his collaborators.  I did not yet have time to pursue Dom's suggestions.  Ravan's group did some of it but not yet all.  He asked me to send it again via email to a larger group.  So I will do that but will recommend that people answer in this forum.

Gerard

Hi Gerard,

Sounds good. Once we know what Ravan's team tried and what outcome it had, we can provide more guidance.

Thank you for asking others to provide answers in this forum - this will help all of us.

Ligia