Stream: ESDS
Topic: CESM-LE
Sanjiv Kumar (Apr 23 2021 at 17:15):
@Will Wieder - Can you please copy the URL that you shared yesterday
@ALL - does anyone has hurricane extraction code from CESM-LE data, or know someone who is working with hurricane using the LE data
Will Wieder (Apr 23 2021 at 17:36):
likely need some updates from my local repository... https://github.com/wwieder/cesm-lens this is built on work by
@Daniel Kennedy https://github.com/djk2120/cesm-lens. to clarify, no hurricane tools here, but file IO for looking at daily CESM2-LE data.
Max Grover (Apr 23 2021 at 21:26):
@Sanjiv Kumar are you interested in historical datasets (hurricanes that have already occurred)? These examples would be helpful for that https://tropycal.github.io/tropycal/examples/tracks.TrackDataset.html#sphx-glr-examples-tracks-trackdataset-py
If you are interested in a machine learning approach, see this repository https://github.com/hammad93/hurricane-net which appears to be exploratory, but would be a good place to start.
Max Grover (Apr 23 2021 at 21:29):
@Sanjiv Kumar also, here is an example of using CESM1-LE data, written up by @Joe Hamman https://medium.com/pangeo/cesm-lens-on-aws-4e2a996397a1 with an an executable notebook here https://github.com/NCAR/cesm-lens-aws/blob/main/notebooks/using-intake-catalog.ipynb which was put together by @Anderson Banihirwe
Katie Dagon (Apr 23 2021 at 22:48):
@Sanjiv Kumar For another ML-based approach to detecting tropical cyclones, you could check out the ClimateNet project: https://portal.nersc.gov/project/ClimateNet/ see also this publication: https://doi.org/10.5194/gmd-14-107-2021
Some of us are working on applying this tool to CESM output (not the LE, but high resolution coupled runs).
Sanjiv Kumar (Apr 24 2021 at 01:45):
@Max Grover Thank you very much, this is very helpful. Over the summer, we will be implementing it; so we will have some more questions for you.
Sanjiv Kumar (Apr 24 2021 at 01:59):
@Katie Dagon Thank you, Katie. This platform very helpful. Thank you for introducing me to this platform.
Daniel Kennedy (May 06 2021 at 21:29):
@Will Wieder and I are looking at daily output from LENS2. When we stitch the historical and SSP simulations together we're finding two instances of 01/01/2015. One comes from the last history file of the historical, and the other from the first history file of the SSP.
When I inspected them, the JAN1 from the historical looks good, but the JAN1 from the SSP looks like an initialization step, and not like valid daily output. We're planning to drop that second JAN1. Does this sound reasonable? Maybe @Nan Rosenbloom can weigh in?
Posting this here in case anyone stumbles across this same problem. Thanks!
Nan Rosenbloom (May 06 2021 at 23:59):
Thanks @Daniel Kennedy and @Will Wieder for finding this. I know that you and Gary were discussing this in slack. Is this something we should fix in the files or something we should warn people about? Also, is it universal or limited to one component and frequency?
Adam Phillips (May 07 2021 at 15:59):
I believe this issue is known. The first timestep in daily atmospheric output from hybrid runs is instantaneous, regardless of whether the entire output stream is set to averages. @Will Wieder I show the first timestep of the historical portion of the CESM2-LENS data to be an instantaneous timestep as well. When I convert the time_bnds array it shows the time range of the first timestep to be 18500101->18500101. Gary and I have asked that this issue and others, including the monthly average output time issue (of being set to the first day of the month after the averaged month) be addressed in a future release. I believe the atmosphere and land SE's are considering changing some of these output behaviors.
Adam Phillips (May 07 2021 at 16:11):
@Nan Rosenbloom Looking at CESM2-LENS data, I see this issue in the atmospheric and land output (although the land output does not show the first timestep as instantaneous, but it has the time range of a hour). I do not see this extra timestep in ocean/ice output.
Will Wieder (May 09 2021 at 12:43):
I know @Keith Lindsay and others have addressed this in different ways. I didn't expect the time stamp issue to also pop up in analysis of HIST and SSP data with these daily data.
Here's a one-line fix for a dataset that includes the duplicated jan 1 2015 values
ds = ds.sel(time=~ds.get_index("time").duplicated(keep='first') )
Last updated: Jan 30 2022 at 12:01 UTC