Cryowrf #2251
Open
Cryowrf #2251
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wrf-model#2185) TYPE: bug fix KEYWORDS: WRF-Chem, dry air density SOURCE: NOAA GSL, Alexander Ukhov (KAUST) DESCRIPTION OF CHANGES: Problem: It was found that dry air density was miscalculated. Solution: Removed unnecessary factor. Simulations before and after did not show any significant difference, as expected. LIST OF MODIFIED FILES: M chem/module_chem_utilities.F TESTS CONDUCTED: The Jenkins tests are all passing. RELEASE NOTE: Fixed calculation of dry air density in module_chem_utilities.F. The bug had a very minor effect.
…-model#2143) TYPE: enhancement KEYWORDS: testing, devops, github, workflow SOURCE: internal DESCRIPTION OF CHANGES: Problem: The CI/CD testing framework using github actions is set to trigger on PR label events. However, labels are not just used for testing and will trigger the workflow. While the workflow does have checks in place to skip any labels that aren't meant to trigger testing, this skipped workflow status will override any previous actual test status. This can be confusing if two labels are applied at the same time, one being a test label, and only one status appears showing a skipped workflow. Unique naming of workflow runs does not mitigate this problem as the posted status is tied to the workflow internal id and not the run name. Solution: Convert the main workflow that hosts the test sets into a dispatch workflow, meaning it must manually be triggered. This has the intended effect of decoupling the workflow id from any PR and will not normally show up as a status at the bottom of PRs solving the issue of independent labels overriding each other. To solve the workflow no longer appearing within PR statuses, the github REST API is used to create a commit status pointing to its respective workflow run via `target_url` along with the current state of the job. As the main workflow must manually be triggered, a new entry point proxy workflow is used to filter test labels and request a test run if needed. This paradigm allows events to be triggered within a PR context, simplifying gathering the data necessary to run the correct PR branch. Furthermore, the entry point will still suffer the initial problem of status override on multiple labels, but this should be acceptable as actual test labels will create their own commit statuses once queued. The dispatch workflow is unable to be run within the context of PR merge refs, nor the head of the branch from a fork (as that would run the workflow in _that_ fork). Thus, the dispatch workflow is run using the base ref of the PR if from a fork, or the head ref *ONLY IF* originating from the parent repo of the workflow. This means testing of the immediate changes to the workflow can only be observed within the PR of an internal repo branch, limiting development slightly. The benefits, however, are a cleaned up status reporting AND increased security as no runner code that isn't already within a branch of the repository will be executed. One should still ensure the underlying tests are okay to run TESTS CONDUCTED: 1. Testing was done in independent fork to demonstrate initial issue and feasibility of this solution.
sviaroCryos
requested review from
a team,
brankokosovic,
domingom and
pedro-jm
as code owners
|
Too many files show up as different including a new WPS which should not be included in a WRF repo. Update a recent version of WRF to minimize differences. |
|
@sviaroCryos Thanks for contributing your development to WRF. But your code is not prepared correctly to make the PR. You have an entire WPS directory and its files in this PR. I also see modified LICENSE.txt and top level README file, which you should not do. If your code is based on earlier versions of WRF, you should probably first rebase (using git) your code to 4.7.1, and make sure the only differences in the final code between your fork and our main branch is the code you modified. Here is some instructions you may find useful. There are other notes on our Wiki page that might also help you. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Submit a new LSM mentioned in the LOI sent to the WPRP
TYPE: new feature
KEYWORDS: LSM, snowpack, blowing snow scheme,
SOURCE: CRYOS lab, EPFL
DESCRIPTION OF CHANGES:
Implementation of a new LSM that treats the cryosphere. Details of this new LSM are in the LOI.
Implementation of a blowing snow physics
LIST OF MODIFIED FILES: available at changelog_WRF.md
TESTS CONDUCTED:
Code tested in Antartica and the Alps. Results published.
RELEASE NOTE: Sharma, V., Gerber, F., and Lehning, M.: Introducing CRYOWRF v1.0: multiscale atmospheric flow simulations with advanced snow cover modelling, Geosci. Model Dev., 16, 719–749, https://doi.org/10.5194/gmd-16-719-2023, 2023.