ENSO use cases?

[benjamin-cash]

Are there any use cases for calculating ENSO indices, verifying ENSO forecasts, calculating teleconnections, etc?

[CPKalb]

Hi Benjamin:

This is an ENSO use case that computes the MaKE and MaKI indices. I see that it doesn't have ENSO in the title, so we should probably add that for more clarity.

Currently, that is the only ENSO use case we have. I have done some work with ENSO in the past (before METplus). Are you looking for a use case that does something specific?

Christina

[CPKalb]

HI Ben:

Ensemble-Stat is set up to read a gridded file in either netCDF (CF compliant, MET format, or from p_interp), grib1/grib2, or from python embedding. In all of these cases, Ensemble-Stat would expect information about the grid (see this information on supported grids). There are specific variables defining the grid that are required, and they vary depending on what projection is used. My suspicion is that giving Ensemble-Stat one data value with a lat/lon associated would not work, though I have not actually tested this. I have, in the past, tried to provide MET with a grid projection that is not supported and it fails with an error.

@JohnHalleyGotway is probably the best person to provide more information on how gridded data is actually read in to MET. However, he is on vacation at the moment. I can check here to see if I can get more information.

Christina

[benjamin-cash]

Thanks! I'll keep an eye on this space. :)

[benjamin-cash]

Is John back in the office this week or still out on vacation?

[JohnHalleyGotway]

Sorry for the long delay on this. I didn't have it on my radar.

So the question is how trivial of a "grid" can MET actually handle? For example, could it handle a "grid" consisting of a single point? I don't know the answer to that off-hand. I'd say maybe, but perhaps there's a better way of handling this situtation?

This reminds me a lot of the case where we already have forecast and observation data matched up at station locations. Point-Stat compares gridded forecasts against to point observations. But if you already have a point forecast matched to a point observation, what should you do? In the past, we've used this data to populate the MPR .stat line type, as if it were output generated from Point-Stat. We reformat that paired data into MPR lines and run the Stat-Analysis tool to compute statistics for those pairs. @CPKalb, I recall you taking this approach for the Xcel Energy project in the past.

The exact same approach can be used with ensemble data, but instead of populating the MPR line type, you populate the ORANK line type. Once the point ensemble forecast and observations are reformatted into ORANK lines for one or more locations and times, you pass them as input to Stat-Analysis and then recompute whatever other ensemble output you want.

Does that sound like what you're looking for? Or should I figure out if MET can handle a 1x1 size grid?

[benjamin-cash]

Hi @JohnHalleyGotway - Now I get to apologize for taking a while to get back to this. :)

Maybe it makes more sense to take a step back and describe what I am trying to do a little better. I have an ensemble of timeseries from a set of model runs. I want to use some of the METplus ensemble/probabilistic verification tools to assess my model against observations. Maybe I could use python embedding to calculate the index in the ORANK format and then feed it into Stat-Analysis? Ideally I would have something that would work on netcdf data (or xarray via embedding) so that I didn't need to transform it into a different data type.

[CPKalb]

Hi John and Ben:

Yes, I have taken this type of approach with the Kuwait energy project in the past. In this case, I had model data that was a single point and wanted to compare it to observations that were also a single point. MET generally requires comparing a gridded model to point data (point_stat, ensemble_stat) or a gridded model to gridded observations (grid_stat, ensemble_stat). To get around this, I used an external python script (not connected to MET) to put data in the MPR line format and fed that into Stat-Analysis. So, the only MET program I ran here was Stat-Analysis.

Since Stat-Analysis can now handle python embedding for the MPR line format, I didn't write any output mpr files, but rather just used python embedding to get these into Stat-Analysis.

However, I'm not sure if Stat-Analysis has python embedding support for the ORANK line type. @JohnHalleyGotway, can Stat-Analysis read the ORANK line type from python embedding or would a file need to be written with the ORANK line type?

Tina

[JohnHalleyGotway]

@CPKalb I realize that this discussion has remained unanswered for a few months now. I believe that we've followed up on these detail in meetings and perhaps on Slack. But I wanted to clarify the state of things in this issue.

Basically, no, as of right now, METplus is not setup well to serve any .stat line type to Stat-Analysis via python. Currently, only the use of MPR data is well supported. However, the dtcenter/MET#2539 issue requests exactly that functionality. I'll note that no changes are actually needed in Stat-Analysis itself. Instead, changes are needed in to the python wrapper code in MET.

I recommend that we mark this discussion as being answered and move any future discussion about python embedding of .stat data in the Stat-Analysis tool to comments on that dtcenter/MET#2539 issue. If that's acceptable, can one of you please select a good answer from this history of correspondence?

[TaraJensen]

He's out until the 10th.

…

On Mon, Jun 26, 2023 at 8:03 AM benjamin-cash ***@***.***> wrote: Is John back in the office this week or still out on vacation? — Reply to this email directly, view it on GitHub <#2222 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFQ7BGZBNWOKK5PGFWE5TTLXNGJBHANCNFSM6AAAAAAZQNLZMM> . You are receiving this because you commented.Message ID: ***@***.***>