GFDL_atmos_cubed_sphere
GFDL_atmos_cubed_sphere copied to clipboard
NOAA-GFDL
Read cube sphere grid increments for DA/IAU
Is your feature request related to a problem? Please describe. In anticipation of transitioning from GSI to JEDI for UFS DA capabilities, we would like FV3 to be able to read increments on the native cube sphere grid in addition to the Gaussian/Lat Lon grid and then interpolated like is currently supported.
Describe the solution you'd like
Now that the UFS-weather-model write-grid component can write out history files on the native grid (with variables with dimensions such as: t(tile, layer, lon, lat)), and FV3-JEDI can read and write these files, being able to read a similarly configured/formatted file for analysis increments would be preferred. Additionally, a configuration table to map model variables to increment file field names would ensure maximum compatibility across different applications.
Describe alternatives you've considered The exact format of the files can still be up for discussion provided that it is flexible for dynamics, tracers, and possibly surface variables, and preferably contains every tile as a dimension in one file.
Additional context EMC/PSL intend to perform the majority of this work but would like to confirm approach/design with GFDL before proceeding.
Cannot assign people, but tagging @jswhit2 @pjpegion @catherinethomas-noaa @russtreadon-noaa for awareness
@CoryMartin-NOAA - for seamless interoperability with existing FMS io infrastucture and performance, it is best the files be constructed similar to a restart file. Instead of a single file with data for all of the tile information, there would be a file specific to each tile. This makes it easier to account for the different rotations as well as handling nested configurations.
Hi, all. Earlier GMAO was doing native-FV3 grid DA on the same lines. Has there been any coordination with them?
Thanks, Lucas
On Fri, Apr 29, 2022 at 9:10 AM Rusty Benson @.***> wrote:
@CoryMartin-NOAA https://github.com/CoryMartin-NOAA - for seamless interoperability with existing FMS io infrastucture and performance, it is best the files be constructed similar to a restart file. Instead of a single file with data for all of the tile information, there would be a file specific to each tile. This makes it easier to account for the different rotations as well as handling nested configurations.
— Reply to this email directly, view it on GitHub https://github.com/NOAA-GFDL/GFDL_atmos_cubed_sphere/issues/188#issuecomment-1113292213, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMUQRVAFCFL2376KF4DKUH3VHPNS3ANCNFSM5UV5EUMA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
I am not sure if @danholdaway plans to read increments for GEOS or not, but he and I have been coordinating on the history file IO to be compatible in FV3-JEDI between UFS and GEOS.
@bensonr would you suggest something like 20220429.120000.fv_increment.tile1.nc in the FMS RESTART format? I think I'm fine with that provided that it is just one increment per tile per IAU time. I'm hesitant to have something like 20220429.120000.fv_tracer.tile1.increment.nc because of the number of files that would entail.
@CoryMartin-NOAA - your suggestion to have all increments in a single file per tile is okay. It is the segmenting per tile that is important and not the variable content.
@CoryMartin-NOAA we might well read increments into the IAU routines but we wouldn't be using any infrastructure from FV3 or FMS to do that. GEOS uses MAPL for handing all IO. If you're writing files that are to be ingested by FV3 would you be using the UFS/GEOS IO from fv3-jedi? I would have thought it would be the FMS IO routines?
@danholdaway based on @bensonr 's comment a few mins ago. I think what I expect we would do (or at least try this) is cube sphere history IO for input, and FMS increments for output. Ensuring we use history input is important because of 7 (hours) * 81 (deterministic + ensemble) background files as input means we need as small of files as possible and the RESTART files are much larger than the history files.