Dead kernels

[bjorgve]

When mrcpp hits a MSG_ABORT. It kills the notebook kernel. We should make sure we find all of these and deal with them
from the vampyr side of the code.

I suggest we list code that lead to a dead kernel here, so that it's easier for us til fix them in the future:

• fetchEndNode when index is out of bound

[stigrj]

Do we know how to handle them on the Python side?

[bjorgve]

No, but we need to hack it some way. I believe we make sure we never have empty FunctionTrees on the Python side. Am I correct?

Or is this "fixed" in mrcpp?

[robertodr]

I don't think you can recover if you hit `abort`. If you raise exceptions you can capture and reraise them, similarly with error codes.

…

On Tue, Oct 12, 2021, 21:10 Magnar Bjorgve ***@***.***> wrote: No, but we need to hack it some way. I believe we make sure we never have empty FunctionTrees on the Python side. Am I correct? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#67 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4JOEIFXILMBKV6RFJC75LUGSBZHANCNFSM5F3J5ZVQ> . 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>.

[robertodr]

Using std::optional is another option: https://en.cppreference.com/w/cpp/utility/optional But it's MRCPP-side, not VAMPyR-side.

[bjorgve]

I was thinking something like this

 .def("fetchEndNode", [](MWTree<D> &tree, int i) {
    if (does i make sense?) return tree.getMWEndNode(i)

    return pybind11::none;
})

I haven't tested if this actually will work. I'll look at it when I have time