Questions to interpolation in computing the fractional density in ~aurora/atomic.py

[zli11]

As a senior to the Aurora, I have a few (maybe naive) questions as following in computing the fractional density of He ionization/recombination (~aurora/atomic.py) with this GREAT framework:

1. In the following line:

https://github.com/fsciortino/Aurora/blob/b64a8ca08ecfe400b3e8a090ce15476536d645fd/aurora/atomic.py#L864

I guess abs(table-table[...,[0]]).all() aims to test if the dimension of X is nontrival, thus a 1D interpolation could work instead of the 2D. However the function of .all() always returns a bool with true=1 and false=0 which is in the opposite of the original expectation.

2. For:

https://github.com/fsciortino/Aurora/blob/b64a8ca08ecfe400b3e8a090ce15476536d645fd/aurora/atomic.py#L867

I’m a bit comfused with this scale: *np.log(10). Since x, y, and table here are all the indeces of 10. Does it really mean 10**np.log(10) which seems make no sense?

3. The interpolation with CartesianGrid requires an equally spaced grids in the table of adf11. https://github.com/fsciortino/Aurora/blob/b64a8ca08ecfe400b3e8a090ce15476536d645fd/aurora/atomic.py#L690 Unfortunately the listed logne and logTe in acd96/scd96 for He are not uniformed (i.e https://open.adas.ac.uk/detail/adf11/acd96r/acd96r_he.dat). Is there any module can deal with that?

Looking forward to your reply!

Cheers, Zhi

[fsciortino]

Hi @zli11 ,

thank you very much for your detailed questions. I'll address them in order:

1. thanks for spotting this mistake. Indeed, the all() operation was in the wrong place, which probably meant that 2D interpolation was always been used (with a small slow-down).

2. The np.log(10) factors are used to change from base-10 logarithms to natural-base logarithms. This has been done because @odstrcilt first noticed that operations in natural base ("e") are faster in python than in base-10. Using numpy everywhere makes the difference smaller, but still not negligible:

>> %timeit np.power(2.718281828459045,3)                                  
2.06 µs ± 67.7 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

>> %timeit np.exp(3)                                                      
1.23 µs ± 64.2 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

3. It's quite impressive that you noticed that the acd96/scd96 for He are not exactly equally-spaced -- the deviation from equally-spaced is very small, actually. You are correct though that CartesianGrid is not designed to deal with non-equally-spaced files. I've started to address this issue, although it may need a little more testing before we merge into the master branch.

I've been making updates/comments to address your questions in PR #41 . Any more feedback from you would be appreciated!