Like FF users, OFFXML parser writers. And the categories of things we might get feedback on include (1) clarification, (2) affects existing behavior, (3) experimental, (4) things we think we need MT – These are good categories. JW mentioned “breaking parsers” and “spec changes” as if they were synonymous. But there are spec changes that wouldn’t break main-line FF parsing. Right now if we ship a FF with LJPME, WBOs, vsites (things that are already in-spec) most parsers will break because they never bothered to implement it. JC – We can put changes into categories and push proposals to be more minimal. JW: The really scary/most to avoid spec change is ones that change the meaning of a prior force field, e.g. changing energies from parsley. But adding a new keyword: NBD. JC: So new changes should require categories, alters processes for consideration and notification. Documentation clarifications straightforward, for ex. MT – There’s already a section in the SEP template where you have to identify effects. JW: Driver should identify category it’s in.
Are we happy with committee composition? Should all decisions continue to require unanimity? DM – Instead of “explicit yes”, how about “absence of veto”? JC – Since folks travel, how about leaving time for asynchronous feedback? DM – That’s a good idea. JW – Could have a system where “no feedback” for two consecutive meetings means “implicit approve” MT – Would prefer some system where “3 yeses and no feedback for a while means 4 yeses”. DM – I propose “we try to have monthly meetings but if we don’t get feedback for a while then assume yes” LW – I think JC was saying that meetings should be used primarily for unblocking. JC – Yes DM – I think the GH issue feedback needs to be clear for asynchronous communication to work. JC – GitHub PR tools can help here. So we can explicitly approve, comment, or request changes. Can also just require “no negative votes”. LW – Two weeks for time bombs would be good. JW – S (General) – Changes are approved with 4 “Accepts”, “2 accepts + 2 weeks, and no request-changes”, and if there’s a “request-changes” that isn’t resolved, that becomes an agenda item in a meeting (General) – We’ll have a standing meeting each month and will just cancel if there’s nothing to discuss.
Should we be expected to read spec proposals ahead of time? Or set aside in-meeting time, Amazon-style? DLM background: Current process owned too much by infrastructure team, including: (possibly) define spec change Review change, discuss spec change, answer questions, defend spec change, carefully consider all aspects Get stakeholders to agree/iterate to convergence implement
Creates perverse/adverse incentives: Requires a huge amount of work to define the work that needs to be done. Possible new procedure:
|
Add LJPME to spec | MT | | Github link macro |
|---|
| link | https://github.com/openforcefield/standards/pull/55 |
|---|
|
JC – Would it make sense to say “conductingboundary” for vdW? And is it just the r^6 term that gets handled or also r^12. MT – Not sure, just copied language from electrostatics JC – we should clarify combinations of options and make sure there’s room in the future to add more if necessary MT – this way of adding new methods should be very amenable to future methods or variations. The scope of this proposal isn’t to fully define LJPME (electrostatics correspondingly doesn’t fully define PME). JC – That’s right. Here vdW can have different forms like buckingham, 12-6, 10-6, etc. Does LJPME apply to all power terms here? MT – is there a standard in the community? JC – not sure. I don’t think it makes sense to do the 12 MT – Re: Handling non-12-6 - That’s tricky. It’d be easy to say “this only applies to 12-6 lennard jones”. JC – From the science perspective, it’s not unreasonable that we might do PME for the r^6, and something else for other powers. JW – We could MT – JC – Might this block us from doing anything in the future? MT + JW – I don’t think so. JC – OpenMM only includes 1/r6 part MT – I’ll think about how to better communicate this in the keyword description. Also “conductingboundary” doesn’t make a lot of sense. JC – Also, this will only work with arithmetic combining rules. Geometric would take other work. There’s a paper from the GROMACS folks about it. https://pubs.acs.org/doi/full/10.1021/acs.jctc.5b00726 . The current default, Lorentz-berthelot is geometric for epsilon but arithmetic for sigma. MT – Also, does this require a version bump? (General) – We’ll anticipate the PR to be reviewed asynchronously, on GitHub.
|