Abstraction

[prisae]

Create main classes

• survey,
• model, and
• settings,

where settings might be part of survey. Have a look at SimPEG and a chat with the SimPEG folks to discuss this.

[prisae]

Current input parameters would go into these classes:

survey	model	settings
src	depth	xdirect
rec	res	ht
msrc	aniso	htarg
mrec	epermH	ft
strength	epermV	ftarg
srcpts	mpermH	loop
recpts	mpermV	parallel
freqtime
signal
ab

Most of the utils-functions would also go into these classes.

[prisae]

At the moment, empymod exists without classes. With two exceptions: (1) Sub-classing ndarray to add amp and pha attributes, and (2) the DigitalFilter-class which is a dummy to store values, could be done with a dict too.

One of the reasons why I chose to do it that way is that I think code like this is so much easier to understand by someone coming new to a project. Easier to read, easier to understand, easier to follow. Almost all arguments are passed explicitly, you know exactly what goes into a function. With some lists and dicts this isn't strictly true either, but for instance in empymod.kernel you can look at the function-signature and know exactly what is used, without inspecting a class-object.

It probably goes a bit along the lines of the controversy talk by Jack Diederich: https://www.youtube.com/watch?v=o9pEzgHorH0 (PYCON US 2012).

Now, I am thinking that empymod v2.0.0 will be backwards incompatible (although without breaking the main routines model.dipole, model.bipole, and model.analytical), and take the opportunity to clear-out and improve things that I would do differently today. One of them would be to use a few classes, for instance a Survey and a Model class, and probably a Settings class, although that could go into the Survey.

Now, I am not sure yet if I follow this road, if I will change everything under the hood for more abstractions, and what an eventual timeline would look like. I am merely at a brainstorming point.

[prisae]

More and more I think this is not the way to go. empymod is a small package, and its strength is simplicity. We can do something like

import empymod 
EMfield = empymod.model.dipole( 
    src=[0, 0, 100], 
    rec=[1000, 0, 200], 
    depth=[0, 300, 1000, 1050], 
    res=[2e14, 0.3, 1, 50, 1], 
    freqtime=1 
) 

So I think the functional approach is appropriate, good enough, or just fine for its purpose.

However, one thing to think about is using the new dataclass feature internally. And generally, reduce, e.g.,

def dipole(src, rec, depth, res, freqtime, signal=None, ab=11, aniso=None,
           epermH=None, epermV=None, mpermH=None, mpermV=None, xdirect=False,
           ht='fht', htarg=None, ft='sin', ftarg=None, opt=None, loop=None,
           verb=2)`

to

def dipole(src, rec, depth, res, freqtime, signal=None, ab=11, aniso=None, **kwargs):

or similar.

[prisae]

Also, bipole, dipole, loop, analytical, dipole_k, and gpr should be combined into a more general routine that can handle all cases.

[prisae]

It stays mostly as it is. empymod is a small routine, and fine as it stands. Abstraction would require a huge re-write, and make it much less readable. kwargs was introduced in v2. An overarching general modelling routine might be an idea at some point, but no must. That's it for #14.