Psi4 causing jupyter notebook kernel to crash #862
Comments
|
It should work. I use psi4 in a jupyter notebook regularly. However, that's on Mac, not Linux, and I can't check Linux until tomorrow. Only thing you might try in the interim is pulling jupyter and friends from defaults or from intel channel, rather than conda-forge. EDIT: and thanks for the |
|
Thanks for confirming that it should work! Tomorrow I'll try pulling in |
|
Inside my Do you have any thoughts? |
|
Crash replicated. Almost certainly what's going on is that a fundamental library (gcc, mkl are the usual suspects) is in conflict between jupyter's Indeed, if I install psi4 the way you listed into Next problem is that So you've found a real problem, and I don't have a ready solution. The medium-term solution is to go with the new compilers that conda is rolling out (7.2). Then psi can rejoin the common gcc track of the rest of the conda ecosystem. Fortunately, I was working on that this week. Copying people who have had related problems. @dsirianni, @j3mdamas, Pascal (hit a |
Ah, I ran into this for the first time recently with another module.
Okay, I'll give this a shot.
Is there anything actionable with this or do I sit tight until there's a new psi4 release? |
|
If you want to try the new compilers version, create a new environment If that doesn't work (and I won't be able to test it myself until Monday), no, there's nothing actionable. |
|
Just as a note, I tried it out with the new compilers ( |
|
Thanks for the update, @loriab, I appreciate it. At the moment, I'm running outside of At the risk of going off topic, I have a tangentially related question. I'm trying to do a torsion scan to derive a potential energy surface and I believe that (As a comparative data point, I did the "same" calculation with Gaussian 09 on 16 cores and it completed the scan overnight. I say "same" because I let Gaussian do the hard work of scanning the dihedral itself, beginning from the initial coordinates instead of using separate files, and I used HF/6-31G.) |
|
Unless your molecule has a couple hundred atoms, that does sound slow. You're setting |
The molecule is big, but not that big -- about 50 atoms (mostly C and H).
I started running on a remote machine, and even though I have
Based on the script you sent, it does appear that threading is working (see below), however, I have noticed that during my geometry optimization and single point energy that most of the time |
|
My input file basically just has the molecule definition and then: ...so I don't think it should be doing anything fancy. |
|
I have the same issue: It works under terminal and |
|
Hmm, @loriab could this be a glibc mismatch? |
|
Possible, but I really doubt it, as glibc mismatches aren't usually healable. Usually this is a symptom of packages depending on different versions of a library and symbols getting sometimes loaded one way and sometimes another depending on import order. Often fixable by swapping import order, but in the psi-in-jupyter case, there's simply nothing to swap. I thoroughly expected this to be fixed when I built with the newer compilers and was alarmed when it wasn't. @sergsb, would you want to try the conda env line in #862 (comment) ? Possibly more defaults packages have been updated to the new compilers since November and healed the problem. Only thing else I can think of is that I'm still linking libc++ statically (which it should be entirely safe to do, being the least-fundamental of the |
|
I started running on a remote machine, and even though I have PSI_SCRATCH
set on my local machine, I don't have it set on the remote machine
(probably didn't re-source ~/.bashrc after installing psi4. However, it
should be writing to local disks. I can see psi...clean files in the local
directory, are those scratch files?
No, psi.[pid].clean is a little text file that contains a list of all the
scratch files to clean up. You should look at the list of scratch files in
this psi.[pid].clean file to see where it is writing the scratch files, and
make sure that it isn't to a NFS-mounted directory. Otherwise you'll take
a huge performance hit.
…On Thu, Mar 1, 2018 at 11:05 AM, Lori A. Burns ***@***.***> wrote:
Possible, but I really doubt it, as glibc mismatches aren't usually
healable. Usually this is a symptom of packages depending on different
versions of a library and symbols getting sometimes loaded one way and
sometimes another depending on import order. Often fixable by swapping
import order, but in the psi-in-jupyter case, there's simply nothing to
swap.
I thoroughly expected this to be fixed when I built with the newer
compilers and was alarmed when it wasn't. @sergsb
<https://github.com/sergsb>, would you want to try the conda env line in #862
(comment) <#862 (comment)>
? Possibly more defaults packages have been updated to the new compilers
since November and healed the problem.
Only thing else I can think of is that I'm still linking libc++ statically
(which it should be entirely safe to do, being the least-fundamental of the
glibc, libgcc_s, libstdc++ trio) and that's running into a symbol error
with the jupyter stack.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#862 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AC9Qdr3o6Z-YaJeCQ901ywG8eMHjO8c5ks5taBxDgaJpZM4Qhais>
.
|
|
I've been playing build bisect today on the conda package and narrowed this problem down to |
|
I shall transfer 5 of my psicoin when we mint our own cryprtocurrency to you. |
|
Whoa, fantastic! These kinds of issues are extremely tough to track down, so I also transfer 5 psicoin. |
|
Thanks. I haven't tackled Mac yet (or clang on Linux) on the conda revamp, but it's unlikely to be a problem. If I had built packages the canonical conda way (dynamic link everything), psi4 wouldn't have had this problem in the first place. Slowly all my "tricks" in the original psi4 binary (where python itself was practically the only non-static dependency) have been given up for good technical reasons in favor of system packages from the conda ecosystem. On Mac (clang), I never implemented those tricks in the first place, so it didn't hit this problem. |
|
For the record, |
|
This has been identified and will be fixed in the Psi4 1.2 release. This happens in custom build scripts and no changes are required on GitHub. |
I'm trying to use Psi4 in a
jupyter notebookand getting an immediate crash. I didn't see anything in documentation or issues about running inside a notebook, so I'm not sure if this is supported behavior.I installed Psi4 using
condain its own environment, following the instructions here withconda create -n p4env python=3.6 psi4 psi4-rt -c psi4/label/dev -c psi4. I canimport psi4correctly using the python interactive shell.$ source activate p4env $ pythonIf I run inside a notebook,
sys.pathandsys.executableare the same, but when Iimport psi4, I get a message "The kernel appears to have died. It will restart automatically." In the terminal, I see:I think the first three lines are unrelated. The kernel never recovers and I can't import the module. Should I expect that Psi4 will work inside a
jupyter notebookand if so, is there any way to get more information about what's going wrong?Edit: I should add that to get
jupyter notebookto see thep4envconda environment, I executedconda install ipykernel --name p4envand then~/data/applications/psi4conda/envs/p4env/bin/python -m ipykernel install --user(according to these instructions).Output of `conda list`
The text was updated successfully, but these errors were encountered: