Page 1 of 1

Tetrahedric mesh, is there a future for it in OpenEMS?

Posted: Wed 06 Jul 2016, 05:05
by Hale_812
http://www.eletr.ufpr.br/artuzi/pesquis ... per.44.pdf
This paper from 2004 tells about solving with FDTD method basing on tetrahedric mesh. With impressive precision, and no wonder, no useless job is performed at oblique shapes. Increasing local density does not affect all the space.
I.e. At the moment it is not possible to simulate a tapped mushroom surface because of the local density increase around via propagates on all the volume, including useless free space, or adjacent mushrooms with different pitch and via shift.

And I don't know a thing about unconditional convergence, but OpenEMS does not converge often at resonant (imperfectly matched) cavities and around band gaps. Especially when the mesh is too dense. That makes numerical noise amplify S-params to +dB of singularity like great values which is physically impossible. Really, that is ridiculous to have S11 about +50 dB and S21 around +300dB, just because there is a small band-gap. Maybe making a smoother irregular mesh without overcrowded areas would help with this effect?

Re: Tetrahedric mesh, is there a future for it in OpenEMS?

Posted: Fri 08 Jul 2016, 21:39
by thorsten
To answer your question in the topic. openEMS is free software and thus you (or anyone else) are of course free to implement anything based on it. ;)

I will (if time permits) have a look at the paper, but I doubt it's promises. I bet that at the end of the day, this method will not be much different or better than just using a plain old FEM or MoM method. Conventional FDTD just is this efficient because it just is this stupidly simply and thus very memory and computation efficient. (Sidenote: there exist commercial FDTD solver that reach 10-100x the speed of openEMS on the same machine)...
Of course if your structure does not match its mesh, you just are screwed...
What I need to look at some day is, how to fix the increased memory consumption during setup. So far, I never cared since simulations that are this large, are running to long anyways and need a mesh refinement anyhow...
Really, that is ridiculous to have S11 about +50 dB and S21 around +300dB
Agreed and it indicates that something it seriously wrong with your setup. This should never happen...
The FDTD method in openEMS is unconditionally stable. The only way to get it unstable is to use dispersive models with a unadjusted (too large) timestep or using the PML incorrectly.

regards
Thorsten