Page Comparison

MT – vdW methods and periodicity:

• MT – The straightforward solution is to do something like what we’d done with electrostatics. and split periodic and nonperiodic potentials.

• JW – What would the vdW keywords change to?

  • MT – potential would stay, method would split into periodic_method and nonperiodic_method This should make us ready to switch to LJPME when the day comes.

  • (MT taking notes in a comment on that issue)

• JW –

• MT – I’m

• JW – Is there a case where users will get totally stopped in trying to do something like a vacuum simulation in AMBER by specifying this?

  • …

  • (General) – If that happens, there will probably be a workaround that experts would use anyway. So we should go ahead and draft

• Pre-EP summary comment:

  Github link macro
  link https://github.com/openforcefield/standards/issues/51#issuecomment-1659340028

Committee composition?

• DM + LW – Change rules to majority?

• JW – Have reviewer “pools” - like “technical” and “scientific”, requiring approvals from both?

• MT – I’d like to make sure that we have organizational capacity to get changes through to the finish line. I think it’s too easy to let things lose momentum on GitHub. I like the idea of monthly meetings, which are cancelled ahead of time if there’s no agenda.

  • DM – Yeah, we’d need JC for that discussion.

JW/DM – Committee tempo/ procedures

• Recap issues discussed previously in /wiki/spaces/MEET/pages/2590736396

  • Brief summary: 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 all 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:

    • The infrastructure team is only involved in review, final approval, and implementation; there needs to be another driver

      • Driver has the right to limit scope, e.g. “This is a good thing to consider but falls outside scope of current proposal; suggester can create new proposal and be driver on that”

    • Relevant committee commits to meet at some predictable frequency to make synchronous decisions

      • Meet monthly on recurring schedule and change voting?

      • Or meet one-off each month?

    • Batching small changes so a variety go into a spec update

      • e.g. Q4-2023 branch which will have several different EPs merged into it that will eventually go into next point release of section spec, e.g. 0.5, when quarter’s changes wrap up.

      • Proposed goal: Release once a quarter, but changes are approved and can be implemented once EPs merged.

  • Suggested monthly meeting

    • Should we change committee composition and/or requirements to make a recurring meeting? Or schedule one-off each month?

• Next steps:

  • Reschedule and use john.chodera@choderalab.org to make sure JC gets the invite

    • JC will share his calendar for recurring availability

  • Draft up a pre-EP for JC to review

    • MT – This is basically the comment I just put on the issue

    • https://github.com/openforcefield/standards/issues/51#issuecomment-1659340028

    • JC will review this tonight

  • Draft up a full EP for JC to review.

    • JW – I’d be fine with shorter EPs