About a more robust MBAR solver

[xiki-tempula]

Due to choderalab/pymbar#419, a number of downstream packages such as https://github.com/luancarvalhomartins/PyAutoFEP have to stick with alchemlyb 0.3.0 & pymbar 3.0.3. I'm thinking if it would be nice to have a more robust MBAR solver so that the downstream packages could use the latest version.

The pseudocode might be that

class MBAR(method=None):
    def fit(self,):
        if method is not None:
            pymbar.MBAR(method=method)
        else:
            try:
                pymbar.MBAR(method='adaptive')
            except:
                pymbar.MBAR(method='BFGS')

I'm aware that pymbar is working on solving this problem. I think it won't hurt to have an extra layer of protection at alchemlyb level.

[orbeckst]

Where would we put it? Into our estimators?

Would we be using it ourselves?

[xiki-tempula]

@orbeckst Yes, Into our estimators. When no method is provided, this fallback routine is used. When the method is supplied, it is used as is done now.

[mrshirts]

So to some extent, the solution is here: choderalab/pymbar#419 (comment) This is probably how it should be called internally in alchemlyb for now In terms of additional adaptive adjustments within MBAR, I have some pymbar work schedule, but it's probably not going to happen until after the semester is over in early December.

…

On Wed, Oct 20, 2021 at 1:56 PM Zhiyi Wu ***@***.***> wrote: @orbeckst <https://github.com/orbeckst> Yes, Into our estimators. When no method is provided, this fallback routine is used. When the method is supplied, it is used as is done now. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#170 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABATPVGTVXLFB6A2LYENRYLUH4NIFANCNFSM5F2DETKA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[xiki-tempula]

@mrshirts Thank you for the advice, I have adopted this comment in #162. However, for some cases, it still won't work for some cases, where switching to BFGS would solve the problem.

[orbeckst]

@xiki-tempula I can see the merit of your approach, at least in the short-to-midterm (until anything changes in pymbar for good). Do you want to start a PR and then we can hash out details there?

We could always make it a separate estimator, such as "AutoMBAR", to distinguish it from the actual pymbar implementation, just so that there's less confusion when results change after an upgrade.