add test for E3SM data

[chengzhuzhang]

This is an initial PR for testing xcdat general functionalities. It is a copy of @lee1043 's demo, but apply to E3SM data. We can re-organize later to remove redundancy, but at this point, it just help to visualize the test results with another model format.

• To start with, E3SM has this time being recorded at the end of the time interval problem (specifically for monthly time series), i.e., the first time step (time for the first month) gives Feb 1st. Since we will add centering time for climo calculation, maybe this step should be generalized and integrate into decode_time.
• A small glitch data_var should replace keep_var in the docs?
• I will test more, but it might be helpful to merge this PR to render the notebook? @tomvothecoder let me know what you think.

[lee1043]

@chengzhuzhang the test looks great, thank you for adding it. While @tomvothecoder may comment on your points, I have a few thoughts:

• Can you write little more in specific how to get the input data? Maybe pointing to ESGF/e3sm would help users finding where to start.
• I think notebook can be rendered even it is on branch as here

[chengzhuzhang]

Hey @lee1043 thanks a lot, I made an update to reflect the input data source, and added you to author list.
Great tip! I will keep working on this PR without merging then.

[lee1043]

@chengzhuzhang I am not serious about having my name there, but thanks for listing me on the notebook. I don't mind merging small PRs multiple times or big PRs fewer times. Please feel free to merge it whenever you feel comfortable. Many thanks for working on this.

[tomvothecoder]

This is an initial PR for testing xcdat general functionalities. It is a copy of @lee1043 's demo, but apply to E3SM data. We can re-organize later to remove redundancy, but at this point, it just help to visualize the test results with another model format.

I agree, having another demo with a different model format sounds useful.

• To start with, E3SM has this time being recorded at the end of the time interval problem (specifically for monthly time series), i.e., the first time step (time for the first month) gives Feb 1st. Since we will add centering time for climo calculation, maybe this step should be generalized and integrate into decode_time.

I think the robust implementation is having a separate normalize_time() method that the user has to explicitly call if they want to center the time using the time bounds. It might frustrate users if they expect to use the raw dataset time coordinates after calling xcdat.open_dataset(), but instead it has been implicitly recomputed with a call to decode_times().

This method has been implemented in xCDAT/xcdat#107 and can be called like so:

import xcdat
ds = xcdat.open_dataset()

# Explicitly recompute time
ds = ds.temporal.normalize_time()

# Time is recomputed for temporal averaging operations.
# It doesn't update time in the dataset, user has to explicitly do it (line above).
ds = ds.temporal.avg("climatology"....)

• A small glitch data_var should replace keep_var in the docs?

Thanks for the catch, I will open an issue to fix this typo.

• I will test more, but it might be helpful to merge this PR to render the notebook? @tomvothecoder let me know what you think.

Sounds good!

Note: Rename as center_time()

[lee1043]

@chengzhuzhang this PR looks ready to be merged, would you be okay with that?

[chengzhuzhang]

@tomvothecoder @lee1043, hey, thanks both for your input. I will think more about the implementation of set time at the middle of time bounds and add more tests to this PR :).

[chengzhuzhang]

sorry for the food of committing messages. I'm less familiar with committing changes in JupyterNotebook, and the committing history may be messed up. I will have a new PR later and will discard this one...

[tomvothecoder]

@chengzhuzhang No worries, you can squash the commits if you want.