Yannick announced that we are not ready for the discussion on the Locations class, so this will be postponed to a later meeting date to be determined. There are vacations and work trips coming up soon for a fair amount of people so we may have to wait several weeks before having the Locations class discussion.

Yannick also announced that we have successfully run an increment of the first 4D var using FV3 and AMSU-A data.

Yannick then opened the floor to updates/concerns/questions.

NCAR

Chris raised a couple questions about variables being analyzed by the model

  • What we should call these variables? The current terminology is confusing so he is asking for clarity by getting agreement on terminology. Chris proposed the term "Analysis Variables".
  • Should we be producing Theta and Rho, or should it be Temperature and Pressure?
  • It was decided to continue this discussion in tomorrow's B-Matrix meeting

Chris mentioned that he logged an issue in ZenHub concerning the use of staggered grids. The issue is essentially what grid location to use (center vs edges) and the impact that this choice has on the work for BUMP. (Note that the discussion under FV3 below begins to address this issue.)

Junmei presented work she has done with IODA.

  • Wrote a putdb method that dumps out data into a netcdf file
    • Next step is to write this output into an ODB2 (odb_api) file
  • Using Magics to create plots of various analysis quantities
    • Magics is installed on Cheyenne (not a trivial task)
    • Convert netcdf to ODB which can then be read into Magics
  • Here is a copy of Junmei's slides:


Junmei asked about when the multiple variable version of UFO/IODA will be available? Yannick responded that Xin's work will be merged soon, perhaps in the next couple days. Yannick also noted that multiple variables will only be implemented for Radiosonde and Aircraft obs types in this merge.

Junmei asked about the status of ODB2. David Davies from the UK Met Office responded that we are close to having ODB access working in JEDI. Should have a pull request soon, perhaps next week.

Magics provides plotting capabilities through a Python API. A discussion broke out about diagnostic tools, such as Magics, and how this relates to the choice of obs database file format (ODB, netcdf, etc.)

  • If we go with a format other than ODB, we may have a bit of work in order to provide plotting capabilities on par with Magics
    • Magics operates with ODB format only
  • Installing Magics on an HPC system (Cheyenne) was not a trivial task
    • MetView (a GUI to run Magics) may be even more difficult to install on an HPC system
  • Magics makes some assumptions about how data is organized in the ODB (eg, u and v are interleaved)
    • Be aware of this
    • This may have been fixed in the latest version of Magics, but not sure about this
  • There are multiple Python plotting packages so we could go with one of these if Magics becomes problematic
    • Key point is that we should stick with Python for diagnostics so that we can take advantage of the many data analysis features of Python (other than plotting)

UK Met Office

Steve is working on getting the JEDI version of LFRic updated to the head of the trunk (of the primary source repository for LFRic, I assume).

College Park

Guillaume reported that a new pull request is coming soon, perhaps next week. He is implementing a linked list interpolation scheme for SOCA (which is similar to a scheme Dan put into FV3).

FV3 work

Dan merged in the "nothing2something" pull request. This allows for doing trajectories for multi-BUMP cases. He is working on adding in these new trajectories.

A discussion ensued regarding BUMP configuration with the different models. If I understood correctly,

  • Multi-BUMP comes about from staggered grids.
    • In an Arakawa-C grid you have u on the east-west edges, v on the north-south edges and scalars in the center which yields 3 grid locations. Consequently, this requires 3 BUMP configurations (one for each grid location) in order to eliminate multiple interpolations (eg, center to edge and vice versa).
  • The implication is that all of the models will need to make the appropriate BUMP configurations according to their grid setups.

Others

Mark (core team) has Webhooks operating that will check for certain policies related to our software development methodology

  • After a push occurs into a GitHub repository, the Webhooks will:
    • Check if the repository is past a size limit (this would imply that files which belong in git-lfs have not been placed into git-lfs)
    • Check if the git-flow naming convention for branches (feature, hotfix, etc) has been followed
    • If either of these are violated an email is sent to the core team and the person that just did the push, so that these issues can get resolved
  • The Webhooks capability is being operated through an Amazon service

Steve (core team) is working on getting the April 15, 2018, 00Z BUFR obs data converted to netcdf

  • He is planning on using netcdf CF naming convention where applicable
    • Variables will use CF names (air_temperature, air_pressure, brightness_temperature, etc)
    • Metadata (error, qc marks, etc) will use the CF variable name with an appropriate suffix (_err, _qc, etc)

Chris Harrop

  • git-LFS is working on Theia now (the firewall was opened up to allow this).
  • He is working on instantiating an MPI communicator object (from eckit) into a JEDI Run object
    • What is the best way to pass this down to the other JEDI objects?
    • Yannick responded that he should first pass the communicator to Geometry and ObsSpace (since these currently can utilize that information)

Misc

Next week Yannick will be gone. However we can still have a meeting if we deem it necessary. Mark (core team) will help organize.

Two weeks from now is the summer DA colloquium in Bozeman, Montana.


  • No labels