# Kernel quits without error in NDSolveValue

The crash is fixed in version 10.3

I am using the latest 10.1. The following single line command makes the kernel quit without error message (just a beep):

NDSolveValue[{-Derivative[0, 2][Φ][x, t] + Derivative[2, 0][Φ][x, t] == Sin[Φ[x, t]],
Φ[x, 0] == 0, -Derivative[0, 1][Φ][0, t] + Derivative[1, 0][Φ][0, t] == 2*Sin[2*t]},
{Φ[x, t], Derivative[1, 0][Φ][x, t]}, {x, 0, 1}, {t, 0, 1}]


What goes wrong with this?

• Cannot understand the code! Can you please copy paste the command in the notebook? – Nick Mpountouropoulos Apr 19 '15 at 0:23
• Welcome to Mathematica.SE! I suggest the following: 1) As you receive help, try to give it too, by answering questions in your area of expertise. 2) Read the faq! 3) When you see good questions and answers, vote them up by clicking the gray triangles, because the credibility of the system is based on the reputation gained by users sharing their knowledge. Also, please remember to accept the answer, if any, that solves your problem, by clicking the checkmark sign! – Michael E2 Apr 19 '15 at 0:49
• As Nick said, please post the InputForm of your code. Also, you can format inline code and code blocks by selecting it and clicking the {} button above the edit window. The edit window help button ? is also useful for learning how to format your questions and answers. – Michael E2 Apr 19 '15 at 0:50
• I was able to reformat the code in a more intelligible form, and the local kernel does terminate with a beep. – bbgodfrey Apr 19 '15 at 1:14
• In addition to the specified boundary conditions, the computation needs a boundary condition at x = 1 and a second boundary condition at t = 0. – bbgodfrey Apr 19 '15 at 1:46

I began this thinking of adding a comment to the answer by bbgodfrey, who points out mathematical fixes to the OP's problem. But each idea led to another test and another idea. Aside from the unceremonious crashing of the kernel, there is more evidence below of a bug or bugs in the parsing of the equations. The fix by bbgodfrey works, it seems, because it leads the parser away from the bug. Clearly the expected behavior should be to emit some messages about initial and boundary conditions and return unevaluated, or possibly to return a solution with default conditions being assumed. That expectation rests on an assumption that the parser will interpret the problem the way I do.

For NDSolveProcessEquations used below, see tutorial/NDSolveStateData.

### The upshot

I'd like first to state what my answer to this question is as a programming problem or as a Mathematica usage problem (as distinct from the mathematical solution given by bbgodfrey). This PDE requires the use of the Method of Lines. For that to be successful, it has to be parsed correctly. That may be done by adding the option

Method -> {"MethodOfLines", "TemporalVariable" -> t}


This leads to error messages that indicate mathematical problems that may be fixed as bbgodfrey shows.

A second conclusion is that the crash should not happen, and the OP should be encouraged to report the issue to Wolfram Support. Given that the input is incomplete, I do not think one can really fault Mathematica's parser for misinterpreting the input, even if it might be possible for the developers to improve it.

### Parsing problems

The first snippet below shows the problem arises in processing the equations. It will turn out that the complicated boundary condition (in terms of partial derivatives with respect to different variables) and sometimes the term Sin[Φ[x, t]] are leading the parser into trouble.

(* Crashes in the equation-processing stage *)
NDSolveProcessEquations[{
-Derivative[0, 2][Φ][x, t] + Derivative[2, 0][Φ][x, t] == Sin[Φ[x, t]],
Φ[x, 0] == 0,
-Derivative[0, 1][Φ][0, t] + Derivative[1, 0][Φ][0, t] == 2*Sin[2*t]},
Φ,
{x, 0, 1}, {t, 0, 1}]


The next snippet shows that if one of the partial derivative terms is commented out of the boundary conditions, the Finite Element Method seems to be tried. The nature of the messages, reflect an internal error that should not be escaping to the user level, at least in this form. (More on this below.)

(* Messages show a possible bug. FEM method seems to be tried. *)
NDSolveProcessEquations[{
-Derivative[0, 2][Φ][x, t] + Derivative[2, 0][Φ][x, t] == Sin[Φ[x, t]],
Φ[x, 0] == 0,
(*-Derivative[0,1][Φ][0,t]+*) Derivative[1, 0][Φ][0, t] == 2*Sin[2*t]},
Φ,
{x, 0, 1}, {t, 0, 1}];


CoefficientArrays::poly: -Φ$12983+Φ$12984-Sin[Φ] is not a polynomial. >>
NDSolveProcessEquations::femper: -- Message text not found -- ({-Φ$12983+Φ$12984-Sin[Φ]})

The Method of Lines is the usual default. We can force it with the Method option as below. A message is emitted but a solution is not produced. The message itself is a curious choice and perhaps suggests that the parser is confused by the complicated boundary condition. As bbgodfrey implies, for the method of lines, the number of initial conditions should be equal to the differential order of the time variable t (which is two). Likewise one would expect the number of boundary conditions to equal the differential order of the spatial variable x.

(* Force Method of Lines - does not crash but no solution is produced *)
NDSolveProcessEquations[{
-Derivative[0, 2][Φ][x, t] + Derivative[2, 0][Φ][x, t] == Sin[Φ[x, t]],
Φ[x, 0] == 0,
-Derivative[0, 1][Φ][0, t] + Derivative[1, 0][Φ][0, t] == 2*Sin[2*t]},
Φ,
{x, 0, 1}, {t, 0, 1},
Method -> "MethodOfLines"];


NDSolveProcessEquations::ivone: Boundary values may only be specified for one independent variable. Initial values may only be specified at one value of the other independent variable.

