First Meeting

[mgrover1]

Let's plan on putting together a meeting... I can send out an availability poll, if people can send me their emails (send an email to [email protected]).

I am thinking some time next week?

Tagging everyone in the previous discussion at fmaussion/salem#205

@lpilz @tjwixtrom @erogluorhan @jthielen @michaelavs @fmaussion

[mgrover1]

If you cannot make the meeting, we can have an asynchronous chat on here! I will be sure to send out the notes from this meeting as well.

[erogluorhan]

Looking forward to the poll

[mgrover1]

Here is the drafted agenda! Feel free to add additional talking points/points of discussion.

[fmaussion]

Had a look at the agenda - thanks! I think one thing I'm very curious about is:

• will there be diagnostic variables?
• quid from wrf-python? Will xwrf make wrf-python look more "pythonic" and less "ncl-y" or are the two projects unrelated?

[jthielen]

Thanks for putting together the agenda! Hopefully it's okay that I added an additional notes section with a summary of points from fmaussion/salem#205 and some tweaks to the agenda (which also hopefully addresses @fmaussion's points).

[mgrover1]

@fmaussion those would be good points to bring up for discussion! And @jthielen, that would be great!

[jthielen]

Just jotting down this thought/proposal based on the discussion that was cut short at the end of the video call (which I can elaborate on in feature comparison write-ups):

I concur with the point about avoiding a monolithic implementation or having a package just wrap implementations of other packages without adding value (outside of a shared namespace/API). With that in mind, I'd propose the following breakdown of roles for a typical "Pangeo-style" workflow of analyzing WRF output:

• xwrf as a compatibility layer between raw WRF output and CF-friendly xarray Datasets with actual physical variables (rather than offsets or split components like raw WRF has) backed by Dask arrays all ready-to-use by other packages
• xgcm to handle grid-related functionality (e.g., vertical coordinate interpolation)
  • MetPy and geocat-comp also have/will have functionality in this area, and are likely sufficient if you solely want destaggered variables
• MetPy to handle advanced diagnostics (i.e., thermodynamic variables not present in WRF output, CAPE, SRH, divergence, etc.)
  • Until ongoing improvements are completed (xref xarray parcel functions Unidata/MetPy#1968, Support for Dask Arrays Unidata/MetPy#1479), MetPy's parcel calculations are insufficient for gridded data and Dask support overall is spotty (but hopefully these can be accomplished on a similar timeline to that of a full demo-ready xwrf...and needs here could accelerate upstream development through community contributions).
  • xcape and geocat-comp have partial functionality in this area
• matplotlib/cartopy/HoloViews/GeoViews/geocat-viz/etc. to handle visualization

That said, I would love to see the documentation provide a "one-stop shop" of how to carry out typical workflows (rather than relying on connecting all the pieces oneself)!

[fmaussion]

xwrf as a compatibility layer between raw WRF output and CF-friendly xarray Datasets with actual physical variables (rather than offsets or split components like raw WRF has) backed by Dask arrays all ready-to-use by other packages

Yes!!! Getting rid of accumulated values for fluxes (including precip, i.e. using units over time instead) would be another wish of mine but maybe too dirty to handle generally. But this is what salem was good at: hiding how weird the raw WRF output is.

MetPy to handle advanced diagnostics

I believe the reason wrf-python is so widely used is for:

• unstaggering
• https://wrf-python.readthedocs.io/en/latest/diagnostics.html

How far / close is MetPy from providing all these diags?

[lpilz]

@jthielen I think this is a very nice approach. I might not have been a little unclear in the discussion beforehand. My idea was not to have a one-stop-shopping experience including everything from I/O to plotting to every diagnostic variable one could think of. Rather, the desire was to be able to have one package which provides real, physical variables from wrf output ready for further analysis.

One issue which you did not cover explicitly was horizontal destaggering. My feeling is that, I would like to hide the WRF-specific Arakawa-C grid complexity behind this xwrf layer. However, this would mean either depending on xgcm for destaggering or implementing the functionality directly in xwrf. Do you guys and gals have any thoughts on this?

[jthielen]

Yes!!! Getting rid of accumulated values for fluxes (including precip, i.e. using units over time instead) would be another wish of mine but maybe too dirty to handle generally.

I think that's a worthwhile inclusion to have somewhere! Though, if the accumulated variables can be sufficiently well-described by CF, then this becomes a more general purpose functionality that would likely fit better upstream (and may even be doable with xarray alone?).

How far / close is MetPy from providing all these diags?

I'll be sure to include that info in my later write-up! While a good portion of those diags fall under the "raw to physical variable" conversion, the rest fall into a fairly even split between

• fully provided in a grid-capable way
• provided, but not yet grid-capable
• not provided in MetPy, but derivable using a little bit of extra work or other tools (and could be considered for inclusion in MetPy for ease-of-use)

One issue which you did not cover explicitly was horizontal destaggering. My feeling is that, I would like to hide the WRF-specific Arakawa-C grid complexity behind this xwrf layer. However, this would mean either depending on xgcm for destaggering or implementing the functionality directly in xwrf. Do you guys have any thoughts on this?

Sorry I didn't call that out directly! Since destaggering is pretty lightweight implementation-wise (just average two offset sliced arrays), I envisioned horizontal destaggering being an option for the xwrf backend that xwrf can just do itself without dependency. I'm not sure which (destaggering or keeping the staggered grid) should be the default, but there are good use cases for each, so we'd want to support both.

[andersy005]

I'll be sure to include that info in my later write-up!

👍🏽

Since this thread is getting long :), would it be useful to start documenting this in standalone issues or discussions so as to make it easy to keep track of once we start working on implementations?

