Severe clashes much more common in 1.5

[PlethoraChutney]

Hello! I love ISOLDE!

I have noticed that since switching to v1.5 I'm getting the severe clash error more often.

ISOLDE has detected severe clashes in the model that the minimiser is unable to reconcile on its own. The simulation is still initialised, but cannot continue until these are corrected. Clicking OK will open the clash validation panel with a list of atoms currently experiencing extreme forces. In most cases these can be dealt with by choosing more appropriate rotamers. For more extreme issues you may need to stop the simulation and tell ISOLDE to temporarily ignore some residues using the command "isolde ignore {selection}". Once you have moved the adjacent atoms into non-clashing positions, you can stop the simulation and stop ignoring the residues using "isolde ~ignore".

NOTE: the true culprit may not necessarily be at the top of the list. Look for clashes that have no direct path away from each other (e.g. bonds threaded through rings). After rearranging atoms you may check to see if this has solved the problem by pressing the play button.

When I opened the clash panel for this most recent occurrence, the most severe clash (with an overlap of 0.75) is pictured below --- to my eye, this barely looks like a clash, let alone an irreconcilable one, but perhaps I'm not properly attuned to the fields :)

Often times, when this error occurs, discarding the simulation and starting again with the exact same selection, without modifying the coordinates or settings in any way, will not result in the clash error.

In any case, I wonder if there was a change to the minimizer (or to this error) which might have increased the frequency? Is there a setting I ought to change? I've tested with another model/map pair as well. I don't see anything in the log, but if there's more information you'd like, please let me know!

Information:

Param	Value
ISOLDE Version	1.5
ChimeraX Version	1.5rc202211091945 (2022-11-09)
Machine	M2 Macbook Air
Map Type	cryoEM
GSFSC resolutions tested	2.2, 2.8 A

[tristanic]

Hmm... that's concerning. I haven't made any changes that should cause this sort of behaviour. Can you point me to (or provide) an example that I can use to try to reproduce it?

…

On Sat, Nov 12, 2022 at 2:11 AM Rich ***@***.***> wrote: Hello! I love ISOLDE! I have noticed that since switching to v1.5 I'm getting the severe clash error more often. ISOLDE has detected severe clashes in the model that the minimiser is unable to reconcile on its own. The simulation is still initialised, but cannot continue until these are corrected. Clicking OK will open the clash validation panel with a list of atoms currently experiencing extreme forces. In most cases these can be dealt with by choosing more appropriate rotamers. For more extreme issues you may need to stop the simulation and tell ISOLDE to temporarily ignore some residues using the command "isolde ignore {selection}". Once you have moved the adjacent atoms into non-clashing positions, you can stop the simulation and stop ignoring the residues using "isolde ~ignore". NOTE: the true culprit may not necessarily be at the top of the list. Look for clashes that have no direct path away from each other (e.g. bonds threaded through rings). After rearranging atoms you may check to see if this has solved the problem by pressing the play button. When I opened the clash panel for this most recent occurrence, the most severe clash (with an overlap of 0.75) is pictured below --- to my eye, this barely looks like a clash, let alone an irreconcilable one, but perhaps I'm not properly attuned to the fields :) [image: image] <https://user-images.githubusercontent.com/27385979/201451589-138ed9ae-e142-470a-a263-9c28f61e1ba0.png> Often times, when this error occurs, discarding the simulation and starting again with the exact same selection, without modifying the coordinates or settings in any way, will not result in the clash error. In any case, I wonder if there was a change to the minimizer (or to this error) which might have increased the frequency? Is there a setting I ought to change? I've tested with another model/map pair as well. I don't see anything in the log, but if there's more information you'd like, please let me know! Information: Param Value ISOLDE Version 1.5 ChimeraX Version 1.5rc202211091945 (2022-11-09) Machine M2 Macbook Air Map Type cryoEM GSFSC resolutions tested 2.2, 2.8 A — Reply to this email directly, view it on GitHub <#12>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFM54YGIEXMVG7F3TGEGWODWH34EZANCNFSM6AAAAAAR6CT5T4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[PlethoraChutney]

Unfortunately I'm working with stuff I can't share yet, but I'm happy to poke around EMDB and find something :). I'll report back when I do!

[tristanic]

One other thought/hint: on reflection the text in that warning message could be a bit misleading in some unusual cases. It's triggered not by clashes *per se*, but by very large forces that the minimiser is unable to find a way to reduce. While that's *almost* always caused by clashes, there are some other possible scenarios that could lead to similar issues. "Hot" voxels (i.e. very large positive or negative values) in the map might do it, for instance. Some unusual geometry (e.g. a hydrogen shifted to sit right on top of its bonded neighbour) would not show up as a clash since bonded neighbours are ignored for that analysis. Might be worth running your model past a more comprehensive validation like MolProbity to see if anything jumps out at you. Meanwhile, I'll find the time to try a few different test cases on the Mac build - I've been using the Linux and Windows builds without trouble quite a bit lately, but I'll admit the Mac tends to get relatively light testing from me.

…

On Sat, Nov 12, 2022 at 4:27 PM Rich ***@***.***> wrote: Unfortunately I'm working with stuff I can't share yet, but I'm happy to poke around EMDB and find something :). I'll report back when I do! — Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFM54YBLZSHMXAHWF6JWRI3WH7AOXANCNFSM6AAAAAAR6CT5T4> . You are receiving this because you commented.Message ID: ***@***.***>

[PlethoraChutney]

That's a good tip --- these models score pretty well on MolProbity but IIRC the hydrogens get removed and re-added, so that might be it. And would much prefer the errors to not having a mac build at all so thank you either way :)

[tristanic]

I've had no success so far trying to replicate the behaviour you see, suggesting the problem is either one of hardware (or drivers?) or something specific to your model/map. Admittedly my test machine is a bit different to yours (2021 M1 Pro chip, not the M2). Given that Apple have officially deprecated OpenCL I can't rule out the idea they've introduced some new bug there, but I'd still suggest taking a close look at your particular scenario (with all hydrogens shown - "show H"; you can return to the default representation - only polar hydrogens shown - later with "hide HC"). Go through the first dozen or so clashes to see if anything jumps out at you; see if the map histogram looks sensible; check the map weight in the "Non-crystallographic map settings" widget. The algorithm I use for automatically guessing a reasonable map weight assumes the model is already reasonably well docked when you first initialise it; if that's not the case it could end up setting the weight far too high which can in theory lead to this. Maybe try reducing the map weight 10-fold and then gradually adjusting it back up until the behaviour seems reasonable (i.e. the atoms are pulled nicely into the map without introducing undue distortion) - you can adjust on the fly in a running simulation so this can be reasonably fast.

Other than that, without a reproducible test case there's not much I can do to diagnose and fix this. Please do let me know if you find a publicly-available one or when your current one becomes shareable.