Zppy pcmdi new

[zhangshixuan1987]

Issue resolution

• Closes #<ISSUE_NUMBER_HERE>

Select one: This pull request is...

• a bug fix: increment the patch version
• a small improvement: increment the minor version
• an incompatible (non-backwards compatible) API change: increment the major version

1. Does this do what we want it to do?

Objectives:

• Objective 1
• Objective 2
• ...
• Objective n

Required:

• Product Management: I have confirmed with the stakeholders that the objectives above are correct and complete.
• Testing: I have added or modified at least one "min-case" configuration file to test this change. Every objective above is represented in at least one cfg.
• Testing: I have considered likely and/or severe edge cases and have included them in testing.

If applicable:

• Testing: this pull request introduces an important feature or bug fix that we must test often. I have updated the weekly-test configuration files, not just a "min-case" one.
• Testing: this pull request adds at least one new possible parameter to the cfg. I have tested using this parameter with and without any other parameter that may interact with it.

2. Are the implementation details accurate & efficient?

Required:

• Logic: I have visually inspected the entire pull request myself.
• Logic: I have left GitHub comments highlighting important pieces of code logic. I have had these code blocks reviewed by at least one other team member.

If applicable:

• Dependencies: This pull request introduces a new dependency. I have discussed this requirement with at least one other team member. The dependency is noted in zppy/conda, not just an import statement.

3. Is this well documented?

Required:

• Documentation: by looking at the docs, a new user could easily understand the functionality introduced by this pull request.

4. Is this code clean?

Required:

• Readability: The code is as simple as possible and well-commented, such that a new team member could understand what's happening.
• Pre-commit checks: All the pre-commits checks have passed.

If applicable:

• Software architecture: I have discussed relevant trade-offs in design decisions with at least one other team member. It is unlikely that this pull request will increase tech debt.

[zhangshixuan1987]

Notes from Shixuan : The changes made in this file are mainly to a. add the update following e3sm_diags.py and b. add code block here to deal with the external function module and parameter files that will be needed for the pcmdi-pmp diagnostics.

[zhangshixuan1987]

@zhangshixuan1987 : This file has been recoded and refined, and is now ready for review.

[zhangshixuan1987]

Hi @chengzhuzhang, I have refined the code and added the viewer module into the code base, and I think that the code is ready for you and Ryan to review, and then we can discuss how to modify and merge to the zppy master code

[zhangshixuan1987]

Hi @chengzhuzhang @forsyth2:

I reopened this pull request after finishing the refactoring and refinement of the code. A brief summary on the changes and tests I have done:

1. zppy/pcmdi_diags.py and zppy/templates/pcmdi_diags.bash: These two scripts have been refactored and simplified based on my understanding. I hope that this version can better satisfy the requirment of the zppy workflow.
2. A data structure is created and save at the /lcrc/group/e3sm/diagnostics/pcmdi_data/ to facilitate the zppy-pcmdi diagnostics:

• metrics_data/ : This directory contains PCMDI metrics datasets for CMIP models, downloaded from the PCMDI Metrics Results Archive GitHub repository. These datasets provide precomputed mean climate metrics for a wide range of CMIP models and are used as a baseline for comparison in PCMDI diagnostic workflows.

• reference/reference_alias.json: This file contains a modifiable dictionary that documents all available reference (observational) datasets supported by the E3SM Diags package for use in PCMDI diagnostics. It was created to enable flexible and consistent identification of reference/observational datasets across diagnostic runs. By using this alias mapping, users can specify shorthand names for reference datasets, which are then resolved to their full identifiers or paths during processing.

• region/regions_specs.json: This file contains a modifiable dictionary that defines the spatial regions used by PCMDI diagnostics to compute regional and global mean metrics. Each entry specifies the boundaries and identifiers for a region, enabling consistent region-based metric calculations across different diagnostics.

-synthetic_metrics/synthetic_metrics_list.json : This file contains a modifiable dictionary that defines the key configurations for generating summary metrics plots, such as portrait plots and parallel coordinate plots of model errors. It specifies which metrics to include, how they are grouped, and how they should be visualized in synthetic summary diagnostics.

• utility/pcmdi_zppy_util.py and utility/pcmdi_viewer_util.py: These two Python scripts contain utility functions used to support PCMDI diagnostic workflows within zppy. They help automate key tasks such as metrics calculation, output file reorganization, and HTML-based visualization generation. These utilities enable seamless integration of PCMDI metrics into the zppy post-processing pipeline.

• viewer/: This directory contains the HTML template and logo image files used to generate the viewer page for PCMDI diagnostics within zppy. These assets define the layout, styling, and branding of the final diagnostic HTML reports.

I have run a test with the simulation data from v3.LR.amip_0101. The configuration file is attached here:

• post.v3.LR.amip.0101.cfg.txt

The final product of the package is now a webpage shown in this example

