Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

Participants

Discussion topics

Item

Notes

0.1.0beta1 scientific review

  • Long thread: https://openforcefieldgroup.slack.com/archives/C03T3LLVC1J/p1729531583859449

  • 180 conformers out of 80k optimize to slightly different structures, which led to most of the differences in the results. Discussion between AMI and BW came to conclusion this was expected deviation. Some of the small deviations led to relatively large (~0.5 kcal/mol) in total energy

  • BW - nothing to add, AM did the hard work

  • Decision: This beta is good to go

  • MT: less than 1% conformers optimizing to something different is informative to seeing how opts differ between runs. Is this similar to what you would expect?

Torsions

https://github.com/openforcefield/yammbs/pull/76

MT – Nevermind, no input needed

Feature requests

MT – Plan to include biopolymer benchmarks

MT – In-YAMMBS filtering

MT – Non-QCA datasets

BW - Parallelize data ingestion & metric computation (not minimization)

LW – (forgot the name of the actual benchmark) but the torsionnet-style torsion benchmark that compares minima matching/placement as well as energy profiles

LW – all the easy NAGL benchmarks to QM properties to ESPs, dipoles, electric fields (code for this exists as part of nagl project repo)

LW – dimer energy benchmarks – the energy part is easy but dimers might not be currently technically supported (I have code for this somewhere)

LW – (related to ICRMSDs) – being able to compare MM vs QM values per-parameter. (There’s code for this in the sage-2.2.1 repo)

BW – A once-over on performance - especially dataset loading and metric computation. The middle part (where we run minimizations) scales really well on more CPUs. But dataset loading and metric computation is bottleneck.

LM – We’ve discussed not considering DDEs of molecules that are really structurally different from each other (like, with huge RMSDs). I’d be happy to help with this.

Strategy for making YAMMBS public-facing

MT – Not advocating a big season-2-benchmarking style effort

LW – So, making YAMMBS publicly available, but not leading a big benchmarking effort

  • MT – Yes

LW – I’m in favor of this, is maintenance affordable?

JW – Will depend a lot on details

MT – Let’s leave this for another meeting

Action items

  •  

Decisions

  • No labels