Custom\manual waveguide modes definition for Excitations

[gadiLhv]

As I am getting the hang of the Git protocol, I can start this, seperately. This was (re)based around the original repository master, rather than my one, which has the absorbers. In the future I'll make a habit of opening branches for new features.

I'll go over the remarks from the previous PR

The python interface is wrong? It talks about coors? (coordinates??) and "Weights" but only has the latter?

The line that guided me here was "make as little damage as possible". This was for two main reasons:

1. Avoid code repetitions, where possible.
2. Backwards compatibility with existing code.

Hence, the fields for the mode consist of three columns of coordinates, and three columns of field values: [X,Y,Z,Ex,Ey,Ez]. Replace with H at your own convenience.

The mode should be purely 2D on a plane right? Why does it accept coords in x,y and z and why weights in x/y/z? I would expect only x/y-coordinates (or maybe more general x0 and x1) and a 2D array of weights? That does all make little sense to me?

Three reasons, this time

1. Make as little damage as possible to the original code. This is clearer in openEMS. I know they are seperate, but still. I do a "nearest neighbor" search later, and it makes a lot more sense.
2. The mode functions are also given in all three axes, so it made sense to me.
3. This may sound arbitrary, but it isn't. When I output the geometry data to my mode solver (I am hoping to finalize that some day with the new library I'm using, so I can share it), I am simply snipping it out of the 3D structure. In case the normal is z, it's simple enough. But if the normal is y, I need to rotate the geometry 90 degrees...
   To avoid all this mess, I simply extract all three coordinates. I'll give this some more re-thinking.

I really do not like to give this class possibly large arrays of data like this and none of these values are stored and read into xml? This would be needed if at some point the Matlab/Octave interface want to use this feature too.

I know. I didn't find any built-in XML functions for handling arrays, except for the mesh processing. Care to give me a hint?

I really do not like that this is implemented twice in the excitation and the probe! (Large) redundant code is a no-no!!

I'll think how to implement these functions just one time. Missed this remark while re-basing the code.

Create a new file format (maybe plain csv or json or hdf5) that holds all required info about the modes, e.g. x and y grid coordinates and the mode on a 2D plane
The excitation and probes use a function SetWeightFromFile with some additional info's (see next point)
Supply an additional translation (and maybe rotation) information to allow to reuse the mode file for multiple ports at multiple locations and rotations

This will take some figuring out. CSV is my weapon of choice, I guess. Easy to manipulate both in M-script and python. If I make this a 2D file, how do I handle the coordinate shift? Rotation is the easy bit, but where is (0,0)?

This approach would allow openEMS to have one new (utility) method to read and interpolate this custom mode for both the excitation and the probe and thus avoid redundant code and memory usage