CBy – What are numerical instability issues? Would they be severe?
LW – BSwope had mentioned that there could be one. He was unsure about the severity.
MS – Can lead to crashes
JW --My experience is that this leads kinetic energy to get dumped into the system, leading to a higher sim temperature than the thermostat is set to (or crashes)
CBy – I think it’s such a small difference that there aren’t major consequences to setting to 180.
LW – I see two possible directions:
Do like GAFF and set it to nonlinear but with a high enough force constant to never hit the cusp
Set to 180 to remove the cusp, and flag for possible future work.
JW + MS + CBy – We’re in favor of this one.
LW – I’ll plan to release with original k values (not from MSMs).
CBy – At OE, as we’ve started using 2.2.0, we’ve seen improvements on sulfonamides. But we’ve seen issues in nonequilibrium switching with cyclopropyl substituents. Wondering if this is related to the resonance issue with C#C triple bonds. So I wonder if we should do vibrational calcs on standard functional groups that could lead to this kind of problem. I don’t have a smoking gun right now. But in general, can we screen for this ahead of time?
LW – You’re suggesting having a validation phase looking at frequencies/to catch resonance problems as part of FF release process?
MS – Do you know what the specific issue with high frequencies is?
CBy – Not sure, the previous case involved triple bond with methyl.
MS – My impression with that was that the frequencies were just too fast, not something harmonic/resonance related.
CBy – Unsure currently. But I’d like to screen for this proactively.
MS – My understanding is that, with integrators, if the
JW – I feel strongly this should not delay a bugfix release. We don’t know that the problem exists, what the root cause is, or whether these changes affect them. This shouldn’t delay the release.
CBy – Fair
JW – In general we would need a reproducing case to understand whether HMR/hybrid molecules were used and whether this is a problem that is within scope for the FF to fix.
CBy – That’s fair.
JW – Reminder of other changes in 2.2.1?
LW – A few small things with other angles and impropers. Some parameters changed a bit but overall agreement with QM was improved.
NAGL charges lookup table update
LW
JW – I’d be in favor of raising an error
CBy – I’m concerned about the quality of OE AM1BCC on these tiny mols. I think it would be good to compare these to RESP charges. I bet OE AM1BCC charges won’t be useful on these tiny mols.
MS – Even cyanide?
CBy – Those would be ok, probably acetonitrile as well. but those were probably IN the training set I used.
MS – If we switched to RESP, I’m worried that it’ll be less suitable since AM1BCC plays well with our vdW.
MS – Also, RESP charges may improve some of the problems we’re seeing for liquid properties like with chloroform.
CBy – It’s possible that common solvents should be carefully tunes
MS – If we just say that NAGL is a replacement for AM1BCC, then the lookup table should use AM1BCC, and we can ALSO say “maybe we need to do more after this”, like RESP.
CBy – Or matching QM electrostatic potential. What’s got me concerned is that AM1BCC is not suitable for tiny molecules.
MS – Yes, but people are CURRENTLY using AM1BCC as implemented here
LW – My argument for not raising an error on mols out of the 800 mols is that it’ll fall back to ambertools
LW – Also, if we don’t raise an error in nagl, then these will get the default NAGL treatment. That’s OK. Otherwise NAGL becomes a gatekeeper for chemical sanity. I propose keeping the AmberTools charges.
CBy – I see that these 3-atom mols are out of scope. But overall it’s a question of whether we accept weird looking inputs. And that’s kinda the user’s business. So basically, we could document that, for mols that are out of scope for our BCCs they may get weird results, but we aren’t in a position to police those. (I agree with LW?)
JW – Agree w LW
MS – Agree w LW
PB (chat) – Does the OE license allow us to cache the charges in a look up table?
CBy – Yes, I think this is fine.
JW – IIRC, we explicitly got permissions for this. Or at least, I don’t see a major distinction between releasing chargesd mols
MS – We should explicitly get approval from this
CBy – OE doesn’t OWN AM1BCC. So OE’s concern is whether you’re reverse-engineering. Releasing some mols doesn’t seem to be a violation. AM1BCC isn’t a proprietary method, and ELF10 was publicly disclosed before it was implemented. So the issue wouldn’t be with the 3 atom molecules, but rather with the general method offering. And AM1BCC is a publicly disclosed method, and there are numerous implementations, so that can’t be a problem. So I wouldn’t go looking for trouble on this.
LW – Though we’re caching the results of running the implementation.
CBy – As the major liason for OE, I think this is all above board.
.
MS – What’s the best way to get this documented in a preprint? Would need to be a data dump somewhere of like 6 hours of Lily’s understanding written down, and then I could take it from there.
LW – I think this is super important, especially since we’re going to start on more advanced nagl later this year. Was thinkign of making a bulleted list as the beginning of a manuscript
MS – That would be great, I could start from that.
LM – I’m happy to help write, since I’m going to be picking up NAGL
CBy – For NAGL2, you don’t need BCCs, instead you can fit directly to ESPs.
LW – NAGL1 already trains to ESPs as part of the objective function. What I’m predicting will give the best results will be dropping fitting to anything BUT ESPs.
CBy – Could be even better to fit to electric field.
LW – Some memory issues there, but I haven’t looked closely. Possibly big gains to be made there by improving implementation.
CBy – I’m quite excited about the possibilities here.
