Bringing in `simpegEM1D` into `SimPEG`

[sgkang]

This is a pull request bringing in simpegEM1D (https://github.com/simpeg/simpegEM1D) to SimPEG This was a team efforts of @dccowan and @jcapriot, so thanks for both Joe and Devin!

Major changes has made for this pull request:

1. Update the em1d codes to be compatible with the latest simulation class
2. Remove the em1d specific source, receiver, and survey classes, and update the em1d codes in a way that can be compatible with the existing em source, receiver, survey classes
3. With the Item 2 users can use the same source, receiver, and survey classes for em1d codes, which use pseudo-analytic solution, and other PDE-based codes

Summary of technical details about the update (from @jcapriot)

• It automatically does things like only calculate unique offsets, and it determines the times needed for quadratures and ensures that the frequency range spans the proper needed times.
• It represents a lot of the empymod filters as their linear matrix operators instead of functions to allow for easy calls of the derivatives.
• It also represents the convolution for an arbitrary source waveform as another matrix multiplication. It also now supports on time measurements (and measurements oddly during ramp ons and ramp-offs).
• I've enable the derivatives for the other physical quantities of interest (susceptibility and layer thicknesses).
• Lastly I've cleaned up a bunch of the leftover files from the previous iteration (all of the files in the folder em1d/ are still there though for comparisons).

Below are items left for further development, but we are planning to address them once we merge this into main

• [ ] Update the tests for derivatives with respect to source height
• [ ] better integrate the stitched 3d regularizers!

[codecov[bot]]

Codecov Report

Merging #1059 (70911cd) into main (1dd03f6) will decrease coverage by 1.13%. The diff coverage is 66.17%.

@@            Coverage Diff             @@
##             main    #1059      +/-   ##
==========================================
- Coverage   78.61%   77.48%   -1.14%     
==========================================
  Files         177      183       +6     
  Lines       21125    22968    +1843     
==========================================
+ Hits        16607    17796    +1189     
- Misses       4518     5172     +654     

Impacted Files	Coverage Δ
SimPEG/electromagnetics/analytics/FDEM.py	85.58% <ø> (-0.13%)	:arrow_down:
SimPEG/electromagnetics/utils/em1d_utils.py	37.23% <37.23%> (ø)
SimPEG/regularization/laterally_constrained.py	55.93% <55.93%> (ø)
SimPEG/electromagnetics/time_domain/receivers.py	90.56% <57.14%> (-2.37%)	:arrow_down:
...electromagnetics/frequency_domain/simulation_1d.py	62.96% <62.96%> (ø)
SimPEG/regularization/regularization_mesh.py	81.37% <67.79%> (-9.32%)	:arrow_down:
...imPEG/electromagnetics/frequency_domain/sources.py	85.25% <69.23%> (-2.34%)	:arrow_down:
...mPEG/electromagnetics/time_domain/simulation_1d.py	70.09% <70.09%> (ø)
SimPEG/electromagnetics/base_1d.py	70.45% <70.45%> (ø)
SimPEG/regularization/base.py	85.29% <84.61%> (-0.28%)	:arrow_down:
... and 16 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 1dd03f6...70911cd. Read the comment docs.

[jcapriot]

@sgkang, Can you remove all of the binary files that got mixed into this branch? It looks like a bunch are in "examples/05-fdem/bookpurnong_inversion/"

[jcapriot]

Looks like there's still some more binary files left in tests/em/em1d/em1dtm/

[jcapriot]

@sgkang There's still tons of data files in this PR. Please go to the "Files Changed" tab here and filter out the .py files to see all of them. It looks like more got added in in the "-remove binary" commit. Mostly in the examples/05-fdem/bookpurnong_inversion directory and tests/em/em1d/em1dfm/ directory.

[jcapriot]

@sgkang After this round finishes, we'll check the diff coverage and ensure it's well tested.

[jcapriot]

I was chatting with @sgkang about this implementation of the stitched inversion. As written the Simulation1DStitched expects a 1D model for each sounding location identified by the user, keyed by a i_sounding argument attached to each source. Meaning sounding i_snd corresponds to a 1D vector sigma[i_snd, :] whose location is at the sounding location.

I would suggest a slightly different implementation that makes use of our discretize meshes to make this more generalized. The physical property model would instead live on a 3D mesh, that is defined by a 2D x-y mesh, and a 1D vertical mesh. The physical property is then interpolated from the nodes of the x-y mesh, to the sounding locations. In my opinion this makes it easier to associate locations with their physical properties, as they are defined by the mesh instead of the source locations and an i_sounding parameter. It might also be easier for a user to interact with the stitched code as well.

If the user provided a SimplexMesh with a node at each sounding location, this would be essentially equivalent to what it is now, however our code could be more generalized to the x-y mesh accepting possibly TensorMesh or TreeMesh as well.

[sgkang]

@jcapriot: I like the idea. A logical place to put the mesh seems discretize?

[jcapriot]

@jcapriot: I like the idea. A logical place to put the mesh seems discretize?

I've got a working PR for SimplexMesh at https://github.com/simpeg/discretize/pull/263