Interfaces to openEMS

How to use openEMS. Discussion on examples, tutorials etc

Moderator: thorsten

lukego
Posts: 6
Joined: Mon 04 Jan 2021, 14:06

Interfaces to openEMS

Post by lukego » Mon 04 Jan 2021, 16:26

I'm getting started with openEMS. I'm planning to generate the code for my models from higher-level CAD representations (of PCBs.) I'm wondering about the pros and cons of interfacing with openEMS via Python vs Octave vs XML vs C++.

C++ is tempting as the direct route. I'm generating the models anyway so generating C++ source and compiling that seems straightforward.

XML is tempting too if it has the same level of directness but is easier to generate.

Python (and Octave) don't immediately appeal to me but I wonder if I'm missing something important. Is there a lot of useful functionality in those frontends that I'd otherwise have to duplicate? Or is it important to have an interactive "REPL" environment while working with openEMS simulations? (I'm imagining mine being longer running processes that take minutes/hours/days to produce a result but that's not based on experience.)

Any tips would be welcome. Generally from browsing the code I'm finding the C++ source the most accessible reference documentation and I'm thinking the XML representation will correspond quite closely with that. The Python/Octave layers seem to introduce more complexity...?

Thanks for reading and I'm really looking forward to working with this software!

HexAndFlex
Posts: 13
Joined: Sat 06 Oct 2018, 09:11

Re: Interfaces to openEMS

Post by HexAndFlex » Mon 04 Jan 2021, 17:15

I would say a big advantage to Octave is being able the availability of example code and ease of plotting results. Matlibplot under python is very similar to Octave plotting, so that would help if you go Python.

thorsten
Posts: 1464
Joined: Mon 27 Jun 2011, 12:26

Re: Interfaces to openEMS

Post by thorsten » Mon 04 Jan 2021, 20:59

As HexAndFlex already said, it depends on what you want to do. The C++ (and xml) interface is more low level, you can e.g. create/manage all properties and primitives and control the simulation.
But only the higher level interfaces (Octave/Python) can create the more complicated concepts/datastructures like ports (which are build from multiple properties and primitives). Additionally all the post-processing, data evaluation and plotting is only done in Octave or Python.
Of course you could also mix it, create the model and simulation with C++ and do the post-processing with Octave/Python, but this would surely be the most difficult approach.

By the way, would it maybe make sense to look at some of the other PCB to openEMS conversion tools that already exist?
hyp2mat, pcb-rnd, pcbmodelgen, just to name a few. I'm sure more already exist...

regards
Thorsten

lukego
Posts: 6
Joined: Mon 04 Jan 2021, 14:06

Re: Interfaces to openEMS

Post by lukego » Tue 05 Jan 2021, 17:49

Thanks for the tips!

I'm planning to start off taking the low level approach of familiarizing myself with the C++ code and generating XML from my own structures and then doing the graphing in R. If I find myself spending a lot of effort duplicating functionality that exists in Python/Octave then I could switch to using one of those. Just now it feels like the interfacing code will be a small amount of the total complexity of simulating slices of PCBs but I'm new to all of this.

I'll take a close look at hyp2mat and so on before I get in too deep. Thanks for that nudge too.

thorsten
Posts: 1464
Joined: Mon 27 Jun 2011, 12:26

Re: Interfaces to openEMS

Post by thorsten » Tue 05 Jan 2021, 19:17

I would honestly recommend to do it the other way round. Start with the Octave or Python interface to understand how a FDTD simulation is setup and how it works. Then have a look what parts the engine itself and thus the C++ part is doing. The Python interface may be good here because it is a direct wrapper around the C++ interface while Octave generates xml only.

At the end of the day I think you will have to reproduce lots of code in R. Just some examples:
A lumped port as created in the Octave/Python interface is created from a resistor, a voltage and current probe and an excitation. How to create such a port is not known to the C++ interface. And this is the most basic and simplest port openEMS knows about.

Once you have all the voltages and currents again the Octave/Python interface calculates the incoming and reflected voltages and then the scattering parameters. Again everything only exists in Octave/Python and again it gets much more advanced with more complicated ports.

When I implemented the "new" python interface it became clear pretty fast that wrapping the C++ classes with cython was the quick part (after learning how to do a C++ wrapper with cython). Most of the work was to re-implement everything else from Octave in python...

And then again I do not see an advantage of R over python? But I'm not very familiar with R, maybe you can share your thoughts on that.

regards
Thorsten

