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

Fixing African easterly wave density plots in TC analysis #851

Merged
merged 7 commits into from
Oct 23, 2024

Conversation

chengzhuzhang
Copy link
Contributor

@chengzhuzhang chengzhuzhang commented Sep 24, 2024

Description

Karthik (@karthik-balaguru) noted the odd Y shapes in easterly wave density plots in recent TC analysis results (issue 1). And @paullric also noticed that the ERA5 results are also off, which always have a base value of ~5 (issue 2).

image

  • Closes #<ISSUE_NUMBER_HERE>

Checklist

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • My changes generate no new warnings
  • Any dependent changes have been merged and published in downstream modules

If applicable:

  • New and existing unit tests pass with my changes (locally and CI/CD build)
  • I have added tests that prove my fix is effective or that my feature works
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I have noted that this is a breaking change for a major release (fix or feature that would cause existing functionality to not work as expected)

@chengzhuzhang
Copy link
Contributor Author

chengzhuzhang commented Sep 24, 2024

Not sure the root cause of issue 2, but I think plotting libraries changes caused the second issue over versions. By reading in files without subsetting the region, it fixed the issue. (Now, the region is bounded only when plotting)
Screenshot 2024-09-23 at 5 26 55 PM

Issue 1 remains, I will keep investigating.

@chengzhuzhang
Copy link
Contributor Author

Comparing with apply tempest-extremes (TE) on native ne120pg2 vs data regrided to 720x1440. The Y shapes only appear with native grid data. Below are the AEW density plots.
awe_ne120pg2
awe_720x1440

The AEW density plots uses three TE functions:
VariableProcessor to calculate relative vorticity
DetectNodes and StitchNodes to detect and stitch candidates
Finally HistogramNodes to generate histogram for the detection.
Detailed steps can be found here

@paullric I'm not sure if TE is applied properly in this case, any advice for further trouble shooting is appreciated!

@chengzhuzhang
Copy link
Contributor Author

Also to add that:
TC count increases if the storms are tracked on the regridded output. ~73 (regridded data on 720x1440) vs ~67 (native ne120) for one year of data.

@chengzhuzhang
Copy link
Contributor Author

Also to add that: TC count increases if the storms are tracked on the regridded output. ~73 (regridded data on 720x1440) vs ~67 (native ne120) for one year of data.

Following suggestion from @wlin7, when regridding, with a bilinear mapping file (to replace the aave one I used), the TC count (70) get closer to the results tracked with native ne120 data.

@chengzhuzhang chengzhuzhang marked this pull request as ready for review October 15, 2024 19:37
@chengzhuzhang
Copy link
Contributor Author

This PR will also address: empty input TC files.
from comment: E3SM-Project/zppy#633 (comment)

@chengzhuzhang
Copy link
Contributor Author

This PR will also address: empty input TC files. from comment: E3SM-Project/zppy#633 (comment)

This is addressed by 0cb36e9 by @tomvothecoder in cdat-migration-branch. I will copy the code over here, so that current main branch also has this fix.

@chengzhuzhang
Copy link
Contributor Author

@tomvothecoder this PR is ready to review, it partially addresses the plotting problem (Y shapes remains); also cross year TCs are removed; I copied over the error capture for cyclones stitches files as well.

Copy link
Collaborator

@tomvothecoder tomvothecoder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with some comments.

Comment on lines +190 to +193
# Add year info
te_stitch_vars["year_start"] = data_start_year
te_stitch_vars["year_end"] = data_end_year
te_stitch_vars["num_years"] = data_end_year - data_start_year + 1
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand correctly, you moved the year info out of _get_vars_from_te_stitch() because they are now different after removing the excessive time points that cross year bounds. Is this right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The start and end years were previously based on data from te_stitches files. It worked fine earlier because in the simulated data, there are always TCs each year. It became problematic when testing v3 datasets, years with no TCs get skipped. The new code now use start and end included in file name, which represent the actually year range being assessed.

Comment on lines +172 to +184
line_ind = []
data_start_year = int(te_stitch_file.split(".")[-2].split("_")[-2])
data_end_year = int(te_stitch_file.split(".")[-2].split("_")[-1])
for i in range(0, np.size(lines_orig)):
if lines_orig[i][0] == "s":
year = int(lines_orig[i].split("\t")[2])

if year <= data_end_year:
line_ind.append(i)

# Remove excessive time points cross year bounds from 6 hourly data
end_ind = line_ind[-1]
lines = lines_orig[0:end_ind]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor suggestion, I would extract this block of logic into a private function called _remove_time_crossing_bounds() or something to make the main run_diags() cleaner.

However, this can be done in the refactored codebase too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the suggestion. I considered to have a function instead as well. I think we can update the refactored code base when bringing more fix and enhancement to tc set.

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

Successfully merging this pull request may close these issues.

2 participants