@Giulianot There are memory limitations also. I just killed the dsolve because it was using 9 Gig of memory, which is all that could devote to it.

Certainly the average computer these days can tolerate an uptime of a few days. Yes, you need to set it so that it doesn't turn off after a certain amount of idle time.

But I don't have much hope for your system. Like I said, dependent variables that appear in the denominators of exponents are a nasty thing.

Use Google's site operator to do a site-specific search. For example

"Maple 6..9" site:www.maplesoft.com/applications

brings up 566 hits.

@Giulianot Thanks, the system is much easier to work with now.

My suspicion is that it's just too complicated. How long have you let it run? I would let it run a few days before giving up. There are four methods available for DAEs: rkf45_dae, ck45_dae, rosenbrock_dae, or mebdfi. For example, I gave the commands:

sys:= {...your long system...}:
dsolve(sys, numeric, method= rosenbrock_dae);

and it's currently running on my machine, although I don't have a few days to devote to it.

@Bendesarts The table is Maple's most flexible data structure: It gives you random access to an unlimited and easily extended amount of memory, and both the indices and the entries can be anything, including sequences. There is a small performance penalty for all that flexibility. In your case, the indices are always names, there are only three memory slots used, and I guess that you'll never need to dynamically extend (enlarge) these structures.

In terms of code readability, Records allow access through the unambiguous colon-dash syntax: MyRecord:-obj. Here, obj is a constant name; it can never be something which has been assigned a value, so a reader would never have to look back for a reference to it. Records also allow access via the usual indexing syntax: MyRecord[obj]. In this case, it's possible (but a bad practice) that obj has been assigned another value.

Another reason to use Records: If you pass a bad index to a Record, then you get an error message; if you pass a bad index to a table, you don't.

@Giulianot I agree with Tom Leslie: If you use interactive (menu-based) commands, it makes your work very difficult to debug. If you were to use typed commands, it could likely be debugged in under an hour. That is, if there is in fact a bug. It could simply be that your system is too complicated to solve. Dependent variables that appear in the denominators of exponents are a fairly nasty thing.

Also, your system is visually a mess to work with, filled with numbers that are meaningless to anyone here.

Try

interface(verboseproc= 2);

before the copy.

@raazia You're the one who said that R was a constant. You need to show me some code.

Please post your code that doesn't work every time.

@KCPower My guess is that Grid doesn't have access to all of gobal memory, even if that's read-only access. In this case, that means that it doesn't have access to t. The simple workaround is to pass t as a parameter:

t:= 1;
A:= proc(n) local i; add(i^2, i= 1..n) end proc;
GS:= proc(t) local k; Grid:-Seq(A(k), k=t..t+4) end proc;
GS(t);

Although it doesn't seem to be necessary, I made i and k local also. It can't hurt.

This is a good time to warn you against using the with command to load commands that will be used inside procedures.

@Oatesy94 If you post the code that you have so far plus a link to a formal description of the algorithm, I can help.

@bordplate To return the portion under the sqrt to 1/r + 1/mu, follow the commands given by Preben with expand(%).

The code formatting in your post is unusual (with the quotation marks) and thus difficult to read. I need to see how the code appears in your worksheet. Please upload your worksheet by using green uparrow in the editor. If you get an error message, make the post anyway. I may still be able to download it.

To summarize the mathematical point that I'm trying to make in a single sentence:

The ODE a*diff(y(t),t$2) + b*diff(y(t),t) + c*y(t) = (d+e*t)*exp(f*t) (a, b, c, d, e, f all complex constants, a<>0, e<>0, f<>0) will have a term of the form t^2*exp(f*t) in its solution only if a*f^2 + b*f + c = 0.

Until you can account for that, the physics are irrelevant.

@tsunamiBTP

I'm just a private citizen who posts here on MaplePrimes. Anyone else who's reading this is welcome to jump in. The counter says that 30 people have read this thread so far. I only understand the mathematics of solving constant-coefficient linear IVPs with polynomial and exponential forcing functions by the Laplace transform method and the method of undetermined coefficients; I don't understand the physics involved in your situtation. Nonetheless, the IVP problem that you present is purely symbolic mathemathics, and it should be possible to solve it without making any reference to the physics.

Here is a worksheet illustrating the situation that I'm talking about. Note that there's a t^2 term in the first solution and no t^2 term in the second solution. Yet the second solution was supposed to be a generalization of the first.

Download Laplace.mw

@emendes Yes, you got that right. I don't have the time to go into details right now, but see what you can learn from the help pages ?Grid. You do not need to address things to specific cores; that part is handled behind the scenes by the package. I find that the easiest way is to set things up as if they were going to be done with a seq command, and then replace it with Grid:-Seq. That's all there is to it! If you have a situation where the input to one command doesn't depend on the output of another, then this is almost always very easy to do.