Timeline for NDSolve runs out of memory
Current License: CC BY-SA 3.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 18, 2012 at 16:45 | vote | accept | fpghost | ||
| Oct 14, 2012 at 23:43 | comment | added | J. M.'s missing motivation♦ | @drN, yes, you still expend the same amount of effort; after all, you still have to do all those evaluations to get to where you want to be. | |
| Oct 14, 2012 at 21:10 | comment | added | dearN | @J.M. But using the same start and end point for the interval for NDSolve would result in the same amount of run time, using just lesser memory then....? | |
| Oct 13, 2012 at 9:04 | comment | added | fpghost | let us continue this discussion in chat | |
| Oct 13, 2012 at 8:43 | comment | added | J. M.'s missing motivation♦ |
Well, "StiffnessSwtiching" uses two different versions of the Bulirsch-Stoer extrapolation scheme as the stiff and nonstiff component integrators. You could try something like Method -> {"StiffnessSwitching", Method -> {"ExplicitRungeKutta", "ImplicitRungeKutta"}}, but you should known that RK methods are less efficient than extrapolative methods for high-accuracy computations. If you don't need too much accuracy (e.g. having only six good digits is fine), then sure, use RK.
|
|
| Oct 13, 2012 at 8:27 | comment | added | fpghost | What about my use of StiffnessSwitching? I'm not really sure what I'm doing with this, but it seems to increase speed, although accuracy is lost. Could there be a case for another method like RungeKutta? | |
| Oct 13, 2012 at 6:45 | comment | added | fpghost | perhaps, and if the method you suggest stops memory death that is at least something. | |
| Oct 12, 2012 at 23:46 | comment | added | J. M.'s missing motivation♦ | "hmm, doesn't seem to show a Timing improvement?" - this is an equation with an oscillatory solution, after all; some amount of effort has to be expended. :) | |
| Oct 12, 2012 at 23:45 | comment | added | J. M.'s missing motivation♦ |
For your second case, you modify the NDSolve[] call appropriately: NDSolve[{eq, Φ[10000] == ...}, Φ, {r, 2, 2}, opts].
|
|
| Oct 12, 2012 at 23:39 | comment | added | fpghost | I also added the other solution where we do integrate from infinity (r=10000) ICs, and I need to use NDSolve to go the other way down to r=2 say. This is the one that NDSolve is really struggling with for large omega.. | |
| Oct 12, 2012 at 23:32 | comment | added | fpghost | hmm, doesn't seem to show a Timing improvement? but maybe there is a memory improvement. I agree that the final interpolating function produced is smaller, but does that also mean NDSolve is using less memory in the process of getting to the result? | |
| Oct 12, 2012 at 23:14 | comment | added | fpghost | Oh, actually, sorry I misunderstood you, maybe that will work then if NDSolve behaves like that. I didn't realise it could skip forward/backward. Unfortunately I have to dash now, but I will try this ASAP. thanks. | |
| Oct 12, 2012 at 23:11 | comment | added | J. M.'s missing motivation♦ |
NDSolve[] will still start at the initial condition you gave (in your new example, Φ[rH] == (* stuff *)); as mentioned in the docs, the integration interval supplied need not contain the value in the initial conditions, and NDSolve[] will go forward or backward as appropriate. That's why I don't understand why you say this won't work. Have you tried it?
|
|
| Oct 12, 2012 at 22:55 | comment | added | fpghost | that's not possible, the IC for the solution I want have to start at a certain radius (the event horizon) and I integrate it out to the "infinity". The solution with ICs set at the infinity and integrated inwards are different, and there is no known way to set the ICs anywhere else..Sorry if that's not a clear explanation, but that much at least is a given in my problem: ICs must be at r=2, point I want must be at r=10000. Edited my post now that should be a working example. Try large omega values to observe the lag. | |
| Oct 12, 2012 at 22:44 | comment | added | J. M.'s missing motivation♦ |
Right; that's why I suggested that you have the start and end points be the same. If you'll edit your question to show the NDSolve[] snippet that you say has taxed your memory, I can edit my answer to match.
|
|
| Oct 12, 2012 at 22:40 | comment | added | fpghost | thanks but that won't work for me. I should have mentioned that I need to set up some initial conditions at a certain radius (the dependent variable) and then integrate outwards to a large distance, and it's the point at large r where I need the solutions. But I don't need the rest of the 10,000, so Mathematica could dump it, as soon as it gets enough data to leap frog to the next point if you see what I mean. | |
| Oct 12, 2012 at 22:17 | history | answered | J. M.'s missing motivation♦ | CC BY-SA 3.0 |