@AmirHosein Sadeghimanesh

I experienced a very similar problem. And this was in Maple 2020!

Indeed, it seems that if one of these "corrupted" files open in Maple, then other files will become corrupted with the error message too.

@vv 

Thanks, I'll give it a go!

@Kitonum 

Thank you for your reply, I was excited to see your solution! Unfortuantely, it was difficult to generalize. I was having trouble obtaining solutions if I made seemingly trivial changes to the intial guesses. It was also difficult to find solutions for other W.

I realized that fsolve is wildly dependent on the number of digits Maple is set to use. For example, use 20 digits? No solution. 50 digits? No solution. 100 digits? Solution! But use 150 digits? No solution. Weird!

In order to obtain solutions for all values of W, I had to run a while loop to cycle through the number of digits to use until a solution was obtained.

What the heck is going on here?

@Carl Love 

Thanks Carl Love! <3

@acer 

I think you are probably right. What I am after is a function I can plug into another function on which I plan to numerically integrate. I will give numeric interpolation a try,

@Carl Love 

Alright, the comma let's me save. Unfortunately, the read command results in an error: "unable to read 'MyData.map'"

@Carl Love 

Thanks for the swift reply. I tried your suggestion but recieve the error "last argument to save must be a file or library name". Any thoughts?

I also get this if I try to save something simple like a variable temp:=Matrix(2,2):

@acer 

Hey acer,

I was reading your post from nearly a decade ago and have been trying to implement it into my code to improve memory usage. One problem I have encountered is that one of my 'parameters' happens to be a function of the dependent variable of the IVP. It seems that dsolve\parameters must be numeric, not functions. I suppose this makes sense, given that the IVP will change if a new function is substituted each loop. Is there any way around this issue?

Alternatively, is there a way to clear the memory allocation at the end of each loop iteration to reduce memory consumption as the loop increments?

Cheers.

@Carl Love

Okay Carl, I will give that a try. Hopefully that will reduce the memory usage and perhaps even speed things up.

Unfortunately, it's not so simple to turn i and j into parameters of the system. If I naiively write (for just one of the integrals):

RKRsystem := dsolve( {diff(N(K),K) = K*fNO2(i,j), N(1e7) = 0}, numeric, method = rkf45, maxfun = 1000000, parameters=[i,j]),

I recieve the error: Bad index to array (in fNO2). This is because the i and j are meant to be indicies for arrays inside the call to fNO2. For example, something like

fNO2 := (i,j) -> F ( g[ i ], h[ j ] ),

where g and h are arrays of numbers. I guess I will need to restructure my code. Do you happen to know a quick fix for this before I try that?

Cheers.

EDIT:
Nevermind, a moment of thought and the answer presented itself. Thank you for your suggestions.

SECOND EDIT:

Well, I took your advice and was able to condense the 4 dsolve calls into a single dsolve call. It would be nice if I could specify all of my parameters using the dsolve\parameters option, however one of the parmeters happens to be a function of integration variable. It seems that dsolve\parameters must be numeric, not functions. I suppose this makes sense, given that the ODE will change if a new function is substituted each loop. Is there any way around this issue?

Alternatively, is there a way to clear the memory allocation at the end of each loop iteration to reduce memory consumption as the loop increments?

@Carl Love 

Hello Carl,

Thank you for your reply. From some trial and error, I have found that using the dsolve approach (runge kutta) is preferable to numeric integration. Regardless of this, after a calculation is performed and the result is assigned to a matrix element, why isn't the memory freed up? Especially given that I reassign the variables after each loop. Might it be because each call to RKR(c,d) (my dsolve procedure) creates a new procedure that is not cleared from memory each loop?

Cheers.

@Christian Wolinski 

So in short, square brackets are preferable to round brackets. Do I have that correct?

For example, in nested do-loop at the end of my document, when I write:

RR(c,d):=nR:

to update an matrix element of the matrix RR, I should instead write:

RR[c,d]:=nR:

@Christian Wolinski 

Hi Christian, thank you for your reply. I'm not sure I understand you analysis of my code. What is the difference between my implementation and your suggestion? Where do I use Rootz[1] = [2][1]; and what does that line instructing maple to do? (In terms of memory allocation.)

Just to be clear, this is not the part of my code that is causing trouble, but I do realize that the very same poor coding practice later on in the document might be the source of my difficulties.

Please help me try to understand what exatly I'm doing wrong.

Cheers.

@Kitonum 

You are totally right.

@dharr @acer

Thanks for your help, I implemented the necessary changes! Here's another one further on in my calculations Maple can't seem to solve...

071019_Temporal_Integral.mw

It seems like one has to work pretty hard to 'trick' maple into performing an integration. Can either of you direct me to a list of tips and tricks for integration in Maple?

@Carl Love

Thank you for pointing me to the concept of thread safety and the Maple documentation. It appears that the functions I am using are not listed as thread safe. Specifically, the functions are ArrayTools:-Concatenate, which makes sense, but also int, which is troubling because the paralellization I wish to do involves performing an integration many times across a grid with slightly different parameters each time. Is there any way to get around the fact that int is not considered threadsafe so that I may decrease my computation time?