You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 12, 2023. It is now read-only.
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
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.
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.
We have a lot of auto-generation of surveys with preset parameters. We could find a better home for this.
The text was updated successfully, but these errors were encountered:
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.
I am open for this. My main reason for having separate class was for the parallelization.
I guess this is mainly for global problem and survey. I am open for any suggestions. Again, this was mainly for parallelization.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
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.
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.
We have a lot of auto-generation of surveys with preset parameters. We could find a better home for this.
The text was updated successfully, but these errors were encountered: