11

Very often I solve partial differential equations that are nonlinear and could be up to 4th order. In these cases, it is usual for the solution determined by NDSolve to be stiff during a later stage. What I suspect NDSolve does in this case is to resolve the stiffness until the error/local accuracy is very poor. That is when it quits the problem and gives you an Interpolating function polynomial.

Whilst using the BDF method to MaxOrder of 1 for instance, is there someway to tell Mathematica to quit as soon as stiffness is encountered in the solution so that I save time? I don't want to resolve the stiff portion and just stop my solution just as it gets stiff.

The below example looks like a mess in plain text but it copies fine. It gets stiff at t=4806. However, is lots of problems, NDSolve lingers at the time at which stiffness is achieved to try and resolve the features that I would like to circumvent completely.

I will obv. look into the stiffness switching stuff again.

Example

{xMin,xMax}={-4\[Pi]/0.0677,4\[Pi]/0.0677};

k=0.0677/4;

TMax=5000;

uSolpbc[t_,x_]=u[t,x]/.NDSolve[{\!\(
\*SubscriptBox[\(\[PartialD]\), \(t\)]\(u[t, x]\)\)==-100\!\(
\*SubscriptBox[\(\[PartialD]\), \(x\)]\((
\*SuperscriptBox[\(u[t, x]\), \(3\)]\ 
\*SubscriptBox[\(\[PartialD]\), \(x, x, x\)]u[t, x])\)\)+1/3 \!\(
\*SubscriptBox[\(\[PartialD]\), \(x\)]\((
\*SuperscriptBox[\(u[t, x]\), \(3\)]\ 
\*SubscriptBox[\(\[PartialD]\), \(x\)]u[t, x])\)\)-5 \!\(
\*SubscriptBox[\(\[PartialD]\), \(x\)]\((
\*SuperscriptBox[\((
\*FractionBox[\(u[t, x]\), \(1 + u[t, x]\)])\), \(2\)]\ 
\*SubscriptBox[\(\[PartialD]\), \(x\)]u[t, x])\)\),u[0,x]==1-0.1 Cos[k*x],
u[t,xMin]== u[t,xMax],
Derivative[0,1]u[t,xMin]==Derivative[0,1]u[t,xMax],
Derivative[0,2]u[t,xMin]==Derivative[0,2]u[t,xMax],
Derivative[0,3]u[t,xMin]==Derivative[0,3]u[t,xMax]},
u,
{t,0,TMax},
{x,xMin,xMax},
MaxStepFraction->1/150][[1]]
dearN
  • 5,341
  • 3
  • 35
  • 74
  • @J.M. Yes I have. What If I don't want to use stiffness switching? Plus I already use the BDF method which is useful for stiff equations.. but only up to a point. – dearN Jun 21 '12 at 01:52
  • Just making sure. I'm not sure if it's straightforward to hijack the process to quit if stiffness is seen, but I'll look into it. – J. M.'s missing motivation Jun 21 '12 at 01:56
  • @J.M. I was reading about stiffness and obv. I came across the Jacobian and such. I was wondering if there is anyway of checking the jacobian periodically to detect stiffness.... – dearN Jun 21 '12 at 01:59
  • That's what "StiffnessTest" internally does, it seems, apart from a few other tricks. As I said, there might be a clever way to hijack the internals, but it's not obvious to me at the moment. – J. M.'s missing motivation Jun 21 '12 at 02:01
  • 2
    Have you looked into tutorial/NDSolveStiffnessTest? It looks like there are some options for the stiffness test and I could imagine that you can set them so that it won't switch to the stiff method. There is also an example which uses an option "MethodMonitor" which you might be able to use to stop the integration (there are examples for the event locator method which show how to stop). I haven't tried any of the mentioned options to achieve what you want, though. If you provide a self contained example probably someone might start experimenting... – Albert Retey Jun 21 '12 at 07:52
  • @Albert, funny that I already linked to it... :) – J. M.'s missing motivation Jun 21 '12 at 08:29
  • @AlbertRetey Just editted my post with an example. – dearN Jun 21 '12 at 14:08
  • That doesn't copy correctly. When posting things with formatting, please copy it as plain text, on mac os select cell ctrl-click, Copy-As -> Plain Text. I imagine on windows it is a right click. Additionally, please format your code for readability, i.e. put it into a code-block and ensure you don't have to horizontal scroll to read it. – rcollyer Jun 21 '12 at 14:18
  • @AlbertRetey Crap! Sorry – dearN Jun 21 '12 at 14:19
  • @rcollyer Hmmm... its copying fine on my linux machine... :( – dearN Jun 21 '12 at 14:20
  • Correction: convert to Raw Input Form, it's further down on the pop-up menu - Convert To -> Raw Input Form. This removes all mark-up, and makes it readable. Also, apparently putting it in a code-block fixed my inability to copy it correctly. – rcollyer Jun 21 '12 at 14:26
  • @rcollyer Thats quite strange. – dearN Jun 21 '12 at 14:28
  • One more thing, your boundary conditions look incorrect. You have Derivative[0,1]u[t,xMin] which when looking at the Raw Input Form is converted to Derivative[0,1]*u[t,xMin]. Note the addition of the multiplication symbol. I think you meant Derivative[0,1][u][t,xMin]. – rcollyer Jun 21 '12 at 14:33
  • @rcollyer Yes, but it copies absolutely fine on my machine. Is this now OS specific? I use a linux machine. I don't have the Derivative[0,1]*u[t,xMin] and yes, it is Derivative[0,1][u][t,xMin] – dearN Jun 21 '12 at 14:34
  • @J.M.: sorry, didn't look at what your link lead to. – Albert Retey Jun 22 '12 at 06:43
  • @DNA: Do you say "Crap" because these options don't work as specified (I have played a little now and didn't find the I couldn't do what I expect, but maybe the problem is with me) or because they don't address your problem? As for the suggestion to provide an example: I think that did already help, regarding the reactions to it :-) – Albert Retey Jun 22 '12 at 06:56
  • @AlbertRetey "Crap" was for my error of not formatting it... so that scatological statement was directed at moi! :P – dearN Jun 23 '12 at 14:06
  • @DNA: Ah, I was somewhat surprised about that reaction just because I overlooked J.M.'s link and my comment turned out to be rather useless altogether :-) – Albert Retey Jun 24 '12 at 17:20
  • @rcollyer FullForm[Derivative[0,1]u[t,xMin]] Still gives me Times[Derivative[0,1],u[t,xMin]] on a windows 64 bit machine, but mathematica 7.0. As we don't have mathematica 8.0 on campus. – dearN Jun 25 '12 at 21:31

1 Answers1

7

Having played around with your example I don't think that there is any method switching involved at all, as that only seems to be the case when Method is explicitly set to "StiffnessSwitching", which you didn't do (you also haven't specified "BDF" and I'm not sure what NDSolve actually chose...). What you see is that NDSolve just makes the step size smaller and smaller because the errors get worse and worse. As you vary MaxStepFraction you will find that the point where it complains about an effectively zero step size will change. This I think you already have found yourself and thus I agree now that my comment about stiffness switching wasn't very useful.

You could stop the integration when the step size gets smaller than a reasonable amount, e.g. with something like this (there might be better ways to achieve the same thing):

pde = {\!\(
\*SubscriptBox[\(\[PartialD]\), \(t\)]\(u[t, x]\)\) == -100 \!\(
\*SubscriptBox[\(\[PartialD]\), \(x\)]\((
\*SuperscriptBox[\(u[t, x]\), \(3\)] 
\*SubscriptBox[\(\[PartialD]\), \(x, x, x\)]u[t, x])\)\) + 1/3 \!\(
\*SubscriptBox[\(\[PartialD]\), \(x\)]\((
\*SuperscriptBox[\(u[t, x]\), \(3\)] 
\*SubscriptBox[\(\[PartialD]\), \(x\)]u[t, x])\)\) - 5 \!\(
\*SubscriptBox[\(\[PartialD]\), \(x\)]\((
\*SuperscriptBox[\((
\*FractionBox[\(u[t, x]\), \(1 + u[t, x]\)])\), \(2\)] 
\*SubscriptBox[\(\[PartialD]\), \(x\)]u[t, x])\)\), 
   u[0, x] == 1 - 0.1 Cos[k*x], u[t, xMin] == u[t, xMax], 
   Derivative[0, 1][u][t, xMin] == Derivative[0, 1][u][t, xMax], 
   Derivative[0, 2][u][t, xMin] == Derivative[0, 2][u][t, xMax], 
   Derivative[0, 3][u][t, xMin] == Derivative[0, 3][u][t, xMax]};

{xMin, xMax} = {-4 \[Pi]/0.0677, 4 \[Pi]/0.0677};
k = 0.0677/4;
TMax = 5000;
thisstep = 0;
laststep = 0;
Timing[
 uSolpbc = u /. NDSolve[pde, u, {t, 0, TMax}, {x, xMin, xMax},
     MaxStepFraction -> 1/150,
     StepMonitor :> (
       laststep = thisstep; thisstep = t; 
       stepsize = thisstep - laststep;
       ),
     Method -> {"MethodOfLines", 
       Method -> {"EventLocator", 
         "Event" :> (If[stepsize < 10^-4, 0, 1])}}
     ][[1]]
 ]

unfortunately for the given problem this will be even slower than letting NDSolve run into "effectively zero stepsize". It might be different for other problems, but using event locators is in general rather slow, so I wouldn't have much hope to achieve any speedup this way except when the time for a single step is much larger than in this example. You could use something like If[t > 4500, Print[t -> stepsize]] within the StepMonitor to see what happens and check that it does what it is supposed to do.

A much easier approach is to just limit the maximal numbers of steps to be used which will also limit the maximal runtime. It is of course depending on the system you solve how far that number of steps will take you. So it probably needs some estimation about what a good value would be, for your example a value of 200 already seems to show the characteristics of the solution and is about twice as fast:

{xMin, xMax} = {-4 \[Pi]/0.0677, 4 \[Pi]/0.0677};
k = 0.0677/4;
TMax = 5000;
thisstep = 0;
laststep = 0;
Timing[Quiet[
  uSolpbc = u /. NDSolve[pde, u, {t, 0, TMax}, {x, xMin, xMax},
      MaxStepFraction -> 1/150,
      MaxSteps -> 200
      ][[1]], NDSolve::mxst]]

Plot3D[uSolpbc[t, x], {t, 
  0, (uSolpbc@"Domain")[[1, 2]]}, {x, -185.618, 185.618}, 
 PlotRange -> All]
Albert Retey
  • 23,585
  • 60
  • 104
  • Thats very interesting! I didn't think about using MaxSteps. I'll give that a shot as you have demonstrated for a bunch of other problems. Thanks! – dearN Jun 23 '12 at 14:07