work areas, desirable features

[gmichel]

Dear All,

with this thread I would like to initiate a discussion on new features and improvements. Please add your ideas an proposals and comment on the given proposals. Some are easier and some are more difficult to achieve. Here is an unordered list of what comes to my mind:

1. Documentation:
   1. convert original MATLAB documentation into ReStructuredText
   2. produce a UML diagram of openEMS
2. translate the original MATLAB functions to the new Python interface
3. find a way to import Gerber files (maybe with FreeCAD-PCB)
4. make the transparency of primitives in AppCSXCAD adjustable
5. implement periodic boundary conditions.
6. implement sub-grids for cartesian coordinates
7. accelerate NF2FF:
   1. use FFT for the far field calculation
   2. implement a parallelized version (e.g. one host or thread per face of the NF2FF box)
8. implement a GPU accelerated engine (OpenCL, CUDA, AMD HCC)
9. write a companion code for characteristic mode analysis (this is MoM, maybe easiest to achieve by tweaking and interfacing to puma-em.sf.net)

What do you think?

Cheers
Georg

[thorsten]

Hi Georg,

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.
Side-Note: 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...

regards
Thortsen

[LowDepth]

Regarding your point 5:
I am considering to implement periodic boundary conditions (PBC) in openEMS. So if someone is already working on this topic or has been working on it before and set the topic aside, then please contact me to share ideas/code and coordinate our activities. I am just beginning and trying to understand what I have to do to get it working. Thorsten already told me that the correct way would be to create an Engine Extension. As far as I am concerned, I am at the moment trying to get deeper insight into the topic by getting familiar with the C++ core of openEMS. Hopefully In a second step looking at the PBC implementation of Meep will give me an idea of how to get this feature working in openEMS, too.

Best regards
Stefan

[gmichel]

Hi Folks,

maybe for now this is the right place to discuss future improvements. I still have to become acquainted with the source too. From my background, I could take care of the FFT accelerated NF2FF. I am not sure whether it is desirable to have a NF2FF which calculates the whole sphere for "all frequencies" of the Gaussian pulse (which has a finite number of frequencies because it is truncated). This would be possible with a 3D FFT for each face of the nf2ff box (1 dimension for time and two for the wave number). Maybe this is overkill. Instead, one could still do a DFT for one or two (or some non-equidistant) frequencies and use the FFT only for the wavenumbers. Maybe the latter is of more practical value because most of the time one is only interested in one or a few frequencies. In the wave number domain we will have to interpolate anyway at the transition from spherical to cartesian coordinates.

For the technical part, I think it would make sense to implement the wohle thing in Python. It could be a part of the new Python interface and due to the array handling of NumPy/SciPy there should be no speed disadvantage. What do you think?

Torsten, with the characteristic modes I meant the inherent eigenmodes of a conducting structure if we neglect radiation losses (like the eigenmodes of a bell or a steel drum). See this link for an explanation. This is useful for antenna design and cannot be obtained with FDTD. But as I use OpenEMS for antenna analysis, it would be nice to have such a tool for the OpenEMS models. Maybe we just have to write an interface to this code. And maybe we need to modify it somehow.

GPU acceleration is indeed a huge task. In addition, there are at least three "standards" for this which does not make the decision for a specific one easier. Hopefully there is a skillful OpenEMS user who wants to takle this task or who can at least give hints in which direction to go. I think most OpenEMS users could do this, it just needs a lot of time and commitment and eventually a good coordinator.

Ideally, one task is taken by one person while having little or no interdependencies between the tasks. So everyone can work on their own pace.

[gmichel]

Thorsten,

today I just skimmed over the new Python code. I saw that you already implemented a Python version for nf2ff. It uses the C++ nf2ff class. So a possible solution for a FFT-enabled nf2ff would be to implement a C++ class with an API compatible to yours. As Python is very effective also for numerical work, another option would be to implement the far field calculation directly in python. But then I would need to rewrite a lot of C++ code which is not related to the actual far field calculation. This is error prone.

Which (maybe third) option would best fit into the roadmap of OpenEMS?

Cheers
Georg

[thorsten]

Hi,

I think I would prefer to implement this first purely in python. The question is why this would need any rewrite of C++ code?
Python has a very nice hdf5 interface, thus python could read the openEMS generated near-fields and do all the far-field calculations and be done with it. No need for any C/C++ code?
Originally the nf2ff was implemented purely in Matlab, but I recoded it because it was slow like hell... But python has very nice features to speedup even loops etc.
Eventually it could (or maybe not) be back-ported to the nf2ff C++ class... But only if e.g. a better speed would require it.

regards
Thorsten

[gmichel]

Hi Thorsten,

this was my impression as well. In most cases a Python implementation is as fast as a C++ implementation of the same algorithm. Sometimes it is even faster if the C++ is not coded efficiently. I was just not sure about the "technical" code like AnalyzeFile, which I think needs to be recoded in Python. So I think I should go for it. It implies some work, but in the end it pays off as we can have someting like the recently requested time domain far field probes. Also, the computation of the whole sphere will not be much slower than individual circles.

The far field in cylindrical waves should also be feasible with FFT but first I will implement it for cartesian meshes as this is what most users need.

Cheers
Georg

[pedro]

Hi,

I noticed you were mentioning a python interface for openEMS.

Where can I find it?

Regards,

[gmichel]

Hi Pedro,

the Python interface is not yet end user ready. Nevertheless it is functional. For productive use I would still recommend the Matlab/Octave interface. That being said, you can do a recursive git clone of openEMS-Project as described in the install instructions. Then execute "git checkout python" in the subdirectories "CSXCAD" and "openEMS". Afterwards you will see sub-directories "python" in each.

Good luck
Georg

[thorsten]

And if you are a Windows user you are out of luck too. At least for now.
That is the disadvantage of the approach I took to create a direct python/cython wrapper interface to the C++ libraries...
I fear that it will end in me having to compile everything using the MSVC...
Any help in this area would be appreciated...

regards
Thorsten

Edit: typos