Renaming of methods' Problems

In the next release of SimPEG we are renaming many of the base properties to be more in line with pythonic conventions, pep8, etc., and we are also refactoring to get rid of SimPEG’s Problem and replacing it with Simulation (which moves the forward operations from a Survey object that has been paired with a Problem to just a Simulation). As part of this, I’d also like to update the names for each method’s problems, to have a consistent convention across SimPEG.

Currently

For example in FDEM and TDEM, the names are

• Problem3D_E
• Problem3D_B
• Problem3D_H
• Problem3D_j

In natural source em:

• Problem1D_ePrimSec
• Problem3D_ePrimSec

In the static methods IP, and DC, they are

• Problem2D_CC
• Problem2D_N
• Problem3D_CC
• Problem3D_N

The simulations in the potential field methods are currently

• MagneticIntegral
• Problem3D_DiffSecondary
• GravityIntegral
• Problem3D_Diff

In VRM

• Problem_Linear
• Problem_LogUniform

And the others:

• RichardsProblem
• StraightRayProblem

As you can see, the convention in naming is certainly not consistent, and we should make a decision moving forward of a good convention that incorporates the Simulation name possibly. Some things we might want to keep are, distinguishing between dimensionality of a simulation, possibly being able to use autocomplete within each package to find the simulations (a.k.a. they would all start with Simulation), being descriptive with the names, etc. We would like to keep pep8 conventions for class names. Keep in mind that the method names would already be a part of the path to the Simulation class.

Mostly try to think about how suggestions would propagate, as some things might get quite long. For example I’ll put out three possible formats:

Simulation(Dimension)(ShortDescription), Simulation(Dimension)(LongDescription), (LongDescription)Simulation(Dimension).

For Example

1. Problem3D_E → Simulation3DE or Simulation3DElectricField or ElectricFieldSimulation3D.

2. Problem3D_B → Simulation3DB or Simulation3DMagneticFluxDensity or MagneticFluxDensitySimulation3D

3. Problem3D_j → Simulation3DJ or Simulation3DCurrentDensity or CurrentDensity3DSimulation note here, should j be capitalized or not?

4. Problem3D_CC → Simulation3DCC or Simulation3DCellCentered or CellCenteredSimulation3D.

5. MagneticIntegral → Simulation3DInt or Simulation3DIntegral or IntegralSimulation3D

[jcapriot]

Just to keep this updated, we had a nice discussion on this at the last SimPEG meeting (Feb. 26th, 2020) and decided on a general format of Simulation(Dimension)(LongDescription).

With two major thoughts, the first being that a longer description allows an unfamiliar user to better understand what it is. The second, that you can always do something in your own code such as from SimPEG.electromagnetics.frequeny_domain import Simulation3DElectricField as Sim so it doesn’t need to be typed out every time.

[lheagy]

Thanks for getting this going @jcapriot! I agree with the general naming convention of Simulation(Dimension)(ShortDescription). This keeps the names grouped together when tab-completing, and stays fairly compact.

So my vote is with the pattern

1. Problem3D_E → Simulation3DE

2. Problem3D_B → Simulation3DB

3. Problem3D_j → Simulation3DJ

4. Problem3D_CC → Simulation3DCC

5. MagneticIntegral → Simulation3DIntegral (here I think Integral is worth spelling out b/c Int maps to Integer in so many other contexts)

for visuals, I am also fine with lower-casing the E, CC etc