Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unintuitive behavior in taking a time-series of sub-monthly data #262

Open
chuaxr opened this issue Mar 31, 2018 · 5 comments
Open

Unintuitive behavior in taking a time-series of sub-monthly data #262

chuaxr opened this issue Mar 31, 2018 · 5 comments

Comments

@chuaxr
Copy link

chuaxr commented Mar 31, 2018

In my comment in #229, I thought I had a workaround for domain means. I re-looked this issue and found some unintuitive behavior.

It turns out I needed to

  1. Set def_time to False in the variable definition, as well as all the variables that it depends on.
    Failure to do the latter resulted in an "Unknown file format" error when attempting to open the output.

  2. Define a region for the whole domain and use
    output_time_regional_reductions = ['reg.ts']
    (For a regular time series, 'ts'.)

  3. Use an option other than 'ann' for output_time_intervals. e.g. [1].
    (I tested this for a dataset from Jan-June, and it worked for 'djf', [1],[12])

It seemed very confusing to have to set a time string in order to avoid subsetting by time and output the entire time series. As a workaround, I made the following change in time_label (utils/io.py) so that I could set output_time_intervals=[0]:

elif type(intvl) == int and intvl in range(1, 13):

to

elif type(intvl) == int and intvl in range(0, 13):

We had a related discussion in #204 . I would appreciate knowing if there were a better fix or if this might introduce unwanted issues. If not, we can treat this as documentation.

@spencerkclark
Copy link
Collaborator

@chuaxr thanks for posting this workaround! I think I understand what you are getting at. Would this issue be addressed if we cleanly supported #252?

@chuaxr
Copy link
Author

chuaxr commented Apr 1, 2018

It certainly would, especially together with a more meaningful option for output_time_intervals (perhaps 'all'). Thanks!

@spencerahill
Copy link
Owner

@chuaxr thanks for this report. #252 is definitely our priority moving forward (after I finish the work I started on #229). Sorry we've been slow on this one...I've been tied up with non-aospy stuff mostly so far this year.

@chuaxr
Copy link
Author

chuaxr commented Apr 2, 2018

It's likely that I'll only be able to update aospy after #208 is resolved, so that would be highest on my wish list. Or perhaps the two issues could be resolved simultaneously? :)

@spencerahill
Copy link
Owner

Yes those will both be handled together :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants