-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fields #3
Comments
In the current implementation we need to... for the data misfit it is important, otherwise they will be recomputed: https://github.com/simpeg/simpeg/blob/master/SimPEG/DataMisfit.py#L147 |
We could think about attaching the fields to the |
I think that this pulling out is showing where some of the holes are. Fields should be closer to where they are used. The objective functions really shouldn't care that there are dependencies to an operation. These should be captured elsewhere (like the simulation). I think that we would also have difficulty in the current implementation for a multiphysics inversion? if fields get passed to both objects? Not sure if @thast got around this or it was fine. |
I do not remember having to change anything and have not notice significant problem. Load Data
Wires and mapping
Grav problem
Mag problem
Data Misfit
|
Thanks for the code snippets! I think this works because they are both linear problems and you don't have to account for the fields in your https://github.com/simpeg/simpeg/blob/master/SimPEG/PF/Gravity.py#L124 So although it is probably passing the fields object around, it is never used - and I am not sure which one it would be (mag or grav problem). |
Thanks for pointing this out @rowanc1 ! True I have not try joint inversion for nonlinear problem yet. I will keep you updated once I've tried it. |
Sometime we pass around fields? Do we need to?
The text was updated successfully, but these errors were encountered: