I'm working on a program on the Klein paradoxon of the Dirac equation which together with the evolving wave function shows derived quantities in separate graphics so that the final expression of my Manipulate is a GraphicsGrid with presently 3 entries. The third entry was added only recently and turned the very nice working of the program into a very undesirable one. At varying stages of the program run it stops with a beep and as reason I read "The kernel Local has quit (exited) during the course of an evaluation". My system monitor tool 'speccy' gives a core temperature lower than 60 degrees centigrade so that I seem not to have a temperature problem. In thinking about the problem I became aware of the obvious fact that the recently added graphics does not change with time and thus can be computed at the beginning of the run and than simply displayed. With this change (which would not have been necessary if I had arranged things approriately in the first place) the malfunction dissapeared (as of present). This experience left me wondering under what circumstances the kernel is known to quit and which means can be recommended for finding the reason for exiting. This refers to Mathematica 184.108.40.206 on Windows 10. The notebook which shows the malfunction on my computer is attached.
Glad to see somebody on Windows got the same "kernel exited" problem. I changed from Windows to Mac almost at the same time as I upgraded to Mathematica version 10.
I use a lot of ParametricPlot3D and never got a problem in versions prior to 10. With 10.01 nd 10.02 I started getting this problem very often. It got much better in 10.2 and I even informed Tech Support the problem was probably solved. But it happens still albeit less frequently and the kernel exits and I get:"The kernel Local has quit (exited) during the course of an evaluation" during Manipulates with ParametricPlot3D
It has in my experience to do with graphics and with continuous updating of plots or manipulate.
I leaned to live with it but it has something to do with version 10. Maybe Wolfram solves this in next version? Or informs us of some setting that can avoid, circumvent or eliminate this?
Thanks, David for your efforts. I don't need to see your PDFs. If also your n=512 experiment runs through I would conclude that the problem is not with the code. I plan to upgrade soon to the most recent version of Mathematica and, when this is done, will try again this notebook to see whether it then works as it works for you.
As I wrote above, I have a working version (on my system) for further development of the simulation.
Of course, it is very desirable to get a hint concerning the reason for the failure on my system. It would be very helpful if a Wolfram-expert would give his oppinion on the most probable ocurrence of a message:
"The kernel Local has quit (exited) during the course of an evaluation"
Actually it turned out that the run went with tfr =5 and n=64. The calculation stopped at t=10.6719s. Are the .pdf files of any interest to you?
Ulrich, here we go. N=512, tfr=5.18. Fingers crossed.
thank you very much for your good news. You could run up to a larger t by increasing the quantity tfr ( = time final relative) by shifting the corresponding slider to the right. Since the failures observed on my system seemed to occur at random, running longer gives failure a greater chance. Changing n (e.g. from 64 to 200, need not be a power of 2) increases the workload and memory consumption considerably and - unfortunately - takes more from your time. Perhaps such increased workload is a problem even for your strong system.
Would be great hearing more of your experiences.
I have executed your code under M10.1 on my Macbook Pro and it is certainly running without crashing the kernel. I changed a few of the sliders without knowing at all what I was doing, and the dynamic trends are updating to 1.2 seconds and beyond now. According to the Mac applications monitor, less than 3Gb of memory is being used. As I have been typing, the simulations have stopped at around t=1.334s with no apparent MMA error messages.
Maybe you could suggest some slider settings and I shall try those.
On my system what happens is not spectacular but also not nothing. The activity of a cell which is normally indicated by a yellow vertical bar stops and the check mark of the make box disappears. If this has happened you should invoke the 'run'-box and then the kernel may exit spontaneously after a while or the program will end regularly (again the yellow cell bar vanishes, the run-checkmark disappears.
A new sequence 'change sliders', 'make', 'run' may be started. Good luck!
Jetzt stürzt das System zwar nicht mehr ab, aber wenn ich "make" aktiviere, erscheint die grüne Schrift und dann tut sich nichts mehr. Unendliche Schleife?
Extremely sorry Hans,
my intention was to refer to the checkboxes in the user interface of my Manipulate. There are boxes such as 'run', 'reset', 'make', 'take' above the area where the many sliders are placed. Invoking the check boxes means clicking on them. Sorry for having used slang instead of clear language. Hope this helps. Of course, you are well-come to ask whatever comes up.
Sorry Ulrich, I am working with version 7 and never heard about "invoke make". Seems my "expertise" is less than estimated.
I should have told you.
The job 'runs' which in this case means only that it waits until 'make' is invoked. (Before you invoke 'make' you could play arround with the sliders to set the inititial state of the system. Ignore this option at first.) When 'make' came to an end , which is after less than a minute for the preset values (n is the most influential quantity), you invoke 'run' and sometimes the run comes to its regular preset end and sometimes it ends with a beep and an inactive local kernel. In running, five pdf-files will be written to a place which depends on the systems (sorry for the inconvenience).
I look forward to your experiences!
Now my system doesn't crash, and the job runs, but does nothing. I should invoke "make", which means what...?
Attached is a version of my notebook now saved with all preexisting output purged so that the file is much smaller and, so my hope, will crash nobodies computer.
That sounds good. But in addition think about the amount of memory the manipulate-object may need. I noticed that you arranged for the change of quite a lot of parameters.
My computer has 8GB of RAM and is far from being overloaded for the value 64 to which the parameter n (= number of discretization points) is preset. With similar versions of my program I did n=256 without memory problems.
You report that my notebook makes your system crash upon enabling dynamic content. I suspect that simply attaching the file in the state that it had from my last working on it was not a good idea. I will try to provide a cleaner copy and, in case of success, will send this with a contribution to follow.
How much memory do you have? I encountered a phenomenon like this when the actual calculation simply blowed the capacity of my computer.
P.S. On my system I can open your notebook, but the system crashes when enabling the dynamic content (whatever that means)