[mgrover1]

For those who missed the meeting or those who want to have a record of what was discussed, here are the notes!

xWRF Discussion (27 October 2021)

Introductions (Name / Organization / @github)

• Max Grover / NCAR / @mgrover1
• Jon Thielen / CSU / @jthielen
• Kevin Paul / NCAR / @kmpaul
• Julia Kent / NCAR / @jukent
• Orhan Eroglu / NCAR / @erogluorhan
• Michaela Sizemore / NCAR / @michaelavs
• Fabien Maussion / University of Innsbruck / @fmaussion
• Lukas Pilz / Heidelberg University / @lpilz
• Anderson Banihirwe / NCAR / @andersy005

Agenda

• Why create a new package
  • Just a prototype for now
    • Helping Cindy in MMM with her workflow
      • Using wrf-python to read in a bunch of files
      • Required to load everything into memory
      • Want to make it easier to integrate with Pangeo community
    • Focus is on lightweight - just get it into an xarray dataset
    • Doesn't have full functionality of wrf-python
  • Xarray backends
    • Could add our own decoder here
  • How xwrf is currently implemented
  • Additional features desired
• Support of WRF users with Python
  • GeoCAT team - NCAR's Pivot to Python efforts
    • Team of 4
    • Maintain wrf-python, develop GeoCAT-comp/GeoCAT-viz
    • wrf-python
      • Could improve on this - team of 4, several toolkits
      • In mature position compared to other toolkits, not neccessarily priority
      • Should support, maintain, actively develop
        • Mostly supporting end-users
      • Everything could be developed in tandem
    • Share experience + knowledge, make decisions down the road
  • Should get MMM involved - they are the primary stakeholder
  • Key summary points
    • Only so many people who can give resources to this
      • wrf-python in maintenance mode, original developer left
        • Developed pre-pangeo
      • New prototype - what value does wrf-python add? How can we integrate with Pangeo?
      • Limited resources - quick, somewhat dirty
      • Want external help with this too - open-source
• External collaborators
  • Strong need within the university community
  • Need to be able to work with Dask for scalability
  • Focus should be on getting external collaborators too
  • At some point, add user stories
    • What could be done with this?
    • How bad is it now? How awesome can we make it?
• Xdev's role
  • Going to add this onto the schedule - the next project!
  • Plan is to roll with these short-term, agile projects
• What falls within the scope of this package?
  • Data access through xarray
  • Interfacing with xGCM
  • Dask compatibility
  • Diagnositc variable calculations
• Who is interested in helping with development?
  • Lukas Pilz - will chat with PI, but would be very interested in contributing
  • Jon Thielen - provide user stories, development efforts
• Long-term dev
  • This is where MMM can come in... thinking about sustainability
    • Reaching out to them now - find someone with free cycles
• What is the best way of collaborating with the GeoCAT team?
  • GeoCAT team chatted about where xwrf will go
    • How to integrate with wrf-python
  • Would xwrf be redundant?
  • How do we bring in what we already have? How can we upgrade and move forward?
    • wrf-python users want xarray-compatibility
    • ncl users complain
    • Not easy to get rid of a tool
    • 1300 monthly visits to wrf-python
    • Responsibility to respect existing user base
    • wrf-python can use xwrf for now - can help transition
  • Thoughts
    • Might be beter to think of xwrf first, integrate later - the api might be a limiting step
    • Lots of technical debt with wrf-python
      • Starting from scratch is an investment, but could get contributors
      • If pure python - get more people that can jump in
    • Split dev path
      • xwrf - meet the user community need, keep wrf-python as is, re-evaluate later on
    • User api with wrf-python
      • Elements that don't belong in the same package
      • Ex. many plotting elements that fit into geocat-viz

Next Steps

• Planning on meeting again in a few weeks
• User stories
  • Examples of workflow, what the need is
  • Why would someone use this package?
  • Get feedback from current wrf-python community
  • Jon has some sample stories/sample code!
• API design
  • What already exists and where?
  • What doesn't exist and where should it go?
• Send out survey once we think this has value

Additional Notes

Desired Features for a WRF Analysis Package in the Pangeo Ecosystem

