search

Amber-MD / cpptraj

Biomolecular simulation trajectory/data analysis.
Other
138 stars 64 forks source link

Add 'openmm' keyword to 'energy' action #1042

Closed drroe closed 1 year ago

drroe commented 1 year ago

Version 6.20.2. Add 'openmm' keyword to 'energy' action to use OpenMM (if support compiled in) to calculate total energy.

drroe commented 1 year ago

Not sure why the pytraj build fails - it works locally. Will try to re-run.

drroe commented 1 year ago

I hate python. Keeping python CI running is whack-a-mole nonsense.

hainm commented 1 year ago

I hate python. Keeping python CI running is whack-a-mole nonsense.

:D

swails commented 1 year ago

I hate python. Keeping python CI running is whack-a-mole nonsense.

I think pytraj may be a little over-tested. But the two real solutions I see here are:

  1. Find a proper maintainer for pytraj.
  2. Deprecate pytraj and push people towards alternatives like MDAnalysis or mdtraj.

I know pytraj is used (some people use it here at Entos), so the 83 "dependents" reported by GitHub is certainly an underestimate, and possibly significantly so.

Judging from my own experience with ParmEd, @hainm does not have the bandwidth to maintain pytraj (in my case, needs here at Entos now afford me to expend some time on ParmEd maintenance and development, but that was not always the case).

@drroe or @hainm - proposals or suggestions here? As it stands right now, pytraj is an unfair weight to tie around cpptraj development.

hainm commented 1 year ago

@swails yeah, I do not have much bandwidth to maintain pytraj nowadays. However, I always immediately work on resolving the issue if Dave or Dan pinged me. Deprecating pytraj is not an option since it is being used to access cpptraj functionality. pytraj also gets some citations here: https://scholar.google.com/scholar?hl=en&as_sdt=0%2C33&q=pytraj&btnG= and I still see see people are using it this year. :D

The option 1 seems reasonable, but I am not sure where to find a volunteer for that. So in general, I don't have any solution besides continuing to respond to requests from Dave and Dan.

pytraj may be a little over-tested.

agree.

swails commented 1 year ago

The current situation makes Dan the pytraj maintainer by default, albeit a maintainer who can call you in for help. If he gets frustrated enough with the cost of keeping pytraj working and decides to stop doing it and turn off the tests, then the end result is the deprecation of pytraj (if it can't be built, it won't be available).

Basically, if pytraj lacks a willing maintainer, the choice of deprecation falls to whoever is left holding the bag (Dan in this case). The fact that it's being used is not a hard blocker on ending support for the project (examples abound everywhere). The presence of conda packages will give people a band-aid to keep using it while they transition away. This is OK and happens all the time.

But I think it's important to understand Dan's frustration here as one of the classic steps on the pathway to choice 2.

drroe commented 1 year ago

First of all, I appreciate the in-depth and earnest commentary from @swails and @hainm - I thought my comment was just a little screaming into the void and didn't expect a response (although the conversation is certainly worth having).

If he gets frustrated enough with the cost of keeping pytraj working and decides to stop doing it and turn off the tests, then the end result is the deprecation of pytraj

I may not love developing in python, but I recognize its utility for users and I think pytraj is worth maintaining. @hainm has put a lot of work into it and I don't think it has run its course yet.

Basically, if pytraj lacks a willing maintainer, the choice of deprecation falls to whoever is left holding the bag

This is an important point, and perhaps worth a short virtual (zoom/hangouts) extended conversation if you two are up for it?