GNU Scientific Library - Bugs: bug #46678, Bug in gsl_sf_coulomb_wave_F_array
You are not allowed to post comments on this tracker with your current authentication level.
bug #46678: Bug in gsl_sf_coulomb_wave_F_array
Submitter: | Patrick Alken <psa> | ||
Submitted: | Sat 12 Dec 2015 09:09:10 PM UTC | ||
Category: | None | Severity: | 3 - Normal |
Operating System: | Status: | None | |
Assigned to: | None | Open/Closed: | Open |
Release: |
Attached Files
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
Follows 1 latest change.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2015-12-12 | psa | Attached File | - | ![]() |
Added testCoulomb.cpp, #35718 |
from nih =at= pks =dot= mpg =dot= de
Dear GSL developers,
I found a bug in the function gsl_sf_coulomb_wave_F_array which uses the recurrence relation to obtain F for different l's.
To be short, when eta is large, and l is at least moderately large, inaccuracy occurs in the implementation of the recurrence such that F has unphysical spikes at certain x for smaller l's.
My observation is that F is determined directly for the largest l, and F for smaller l's are determined from the recurrence relation.
When l is large, the number of recurrence is large to obtain F for small l's.
Therefore, errors in F's get accumulated as we proceed to get F for small l's.
Attached please find a test program.
The program uses two methods to obtain F for different l's and x's.
The first method obtains F directly, and the second method obtains F from recurrence relation.
Please compile it using "g++ testCoulomb.cpp -lgsl -lgslcblas".
Now run the program using "./a.out > resultCoulomb".
We can now take a look at the output of the program using gnuplot.
After launching gnuplot, just type plot "resultCoulomb" using 1:2 every ::2::2000 to see the output for l=0 at different x's using the first method.
And type plot "resultCoulomb" using 1:2 every ::2002::4000 to see the output for l=0 at different x's using the second method.
Now you can find, F is fine using the first method, but F has unphysical spikes.
You can see similar behaviors for other l's by "using 1:3", "using 1:4" etc in gnuplot.
I can of course always stick to the first method, but the second method is much faster.
So it would be great if you could fix this problem.