-
Notifications
You must be signed in to change notification settings - Fork 364
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
Adds a new tool to replace gen_domain in CIME #6347
Conversation
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for rewriting this tool! I left some very minor comments.
I think this PR is ready for a thorough review. I've added documentation for this tool and a new "tools" section of the E3SM docs. I expect other tool documentaiton will show up there soon. Additionally, I've also started working on recreating the guide for "Running E3SM on New Grids" in the new E3SM docs repo. So there will naturally be some redundant documentation for this tool, but I think that's ok. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Flash review. Feel free to push back and/or ignore. I like the shiny new tool! I think eventually we want to have a neat conda package with all your tools 😸
@@ -0,0 +1 @@ | |||
site_name: generate_domain_files |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two comments here:
- I am not sure we want this to be
generate_domain_files
--- maybe like the title in the file? "Generating Domain Files"? - I am not sure if we want each tool to have its sub-site like this. Maybe our strategy should be that we give "tools" their own website (like eam) but then inside tools, each additional tool will just be a page (and maybe some subpages)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, I'm a bit unsure about the best strategy here as well. Initially I was envisioning a more complicated hierarchy, but then Ben Hillman pointed out that I was committing the sin of premature optimization. So I think it's best to see how the documentation evolves and what new tools get added before we make any decisions about how to reorganize things.
I don't think we should have each tool get its own sub-website with mkdocs.yaml. Pinging @rljacob who added the monorepo functionality. Having said that, we can resolve this issue later (it is mostly cosmetic, nothing fundamental), so no need to hold this PR. |
@singhbalwinder - I was going to test it and compare output from the Fortran tool quickly, but I'll do that today and post results here |
@whannah1 -- it failed for me trying to regenerate a domain file from one of our recent ice/ocn meshes:
Of course it's highly likely to be user error |
I agree with @mahf708. Move the docs directory to just under tools. |
@singhbalwinder looks like I have another problem with the output domain files that I need to investigate, so we need to hold off on merging this. |
@whannah1, not to add more work to this, but should we consider adding a unit test to go with this? Then, we can even have that unit test go in one of these actions. An example of a python-centric unit test:
If we have these files on the inputdata server, it is then relatively easy to request them, etc. (as long as we are not accumulating more than ~20 GB or so, we should be able to test this pretty quickly). I thought it would be opportune time to suggest since you're likely debugging and having a clear systematic view of the code, etc., and I am happy to put together whatever you end up assembling in a gh-ci-compliant format :) |
94a1882
to
e56c1bc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved based on testing, which showed BFB results comparing a land domain file made with this tool vs one made with the Fortran version
@mahf708 I want to hold off on the testing idea mainly because I'm not sure how to write a coherent test. We could set it up to just go through motions and prove that it can produce a set of files, but I'm not sure how to test the output for any sort of correctness. So let's hold off. @singhbalwinder The issue that Jon identified is now fixed, so this PR is ready to be merged. |
As one last test I ran a quick test using F2010 on the ne30pg2_oECv3 grid replacing the default domain files with ones produced by the new tool and it ran without issue. However, I didn't do a baseline comparison. |
Adds a new tool to replace gen_domain in CIME "generate_domain_files_E3SM.py" is a new tool to replace the fortran gen_domain.F90 tool that exists in CIME. The old version was problematic to use because the build configuration was almost always broken when a user went to build it. The new python version works efficiently due to the numba package, which is included in the E3SM unified environment. [BFB] * whannah/new-gen_domain-tool: revert lfrac threshold and adjust default fminval add opts.lnd_mask_threshold for new gen domain tool remove "test" prefix for output domain files cosmetic fix misc bug fixes after PR changes switch bash to shell change yaml to yml typo fix in docs refactor domain generation tool remove un-used eps variable linter fixes update docs update docs add text to docs fix typo rename yaml file move domain tool and add documentation update tools/generate_domain_files_E3SM.py add new tool to replace gen_domain in cime
Merged to next |
"generate_domain_files_E3SM.py" is a new tool to replace the fortran
gen_domain.F90 tool that exists in CIME. The old version was problematic
to use because the build configuration was almost always broken when a
user went to build it. The new python version works efficiently due to
the numba package, which is included in the E3SM unified environment.
[BFB]