2020-04-15 Interoperability chat

interoperability

• Can we design a system object for our needs and add in interoperability glue later on?

  • Yes

pydantic

• MolSSI has done a lot of work building things off of pydantic objects - insights on what went well, didn’t go well, if this should be the path forward

  • LN: Generally like pydantic, not useful for everything, but good when validation and serialization are useful

  • JW: big fan of pydantic since a lot of stuff needs serialization

  • LN: Not quite as clean-cut as a silver bullet, i.e. it is pure Python so not particularly fast and not a good fit when high-throughput is necessary

community and cultural aspects

• How to enable community involvement without necessarily depending on it

  • Not explicitly discussed in our meeting, but an API-first approach (as distinct from a “class-first” sort of approach) may be easier to adopt

MolSSI status in this space

LN:

• MolSSI still interested in this, current project would benefit from it but isn’t necessary.

• Basically come to the conclusion that a broad, grand interoperability CLASS that the community agrees upon is not feasible. But what you can make some progress in is an API (i.e. not a single class) that people can use.

• It would be great to go interoperability first, since that’s better design. But it will be a lot of work, require a lot of community buy-in, etc. and therefore maybe not so tractable.

General discussion

It would be better to have an API that specifies stuff users need (they care about to_my_thing, not the object that stores the data) and

key point (JW agreeing with LN): needs to PROVIDE FUNCTIONALITY, and whatever structure accomplishes that is a nice secondary goal

LN: two issues you will run into

1. People have different definitions for particular scopes, i.e. a “System” means one thing for OpenMM and another thing for other scopes (i.e. is the thermodynamic state included in the system? the OpenMM concept of a context doesn’t mean anything scientifically, but is useful for defining how to interact with the hardware). Similar issues with defining a Molecule. TO DO: Figure out the SET OF INFORMATION we need, the SET OF INFORMATION the USERS need, and how to marry those aims. Simply doing a super-union of everything anybody could ever consider a part of a “system” is not tractable

2. “why does everybody want to go TO something?” this is a good question to follow-up with other questions

   1. why always TO?

   2. what are users coming FROM? always some intermediate X? or is it that the starting point doesn’t accomplish enough of the users' needs?

   3. why isn’t the community trying to migrate towards something better?

   4. “the inertia of doing nothing” if we want to get people to use something new, we need to overcome the inertia of “well what I have works”

      1. JW: pushback in that we have something that people want (our force fields) and could use that to pressure people to use our stuff

      2. LN: pushback-back: that’s creating a barrier, and could put people off of using OpenFF infrastructure

   5. (general point) need to asses WHAT PEOPLE NEED and go from there

two kinda different fundamental philosophies (LN isn’t saying one is best)

• Make a central class that does everything (probably lossless) and makes conversions unnecessary since everything will be built off of the same class/object/structure

  • We generally agreed this is a colossal amount of work (technical and community)

• Make interoperability the main goal (i.e. make conversions easiest) and classes just enough to facilitate the interoperability

  • This seems much more tractable in the short-term, but still takes a significant amount of design effort

It’s not clear that a middle ground between these two is impossible

people say what they want, our job is to figure out what they NEED (or actually want, not what they say; what they say they need is what fixes things this week vs. what the community needs more broadly and what people will want in 5 years)

JW’s idea for two paths forward

• option A: build something that works now for current requirements and plan to make a set of major API-breaking changes (i.e. a 1.x release) that improves based on things learned while developing and using 0.x (the common approach, although the spirit of a 1.0 release almost never happens)

• option B: think really hard for a long time and only make something when we know exactly what we want (tremendously difficult and comes in conflict with other objects)