Added shift_field and outer_dot_shifted function to ElectroMagneticFi…

[prashkh]

…eldData Class

@momchil-flex Based on your suggestion a few weeks ago, I started adding functions to the ElectroMagneticFieldData class so that we can easily shift fields and do mode overlaps. Let me know if this is what you were thinking of for implementation. I checked the results of the new outer_dot_shifted with the results fromouter_dot when the relative shift is (0,0) and things are consistent.

[momchil-flex]

Thanks @prashkh, this would certainly be super useful to have.

I had a somewhat different idea about how this can be incorporated in the code, but maybe I didn't convey it too well, or maybe you had your reasons to make some of these design decisions. But here's what I had in mind, let me think if you think this will work:

We can have something like a ElectromagneticFieldData.translated_copy method which allows you to translate the data along x, y, z. This does not interpolate - it just shifts all relevant data like the coordinates and the associated monitor position, as illustrated here. This was written very quickly and would need to be tested, and also I think we need to shift grid_expanded (and just overall take a look at what attributes field data contains and shift everything that needs shifting).

This first step is the nontrivial one, but after that doesn't everything just come for free? Our current outer_dot already handles data that are not on the same grid, and I think it handles even the case where the grid spans are not the same, but if not, it could be fixed to do so. So a user would just do something like

outer_dot_shifted = data1.outer_dot(data2.translated_copy(dx=5, dy=0))

Basically you won't need to re-interpolate to a uniform grid, you won't need to handle things like not knowing which dimensions exactly are the tangential ones, and you won't need to introduce a lot of duplicated code in your current outer_dot_shifted method.

Regarding the point that you don't need to care about which dimensions are the tangential ones, in my example above I assume the user knows that and uses the translated_copy method properly. That is to say we allow translating along x y and z and it's up to the user to translate along x and y if their normal direction is z, etc.

[prashkh]

@momchil-flex thanks for the feedback and the detailed explanation. I think the approach you described makes sense now. Let me try to implement that sometime next week and I'll let you know if I run into any issues.

[caseyflex]

Will this resolve this issue?
#1526

[momchil-flex]

Will this resolve this issue? #1526

Yeah I reference it in my comment. It just needs to be done a bit more carefully and tested.

[caseyflex]

Will this resolve this issue? #1526

Yeah I reference it in my comment. It just needs to be done a bit more carefully and tested.

Maybe the link was wrong in your comment?

[momchil-flex]

Ah you are right sorry! Updated it just in case someone clicks it in the future.