Open tlhr opened 2 months ago
@tlhr are you getting these failures with pymbar 3 or just solely with pymbar 4?
If it's happening with pymbar 3 then we definitely would love more details - this is something we haven't observed as much on our end.
As you mention the current solver protocol for pymbar 4 isn't set to the robust one by default - it's on ours (and the OpenMMTools' team) todo list to validate enforcing the use of the robust solver, we will hopefully do this soon enough. For now, we recommend that folks stick to pymbar 3 unless they have a specific use case that prevents them from doing this.
@IAlibay it's indeed happening with pymbar 3 and all the default settings. Unfortunately I can't share the structure, but is there any other information I can give you on the transformation that might help?
@tlhr possible things to try;
Sorry for the very quick responses, we'll try to triage this properly a bit later in the week.
Post the mbar overlap matrix and the forward and reverse analysis if possible
Apologies, I'm realising this isnt possible, if the simulation is failing 😅
@tlhr could you report the OpenFE version you're using? There's a known bug in versions 0.14 to pre 1.0 that could be the cause of this.
I've noticed that for some systems legs fail due to:
This example was an RBFE solvent leg running for 10 ns with 15 lambda windows, so I would have expected adequate sampling. Could it be related to this PyMBAR issue? My analysis succeeds when I force an update to PyMBAR 4.0.3 and modify
MultistateEquilFEAnalysis
to passanalysis_kwargs={"solver_protocol": "robust"}
toMultiStateSamplerAnalyzer
as suggested in the last comment. Maybe this could be made the default? I guess this is also related to #443.