search

spencerahill / aospy

Python package for automated analysis and management of gridded climate data
Apache License 2.0
83 stars 12 forks source link

Support WRF's vertical coordinate system #184

Open spencerahill opened 7 years ago

spencerahill commented 7 years ago

C.f. https://github.com/spencerahill/aospy/pull/183#issuecomment-301452304

This could be done as part of #80, but doesn't have to be. In fact there's more urgency to get this WRF functionality in place than for a broader refactor, due to potential new users wanting to use WRF data.

spencerahill commented 7 years ago

@spencerkclark is this still a problem for the WRF user? If so we could hold out for the v0.2 release until it's in (c.f. #198). But I also could imagine this being difficult enough to be dangerous as a blocker.

spencerkclark commented 7 years ago

Good question -- I'll check in with them today and see.

spencerkclark commented 7 years ago

I just discussed things offline with @chuaxr (who now has a GitHub account!). Currently she computes the pressure (as well as some other variables that depend on pressure, like density) in her preprocessing step. This essentially makes them appear like model-native variables; this way she can use them in functions that compute other variables.

The conclusion was that since she needs these other non-model-native variables in addition to pressure to be available to her calculations, regardless of whether this specific issue were addressed she would still need to compute pressure in her preprocessing step (to compute these other things). Therefore what would really be ideal would be a fix to #3. Given that #3 is a bigger, more general issue, and that she has an existing workaround, we feel this is OK to push to the "before v1.0" milestone (so it is not a blocker for v0.2).

spencerahill commented 7 years ago

Welcome to Github @chuaxr! Thanks for working with us to iron out these kinks with WRF. And thanks for opening #201 -- I believe it's our (long awaited) first ever user-created Issue!

Therefore what would really be ideal would be a fix to #3. Given that #3 is a bigger, more general issue, and that she has an existing workaround, we feel this is OK to push to the "before v1.0" milestone

OK, that sounds good to me too. Will try to make that more of a priority. Thanks for following up with Xin Rong on this.