OSS EM Solver Discussion

[Mechatrommer]

i'm sick with the on-the-market EM Solvers around. why do they have to mine Gold to build one? the cost is just unbelievable. the free trial version is next to useless, i just made a very simple microstrip elements in Sonnet and it started to complain memory limitation, the next is paid version, but still alot to be crippled, ok you pay a little money and there will be memory extension, but what if i need extra more 1 port, pcb layers and all? i may be just screwing myself into digging into a sheethole of money sucking vampire... well the $12K++ Sonnet pro version maybe a (not so) soothing experience, we go to other brand like Genesys or MWO, someone commented you may need like $80K to get the features you want, just farknbelievable! its just a software?!@ ok enuff rant if you dont like it make it your own...

i know there are free and OSS solvers out there like openEMS but it works on who knows how matlab scripting, the 3D-TLM, but they havent figured out yet how to build an exe for that they have a charming figures on the GUI but isnt that a made up animation?, well anyway but they have the source code and i got it thank you! any other suggestions? or if somebody have a thesis or paper on just how to get closer to the boundary condition of spatially chopped maxwell equilibrium algorithm that will be much helpfull in realizing the dream of possessing the your majesty crown jewels.

[daqq]

Well, you already named openEMS, which work pretty well once you figure out the basics. You can use Octave instead of Matlab. Feel free to build a better GUI 

i just made a very simple microstrip elements in Sonnet and it started to complain memory limitation,

FDTD methods are very memory hungry, try setting a lower resolution.

As to the pricing of commercial stuff, yeah, it's annoying, but understandable - this isn't exactly software that everyone buys and needs and they do need to finance their development.

You can get around this if you 'outsource' the simulation to someone with the software (commercial or some friend at a university). There might also be an option to rent some of the software.

[Mechatrommer]

FDTD methods are very memory hungry, try setting a lower resolution.

yes. i made a 5 x 10 cm box and some stupid traces (still learning on that). try to simulate at 100KHz - 6GHz, reducing freq span to 5 - 6GHz doesnt help. i need to increase the cell size from 1mm to 2mm to reduce memory consumption from 205MB to 14MB, look at the attached picture... with 2mm cells it is.... useless.

[daqq]

Yup, seems useless. I don't think you can simulate your simulation using the purposefully limited software. Perhaps you can use a non uniform grid for that particular problem - basically use a higher resolution locally and a lower resolution in different areas. This can be done, since the mathematical method does enable this.

but they havent figured out yet how to build an exe for that they have a charming figures on the GUI but isnt that a made up animation?

The actual calculation takes place in an exe, Octave (or Matlab) is just used for plotting. Or paraview.

[darrell]

OpenEMS is worth the investment of time to learn. The latest release adds a Python interface as an alternative to Matlab/Octave. I'm using Python now.

I attached an image of the model and result from a simulation I ran earlier today. It's a transition from microstrip on top to stripline on an inner layer. It took 25 seconds to solve.

[TheUnnamedNewbie]

FDTD methods are very memory hungry, try setting a lower resolution.

yes. i made a 5 x 10 cm box and some stupid traces (still learning on that). try to simulate at 100KHz - 6GHz, reducing freq span to 5 - 6GHz doesnt help. i need to increase the cell size from 1mm to 2mm to reduce memory consumption from 205MB to 14MB, look at the attached picture... with 2mm cells it is.... useless.

Unfortunatly that is just the way those simulations are. For my work I just did some simulations on a simple piece of dielectric waveguide (waveguide is 3 mm wide and 175 um high, 4 mm long - system itself is 8 mm x 6 mm x 4 mm) - and it needed north of 1 gigabyte of memory. These operations are very memory hungry, unfortunately that is just the way they are.

Isn't there a way for you to do automated meshing or something in your software? That meshing looks a bit silly.

[Mechatrommer]

fwiw... there are very good documentations available in the net about this stuffs. i always love down to bare metal knowledges, except the math will be a bit hard without proper example...
http://dougneubauer.com/fdtd/
http://www.eecs.wsu.edu/~schneidj/ufdtd/ufdtd.pdf
https://fdtd.wikispaces.com/Code
and many more if we search incl the already made oss code such as Meep and elmer FEM. so a diy oss or proper GUI using the ready made engine should not be far from reality...

[jungle vegetable]

Btw, memory consumption being the way it is, it's easy to rent large-ram cloud VMs with per-minute pricing these days and SSH or RDP into them to do simulations which don't fit into your laptop/PC. Check out AWS/Azure/Google Cloud

[daqq]

Btw, memory consumption being the way it is, it's easy to rent large-ram cloud VMs with per-minute pricing these days and SSH or RDP into them to do simulations which don't fit into your laptop/PC. Check out AWS/Azure/Google Cloud

I tried this actually. A simulation of ate around 28GB of RAM and took around three days to run on an 4 core i7 (my PC). I tried running the simulation remotely, but it was faster to do it locally, apparently there's some extra overhead when you're on doing this kind of stuff on a very virtualized machine - which you'll probably get on a cloud. This stuff is very intense computationally, and hyperthreading may not actually help, or even slightly worsen the situation.

That said, some fiddling around with the settings might yield some other optimum, who knows. Also, it's possible that this was an OpenEMS thing, or that it's no longer relevant and will work great on a rented machine.

[jungle vegetable]

I tried running the simulation remotely, but it was faster to do it locally, apparently there's some extra overhead when you're on doing this kind of stuff on a very virtualized machine - which you'll probably get on a cloud. This stuff is very intense computationally, and hyperthreading may not actually help, or even slightly worsen the situation.

Sure, there are things to watch out like virtualization overhead and networked storage performance (you might want a local SSD or another high-IOPS option) but if all you have on hand is a 16GB laptop and the simulation just doesn't fit, cloud VMs could be a godsend

Some simulation packages (don't know about openEMS) also support parallel simulations on several remote machines, which is rather awesome