on the long run, we might want to have something like this post in the wiki? Thus everybody can just edit and add things?
Let me comment on your list:
convert original MATLAB documentation into ReStructuredText
This has to be done by a script to automatically translate the inline API help.
The overall openEMS documentation (and potentially user manual) is another topic. There was some recent interest by a user to look into that.
I told him that there already have been some first steps, see here: https://github.com/thliebig/openEMS_docu
It too contains some API documentation, thus the script I mentioned before should create latex files for this documentation too if possible.
My question would be, does it make sense to have multiple documentation sources? Wiki, API doc (with sphinx maybe), Latex User-Manual?
produce a UML diagram of openEMS
Would a doxygen
generated version be enough? At the moment openEMS already has a Doxyfile in its tree, but I haven't tried it in a long time...
translate the original MATLAB functions to the new Python interface
That interface is still in its early feasibility testing stages. It looks quite good though, but most Matlab functions will be available from the beginning...
If someone is interested to see more, please let me know.
find a way to import Gerber files (maybe with FreeCAD-PCB)
Some people are already working on this area. I will ask them to maybe discuss it a bit more in the forum instead of just (private) email.
implement periodic boundary conditions.
Someone mentioned interest in implementing this recently, I will ask him what the status is.
implement sub-grids for cartesian coordinates
I'm not a big fan of this. It has been tried many times and it was never worth the trouble.
the concept is a totally different one from the cylindrical mesh, where sub-grids do not only make sense, but in most case are mandatory...
use FFT for the far field calculation
May need further discussion, but why not try..
implement a parallelized version (e.g. one host or thread per face of the NF2FF box)
That is already the case or what do you mean specifically?
implement a GPU accelerated engine (OpenCL, CUDA, AMD HCC)
That is going to be a ton of work, but would be very interesting and very useful for pretty much everyone...
write a companion code for characteristic mode analysis (this is MoM, maybe easiest to achieve by tweaking and interfacing to puma-em.sf.net)
I'm not sure what you mean exactly, but I think you want to calculate the (2D) mode pattern from a given waveguide shape and use that for excitation and mode analysis right?
Again, thanks again for your (already made and future) contributions to openEMS...