search

simpeg / simpegEM1D

Frequency and time domain EM forward modeling and inversion program
MIT License
18 stars 11 forks source link

Transfer to Simulation: survey, source and receiver classes #39

Open dccowan opened 4 years ago

dccowan commented 4 years ago

Here, we want to outline the structure and properties for the survey, source and receivers class.

Current Organization

Sources and receiver: No classes for these right now. Everything is defined in survey

Survey: all properties (locations, frequencies, source type, Tx-Rx offset, waveform ...) are defined here

Survey for stitched 1D: This is defined in the same .py as the simulation for stitched 1D. Most of the survey properties are actually defined in the simulation class.

Waveforms: We have Waveform.py which makes standard waveforms and Waveforms.py which contains preset waveforms. We should give this a better home to be more like SimPEG's TDEM class.

Challenges

  1. Right now, the problem is solved assuming the same source and receiver type are used for all measurements. It makes sense to define the source and receiver properties in a single survey object in this case. Should we stick to the current organization, or define the source and receiver classes properly? We could do something to make the code efficient if the transmitter-receiver pairs have identical properties.

  2. Do we want to make a single survey object that works for the local 1D AND stitched 1D simulation, or do we want to keep as separate surveys? Right now, the survey class for the local 1D problem allows you to define Tx and Rx locations. This is done purely to compute the separation distance. However, we could likely create a single survey class. In the event you are only doing local 1D, some properties just wouldn't be used.

  3. We have a lot of auto-generation of surveys with preset parameters. We could find a better home for this.

dccowan commented 4 years ago

Initial consensus is that we want the code to be fully generalized

sgkang commented 4 years ago

Hi Dev, thanks for making comments.

  1. Not sure what's the best way... We can generalize, but then we need to develop a kernel function supporting various components .. At this point, I would rather stick to current organization, but make it bit clearer.

  2. I am open for this. My main reason for having separate class was for the parallelization.

  3. I guess this is mainly for global problem and survey. I am open for any suggestions. Again, this was mainly for parallelization.