What causes oscillating energy when running simulations?

[AJ528]

Hello,

I am relatively new to openEMS and have noticed an interesting behavior that occurs with some of the simulations I attempt to run.

Sometimes, when running a simulation, the energy shown for each timestep starts oscillating. I have an example attached where this behavior is easily evident. When the stop frequency (sim_params.fstop) is set to 2GHz, the simulation runs and completes in less than 30 seconds on my machine. If I change the stop frequency to 2.2 GHz, and change nothing else, it takes 10 minutes to run. So for increasing the scan frequency 10%, the simulation time increases 20x. During that increased time, the energy printed out each time oscillates up and down, slowly trending lower until finally hitting -40dB.

Does anyone know why this behavior occurs? and why the simulation time increases so dramatically above a certain point? Does it have to do with the mesh size?

As I mentioned, I have seen this on other simulations I attempt to run, so I'm hoping to learn more about what's causing this issue and how I can fix it the next time I see it. If I wanted to do a 10 GHz frequency analysis on the attached simulation, is there anything I can do to avoid the simulation taking 2+ hours?

Thanks

openEMS_sim.zip

[gadiLhv]

Hey there, @AJ528

Since sometimes setting up and running takes a moment (and sometimes people view this with their cell phones), be so kind as to add some images. Show us the structure, the oscillations that you see, etc.

I looked at the scripts, as I won't have a chance to run them today. Your meshing seems fine, so if I had to guess, your structure resonantes somewhere near the added frequencies. I will try and verify that, but allow me to sugget two ways to verify this:

1. Export the fields. A bit tricky because openEMS don't have surface current monitors, if I recall correctly, but I'm sure you can improvise. This is costly in time and disk space, but does make for some pretty picutres.
2. Make the relevant all lines in the structure about 10-20% shorter in length, and the substrate 10-20% narrower. See if the "oscillations" disappear. In length, in case the resonance is appearing on the trace itself, and in width if it appears on the ground. This is a bit faster to try out, but no pretty pictures.

Cheers

[gadiLhv]

Hey @AJ528

Tested my theory. With ground and trace length parameters

    l1 = 16
    l2 = 8
    l3 = 16

    gnd_oversize = 4

and it converges very fast in f = 2.2GHz.

[@        4s] Timestep:        19928 || Speed:  185.3 MC/s (2.174e-04 s/TS) || Energy: ~1.37e-15 (- 0.00dB)
Multithreaded engine using 2 threads. Utilization: (27;26)
[@       13s] Timestep:        24910 || Speed:   20.9 MC/s (1.930e-03 s/TS) || Energy: ~3.78e-15 (- 0.00dB)
Multithreaded engine using 1 threads. Utilization: (53)
Multithreaded Engine: Best performance found using 1 threads.
[@       18s] Timestep:        44838 || Speed:  186.4 MC/s (2.160e-04 s/TS) || Energy: ~1.14e-12 (- 0.00dB)
[@       22s] Timestep:        64766 || Speed:  187.5 MC/s (2.148e-04 s/TS) || Energy: ~7.04e-12 (- 0.00dB)
[@       26s] Timestep:        84694 || Speed:  185.5 MC/s (2.172e-04 s/TS) || Energy: ~1.00e-12 (- 8.46dB)
[@       31s] Timestep:       104622 || Speed:  192.6 MC/s (2.092e-04 s/TS) || Energy: ~3.97e-15 (-32.49dB)
[@       35s] Timestep:       124550 || Speed:  190.5 MC/s (2.114e-04 s/TS) || Energy: ~5.79e-17 (-50.85dB)
Time for 124550 iterations with 40280.00 cells : 35.25 sec
Speed: 142.34 MCells/s 

I guess it's more a lesson in RF layout than openEMS...

[AJ528]

Hi @gadiLhv,

Thanks for the reply. I would not have considered those two approaches, so thank you for the suggestions!

When you suggest "Export the fields", are you talking about using a dump box to capture the E-field over time? In my simulation, I have a dump box that encloses the substrate and copper, and I can view the results in Paraview, but how will the pretty pictures in Paraview help me determine the issue?

It looks like you used the second strategy and were able to determine the issue was due to the copper geometry itself. So if I am running a simulation and the energy takes a while to dissipate or oscillates (like below where it jumps from -28dB to -26dB), is that normally a good indication something is resonating? Are there other issues that could cause this?

[@     4m31s] Timestep:      1302048 || Speed:  223.2 MC/s (2.146e-04 s/TS) || Energy: ~1.09e-14 (-28.13dB)
[@     4m35s] Timestep:      1321776 || Speed:  215.3 MC/s (2.224e-04 s/TS) || Energy: ~1.08e-14 (-28.16dB)
[@     4m39s] Timestep:      1341504 || Speed:  217.3 MC/s (2.203e-04 s/TS) || Energy: ~1.08e-14 (-28.18dB)
[@     4m44s] Timestep:      1361232 || Speed:  216.3 MC/s (2.214e-04 s/TS) || Energy: ~1.07e-14 (-28.20dB)
[@     4m48s] Timestep:      1378768 || Speed:  207.3 MC/s (2.310e-04 s/TS) || Energy: ~1.06e-14 (-28.26dB)
[@     4m52s] Timestep:      1398496 || Speed:  217.4 MC/s (2.202e-04 s/TS) || Energy: ~1.04e-14 (-28.34dB)
[@     4m57s] Timestep:      1416032 || Speed:  185.2 MC/s (2.585e-04 s/TS) || Energy: ~1.77e-14 (-26.02dB)
[@     5m01s] Timestep:      1435760 || Speed:  220.9 MC/s (2.168e-04 s/TS) || Energy: ~1.74e-14 (-26.10dB)
[@     5m05s] Timestep:      1455488 || Speed:  234.5 MC/s (2.042e-04 s/TS) || Energy: ~1.71e-14 (-26.17dB)
[@     5m09s] Timestep:      1475216 || Speed:  216.0 MC/s (2.217e-04 s/TS) || Energy: ~1.68e-14 (-26.25dB)
[@     5m14s] Timestep:      1497136 || Speed:  240.5 MC/s (1.991e-04 s/TS) || Energy: ~9.49e-15 (-28.73dB)
[@     5m18s] Timestep:      1516864 || Speed:  224.5 MC/s (2.133e-04 s/TS) || Energy: ~9.33e-15 (-28.80dB)
[@     5m22s] Timestep:      1536592 || Speed:  221.8 MC/s (2.159e-04 s/TS) || Energy: ~9.17e-15 (-28.88dB)
[@     5m26s] Timestep:      1556320 || Speed:  223.2 MC/s (2.145e-04 s/TS) || Energy: ~9.01e-15 (-28.95dB)

[VolkerMuehlhaus]

I agree .. It's always trouble to get models from other users to simulate or preview, this hardly ever works out of the box.

It would be nice to see an image what your model looks like in CSXCAD, to motivate others to spend time on your issue.

[VolkerMuehlhaus]

Here's the geometry and a (not converged) plot of Zin calculated by your script:

The resonace seems to be high Q, it can be from geometry itself (as indicated by the change done by @gadiLhv) or it could also be a box mode excited by radiation from the line. Such box modes can exist because you have PEC boundaries everywhere.

In any case, a resonance with high Q means that energy decay in the simulation volume is really slow. It seems that your 2 GHz frequency limit was just low enough to NOT excite that 2.16 GHz resonance.

[AJ528]

Hi all,

Thank you very much for the responses so far. I got a lot going on this weekend (moving houses), but I will review your replies in depth soon.

[AJ528]

Hi @gadiLhv and @VolkerMuehlhaus,

Thank you both for taking the time to review my simulation. You made a good point about image previews, I will be sure to include those next time. @VolkerMuehlhaus, thank you for providing an image this time.

Based on your replies, it would appear something in my simulation resonates at 2.16 GHz. So when my simulation includes that frequency, it oscillates and takes a long time to dissipate the energy. @VolkerMuehlhaus, you mention it's also possible to get resonances due to the outer box geometry because I'm using PEC as the boundary? I was using PEC because that's what the original example used as a boundary material. Is there a different material you would suggest using instead?

Besides tweaking the geometry, are there any tricks to get the simulation to run through the resonance frequency and not take forever? Maybe some way to make the energy dissipate faster? Ideally, I'd like to do a wide bandwidth sweep quickly, and if there are any troublesome frequency ranges (like the Zin discontinuity in @VolkerMuehlhaus's response), I can go back and run a higher resolution sweep through that small range. Is it possible to do that?

[VolkerMuehlhaus]

@VolkerMuehlhaus, you mention it's also possible to get resonances due to the outer box geometry because I'm using PEC as the boundary?

Yes, I think you know box resonances in a metal cavity, and that's what you build if dimensions are large enough and you have PEC boundaries.

I was using PEC because that's what the original example used as a boundary material. Is there a different material you would suggest using instead?

