I understand the want to make them more discoverable, but I feel like there should be only be one place to import them from. You could add a link to those functions in the induced_polarization documentation pages instead?

Should it just be in simpeg.electromagnetics.static.utils?

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.20%. Comparing base (f04ba47) to head (b41e433).

@@           Coverage Diff           @@
##             main    #1442   +/-   ##
=======================================
  Coverage   86.19%   86.20%           
=======================================
  Files         432      434    +2     
  Lines       56119    56131   +12     
  Branches     5209     5209           
=======================================
+ Hits        48373    48385   +12     
  Misses       6350     6350           
  Partials     1396     1396           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I agree that having utils everywhere can be annoying, and having a single place for them would be much better. I was trying to tackle #1440 based on @lheagy's comments. But I'm totally open to a better solution.

@lheagy having all the utils in simpeg.electromagnetics.static.utils sounds like a good alternative?

Thanks @santisoler and @jcapriot! And sorry for my slow reply here.

Having the utils be consolidated under simpeg.electromagnetics.static.utils sounds good to me. But as a user, I would still like to be able to access those under the relevant physics, e.g.

from simpeg.electromagnetics.static import resistivity as dc
dc.utils  # should contain all utils under simpeg.electromagnetics.static.utils

That way, once you import any of they physics, they come "fully loaded" as a user, it is subtle that you need to import utils from somewhere else

I don’t think it’s necessary, and it encourages users to work in isolated modes. SimPEG is about modularity!

Ideally, I’d love for all utility code to exist in a single module: simpeg.utils

Thanks Joe, I don't necessarily think that having the ability to import the relevant utils from the related physics module goes against modularity. If it can help with the discoverability of useful things without adding maintenance load (all this would be is a file that imports the relevant functions in the resitivity module), then I view that as a positive. Otherwise, we are placing a pretty high load on users expecting them to have a mental map of where pieces live. We want users to build the mental map of the big picture pieces -- how simulations work and how to set up inversions, but for stuff like utils, I think a user should be able to explore what is relevant via tab completion -- e.g. I imported resistivity as dc, now what can I do with it? dc. [tab] and then you find utils and can start to explore.

This touches a bit on a bigger picture question about imports. I would like to see us simplify some of this e.g. having to go 4 layers deep to get to DC resistivity is pretty deep (simpeg.electromagnetics.static.resistivity), I think it would be useful if we could start to make better use of private namespaces to allow us to keep the same modular design, but simplify things for users (I think we should be able to import simpeg.electromagnetics.resistivity). But anyways, that is a bigger conversation that we can parse into a separate issue.

The organization of utils will take a bit of thought. For example, plotting pseudosections is only relevant to DC, IP, and SP, so I think it is appropriate to keep them with the static code.

For now, I still think that we should help users discover relevant utils by having it available with the physics that they import

I guess my biggest issue with it is that it goes against the Zen of Python.
Specifically:
“There should be one-- and preferably only one --obvious way to do it.”

Sorry for my late reply! That is a reasonable point Joe. I am not too hung up on this, importing from static.utils is much better than the previous import path. I think it is still worth us thinking about how utils are discovered, but that doesn't need to hold up this pr