Replies: 14 comments 17 replies
-
|
Not having jax a required dependency would be good. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I understand. I think, this discussion was looking at the possibility to make it optional at the pymbar level so that it wouldn't have been pulled in automatically with alchemlyb. But making the decisions to make it required for pymbar is fine — I assume it installs without problems from pypi and from conda-forge. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, good question. pymbar does install JAX, as we were not able to figure out a good way to handle it to have two releases. It's all conda installable, so that should help that at least? No need to manually do anything. Pymbar can run without jax, if the jax install fails for whatever reason (Though it's 2x slower). pymbar does not do any GPU configuration or pull GPU libraries, so that removes that chance of something breaking. Other thoughts on this? |
Beta Was this translation helpful? Give feedback.
-
|
Correct. We would not have made JAX a dependency if it didn't install without problems from conda-forge (I HAVEN'T checked pypi installation, though). |
Beta Was this translation helpful? Give feedback.
-
|
My main concern was GPU libraries etc so if the dependency chain remains light-weight, I don't have particular concerns. At the end of the day, pymbar should present the best user experience out of the box so alchemlyb will simply follow. Thanks for all the hard work on pymbar, @mrshirts ! |
Beta Was this translation helpful? Give feedback.
-
|
Yes, GPU libraries are NOT downloaded, users need to configure that themselves, so that avoids that concern. My pleasure to help out. Please don't hesitate to reach out on any issues involving the actual calculation or reporting of free energies (i.e. anything post file parsing). |
Beta Was this translation helpful? Give feedback.
-
|
Is there a way to make an optional dependency? We could release 2 packages, I'm not sure how complicated that would be. Fortunately the amount of different code is low. |
Beta Was this translation helpful? Give feedback.
-
|
I think the answer is yes, at least for the PyPi package, as long as your code fails gracefully and just complains that the user has to install this other package. In setuptools there is a way to handle optional dependencies. For conda packages, you probably should make the standard conda package install everything as this is likely what most of your users want. I am not sure if it's worthwhile to create a "light" package with reduced dependencies (although we're doing exactly that for the panedr package at the moment so that pandas becomes an optional dependency). |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, so my instinct would to be include JAX in the conda-install, whether the have the correct GPU support might be up to the user (it will run either way). I'm not sure about PyPi packaging, we've been more focused on conda. |
Beta Was this translation helpful? Give feedback.
-
|
We package for PyPi first and then let the condaforge regrocf autobot pick up the package from PyPi and automatically create the PR on the condaforge feedstock. If all goes well, you only need approve the PR and merge. |
Beta Was this translation helpful? Give feedback.
-
|
@mrshirts Many thanks for the work. I wonder the pymbar 4.0 is API stable now? So I could have a test to see what are the differences that needs to be made in alchemlyb. |
Beta Was this translation helpful? Give feedback.
-
|
Essentially, yes. The key changes are returns as dictionaries, and
standardized snake_case command names. I might add additional return values
for bootstrapping, but that would not break things (and is one of the
reasons to switch to a dictionary). The common commands should not change
either.
Apologies that the documentation for the API is not yet done, that's one of
the tasks for the 4.0 release!
…On Sun, Jul 3, 2022 at 4:18 AM Zhiyi Wu ***@***.***> wrote:
@mrshirts <https://github.com/mrshirts> Many thanks for the work. I
wonder the pymbar 4.0 is API stable now? So I could have a test to see what
are the differences that needs to be made in alchemlyb.
—
Reply to this email directly, view it on GitHub
<#204 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABATPVCBYMSFAFH3GBJHDJ3VSFSIFANCNFSM52HWEN4A>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
@mrshirts Thank you for answering. I wonder what is the plan for the current pymbar 3? Would it be like py2/py3 where pymbar 3 will stay on for some time or everything will go to pymbar 4? |
Beta Was this translation helpful? Give feedback.
-
|
So there has been a bit more solidification on the plans - there will be a long term maintenance version of pymbar3 for 6-12 months or so, but only critical updates will go in (maybe one or two features that the Chodera lab wants, but those won't be as well tested/integrated). |
Beta Was this translation helpful? Give feedback.
-
|
There is not yet consensus on this. I need feedback from a few more people. If you have a suggestion, let me know. Given the difficulty of maintaining two branches given personnel (mostly just me), probably not for very long. |
Beta Was this translation helpful? Give feedback.
-
|
In how far do pymbar 3 and 4 give the same results? I.e., will there be a sizable interest to keep the 3.x branch alive? |
Beta Was this translation helpful? Give feedback.
-
|
They all solve the same equations, just additional functionality (like bootstrapping), speed, and robustness. I cannot maintain both, pymbar 4 would be the successor that contains the lessons learned in making pymbar so far. |
Beta Was this translation helpful? Give feedback.
-
|
I take this as a "no" ;-) — then the only reason for using pymbar 3.x is for historical comparisons. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I'd like to just keep one branch, the most recent. |
Beta Was this translation helpful? Give feedback.
-
|
@mrshirts Thanks. I was looking at the code and thinking of it. If the result is returned as dictionary, can we assume that the dictionary will definitely have certain keywords with defined output or it is a more fluid situation? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, you can assume the dictionaries will have the keywords they now have. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, we are not planning on the keywords changing. Possibly some could be added, but the plan is for them not to change anymore (on the forseeable timeline). |
Beta Was this translation helpful? Give feedback.
-
|
For alchemlyb we will not be able to support pymbar 3 and 4 in parallel — that's just too complicated. I propose that we are aiming for an alchemlyb 1.0 release that supports pymbar 3.x. (We should to do a 1.0 anyway...) We can then start work on alchemlyb 2.0 with pymbar 4.x. In this way it is very clear what is supported and we have at least the option to backport 2.x fixes to 1.x if really necessary (although that will mostly depend on someone offering to do the work...). |
Beta Was this translation helpful? Give feedback.
-
|
I made this issue a Discussion thread. We can spawn specific issues from it in the issue tracker. |
Beta Was this translation helpful? Give feedback.
-
|
OK, pymbar 4 is released! https://github.com/choderalab/pymbar/releases/tag/4.0.1. Documentation on changes is in https://pymbar.readthedocs.io/en/master/, and I don't think will be that hard. Please post any issues you see! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! Will open an issue for updating alchemlyb. |
Beta Was this translation helpful? Give feedback.
-
|
See new issue #207 |
Beta Was this translation helpful? Give feedback.
-
|
Just as context for this thread: pymbar is also supporting 3.x LTS releases (see the new 3.1 LTS release and the note in 4.0.0
|
Beta Was this translation helpful? Give feedback.
-
|
With PR #268 ready to be merged, we are on track to soon provide alchemlyb 2.0.0 with exclusive support for pymbar 4.x. |
Beta Was this translation helpful? Give feedback.
-
|
We released alchemlyb 2.0.0 on conda-forge and pypi. It is based on pymbar >= 4. |
Beta Was this translation helpful? Give feedback.
-
We are moving towards a pymbar 4.0 release in the next while (exact timing to be determined, could be on the order of weeks). The current state of the 4.0 code is at https://github.com/choderalab/pymbar/tree/pymbar4/
The main points are:
The API is not yet fully documented, but you can see the calls in https://github.com/choderalab/pymbar/tree/pymbar4/examples, for example. We will try try to get something more concrete soon.
We are also looking at acceleration with jax. Are there advantages to making this optional, rather than required, to fit into alchemlyb workflows better? Are there issues with adding jax dependencies?
How can we help to make incorporation easier?
Now is also a good time for any other suggestions.
Beta Was this translation helpful? Give feedback.
All reactions