Skip to content
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

Merged
merged 21 commits into from
Jul 31, 2023
Merged

API docs updates #493

merged 21 commits into from
Jul 31, 2023

Conversation

Yoshanuikabundi
Copy link
Contributor

This PR:

  • Adds an improved stylesheet for the API reference
  • Fixes the root cause necessitating workarounds in equil_rfe_methods.py to document protocol settings (important modules were mocked when they were present in the RTD environment)
  • Organises the API reference with Autosummary for easier browsing
  • Adds more member documentation to the API docs
  • Sets up Intersphinx for linking to other documentation
  • Fixes some typos and mistakes in the installation and user guide docs

There's also one possibly controversial change:

  • Annotate RelativeHybridTopologyProtocolSettings.forcefield_settings: OpenMMSystemGeneratorFFSettings. Previously it inherited the Settings.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 be OpenMMSystemGeneratorFFSettings 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 default RelativeHybridTopologyProtocolSettings 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

@codecov
Copy link

codecov bot commented Jul 19, 2023

Codecov Report

Patch coverage: 100.00% and project coverage change: +0.01% 🎉

Comparison is base (2d0fdad) 91.72% compared to head (8ffdccf) 91.73%.
Report is 2 commits behind head on main.

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              
Files Changed Coverage Δ
openfe/protocols/openmm_rfe/equil_rfe_settings.py 87.44% <100.00%> (+0.61%) ⬆️

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@Yoshanuikabundi
Copy link
Contributor Author

RTD is failing because it is configured not to permit warnings; the warnings introduced by this PR are fixed in OpenFreeEnergy/gufe#210

docs/_ext/sass.py Outdated Show resolved Hide resolved
docs/conf.py Outdated
]

autoclass_content = 'both'
intersphinx_mapping = {
"python": ("https://docs.python.org/3.7", None),
Copy link
Contributor

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?

Copy link
Contributor Author

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)?

Copy link
Contributor Author

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.

Copy link
Member

@dwhswenson dwhswenson left a 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.

Comment on lines +7 to +14
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
"""
Copy link
Member

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.

Copy link
Contributor Author

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.
Copy link
Member

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!

Copy link
Contributor Author

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 😆

Comment on lines +427 to +433
# Inherited things

forcefield_settings: OpenMMSystemGeneratorFFSettings
"""Parameters to set up the force field with OpenMM Force Fields."""
thermo_settings: ThermoSettings
"""Settings for thermodynamic parameters."""

Copy link
Member

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.)

Copy link
Contributor Author

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.

Copy link
Member

@IAlibay IAlibay left a 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


Copy link
Member

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?

Copy link
Contributor Author

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 :(

Copy link
Member

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 🙃

Copy link
Contributor Author

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."""
Copy link
Member

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".

Copy link
Member

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.

openfe/protocols/openmm_rfe/equil_rfe_settings.py Outdated Show resolved Hide resolved
alchemical_sampler_settings: AlchemicalSamplerSettings
"""Settings for sampling within lambda windows."""
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"""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.

Copy link
Contributor Author

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?

Copy link
Member

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.

Copy link
Contributor Author

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,
)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

Le PEP8?

@Yoshanuikabundi
Copy link
Contributor Author

Am I good to merge this?

@IAlibay IAlibay merged commit b513ded into main Jul 31, 2023
6 checks passed
@IAlibay IAlibay deleted the docs-updates branch July 31, 2023 15:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants