MaplePrimes - answers and comments on Question, Non-fatal error while reading data from kernel

Bug in Standard GUI

Carl Love — Sat, 26 Jan 2013 19:45:33 Z

This is a bug in the Standard GUI. Your commands run fine in the command-line Maple. If you have access to the Classic GUI (I don't), try that also.

A warning to anyone trying to investigate this: If you try to probe this, say with printlevel:= 100, the GUI will lose connection with the kernel (without any message), and you'll be stuck. Setting interface(prettyprint= 0) does not help. Another curiosity: The output, i.e. the returned value, of the OP's commands is literally the symbol `Non-fatal error while reading data from kernel.`; that is what soltn is set to; it is not an error message in the usual sense. Therefore, it must the kernel that is sending the message!

Work around

Joe Riel — Sat, 26 Jan 2013 23:49:53 Z

As Carl points out, this is a weird kernel/gui bug. To work around it, terminate the call to dsolve with a colon (so nothing is printed). You can then use soltn as desired:

(**) eqn1 := diff(R1(r),r) + I*R2(r) = 0:
(**) eqn2 := diff(R2(r),r) + R1(r) = 0:
(**) st := 1.3:
(**) fn := 4.3:
(**) soltn := dsolve([eqn1,eqn2,R1(st)=0.1,R2(st)=0.2], [R1(r),R2(r)], numeric, range=st..fn): # terminate with a colon
(**) soltn(2);
   [r = 2., R1(r) = 0.110429803108025 - 0.115236213462622 I, R2(r) = 0.128139507027451 + 0.0432522993325482 I]

Correction:

My work-around doesn't really do anything other than prevent the message from being displayed. Originally I hadn't realized that soltn was being assigned correctly, regardless. I've submitted this as an SCR. The bug lies in the display of soltn. To see that, execute

print(soltn);
                       Non-fatal error while reading data from kernel.

Another workaround

Carl Love — Sun, 27 Jan 2013 02:19:09 Z

Another workaround is to set Digits:= 20.

More curiosities

Alejandro Jakubi — Sun, 27 Jan 2013 04:46:44 Z

I can confirm that the OP's commands work as expected in Maple 16.02 Classic GUI on Linux Mint 13 32-bit. Yet, on this same platform and Maple version, the Standard GUI (worksheet mode, 1-D input, typesetting standard), produces no output (rather than the symbol `Non-fatal error ...`). Certainly,

ToInert(eval(soltn));

does show the inert form of a procedure after an unusual long time. But

FromInert(%);

shows no output either. On the other hand:

disassemble(eval(soltn));

produces here a "Kernel Connection Lost" crash. And

S := ToInert(eval(soltn)):
mx := kernelopts('maximmediate'):
select(`>`, FromInert~(indets(S, _Inert_INTPOS(anything))), +mx);

produces a set of 272 integer, while

select(`<`, FromInert~(indets(S, _Inert_INTNEG(anything))), -mx);

produces a set of 98 integers. And Digits:=20 does not work here. So there is a 32 vs 64-bit condiment involved in this bug.

Also, this is a regression bug. I observe it also in Maple 14.01 and 15.01 Standard GUI, while it does not occur in Maple 13.02 or before.

may be not

Alejandro Jakubi — Sun, 27 Jan 2013 05:27:27 Z

I have inspected the localhost TCP stream of the conversation between the Maple 16.02 Standard GUI and the C kernel, when executing the OP's commands on Linux 32-bit. As I have stated below, no output occurs in this platform (instead of the symbol `Non-fatal error...`). Yet, what I observe as result from the C kernel for the GUI is the expected procedure in Typesetting call form. So, that it does not print is an issue purely of the Java sector of the system.

I do not have a 64-bit setup to check this issue at this moment. But may be that the symbol that you observe is produced by the Java kernel instead.

odeplot

cosmicstring — Sun, 27 Jan 2013 01:15:09 Z

Thank you very much Joe!

This work-around lets me see the numerical values. Then, I tried to plot my solution using odeplot.

First I tried the most basic form:

Then,

to plot just R1(r). To plot the real part of R1(r), I tried:

But none of them plotted the results. I checked some numerical values and there should be some graphs:

   [r = 2., R1(r) = 0.110429803108025 - 0.115236213462622 I,

     R2(r) = 0.128139507027451 + 0.0432522993325482 I]
[r = 2.1, R1(r) = 0.115352112959516 - 0.127490328044104 I,

    R2(r) = 0.116860522168709 + 0.0553980382159244 I]
[r = 2.2, R1(r) = 0.121548358755804 - 0.138589827223535 I,

    R2(r) = 0.105026606192974 + 0.0687118967487442 I]
[r = 2.3, R1(r) = 0.129129499693604 - 0.148472718421773 I,

    R2(r) = 0.0925046702134434 + 0.0830754749112501 I]
[r = 2.4, R1(r) = 0.138194280312590 - 0.157063052476409 I,

etc.

Is it possible that this bug prevents odeplot to reach the soltn to get the numerical values? (I am using odeplot for the first time, so I may be missing a point.)