ajfriedlan

35 Reputation

4 Badges

1 years, 285 days

MaplePrimes Activity


These are replies submitted by ajfriedlan

@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?

@acer 

This is research project of mine, I'd like to keep the code confidential. That being said, I also (perhaps wrongly) figured that if the code worked sometimes, the issue was not related to the code itself. If you would be so kind to look at my code, I can send it to you privately.

 

Thank you.

 

 

@Carl Love To 20 digits of precision it does indeed run very slowly. I'm going to let it finish one round of simulations so I have the data, but then I will certainly explore other methods.

@vv Can you explain why increasing the number of digits made everything work out just fine?

Also, not so sure that rkf45 is the best method, it was a suggestion from my supervisor. I'll give it another try, allowing dsolve to choose.

Thank you so much for your insight!

Page 1 of 1