Brian Bonnlander (Apr 10 2020 at 20:42): Brian Bonnlander (Apr 10 2020 at 20:42):@geocat I'm interested in adding python code that mimics the NCL functions month_to_season() and getind_latlon2d(). I have some questions about how to do this. Do I put these functions in separate python source files (one function per file), or a single file? What should these files be called? How much in the way of unit tests are you looking for, and do these go in a single file, or separate files for each function?
Brian Bonnlander (Apr 10 2020 at 20:46):Are there perhaps unit tests for the original NCL functions, that could be ported over to python?
Deepak Cherian (Apr 10 2020 at 21:15):@geocat I'm interested in adding python code that mimics the NCL functions
month_to_season()andgetind_latlon2d(). I have some questions about how to do this. Do I put these functions in separate python source files (one function per file), or a single file? What should these files be called? How much in the way of unit tests are you looking for, and do these go in a single file, or separate files for each function?
re: month_to_season; it should be fairly straightforward to add a custom season-start-month to our current da.time.dt.season. (https://xarray.pydata.org/en/stable/time-series.html#datetime-components) and then that could plugged into da.resample to build month_to_season or really anything_to_season.
Brian Bonnlander (Apr 10 2020 at 21:19):So, the NCL version takes the simple mean of three months' worth of data, which some have pointed out is not the best way to compute the seasonal mean. So I was originally thinking of duplicating this behavior, ignoring the number of days in each month. I'm assuming this is incompatible with how xarray wants to handle this.
Deepak Cherian (Apr 10 2020 at 21:25):xarray now has dt.days_in_month for CFTime indexes so you can get the weights easily: https://github.com/pydata/xarray/pull/3935
Also see updated example: https://xarray.pydata.org/en/latest/examples/monthly-means.html#Now-for-the-heavy-lifting:
Deepak Cherian (Apr 10 2020 at 21:50):yeah so month_to_season is just da.resample(time="QS-Feb").mean()with syntax from https://pandas.pydata.org/pandas-docs/stable/user_guide/timeseries.html#dateoffset-objects (QS-Feb = calendar Quarter, labelled with Start-date and starting in Feb
Once this (https://github.com/pydata/xarray/issues/3937) is implemented
it could be
da.weighted(da.time.dt.days_in_month).resample(time="QS-Feb").mean() or other weights as appropriate.
Orhan Eroglu (Apr 10 2020 at 21:54):@geocat I'm interested in adding python code that mimics the NCL functions
month_to_season()andgetind_latlon2d(). I have some questions about how to do this. Do I put these functions in separate python source files (one function per file), or a single file? What should these files be called? How much in the way of unit tests are you looking for, and do these go in a single file, or separate files for each function?re: month_to_season; it should be fairly straightforward to add a custom season-start-month to our current
da.time.dt.season. (https://xarray.pydata.org/en/stable/time-series.html#datetime-components) and then that could plugged intoda.resampleto buildmonth_to_seasonor reallyanything_to_season.
Hey @Brian Bonnlander , thanks a lot for your interest in contributing to geocat-comp. I can have a few suggestions here:
Pure Python functions are implemented within their own files each in geocat-comp. So, it would be good for you to add your functions as separate files for each, too. For an example, you can see the following pure Python function: https://github.com/NCAR/geocat-comp/blob/develop/src/geocat/comp/polynomial.py. Just FYI: We are in the beginning of a structural modification to our geocat-comp in order to separate pure Python and Fortran-dependent codes from each other as separate repo's. I believe that it shouldn't affect your current contribution as here; however, alternative thoughts would welcome from our other @geocat members.
Orhan Eroglu (Apr 10 2020 at 22:04):Are there perhaps unit tests for the original NCL functions, that could be ported over to python?
Hey @Brian Bonnlander , in regards to your questions about test cases:
First, you can find a bunch of test cases for several functions under here: https://github.com/NCAR/geocat-comp/tree/develop/test
Second, as a more precise example, you may want to have a look at this: https://github.com/NCAR/geocat-comp/blob/develop/test/test_linint2points.py. In this case, test cases are written for the sake of acquiring outputs identical to NCL outputs regarding not only dimensions etc. but also content. When you read throughout the code, you can see input arrays and ground-truth (or expected) output arrays. These input and output arrays are generated by running NCL scripts first then using them in these Python cases. You can see those NCL test scripts (written by us for the python test) attached here: test_linint2_points_msg.ncl test_linint2_points.ncl
Brian Bonnlander (Apr 10 2020 at 22:14):OK, but if I want to see existing tests written in NCL for some other function I want to submit, where can I look to see if there are unit tests written in NCL for that function? In other words, can I confirm that my python version of a function will pass the original units tests for the NCL version?
Orhan Eroglu (Apr 11 2020 at 09:19):We haven't conducted any investigations with respect to the original NCL unit tests, and it is beyond my knowledge if there is a source where we can find original NCL unit tests. Any thoughts from @geocat team?
Last updated: May 16 2025 at 17:14 UTC