the problem with "Problem"

I had a chat with @dougoldenburg today and he brought to light some of the confusion introduced by the term Problem in the framework, in particular when first introducing the SimPEG framework to new community members, which is perhaps indication of a more systemic issue.

Points of confusion

• often a first association with the word “Problem” is the thing you are trying to solve: the application, the reason you are considering inversion in the first place.
• “Problem” is over-used already. “Forward Problem”, “Inverse Problem”
• even in the paper, we use “problem” to mean two different things \cite{SimPEGpaper}

Potential Alternatives

• Physics
• GoverningEquations
• PartialDifferentialEquations
• PDE
• Equations

In looking at the current Problem.py and considering the construction of a forward simulation, I am (first pass!) partial to Equations.

• BaseProblem --> BaseEquations
• BaseTimeProblem --> BaseTimeEquations
• perhaps Problem.py --> GoverningEquations.py

Then in a module, if we consider EM

• BaseEMequations
• BaseFDEMequations
• Maxwell3D_e(BaseFDEMequations)

from SimPEG.EM import FDEM
equations = FDEM.Maxwell3D_e(mesh)
survey = FDEM.Survey(srcList)
equations.pair(survey)  # or fwdSim = simulation(equations, survey) down the road

I look forward to hearing thoughts!

[prisae]

This is only loosely related to this issue. But I would very much appreciate your feedback.

I created an issue related to Survey and Model classes in a potential future version of empymod: https://github.com/empymod/empymod/issues/14.

I would highly appreciate any of your thoughts and ideas, specifically from you experience with SimPEG. One benefit could be that it would be easier to implement empymod into SimPEG, if I follow a similar set-up as SimPEG.

[rowanc1]

If we go with an extra Simulation class this would remove the pair function (which made an initial parallel implementation I did with @bsmithyman difficult, as I recall) as well as add some ambiguity about where to put the functions calc_jvec, calc_fields, calc_dpred etc. (maybe some better introduction of pep8 here? and standards of calculating things?).

It would probably help out with simulation.validate() which could do a whole lot of things to try and catch errors before running a simulation or inversion.

Something weird about the introduction of multi-parameter inversions is that you actually need not even have a model. All parameters could be set directly and there are no mappings at all! Making the higher-level interface for fields/data etc be empty calls; i.e. calc_fields().

Another thing that is bugging me right now is if the simulation object is “stateful”, that is, does it have a simulation.model or are those stored somewhere else? Maybe in a slightly more generic cache than we have right now on the inversion object - which does warm_starts so as to skip some steps in the initiation of an inversion. This could also be a better way of doing deleteTheseOnModelUpdate by just saying physics.cache.set(model, 'MfSigma', MfSigma) and physics.cache.clear(). The cache could have it’s own settings on it for how long to remember things. This is implemented in a bunch of places including the receivers, fields and timemesh etc. If there were some better standards around this, than we could call simulation.cache.clear() to do a hard reset on everything.

This is a slightly bigger discussion obviously, and a bit undirected. Wanted to get my thoughts down somewhere though.