Stream: ESDS

Topic: Support for Climatology Functions

view this post on Zulip Heather Craker (Jul 12 2021 at 21:05):

Hi all. There were a lot of questions at this WIP talk today, and I was unable to address them all. If you have further questions about how climatology means calculations are being done in geocat-comp or if you have suggestions, please post them here. Thanks!

view this post on Zulip Daniel Marsh (Jul 12 2021 at 21:10):

Thanks for a great presentation. I hope there's some discussion about how to leverage this work for the CAM diagnostics package.
I was wondering if the time argument for the calendar average function can take a time bounds array and if the routine returns an updated time bounds array. That way you should get the same answer if you average daily into months then seasons as just average into seasons and also gets around the whole CESM monthly mean h0 output issue of the date field be written on the first day of the following month.

view this post on Zulip Isla Simpson (Jul 12 2021 at 21:14):

Thanks for the great presentation. My questions were going to be the following: (1) When you calculate DJF, I assume it's the D of one year and the J and F of the following? (2) Are you thinking of support for non-standard seasons? e.g., DJFM, JAS etc. I think that could be useful if it's not something you've already considered.

view this post on Zulip Heather Craker (Jul 13 2021 at 14:03):

Thanks for the question @Daniel Marsh. I don't know anything about the CAM diagnostics package, but I am aware that CESM monthly mean has an offset date field. That is a use case that I have yet to tackle, but it is on the todo list.

At the moment, there is no way to pass time bounds into calendar_average. The function infers the time bounds based on how the data is spaced temporally, and it does not return what the new time bounds are. I'm interested in talking with you further about how specifying time bounds can solve the CESM date field issue since this functionality sounds very useful.

Currently it doesn't matter what intermediary steps you take when aggregating the data as the result should be the same regardless of the path you take. If you average daily data into monthly and then into seasonally, that should give you the same values as going from daily data straight to seasonal averages. I'm using the word "should" here because I haven't tested that claim fully, but it works in the cases I have.

view this post on Zulip Daniel Marsh (Jul 13 2021 at 14:23):

The last post in the FAQ shows a workaround for dealing with the CESM date field issue by computing new time axis by averaging the time bounds (https://ncar.github.io/esds/faq/) I am not sure if this is still the best way for dealing with this issue.

I guess if you know the calendar, a DJF mean based on the weighted (by length of month) average of D, J and F is the same as averaging over all days in D, J and F.

view this post on Zulip Heather Craker (Jul 13 2021 at 14:23):

Hi @Isla Simpson (1) Your assumption is correct! DJF means December in one year followed by January and February of the next year. (2) Currently the function month_to_season exists in geocat-comp, and it is a pure python version of the NCL function of the same name. It computes an average for a given 3 month season with one data point per year, and non-standard seasons are supported. The one caveat with this function is that it only takes monthly data as the input, and recently I noticed that it does not weight the months by how long they are (i.e. Feb should be weighted less than Jan).

Right now calendar_average only supports the standard seasons, but I am interested in expanding it's capabilities so hourly, daily, or monthly data can be aggregated into non-standard seasonal means and month_to_season isn't needed anymore.

view this post on Zulip Heather Craker (Jul 13 2021 at 14:36):

@Daniel Marsh

The last post in the FAQ shows a workaround for dealing with the CESM date field issue

I'll certainly look into this! It may be a more elegant solution that what I'm doing now. Thank you!

view this post on Zulip Daniel Marsh (Jul 13 2021 at 15:09):

BTW, re. the new CAM diagnostics, Brian Medeiros <brianpm@ucar.edu> is leading this - it might be good to reach out to him.

view this post on Zulip Isla Simpson (Jul 13 2021 at 15:19):

Hi Isla Simpson (1) Your assumption is correct! DJF means December in one year followed by January and February of the next year. (2) Currently the function month_to_season exists in geocat-comp, and it is a pure python version of the NCL function of the same name. It computes an average for a given 3 month season with one data point per year, and non-standard seasons are supported. The one caveat with this function is that it only takes monthly data as the input, and recently I noticed that it does not weight the months by how long they are (i.e. Feb should be weighted less than Jan).

Right now calendar_average only supports the standard seasons, but I am interested in expanding it's capabilities so hourly, daily, or monthly data can be aggregated into non-standard seasonal means and month_to_season isn't needed anymore.

Sounds good. Thanks,

view this post on Zulip Daniel Marsh (Jul 13 2021 at 19:11):

And here is a document describing all the diagnostic tool developments within and external to CGD/AMP: https://docs.google.com/document/d/15Z8-cd2VdzCK1Z47m-uuMoU0jOUkGAR39FFbHBnZ1FY/edit?usp=sharing

view this post on Zulip Heather Craker (Jul 14 2021 at 16:10):

If anyone wants access to my slides and the demo code, here is a repo with all of that information https://github.com/hCraker/calendar_average_demo

Last updated: Jan 30 2022 at 12:01 UTC