Provide interpolated points to dlf

[prisae]

@sgkang , that is one of the resulting outcomes of our discussion today. It is now possible to provide the interpolated points to the dlf, so you save one call to get_spline_values (the one in empymod.dlf, not here).

However, this is only available in the dev-branch of empymod, so you better wait a bit with this pull request until the next version of empymod is released.

This would have the biggest impact if you loop over frequencies, specifically in time-domain calculations, where you need a lot of frequencies, but the offsets and therefore lambd and int_pts stay the same. But I think you do all frequencies at once, so the impact might actually be almost nil. Still thought it might be worth it.

[prisae]

Maybe I should expand on this. As your concern is speed (inversions, including sensitivity calculation etc) there might be an additional gain you can get.

In EM1D.py, you calculate in forward

lambd, _ = get_spline_values(self.fhtfilt, r, self.hankel_pts_per_dec)

or, as I suggest in this pull request for the future,

lambd, int_pts = get_spline_values(self.fhtfilt, r, self.hankel_pts_per_dec)

Now this is not extremely costly if you run a model. However, if your run hundreds or thousands of models, all with the same self.fhtfilt, r, and self.hankel_pts_per_dec, then you could potentially save a significant amount of time if you pre-calculate the required lambd and int_pts outside of forward, and store them in self.fhtfiltt and self.int_pts, and then simply call

HzFHT = dlf(PJ, self.lambd, self.r, self.fhtfilt, self.hankel_pts_per_dec,
            factAng=None, ab=33, int_pts=self.int_pts)

So the only thing that would change in the call to dlf is the actual signal, PJ. All the rest remains the same, if the offset(s) r doesn't change.

This could be particular powerful as you calculate time-domain response, which therefore involves a LOT of frequency-domain responses...

[sgkang]

@prisae Thank you very much for your discussion!
Agree with you that it may not improve efficiency for the current simpegEM1D code, but still there can be some use cases. For instance, when computing primary field 3d mesh, we need a lot of dlf, basically each cell.

[prisae]

Yes, I am pretty sure in these situations that would significantly help. The important bit is simply to do the calculation of r, lambd, and int_pts outside of forward (which I haven't implemented in this pull request). It might improve already now for inversions that have a lot of calculations.