I will ask you both for a review and we can discuss in a meeting if you like for the next step. Thank you!

[zhangshixuan1987]

@chengzhuzhang @forsyth2 : Hi Jill and Ryan, I have modified the code and they are now ready for review. I marked all files that have been removed from the zppy directory. Currently, there are only three files to be merged to zppy code base.

[zhangshixuan1987]

@zhangshixuan1987: This file is now removed from zppy directory

[zhangshixuan1987]

@zhangshixuan1987: This file is now removed from zppy directory

[zhangshixuan1987]

@zhangshixuan1987: This file is now removed from zppy directory

[zhangshixuan1987]

@zhangshixuan1987: This file is now removed from zppy directory

[zhangshixuan1987]

@zhangshixuan1987: This file is now removed from zppy directory

[zhangshixuan1987]

@zhangshixuan1987: This file is now removed from zppy directory

[zhangshixuan1987]

@zhangshixuan1987: This file is now removed from zppy directory

[zhangshixuan1987]

@zhangshixuan1987: This file has been recoded and refined, and ready for review.

[zhangshixuan1987]

@zhangshixuan1987 : This file has been recoded and refined, and is now ready for review.

[zhangshixuan1987]

@zhangshixuan1987: This file has been recoded and refined, and is ready for review.

[forsyth2]

@zhangshixuan1987 I haven't had a chance to do a full review yet, but I have a couple early questions:

1. Did you mean to have this PR being to zppy_pcmdi branch rather than the main branch? That is, is this PR an intermediate step to merging Add PCMDI Diags to zppy #647 (which is from the zppy_pcmdi branch to the main branch) or is this intended to be a stand-alone implementation?
2. I don't see a corresponding pull request in https://github.com/E3SM-Project/zppy-interfaces/pulls. Is this implemented completely in zppy? That's not the final design we'll want. In particular, zppy/templates/pcmdi_diags.bash is very large -- over 1200 lines! I imagine we'll want to move much of that into zppy-interfaces. For reference, zppy is for coordinating post-processing tasks and zppy-interfaces is for plotting code or other specific post-processing tasks.

[forsyth2]

Did you mean to have this PR being to zppy_pcmdi branch rather than the main branch?

I created #718 to give the diffs against the main branch instead.

[zhangshixuan1987]

@zhangshixuan1987 I haven't had a chance to do a full review yet, but I have a couple early questions:

1. Did you mean to have this PR being to zppy_pcmdi branch rather than the main branch? That is, is this PR an intermediate step to merging Add PCMDI Diags to zppy #647 (which is from the zppy_pcmdi branch to the main branch) or is this intended to be a stand-alone implementation?
2. I don't see a corresponding pull request in https://github.com/E3SM-Project/zppy-interfaces/pulls. Is this implemented completely in zppy? That's not the final design we'll want. In particular, zppy/templates/pcmdi_diags.bash is very large -- over 1200 lines! I imagine we'll want to move much of that into zppy-interfaces. For reference, zppy is for coordinating post-processing tasks and zppy-interfaces is for plotting code or other specific post-processing tasks.

Hi @forsyth2, I may have misunderstood earlier. I created a new pull request with the finalized and clean version of the code for you and @chengzhuzhang to review. This PR comes from a branch in my forked GitHub repository, rather than a branch directly under the zppy master. I realize this might have caused some confusion—or perhaps it relates to the first question you raised?

As for the second question, I’d appreciate the opportunity to discuss how best to split the implementation between zppy-interfaces and zppy. I’m still a bit unclear about the current infrastructure (e.g. differences in
zppy-interface and zppy, and their purposes), which may be why my pull request wasn’t aligned with expectations.

[forsyth2]

This PR comes from a branch in my forked GitHub repository, rather than a branch directly under the zppy master.

Yes, but the target branch is E3SM-Project:zppy_pcmdi, when it should be E3SM-Project:main. I initially resolved this with #718. However, I've noticed several code cleanup issues that I can address relatively quickly, so I'm doing that in #719.

I’d appreciate the opportunity to discuss how best to split the implementation between zppy-interfaces and zppy. I’m still a bit unclear about the current infrastructure

Yes, this is a good idea. First though, I will continue cleaning up the code in #719 so that I can do a more thorough review. Then I will have a better idea of what should be moved to zppy-interfaces, and how.

[zhangshixuan1987]

@forsyth2: Thank you very much, Ryan, for your thoughtful guidance and support in managing the code workflow and improving the implementation. I’ll leave it to you to complete the proposed work, and would kindly ask that you let me know once you have an idea or direction—I'll be happy to work on the revisions accordingly.

[forsyth2]

@zhangshixuan1987 Sounds good, and thank you as well for putting in all this work! I don't think I'm going to have time this week to do my full code review but hopefully next week there will be time available.

[forsyth2]

This has been replaced by #719.