| |
|---|
JW – Numerical RMSD differences | https://openforcefieldgroup.slack.com/archives/C03T3LLVC1J/p1747068401641489?thread_ts=1747066505.659669&cid=C03T3LLVC1J MT – FC had presented a few times LW – Initial issues was that PB showed some plots where 2.1.0 was best FF. Main difference seems to be different OMM settings (PB was using a very tight force tolderance). This probably happened because OMM changed its force units and there was a period of time where we hadn’t made a compensating change. Also, PB was using all atom RMSD whereas we use heavy atom RMSD. LW – Worth mentioning that PB’s scripts were very old, predating YAMMBS. MT – Are these values that we set specifically in our openMM settings, or using defaults/differences between engines/versions? MT – Now that this is starting to be used in presentations, we probably want to think about YAMMBS less as a strictly internal tool, and think of it more as a public-facing package. So I’ll need to shift my thinking around a few things about how we do docs/releasenotes.
|
MT – EEN → RMSE in torsion analysis? |
MT – What do we think of these changes/metrics? LW – I still mostly use RMSE. Don’t know what EEN is. I’m ambivalent about these new things getting added since I don’t use them. Are there downsides to adding them? MT – Major reason to not add is to keep from needing to rerun all the old torsion analysis. LW – I anticipate that every now and then we will need to rerun everything, so we might think about how this will interact with YDS and our archival strategies. MT – I’d hoped to not have to rerun by instead storing YAMMBS version in provenance of previous runs. LW – I’ve been avoiding using ddE from YAMMBS because of RMSD issue that BSwope raised. I’d meant to bring this up - BS pointed out that some confs minimize to quite faraway from their original conf, and proposed filtering out confs that land >0.4A from the QM minimum. So this is a good point, and I’ve avoided using ddE because I don’t know what the right value is MT – I hadn’t heard of this, would love a breadcrumb in this conversation to follow. LW – Sure, let’s discuss in a longer meeting.
MT – I’ll proceed with replacing EEN with RMSE JW – Why not include all the analyses? MT – My understanding is that RMSE is more standard, and EEN wouldn’t provide value that isn’t already in RMSE. LW – I. expect they’d show relatively similar patterns, some uncertainty about depenndence on number of points. ence on number of points. JW – FC had shown a really interesting metric this morning in ad board, I wonder if that’s in this PR as well - I’d think that’s a valuable metric if so.
MT – I’ll try to add RMSE and make a determination on whether EEN is valuable/whether to remove it.
|
MT – geomeTRIC vs. OpenMM optimization
|
MT – FC had found some behavior differences between OMM and GeomeTRIC opts (sometimes finding wholly different minima). One question is whether to go down this road at all, where either optimizer can be used. Would this be worthwhile? LW – LM had looked into this, determined that geometric optimized to a lower minimum in general, whereas OMM doesn’t stray far from local min. Having geometric as an option in YAMMBS would be useful. If we did that, we’d need to start deciding on settings as defaults, and I’d prefer OMM be default. JC – No strong preferences, though also less history. GeomeTRIC is meant for DFT minimizations where it’s supposed to get out of local minima to find a global one. For our benchmarking purposes, we WANT to capture/stay in local minima. So OMM may be best here. LW – Also the choice of coordinate system in geometric will have an effect, no clear way to say one or another is best.
MT – So it looks like this isn’t a high priority right now. But having GeomeTRIC as a non-default optimizer is a nice-to-have for future research.
|