(see fmaussion/salem#205)

• Pythonic, xarray-centric API
• Full Pangeo stack integration, particularly Dask for parallelization and lazy-loading
• Large collection of performant diagnostic routine calculations that remain portable (i.e., use numba rather than cython or f2py if vectorized NumPy code is insufficient) and are automatically available (i.e., Dask delayed)
• Support for both automatic destaggering (for typical analysis workflows) and working on staggered grid (with xgcm)
• CF compliant metadata with geospatial dimension coordinates (i.e., Salem-like, as needed for integration with other packages like MetPy, cf-xarray, xesmf, etc.)
• Community-oriented development philosophy (e.g.; integrate with existing packages where functionality exists rather than rolling our own; any new, non-WRF-specific functionality needed here gets contributed upstream then reused here)

[lpilz]

Just a quick question: I am currently applying for funding to come to Boulder for a couple of months next September (definitely gonna invite you all out for a beer if this were to actually happen 😉). For the funding agency I have to write some essays about my current and future work and I would really like to mention this project as I think it might be interesting to the selection committee.

I am not quite finished writing and polishing, but I'm planning to include something along the lines of:

This project's aim is to provide the Python-using WRF community (ca. 2000 people) with a prototype for a modern, scalable and sustainable package for post-processing model output. Said prototype is intended to coalesce community interest, determine user needs and lay the groundwork for a community-centric process to build a long-term supportable, pythonic WRF post-processor.

Since this will be read by an expert referee who might be a community member, I just wanted to check if you were comfortable with this. If you think this would be a bad idea - no problem, I'll just drop it.

[lpilz]

PS: I talked to my PI today and she gave me the green light for working on xwrf @kmpaul

[lpilz]

Hi all, I will have some time in the next couple of weeks, so I wanted to get this rolling again. To kick it off, I started a couple of issues (#10, #11) and would love to discuss the best path forwards with you.

@kmpaul @erogluorhan in the meeting, you two mentioned that the allocation of this project within NCAR was not quite clear yet (GeoCAT or MMM). Is there some new information on this? @kmpaul how are capacities on your end?

[kmpaul]

@lpilz: Yes. I think we should start planning this, and we should get @erogluorhan and @dopplershift on board, since we need to coordinate how this project will impact wrf-python and how MetPy can play a role in this shift. Basically, even though the work may not be significant, the impact could be significant and I think we want to think about providing a safe space for the current wrf-python users to land, as well as a clear understanding of what our developers (GeoCAT, Xdev, and Unidata) should expect as we shift the wrf-python user community.

Can we get all of the necessary people together for a meeting to start planning this?

[dopplershift]

I'm on board to help however we can. I'll just toss out that in general, MetPy is heavily based around xarray as our core data model and always looking to add more calculations as our user community requests--or better yet contributes as PRs. Our current development goals (with direct NSF funding for them) are to optimize many of MetPy's calculations to support using grids using something like Numba (or maybe falling back to e.g. Cython), as well as natively support being passed Dask arrays.

[lpilz]

@kmpaul I wholeheartedly agree, let's do this! I created a when2meet with hopefully the right times - let me know if this works or not.

@dopplershift That's great, thanks a lot. Having some more MetPy-specific experience will be a huge boon. I think long-term dask-enabled MetPy would be pretty important for us, as one of this project's goals is to enable out-of-core computations on very large wrf output datasets. But for the moment I think its best to just focus on the wrf-specific computation of diagnostic variables while having the interface with MetPy in mind.

[kmpaul]

@erogluorhan? Are you on board?

[erogluorhan]

Sure, I am on board, but with limited load from GeoCAT, unfortunately. We will make sure we are supporting this effort as much as we can, while we are providing support for the existing WRF-Python users timely and investigating to see if it would be good to improve WRF-Python's xarray compatibility with xwrf's interface for them. It's also important for me to forecast how much impact will be on the current WRF-Python user base after such an effort gets mature, as @kmpaul mentioned. I will think on this.

[kmpaul]

@erogluorhan: This is why we want you in the planning meeting next week. I hope you can attend. Basically, we need to decide whether modifications should go into WRF-Python, or xwrf, or MetPy. If we decide that modifying WRF-Python to play better with Xarray (i.e., incorporating xwrf cod into WRF-Python) is the best approach, then we focus the project on this and I would hope that GeoCAT could collaborate on that. If we decide that functionality in WRF-Python should be split out, with some functionality going into MetPy and some into xwrf (or maybe all into MetPy?), then I hope we could have GeoCAT's blessing. I don't think we should internally be developing competing packages, so it probably does everyone a favor in determining how GeoCAT is different from WRF-Python is different from MetPy, and what is missing to be filled in.

[lpilz]

Hi everyone, it looks like the when2meet has spoken and next Tuesday (11-23) at 10am MST works best for our next xwrf planning meeting. I would suggest we save the date!

[kmpaul]

Can someone create an event for this? I don't think I have everyone's email addresses to invite.

[mgrover1]

Sure - I can take care of that!