The message above suggests that the OP has confused the temporal and spatial variables, or that the parser has done so. Indeed, it may be arguable which is the valid conclusion. We can tell the parser which is the temporal variable with the setting Method -> {"MethodOfLines", "TemporalVariable" -> t}. Now we get useful messages.

(* Force Method of Lines - better messages *)
NDSolveProcessEquations[{
-Derivative[0, 2][Φ][x, t] + Derivative[2, 0][Φ][x, t] == Sin[Φ[x, t]],
Φ[x, 0] == 0,
-Derivative[0, 1][Φ][0, t] + Derivative[1, 0][Φ][0, t] == 2*Sin[2*t]},
Φ,
{x, 0, 1}, {t, 0, 1},
Method -> {"MethodOfLines", "TemporalVariable" -> t}];


NDSolveProcessEquations::tvic: t cannot be used as the temporal independent variable because the conditions {Φ[x,0]==0} for that dimension do not constitute sufficient initial conditions given at only one value of t.
NDSolveProcessEquations::ivone: Boundary values may only be specified for one independent variable. Initial values may only be specified at one value of the other independent variable.

If we give a second initial condition, the parser does not get confused. Replacing NDSolveProcessEquations with just NDSolve yields a solution, which is very close to but not the same as the one obtained by bbgodfrey.

(* Works with a simple 2nd initial value *)
NDSolveProcessEquations[{
-Derivative[0, 2][Φ][x, t] + Derivative[2, 0][Φ][x, t] == Sin[Φ[x, t]],
Φ[x, 0] == 0,
Derivative[0, 1][Φ][x, 0] == 0,
-Derivative[0, 1][Φ][0, t] + Derivative[1, 0][Φ][0, t] == 2*Sin[2*t]},
Φ,
{x, 0, 1}, {t, 0, 1}];


NDSolveProcessEquations::bcart: Warning: an insufficient number of boundary conditions have been specified for the direction of independent variable x. Artificial boundary effects may be present in the solution.

### Finite Element Method

The OP's original code crashes when the Finite Element Method is explicitly invoked. This must be what happens with the default NDSolve call, probably because the system is not set up properly to be solved by the method of lines. Note that the finite element method works only on linear PDEs, so the proper response here would be the error message NDSolveProcessEquations::femnonlinear.

(* Crashes with FEM, but worked with Method of Lines *)
NDSolveProcessEquations[{
-Derivative[0, 2][Φ][x, t] + Derivative[2, 0][Φ][x, t] == Sin[Φ[x, t]],
Φ[x, 0] == 0,
-Derivative[0, 1][Φ][0, t] + Derivative[1, 0][Φ][0, t] == 2*Sin[2*t]},
Φ,
{x, 0, 1}, {t, 0, 1},
Method -> "FiniteElement"];


If we add another initial condition and simplify the boundary condition, we get the strange message we saw above. This should be reported to Wolfram Support, too.

(* FEM does not handle nonlinear PDEs, but message is wrong *)
NDSolveProcessEquations[{
-Derivative[0, 2][Φ][x, t] + Derivative[2, 0][Φ][x, t] == Sin[Φ[x, t]],
Φ[x, 0] == 0,
Derivative[0, 1][Φ][x, 0] == 0,
(*-Derivative[0,1][Φ][0,t]+*) Derivative[1, 0][Φ][0, t] == 2*Sin[2*t]},
Φ,
{x, 0, 1}, {t, 0, 1},
Method -> "FiniteElement"]


CoefficientArrays::poly: -Φ$12517+Φ$12518-Sin[Φ] is not a polynomial. >>
NDSolveProcessEquations::femper: -- Message text not found -- ({-Φ$12517+Φ$12518-Sin[Φ]})

As one might guess from the message, the problem has something to do with the PDE having a term of the form f[Φ[x, t]], when f is not a polynomial. If we change it to a polynomial, say Φ[x, t]^2, it works as I would expect.

(* With a polynomial equation, FEM emits the right message *)
NDSolveProcessEquations[{
-Derivative[0, 2][Φ][x, t] + Derivative[2, 0][Φ][x, t] + Φ[x, t]^2 == 0,
Φ[x, 0] == 0,
Derivative[0, 1][Φ][x, 0] == 0,
(*-Derivative[0,1][Φ][0,t]+*) Derivative[1, 0][Φ][0, t] == 2*Sin[2*t]},
Φ,
{x, 0, 1}, {t, 0, 1},
Method -> "FiniteElement"];


NDSolveProcessEquations::femnonlinear: Nonlinear coefficients are not supported in this version of NDSolve.

• Superb analysis. I learned a lot from reading it. Well done! – bbgodfrey Apr 20 '15 at 1:11
• Worth tagging with bugs, fem, differential-equations to make it more likely that @user21 will see this? – Oleksandr R. Apr 20 '15 at 21:52

It appears that NDSolveValue is failing, because too few boundary conditions have been specified. For instance, with a boundary condition at x = 1 and a second boundary condition at t = 0 specified as follows,

ans = NDSolveValue[
{-Derivative[0, 2][Φ][x, t] + Derivative[2, 0][Φ][x, t] == Sin[Φ[x, t]],
Φ[x, 0] == 0, Derivative[0, 1][Φ][x, 0] == 0,
-Derivative[0, 1][Φ][0, t] + Derivative[1, 0][Φ][0, t] == 2*Sin[2*t],
Derivative[0, 1][Φ][1, t] + Derivative[1, 0][Φ][1, t] == 0},
Φ, {x, 0, 1}, {t, 0, 1}, PrecisionGoal -> 2];


a well behaved solution is produced.

Plot3D[ans[x, t], {x, 0, 1}, {t, 0, 1}, AxesLabel -> {x, t}, PlotRange -> All]


Other boundary conditions will, of course, lead to other solutions.