-
Notifications
You must be signed in to change notification settings - Fork 19
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
API docs updates #493
API docs updates #493
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #493 +/- ##
==========================================
+ Coverage 91.72% 91.73% +0.01%
==========================================
Files 110 110
Lines 6607 6617 +10
==========================================
+ Hits 6060 6070 +10
Misses 547 547
☔ View full report in Codecov by Sentry. |
RTD is failing because it is configured not to permit warnings; the warnings introduced by this PR are fixed in OpenFreeEnergy/gufe#210 |
docs/conf.py
Outdated
] | ||
|
||
autoclass_content = 'both' | ||
intersphinx_mapping = { | ||
"python": ("https://docs.python.org/3.7", None), |
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.
this should probably be our lowest supported version right? which iirc is 3.9 or 3.10?
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 follow NEP29 (in which case 3.9)?
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.
The installation guide just says 3.9 and 3.10 are tested so I'll update this to 3.9.
Co-authored-by: Richard Gowers <[email protected]>
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.
Looks good; some major improvements on what we had!
I had a couple of questions, but nothing that should block merging.
Modified to: | ||
- Write directly to Sphinx output directory | ||
- Infer targets if not given | ||
- Ensure ``target: Path`` in ``configure_path()`` | ||
- Return version number and thread safety from ``setup()`` | ||
- Use compressed style by default | ||
- More complete type checking | ||
""" |
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 there a reason not to open a PR upstream for these changes? I'm fine with vendoring for now, but if upstream will take the changes, I'd rather be able to remove this from our maintenance burden.
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.
The crucial change is that it now writes to the build directory rather than the source directory, which is helpful for minimising the mess that Sphinx re-builds can get into. Once I vendored it to fix that, it seemed worthwhile to make more changes to make it a more natural fit. I'll open a PR upstream and see what happens :)
@@ -34,7 +34,7 @@ The output of **setup** is an :class:`.AlchemicalNetwork`. This contains all | |||
the information about what is being simulated (e.g., what ligands, host proteins, solvation details etc) and the | |||
information about how to perform the simulation (the Protocol). | |||
|
|||
The output of the **executation** stage is the basic results from each edge. | |||
The output of the **execution** stage is the basic results from each edge. |
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.
😂 This had to be me writing, but why was I repeatedly typing "executation"? Thanks for the typo fixes!
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 like, "is this a word with a slightly different meaning that no-one understands the distinction of", like dynamic vs dynamical or alchemic vs alchemical 😆
# Inherited things | ||
|
||
forcefield_settings: OpenMMSystemGeneratorFFSettings | ||
"""Parameters to set up the force field with OpenMM Force Fields.""" | ||
thermo_settings: ThermoSettings | ||
"""Settings for thermodynamic parameters.""" | ||
|
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 take it there's no reasonable way to inherit these docstrings from parent classes? (Curious why, for my own understanding.)
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.
For forcefield_settings
, the base class is meant to be generic over other force field generators. For thermo_settings
, it could be placed in the base class with a PR to GUFE.
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.
it's late, feel free to accept / reject as needed.
@@ -149,7 +55,6 @@ def is_positive_distance(cls, v): | |||
raise ValueError(errmsg) | |||
return v | |||
|
|||
|
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.
Shouldn't this be two empty lines for PEP8?
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.
This is what happens when I can't use Black :(
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, with all my Canadian given authority, give you the unreserved power to apply black
to that entire file 🙃
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.
Sounds like a can of worms I probably shouldn't crack open just yet 😆
# Inherited things | ||
|
||
forcefield_settings: OpenMMSystemGeneratorFFSettings | ||
"""Parameters to set up the force field with OpenMM Force Fields.""" |
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.
Whilst this is true, I do worry this (talking about OpenMM Force Fields) might confuse the less experienced users? The intent originally was that this should just be "force field choices for how your system will be parameterized".
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.
Discussed in today's call - there's probably nothing we can do about this for v1.0.
alchemical_sampler_settings: AlchemicalSamplerSettings | ||
"""Settings for sampling within lambda windows.""" |
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.
"""Settings for sampling within lambda windows.""" | |
""" | |
Settings for alchemical space sampling, including the number of lambda windows | |
and simultaneous sampling replicas. | |
""" |
Something like that, simultaneous sampling replicas is quite a mouthful so feel free to reject. P.S. forgive the formatting it's late.
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.
The number of lambda windows is in AlchemicalSettings
, and alchemical space sampling sounds to me like it would be searching through a space that includes different alchemical states. AlchemicalSamplerSettings
seems focused on how to sample each window - could you clarify why my phrasing is incorrect/inadequate?
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.
re: number of lambda windows - you're 100% right, I'm muddling myself with n_replicas.
re: why I think we need to maybe reword - beyond "sampling within lambda space", these settings also tackle things like the online analysis interval, and (unfortunately) the number of whole repeats of the entire simulation. I was trying (and probably failing to) reword it as something that covers that wider space.
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.
Gotcha, I misunderstood how the protocol worked.
SettingsBaseModel, | ||
OpenMMSystemGeneratorFFSettings, | ||
ThermoSettings, | ||
) | ||
|
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.
Le PEP8?
Am I good to merge this? |
This PR:
equil_rfe_methods.py
to document protocol settings (important modules were mocked when they were present in the RTD environment)There's also one possibly controversial change:
RelativeHybridTopologyProtocolSettings.forcefield_settings: OpenMMSystemGeneratorFFSettings
. Previously it inherited theSettings.forcefield_settings: BaseForceFieldSettings
annotation. This is a Pydantic model so this annotation is a runtime behavior change.@dwhswenson and I briefly discussed this today. It seems like it may just be an oversight;
RelativeHybridTopologyProtocol
certainly assumes that it will beOpenMMSystemGeneratorFFSettings
and has no support for other classes, but maybe downstream consumers are re-using the settings class for their own protocols. The change makes it much easier to understand and find what's supposed to go where. I'm happy to revert this for now though and sort it out when I kick up a stink about the 3 different defaultRelativeHybridTopologyProtocolSettings
values 😅There are new Sphinx warnings, but they relate to docstrings in GUFE that I'll submit a PR to fix in a moment - I'm pretty confident I know what's going on but if I'm wrong I can fix it here too.
Developers certificate of origin