-
Notifications
You must be signed in to change notification settings - Fork 11
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
Updating submodules and pace refactor #75
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.
Two quick questions on the driver init and relative imports, just because it looks a little awkward but nothing blocking
driver/pace/driver/__init__.py
Outdated
MonitorDiagnostics, | ||
NullDiagnostics, | ||
ZSelect, |
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.
What's the logic behind adding these here?
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.
I was just copying what was done in NDSL, with exposing without rationale, and then un-exposing when it is deemed unnecessary.
driver/pace/driver/run.py
Outdated
@@ -6,8 +6,7 @@ | |||
import yaml | |||
|
|||
from ndsl.logging import AVAILABLE_LOG_LEVELS, ndsl_log | |||
|
|||
from .driver import Driver, DriverConfig | |||
from pace.driver.driver import Driver, DriverConfig |
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.
What's the reason for this change?
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.
I am following the style that was set forth in how I handled imports in the submodules. When I am within a package and I am referencing something internal to the package, the absolute path is used, when outside the package the relative path is used.
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.
Yeah that makes sense, it just looks funny here
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.
👍
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.
As I look at the driver/pace/driver code I have a question about what we are building with Pace. If Pace is designed to be the model and we will be adding other components (land, ice, ocean, waves, etc.) within, I'm not sure it makes senes to treat the driver as a submodule. However, if we envision Pace being say the atmospheric component within a larger module, it does make sense to leave the submodule treatment in place.
@oelbert ? |
My understanding has been that Pace is solely an atmospheric model and any ocean or land model would be separate |
Currently Pace is intended to be an atmosphere model, possibly containing a
land component. Ocean and ice are separate from Pace's scope.
Lucas
…On Tue, Apr 9, 2024 at 5:01 PM Oliver Elbert ***@***.***> wrote:
My understanding has been that Pace is solely an atmospheric model and any
ocean or land model would be separate
—
Reply to this email directly, view it on GitHub
<#75 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMUQRVBBT3NTRO5LWX5ZW5DY4RJKDAVCNFSM6AAAAABFCCM2UOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBWGAZTSOBTGM>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
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.
We are using srun in the .jenkins code. Should we use a macro that can be either srun or mpirun as we shouldn't always assume a slurm environment?
Is all of the documentation that is NDSL, pyFV3, or pySHiELD specific also duplicated in those repos? Or better yet, it should live in those repos and become available via the submodule includes.
The driver/pace structure still seems redundant to me. Perhaps it is my lack of Python semantics, but we are in the Pace repo and have a driver/. Why do I need to yet again remind you this is pace by having driver/pace/? Is it better to have pace/ or pace/driver so that all references are pace.X or pace.driver.X?
@@ -142,8 +142,8 @@ test_mpi_54rank: | |||
mpirun -n 54 $(MPIRUN_ARGS) python3 -m mpi4py -m pytest tests/mpi_54rank |
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.
Will we always be using mpirun here or is there a chance it could be another invoker?
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.
A change here would be prompted by a change in the docker image
driver/pace/README.md
Outdated
|
||
This package provides command-line routines to run the Pace model, and utilities to write model driver scripts. | ||
|
||
We suggest reading the code in the examples directory, or taking a look at `pace/driver/run.py` to see how the main entrypoint for this package works. | ||
We suggest reading the code in the examples directory, or taking a look at `driver/pace/driver/run.py` to see how the main entrypoint for this package works. |
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.
Did the structure change to driver/pace/run.py or is it still driver/pace/driver/run.py?
pace/driver/pace/driver/* structure is definitely a relic of Pace's development history, and we want to resolve that. Do you think we should do it here or in a separate PR? |
In response to this comment, this PR is already renaming things from driver/pace/driver. Instead of doing it yet again, I was hoping we could get the structure set in one step. As always, I want the approach with the least chance of breaking things. |
Currently the method of setting up the
Current:
I chose
As opposed to what existed previously:
We can change the use of
This will however not use the requirements file method, and will require some minor changes elsewhere, like in the github workflows, etc. I have tested both of these methods and went with the former as it keeps prevents a need to change the other files. If the latter is preferred the changes can be easily made. Also, I am not attached to the name |
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 taking my suggestions regarding structure. You've done a great job making it work. There are two minor nits that could be saved for a future issue/PR.
pace/README.md
Outdated
|
||
This package provides command-line routines to run the Pace model, and utilities to write model driver scripts. | ||
|
||
We suggest reading the code in the examples directory, or taking a look at `pace/driver/run.py` to see how the main entrypoint for this package works. | ||
We suggest reading the code in the examples directory, or taking a look at `driver/pace/driver/run.py` to see how the main entrypoint for this package works. |
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.
I think this should be pace/run.py
.
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.
Amended in 15fc295
setup_requires=setup_requirements, | ||
tests_require=test_requirements, | ||
name="pace-driver", | ||
name="pace", |
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.
Do we need to update more of this info here in the setup block here?
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.
I think this may be a good issue as I am not sure what would be appropriate to retain relating to the AI2 work.
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.
Phew, that's a lot of changes!
@@ -0,0 +1,31 @@ | |||
name: "Main unit tests" |
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.
Is this workflow file needed?
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.
Are the tests contained within that directory also tested in CI? If so, it can be removed.
Description
This PR updates the
NDSL
,pyFV3
, andpySHiELD
submodules to most recent commits, reflecting the standardized import methods.How Has This Been Tested?
Tested using the currently implemented unit tests in
tests/main
Checklist: