MaplePrimes - answers and comments on Question, Any way to reclaim NAG (_d01akc) allocated memory ?

Some observations

Axel Vogt — Sat, 10 Dec 2011 19:53:44 Z

Some observations, while waiting for more, specific informations about your task.

Let me write w for your variable dz, being positive and large.

Your kmin is positive and small, so you do not need 'piecewise' in the definition
for your function f.

Also I would avoid to involve 'evalhf' in its definition, the NAG routine will do
that for you, if possible.

Roughly your kmax turns out to be of magnitude ~ 30*Pi and your task writes as

  Int(F(k)*cos(k*w),k = kmin .. kmax) for F = k -> BK0(k*rho1)/BK0(k*a)

So it is a finite cosine transform.

If w is large, then this may be a highly oscillating integrand - already for the
cosinus term. And if F is oscillating as well (BK0 = BesselK ?) this may even be
worse. But that heavily depends on the concrete setting (if F has poles ...).

Changing coordinates w = t*Pi/k it becomes

  Pi/w * Int( F(t*Pi/w) * cos(t*Pi), t = 1/2 .. kmax/Pi*w )

so the upper bound is roughly 30*w and w is large.

There are special methods for these highly oscillating integrals, it may be that
NAG's method as 'working horse' is not appropriate.

gc

icegood — Sun, 11 Dec 2011 18:09:28 Z

Run gc()! Already checked on EvalMapleProc from c. It works.

P.S. Problem not in neither evalhf nor in _d01akc itself. NAG itself is very good. Problem in native eval environment. And you must eun evalf because Int itself not accesible from evalhf environment.

thoughts

Axel Vogt — Tue, 13 Dec 2011 01:56:28 Z

I think you need not care so much for memory (if you are in Maple),
the system should care. Have you tried 'forget'?

For BesselK 0: you can try evalhf'ing Ooura's code (or even compile it).

The usual way for such tasks is to approximate F =BK0(..)/BK0(...).
If your a and rho are constant that could be done once.

Since that F is like exp * 1/k one could try a ChebPade approximation
(I think, that is what Ooura does in some sense).

If one 'factors' it into partial fractions over the Reals, then Maple can
find Int( F*cos ) symbolically in terms of ?Si, ?Ci and that evaluation
will be fast (and would avoid special methods for high oscillations).

PS: I do not understand, why replying to a post sometimes works
and sometimes creates a new branch in the thread ... :-(
Can some admin shift it place, please ...

I think I have the solution to my problem

Louis Lamarche — Tue, 13 Dec 2011 03:50:56 Z

I think I have the solution to my problem to this unusual memory consumption.
This is not elegant in the mathematical sense but practical.

in evalf(Int(f, kmin..kmax, method = _d01akc,epsilon=eps,maxintervals=1000000))

maxintervals=1000000 appears to create the problem. I will never use it again.

I used

evalf(Int(f, kmin..kmax, method = _d01akc,epsilon=eps) # eps =1e-12

and divided the interval kmin..kmax in subintervals not presenting more than 2000 oscillations
and avoiding this way the default maximum subinterval limit of 500 in _d01akc.

Thank you for your support and good advice.

played with it, again

Axel Vogt — Wed, 14 Dec 2011 02:01:03 Z

Using Ooura's intdeo (for oscillating factors) and Maple's BesselK I get 
    -0.109408897877946e-3 
(or -0.109408897877997e-3 depending on treating the tail towards infinity)

while the reported Maple result through NAG + Ooura's BesselK0 is
    -0.109403613457678e-3

intdeo is his implementation for 'double exponential integration'
for oscillating factors to an integrand g(x) * sin(omega * x + theta)
where one provides the function g and frequency = omega = dz,
integrals are taken over a range ] constant ... infinity [

Conclusions

Louis Lamarche — Wed, 14 Dec 2011 21:55:13 Z

1) Dont use maxintervals, you will eat all your memory (onless you have only one value to compute).
Split the integration interval
2) The results for this case appears good with a relative difference of 1.2e-10.

The kmin=0.000224399475256414 to kmax =91.5632886852008 was splitted in 52 intervals.
NAG (_d01akc) + Ooura's BK0 now gives -0.000109403613448212
compared with the previous one -0.000109403613457678 obtained with maxintervals=1000000

putting kl=kmax in the following expression for the tail of the integral form kmax to infinity
with the more precise values for

rho1=0.323147799002253 and a = 0.01785 and dz=7000

I obtain NAG (_d01akc) + Ooura's BK0 kmin..infinity = −0.000109403613448236

Axel Vogt used used a=0.323 and obtained intdeo + BesselK(0,x) : -0.000109408897877997
For this case Ooura BK0 + NAG(_d01akc) gives -0.000109408897865057

This appears coherent.

Again thanks a lot for your help.