Eig2D Solver speed up: use float64 and eigsh

[vongostev]

Hi Sébastien!

I've noticed that "The matrix can be very large but it is also very sparse and Hermitian" and trying to speed up eig2d solver:

1. Because of H matrix structure we can use np.float64 instead of np.complex128.
2. Because of H matrix is hermitian we can use eigsh instead of eigh

I added a function to check if H is hermitian and if it True, an algorithm uses eigsh instead of eigh. Also I changed type of H to np.float64. It also needs because complex-number matrix generate small noise in imaginary part of betas and profiles, which is unphysicall.

My version is much faster and generates correct profiles, but some profiles are swapped because of small differences of betas. For example, these betas are swapped:

new                 old
(14.62192877519683, (14.621928775196864-1.4871352228586787e-17j)),
(14.621928775196931, (14.621928775198063-3.882414689743801e-17j))

Performance graph

[vongostev]

Hi Sébastien!

Can one use an approach that you realized in eig solver for microstructured fiber modeling? ~I realized an index profile for microstructured fibers, but the results are trashed.~ I fixed an index profile generation by adding a cladding with correct refractive index. Now it looks like OK.

[vongostev]

I fixed incorrect m indexing in SI solver. Because of it the solver was non-functional.

[vongostev]

Hi Sébastien! I removed untested code of multicore index profiles and saved only tested changes of solvers ad core.

[wavefrontshaping]

Hi Pavel,

Sorry for the long delay, the end of the year was busy. Thanks for the updates.

Just a remark, try to submit smaller commits, focused on one part of a file or one feature and separate cosmetic changes, bug correction, and features. It makes it easier to review merge requests. Moreover, if I want to include one of your modification without the others, it is more difficult.

Otherwise, about eigsh and eigs, I see your point, but the imaginary part also gives information about losses, which can be important, especially for modes close to the cutoff. Does it change drastically the computation time? Maybe we can give the user the choice to discard the imaginary part to save time.

[vongostev]

Hi Sébastien!

I'm so sorry for a little tangled pull requests. I forgot to make a new branch for the code needed to my own purposes. In the future I will make separate branches for new features and pull it separately. Thank you for the remark.

My tests show that there are two points of performance optimization:

1. The algorithm used with float64 is faster than one used complex128
2. eigsh is faster than eigs

If small imaginary parts are important, we can add an additional argument to choose type of numbers. Choise of eigsh instead of eigs is now automatic with a test of H hermiticity.