Fix caspol, excluding direct field in DGF and allowing XikBloch mode

[congzlwag]

scuff-caspol was not able to calculate compact geometries as was in 9c6d0cb , not even for a simple square slab. It turns out there are several data type mismatch, and a bug that the dyadic Green's function should have been the scattering part only.

#220 is a parent of this pull request.

Data type mismatches:

M->LUSolve(RFSource) in GetDyadicGFs.cc : M was real, RFSource is complex

• 5c931ae made RFSource to be real by copying the real part, risking the imaginary part, although the imaginary part should be always 0 from my intuition and preliminary numerical verification.
• 1935f0f made M to be complex at the very beginning of its creation, ensuring no information loss. In this way the memory consumption is doubled at some points.
• I am still verifying whether RFSource can be created as a real matrix or not.

XMatrix in RWGGeometry::GetDyadicGFs: created as complex but based on memory of double array

XBuffer is a pointer to a double array, but XMatrix was created as
HMatrix XMatrix(1,6,LHM_COMPLEX,LHM_NORMAL,XBuffer) . It is verified from the source that XMatrix being complex is unnecessary. Fixed by 44e48b3 .

Direct field should have been excluded when calculating Dyadic Green's Function for caspol

6fb404e fixed this. There must be an explicit ScatterOnly=true .

With these patches, scuff-caspol is able to calculate the potential by a finite PEC slab, and the outcome is very close to the outcome from setting --PECPlate (which invokes a closed form DGF) at those locations close to the slab.

[congzlwag]

Update May 21st

In principle we only need one-point DGF, so a7070c0 and 237df82 have reshaped the XMatrix passed into GetDyadics to be (1,3), which hints TwoPointDGF=false later on.

To prune unnecessary memory cost, for compact geometry RFSource, RFDest and M are now all real valued. 00cfc22 , 181ffcb , c5cc8f4 and 79d592e did this.

Later on I realized that in the --XikBlochFile mode, the polarizability was never looked up. Instead, it is loaded only in GetXiIntegrand, which is why this is not a problem in --XiFile mode nor in the full integration mode. To solve it, I separated this procedure into LoadPolarizability, which is called right before the calculation at a certain imaginary frequency, including GetXiIntegrand and GetCPIntegrand . 7bfb0f8 , 97f24be , 81bda29 , 030b1aa and 692739c did this.