# Automatic Boundary conditions in NDSolve

I would like to know what kind of boundary conditions Mathematica implements in NDSolve when not specifying any boundary conditions by hand. So for example solving the transport equation:

eq = With[{l= 2.}, D[u[t, x], t] + l D[u[t, x], x] == 0];
mol[n_Integer, o_Integer] := {"MethodOfLines", "SpatialDiscretization" -> {"TensorProductGrid", "DifferenceOrder" -> o, "Coordinates" -> N[-1 + 2/n*Range[0, n]]}}
solv = NDSolve[{eq, u[0, x] == Exp[-x^2/.1]}, u, {t, 0, 1}, {x, -1, 1}, Method -> mol[51, 4]]
Animate[Plot[Evaluate[u[t, x] /. solv], {x, -1, 1}], {t, 0, 1}]


This gives me a warning:

NDSolve::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.

but the equation is still solved. The boundary conditions at $+1$ look like absorbing or periodic boundary conditions but at $-1$ there is something different going on.

• How does Mathematica treat problems when no boundary condition is given in NDSolve?
• How can I implement in this case absorbing boundary conditions within NDSolve?

Edit: I was asked to edit the question to make it 'unique': Firstly my question refers only to the above stated (first order) transport equation, secondly my question also asks for implementing absorbing boundary condition which is kind of done automatically by mathematica at $+1$, thirdly I am not applying any boundary conditions at all which is different to the question mentioned in the comments and the mentioned question does not explain what NDSolve is doing at the edges.

• Possible duplicate of What boundary is added when boundary condition is not sufficient? – xzczd Jan 16 '18 at 15:00
• OK, I retracted my close vote because the "implementing absorbing boundary condition" part isn't included in the question above, but, "the mentioned question does not explain what NDSolve is doing at the edges." this is explained in the last link in that question, please read it carefully. – xzczd Jan 16 '18 at 15:46
• Could you point out where exactly this is explained? Do you mean: "So, perhaps we'll have to admit the solution is really meaningless in the end"? I want to know how NDSolve is constructing the derivative at the outermost points. Is it using a forward difference scheme on the rhs and a backward scheme on the lhs? Or adding discretization points to the edges and applying some values to them? I cant see this being answered clearly in the link. – Mr Puh Jan 16 '18 at 16:02
• It's one-sided formula that's used at edges. You can search these words in that page and read the relevant part. – xzczd Jan 16 '18 at 16:04
• I've posted a related question in scicomp and started a bounty for it but haven't got a satisfied answer so far… – xzczd Feb 12 '18 at 14:33

If you try this method inside NDSolve

solv = NDSolve[{eq, u[0, x] == Exp[-x^2/.1]},u, {t, 0, 1}, {x, -1, 1},
Method -> {"MethodOfLines", "TemporalVariable" -> t,
"SpatialDiscretization" ->       {"FiniteElement","MeshOptions" ->{"MaxCellMeasure" -> 0.03}}}]


the warning gives some other useful information.

(* NDSolve::femcscd: The PDE is convection dominated and the result may not be stable. Adding artificial diffusion may help. *)


In case of insufficient boundary conditions, I think NDSolve uses "Neumann boundary value"

• (-1) I'm sorry, but this is irrelevant to OP's question. The boundary treatment is very different when "FiniteElement" is chosen for "SpatialDiscretization". Just compare your result to OP's and you'll see the difference. For more information, check the links I gave in the comment above. – xzczd Apr 17 '18 at 5:39
• I don't think so. Just look in the help documentation NeumannValue . – Ulrich Neumann Apr 17 '18 at 6:34
• "FiniteElement" together with NeumannValue etc. is added after v10, while OP's problem has existed long before that. – xzczd Apr 17 '18 at 6:39
• The question has been posed in Jan 2018! I don't know which MMA version is involved. But please be aware, that I tried to give a helpful relevant answer. Your hastly judgement appears to be dispensable. – Ulrich Neumann Apr 17 '18 at 6:47
• I mean, the problem that bcart warning points to has existed long before v10 and is not relevant to "FiniteElement". (Notice OP has manually chosen "TensorProductGrid" method, and even if he doesn't manually choose this, it's the default method in this case. ) Once again, please check the links I gave in the comment above and you'll see some detailed discussion. – xzczd Apr 17 '18 at 6:56