support for single-precision floating point for fields array functions

[oskooi]

#1544 and #1675 added support for the single-precision floating point type for the time-domain and DFT fields. However, the fields array functions such as fields::get_array_slice and fields::get_dft_array only use double precision which unfortunately exacerbates the memory bottleneck described in #1797. This PR modifies all of the array functions to support single precision.

[codecov-commenter]

Codecov Report

Merging #1833 (a852f73) into master (e4b845c) will decrease coverage by 0.13%.
The diff coverage is 88.88%.

@@            Coverage Diff             @@
##           master    #1833      +/-   ##
==========================================
- Coverage   73.53%   73.40%   -0.14%     
==========================================
  Files          17       17              
  Lines        4879     4896      +17     
==========================================
+ Hits         3588     3594       +6     
- Misses       1291     1302      +11     

Impacted Files	Coverage Δ
python/adjoint/optimization_problem.py	56.77% <ø> (ø)
python/adjoint/wrapper.py	98.50% <ø> (ø)
python/simulation.py	76.85% <75.00%> (+0.14%)	⬆️
python/adjoint/utils.py	95.28% <100.00%> (ø)
python/visualization.py	45.65% <0.00%> (-1.12%)	⬇️

[oskooi]

This is finally ready to be merged. There were lots of (little) changes necessary to make everything work. The documentation for get_array and get_dft_array has been updated to mention that the type of the array elements returned by these two functions is the same as the fields themselves.

For now, the gradient computed by the adjoint solver is still in double precision regardless of the type of the forward and adjoint DFT fields. This is not a performance limitation since the gradient is much smaller in memory consumption than the DFT fields .To support computing the gradient in single precision would require changes to geom_epsilon::eff_chi1inv_row and other material-related functions which currently return the ε tensor in double precision. This can be addressed in a separate PR, if necessary.

[stevengj]

The basic principle is to try to keep scalar calculations, like accumulating the integral, in double precision. Use realnum only for arrays like the fields. So, when you take the fields array and integrate it, you convert the value to double precision first (since C++ doesn't support mixed-precision calculations on complex numbers).

It might be helpful to write a little utility function, e.g.

std::complex<double> cdouble(std::complex<float> z) { return std::complex<double>(real(z), imag(z)); }
std::complex<double> cdouble(std::complex<double> z) { return z; }

[oskooi]

The scalar calculations have been reverted to double precision and the realnum type is now used only for the fields arrays.

There are two slight adjustments to the tolerances of the checks in test_adjoint_solver.py which are actually unrelated to this PR. These were necessary because they were causing test failures on my local i7-7700k machine when using single precision.