Skip to main content

numerics - 2D Heat equation: inconsistent boundary and initial conditions


I'm attempting to use NDSolve on a 2D boundary value problem with initial conditions. Upon running my code, I get the following message:


"NDSolve::ibcinc: Warning: Boundary and initial conditions are inconsistent."


After much head-scratching, I can't seem to find my mistake. It seems to me that my initial condition is consistent with my boundary conditions:


k = 1 / (5*(Pi^2));
soln = NDSolve[
  {
  (* PDE *)

  D[u[x, y, t], t] == k*(D[u[x, y, t], x, x] + D[u[x, y, t], y, y]),

  (* initial condition *)
  u[x, y, 0] == y + Cos[Pi*x] Sin[2*Pi*y],

  (* boundary conditions *)
  u[x, 0, t] == 0,
  u[x, 1, t] == 1,
  (D[u[x, y, t], x] /. x -> 0) == 0,
  (D[u[x, y, t], x] /. x -> 1) == 0

  },
 u,
 {x, 0, 1},
 {y, 0, 1},
 {t, 0, 1}
 ]

Any advice is greatly appreciated,


Rick



Answer




The documentation has a full section dedicated to inconsistent boundary conditions in PDEs.


Quoting it,



Occasionally, NDSolve will issue the NDSolve::ibcinc message warning about inconsistent boundary conditions when they are actually consistent. This happens due to discretization error in approximating Neumann boundary conditions or any boundary condition that involves a spatial derivative. The reason this happens is that spatial error estimates (see "Spatial Error Estimates") used to determine how many points to discretize with are based on the PDE and the initial condition, but not the boundary conditions. The one-sided finite difference formulas that are used to approximate the boundary conditions also have larger error than a centered formula of the same order, leading to additional discretization error at the boundary. Typically this is not a problem, but it is possible to construct examples where it does occur.



Then an example follows, and a possible solution using the Method option's "TensorProductGrid" suboption, which we can also apply to your problem.



When the boundary conditions are consistent, a way to correct this error is to specify that NDSolve use a finer spatial discretization.



k = 1/(5*(Pi^2));

soln = NDSolve[{
   D[u[x, y, t], t] == k*(D[u[x, y, t], x, x] + D[u[x, y, t], y, y]),
   u[x, y, 0] == y + Cos[Pi*x] Sin[2*Pi*y],
   u[x, 0, t] == 0, 
   u[x, 1, t] == 1, 
   (D[u[x, y, t], x] /. x -> 0) == 0, 
   (D[u[x, y, t], x] /. x -> 1) == 0}, 

  u, {x, 0, 1}, {y, 0, 1}, {t, 0, 1}, 


  Method -> {"MethodOfLines", 
               "SpatialDiscretization" -> {"TensorProductGrid", "MinPoints" -> 20}}]

In this instance "MinPoints" -> 20 was sufficient to make the problem go away.



The same problem was discussed here. I vaguely remembered it, but it took me a while to find it again ...


Comments

Post a Comment

Popular posts from this blog

functions - Get leading series expansion term?

Given a function f[x] , I would like to have a function leadingSeries that returns just the leading term in the series around x=0 . For example: leadingSeries[(1/x + 2)/(4 + 1/x^2 + x)] x and leadingSeries[(1/x + 2 + (1 - 1/x^3)/4)/(4 + x)] -(1/(16 x^3)) Is there such a function in Mathematica? Or maybe one can implement it efficiently? EDIT I finally went with the following implementation, based on Carl Woll 's answer: lds[ex_,x_]:=( (ex/.x->(x+O[x]^2))/.SeriesData[U_,Z_,L_List,Mi_,Ma_,De_]:>SeriesData[U,Z,{L[[1]]},Mi,Mi+1,De]//Quiet//Normal) The advantage is, that this one also properly works with functions whose leading term is a constant: lds[Exp[x],x] 1 Answer Update 1 Updated to eliminate SeriesData and to not return additional terms Perhaps you could use: leadingSeries[expr_, x_] := Normal[expr /. x->(x+O[x]^2) /. a_List :> Take[a, 1]] Then for your examples: leadingSeries[(1/x + 2)/(4 + 1/x^2 + x), x] leadingSeries[Exp[x], x] leadingSeries[(1/x + 2 + (1 - 1/x...
Post a Comment
Read more

mathematical optimization - Minimizing using indices, error: Part::pkspec1: The expression cannot be used as a part specification

I want to use Minimize where the variables to minimize are indices pointing into an array. Here a MWE that hopefully shows what my problem is. vars = u@# & /@ Range[3]; cons = Flatten@ { Table[(u[j] != #) & /@ vars[[j + 1 ;; -1]], {j, 1, 3 - 1}], 1 vec1 = {1, 2, 3}; vec2 = {1, 2, 3}; Minimize[{Total@((vec1[[#]] - vec2[[u[#]]])^2 & /@ Range[1, 3]), cons}, vars, Integers] The error I get: Part::pkspec1: The expression u[1] cannot be used as a part specification. >> Answer Ok, it seems that one can get around Mathematica trying to evaluate vec2[[u[1]]] too early by using the function Indexed[vec2,u[1]] . The working MWE would then look like the following: vars = u@# & /@ Range[3]; cons = Flatten@{ Table[(u[j] != #) & /@ vars[[j + 1 ;; -1]], {j, 1, 3 - 1}], 1 vec1 = {1, 2, 3}; vec2 = {1, 2, 3}; NMinimize[ {Total@((vec1[[#]] - Indexed[vec2, u[#]])^2 & /@ R...
Post a Comment
Read more

How to remap graph properties?

Graph objects support both custom properties, which do not have special meanings, and standard properties, which may be used by some functions. When importing from formats such as GraphML, we usually get a result with custom properties. What is the simplest way to remap one property to another, e.g. to remap a custom property to a standard one so it can be used with various functions? Example: Let's get Zachary's karate club network with edge weights and vertex names from here: http://nexus.igraph.org/api/dataset_info?id=1&format=html g = Import[ "http://nexus.igraph.org/api/dataset?id=1&format=GraphML", {"ZIP", "karate.GraphML"}] I can remap "name" to VertexLabels and "weights" to EdgeWeight like this: sp[prop_][g_] := SetProperty[g, prop] g2 = g // sp[EdgeWeight -> (PropertyValue[{g, #}, "weight"] & /@ EdgeList[g])] // sp[VertexLabels -> (# -> PropertyValue[{g, #}, "name"]...
Post a Comment
Read more