ENH: Improve FDEM 1D Simulation to for multiple sources or receivers and inversion

[ckohnke]

Proposed new feature or change:

Was looking into using SimPEG to do a 1D inversion of a FDEM LineCurrent source with arbitrary shape to multiple airborne PointMagneticFluxDensity receivers. I tried empymod + pygimli to handle the forward and inversion respectively, but the speed was a bit slower than I anticipated due to the FD approximations to J, so while it was running I started looking into SimPEG's 1D implementation and noticed a few things:

• Currently SimPEG.electromagnetics.frequency_domain.Simulation1DLayered only supports a single source and receiver location. Works if you only want to stitch together a bunch of 1 source location, 1 receiver location soundings.
• Sources can only be airborne (makes sense given the code was likely originally developed for airborne magnetic dipoles)
• Couldn't get a LineCurrent or an arbitrary source direction to work.

I'm at a bit of a loss of what the step forward would like like in improving Simulation1DLayered. Empymod does a great job at solving arbitrary 1D forward problems, but is lacking the inversion components. SimPEG can handle the inversion components, but needs methods to calculate Jvec and Jtvec. I know Dieter has done some work on combining the two back in 2018 (https://github.com/OpenGeophysics/scratchpad), but still computes J by FD.

I'm also wondering if the improvement would be best on the SimPEG side, by creating a simulation that's forward is a wrapper for empymod, and then containing the methods necessary for inversion by solving the derivatives to the 1D recursion relations (tricky, but doable!). Or the solution could be on the empymod side, which should have more direct access to the recursion relations. The other question is if the formulations have to match between the forward and sensitivity. I believe empymod is based on Hunziker et al. 2015 and Key 2012 for the forward, but there may be a more advantageous formulation for the derivative calculations. Theoretically I'd think any pair should be compatible for frequencies/offsets/etc. that they are valid.

[ghwilliams]

I'd like to look at this issue, particularly at the problem of computation of the Jacobian matrices, if indeed there is something that can be done to improve its performance.