lukego
Posts: 6
Joined: Mon 04 Jan 2021, 14:06

Re: Interfaces to openEMS

Post by lukego » Tue 05 Jan 2021, 22:07

Thanks for the feedback. I'll have a better look at the Python code to understand what it adds to the core i.e. what I'd lose or need to replicate if I work directly on the XML/C++ level.

I'm hope to use openEMS more as a library than a stand-alone application. It would be part of a larger system. I'd like to keep the number of programming languages in the system manageable from a maintenance perspective and the number of user interfaces (e.g. plotting libraries) manageable from a user interface perspective. But everything is a compromise...

Thanks again for the quick feedback.

thorsten
Posts: 1464
Joined: Mon 27 Jun 2011, 12:26

Re: Interfaces to openEMS

Post by thorsten » Tue 05 Jan 2021, 22:33

I can totally relate to those considerations.
Just out of curiosity, can you tell what larger system you have in mind and you want/need to support Windows and Linux?

The python interface currently supports only Linux, but I have a working version for windows if you need it. The problem with C++ is that you have to use the same tool chain to build it for all dependencies. And openEMS has a long list of dependencies and to build all these yourself for windows is quite a challenge... I used to cross compile everything for windows from Linux, but that for example does not work with/for python for example.
If you want to link CSXCAD/openEMS to your tool you might run into a similar problem (at least on windows).

Going further I think I will need to make some of the dependencies optional as they might not always be necessary.

Keep me/us up to date about your efforts.

lukego
Posts: 6
Joined: Mon 04 Jan 2021, 14:06

Re: Interfaces to openEMS

Post by lukego » Wed 06 Jan 2021, 08:54

I'm starting right now to develop my own "CAD software stack" for PCB design. I'm targeting only Linux and using the Nix package manager to handle dependencies. openEMS is already packaged for Nix, including the Python version, so adding it to my build is no problem.

My application will be basically a bespoke PCB autorouter tailored to the designs that I want to make. I'll need to be able to export from its native internal format (not design yet) to CSXCAD, Gerber, Blender, Kicad, etc.

Initially I'd like to simulate whole PCBs in openEMS. I would have a dozen or two layers of copper and dielectric material and e.g. high speed signal traces, high-speed ICs, decoupling capacitors, etc. So I'll need to capture the overall geometry for CSXCAD, to represent passives and pins of chips as lumped RLC models, and to carefully craft the 3D grid lines to get dependable results in a realistic timeframe (e.g. "nightly build on AWS.") I don't know how hard this will be yet.

That's a starting point. I'm sure that I'll also want to model specific narrow "slices" of the PCB e.g. to check the impedance of one trace or the crosstalk between two traces. I might want to automate this as input for the autorouter. I don't know yet because it's *really* early days now :)

I see this as a large and risky project. I also want to get the whole thing done this year. So I need to be a bit wary about spending time bogged down in using too many programming languages at the same time and mediating between them. The appeal of the XML representation is that it's just passive data that I can manipulate using any tools that I like. Python might be fine too but then suddenly I'm programming in Python when I wasn't yesterday? That's a huge leap for me and I'd be looking for libraries to generate Python code from my models etc which is possible but more complexity (although I'm already expecting to do that for exporting to Blender so maybe it's fine...)

End braindump :)

thorsten
Posts: 1464
Joined: Mon 27 Jun 2011, 12:26

Re: Interfaces to openEMS

Post by thorsten » Wed 06 Jan 2021, 09:25

Oh wow, that's sounds like a task ahead ;)

And thanks about the nix package manager hint. I was unaware of it. And I was unaware of "pyems". Do you know/use this package? It seems to be specialized for PCB as well...

lukego
Posts: 6
Joined: Mon 04 Jan 2021, 14:06

Re: Interfaces to openEMS

Post by lukego » Wed 06 Jan 2021, 09:57

Thanks for the pyems tip. I'll check that out too. I really need to construct a mental flow graph of all the various PCB formats and the tools that exist to translate them from one to another. I'll need to arrive at a native representation to use myself (possibly based on an existing standard), a set of formats that I'll export to for compatibility with other tools, and a set of formats to avoid like the plague :-)

The way that I'm experimenting with openEMS python interface is to run:

nix-shell -p python3Packages.python-openems

... which drops me into a new bash shell with an appropriate version of Python, all relevant Python libraries, and all openEMS engine code. Then I can just run the examples from the Git repo directly.

Post Reply