The very first step would be to place an absorbing boundary at the top. The usual answer would be MUR then, but somehow ALL of the models where I ever tried to use MUR have numerical issues and don't converge. So the other alternative would be PML_8, but that requires attention because the absorbing layers (8 for PML) will grow INSIDE you simulation volume, so you need enough mesh cells for spacing.

I sometimes use PML_4 for this use case, with only 4 absorbing sheets taking only 4 cells, but that's not officially supported. Works for me, though.

I hope someone else has better advice here, I'm just totally frustrated with MUR that seem defect on all my openEMS installations.

Besides tweaking the geometry, are there any tricks to get the simulation to run through the resonance frequency and not take forever?

If there is that resonance ... there is no magic solution. If the slow energy decay is part of your model, i.e. high Q resonator, you better switch to another simulation method and avoid FDTD.

If the resonance is from the box, try to absorb the energy from the box by an absorbing boundary, just like you would place absorbing foam material in a metal housing if box modes are causing trouble.

If the resonance is from the circuit, it might also help to include realistic (!) losses for metal and dielectric, instead of using lossless materials.

Ideally, I'd like to do a wide bandwidth sweep quickly, and if there are any troublesome frequency ranges (like the Zin discontinuity in @VolkerMuehlhaus's response), I can go back and run a higher resolution sweep through that small range. Is it possible to do that?

No magic solution for a quick wideband sweep, the wideband gaussian pulse will excite any resonance in that band.

[AJ528]

Hmmm, I haven't used PML-8 or PML-4 before. PEC is a 2-dimensional plane at each of the 6 boundaries, yeah? But rather than being 2-dimensional, PML-8 starts at the outer boundary and goes inward, occupying the 8 outer-most layers of mesh, correct? So if I design my model with an outer boundary 8 layers thick, I can use PML-8 and it will act as an absorbing material?

When I was designing the model, I wasn't intentionally designing a resonator at any frequency. But I suppose anytime you have reflections, you'll have resonance. Changing the geometry size just changes the frequency it occurs at, right?

What are the implications of stopping the simulation early? Do the results still give you good data? I tried aborting my simulation after 5 minutes, and my Zin plot also shows the discontinuity at 2.16 GHz.

So the next time I am running a simulation and it's taking longer than expected, would a good debugging strategy be to abort the simulation, look at the results for troublesome frequencies, then examine the geometry for lengths of copper that might be causing issues at that frequency?

If the resonance is from the circuit, it might also help to include realistic (!) losses for metal and dielectric, instead of using lossless materials.

Does openEMS have a nice way to include losses on metal geometry? Or would it just be something like adding a 1 Meg resistor between the trace and ground plane?

[VolkerMuehlhaus]

So if I design my model with an outer boundary 8 layers thick, I can use PML-8 and it will act as an absorbing material?

Yes, add 8 mesh cells extra to make room for PML_8 on each boundary.

When I was designing the model, I wasn't intentionally designing a resonator at any frequency. But I suppose anytime you have reflections, you'll have resonance.

Resonance in the circuit is from standing waves between at least 2 reflections, like the steps in width in your design. In real world, due to copper losses and substrate losses, these resonances are not very "sharp" and energy will decay rather soon.
But for "ideal" cases with no losses, the resonances can be very sharp, with extended "ringing" in time domain once you excite the resonance.

In your model, the substrate and metal are defined lossless:

Sub = sim_params.CSX.AddMaterial('Sub', epsilon=epsilon_substrate)
TopMetal = sim_params.CSX.AddMetal('TopMetal')

Please refer to documentation and example to see how lossy metal and lossy dielectrics can be defined:
https://wiki.openems.de/index.php/Metal_Property.html

For substrate dielectric loss, you can't specify loss tangent directly, and it is converted into conductivity at one frequency point. See example here:

substrate_epsR   = 3.38
substrate_kappa  = 1e-3 * 2*pi*2.45e9 * EPS0*substrate_epsR
substrate = CSX.AddMaterial( 'substrate', epsilon=substrate_epsR, kappa=substrate_kappa)

https://github.com/thliebig/openEMS/blob/master/python/Tutorials/Simple_Patch_Antenna.py

There are some in-depth discussion on this (and better) dielectric loss modelling, but for now, you can use this.

What are the implications of stopping the simulation early? Do the results still give you good data? I tried aborting my simulation after 5 minutes, and my Zin plot also shows the discontinuity at 2.16 GHz.

If you stop too early, you have some ripple on the S-parameter curves. With less residual energy, that ripple decreases.