Big deviations between OpenEMS and HFSS

[nico-arnold]

Hello everybody,

I'm planning to use OpenEMS as a solver for my Open Source project and am currently trying to evaluate the measurements vs simulations as there are some pretty big deviations.
To have a neutral starting point, I decided to take the data from an HFSS tutorial as I know how the S parameters are going to look there. I did the simulation of a microstrip structure (1.6mm FR4 substrate of 20x40mm with a 17 µm copper trace with a width of 3mm), and here are the results I get out of HFSS:

Compared to that, OpenEMS results:

It's visibly "smoother" than the HFSS one and also has a different form.

A colleague told me I should try to decrease the copper conductivity from 58e6 to, say, 58e3, because the now increased resistance should dampen the curve a bit, decreasing the impact of reflection along the length of the microstripe. This is where it, in my opinion, started getting strange. HFSS shows similar results:

But in OpenEMS, the changes of the S11 parameter are increasing.

However, as you can see, the general ballpark is okay. Still, S21 is decreasing in HFSS with increasing frequency (which makes sense), whereas in OpenEMS, it's actually increasing. I think that shouldn't be. What am I doing wrong here? I played around with multiple parameters including feed and measurement shift, resolution, ... But nothing improved the results.

I would be very happy if you could help me here to validate my results as I definitely want to use OpenEMS in the project, and not only for the sake of the coffee reminder x]

best wishes from Dresden and have a great weekend,
Nico

[nico-arnold]

Nearly forgot; here's my .m and result files.

[thliebig]

You should not (need to) change the metal losses artificially. The openEMS s21 should not go up and certainly not go above 0. Something is clearly wrong with your model. Maybe the port is "inverted" or something.
I will see if I can find some time to have a closer look.
At the same time I would not worry to much about the s11 differences. -20 or -30dB just mean 1% or 0.1% insertion loss. This is well within the modeling details and a measurement would yet again look very different...

[thliebig]

After just a quick look, you have no room/air above you MSL? Thus you upper PEC boundary cond. touches your MSL?
You really need to add some space above your MSL for the fields guided along to have room to expand...

[thliebig]

Just in general you z-mesh and boundary cond. are not ideal. You should have a closer look at the MSL Notch-Filter Tutorial maybe... For example you should not try to have multiple cells over the metal trace thickness... This will just kill the time-step.

[toammann]

Hello Nico,
I respectfully disagree with your college :). Increasing the conductor loss helps only if you have non ideal terminations at the ends of the transmission line. The transmission line acts as an attenuator in this case to provide some isolation what improves the interstage matching. This should not be the case in the simulator. To change the material Parameters is not a good idea.

A portion of the differences you see is due to the dispersion Model of the used Substrate. I think HFSS Users the Djorjevic-Sarkar Model by default? Not sure.

Please find further Information
here

For the increasing return loss: Not sure right now. I Need to Look at your script

Can you Upload a Touchstone file Export of your HFSS Simulation?

Regards
Tobias

[nico-arnold]

Hey @thliebig , hey @toammann ,

thanks a lot for your help until here!
I'm terribly sorry, but I just realized I uploaded the wrong file. I pushed the "correct" one ("MSL_Losses_Comp.m" and "tmp" directory) into the shared folder by now and moved the old one to a subdirectory called "old_wrong", just for completeness and other people.
Anyway, the tip with the air above the trace was good as it explains why that other simulation was running but not outputting any dump nor values at all - sure, the trace was just shorted out between the ports. No wonder it didn't work. Thanks!

For the other simulation now that I took the screenshot from - it was built on top of the "OpenEMS\matlab\examples\transmission_lines\MSL_Losses.m" example file with values changed to the ones I simulated in HFSS. I re-checked, there is enough air clearance over the trace itself (7.5 mm) and zero clearance under it because there's a PEC acting as ground.
I also checked the ports, they don't seem to be inverted as they're facing onto each other.

About the tip of my colleague, yeah, that absolutely makes sense. I wasn't sure if the 50 Ohm-Port correctly terminates the strip or if it only uses that impedance to calculate values, and also how big of an impact the measurement shift has, so I gave it a try.
I generated an S2P file and attached it beneath the .m file (:

Link

As next steps I will take a look at the links you sent me and also try to re-generate the file step by step from the example file. I re-evaluated the example file, and the S11 has the correct shape there.

best wishes and have a great start into the week,
Nico

[nico-arnold]

I think I kinda found the problem - it's the substrate thickness. When increased beyond ~500, it shows places where the the S11 increases above 0 dB:

I tried to densify the mesh above the trace starting from that point to get it under control and also added more air above, but neither helped:
mesh.z = SmoothMeshLines( [linspace(0,substrate.thickness,30) 4*lambda/unit], resolution );

[VolkerMuehlhaus]

What model did you use for this test?
One possible reason for such unphysical S-parameters can be large (long) ports indeed, if large field gradients induce a voltage directly into the ports voltage sensor. In that case, you better use a short port plus some length of regular metal.

[toammann]

Hey Nico,
I have also noticed that your port impedance has a significant imaginary part (around 10Ohm). This should not be case. We expect a real line impedance for a microstip.

@VolkerMuehlhaus I can also imagine, that the field cause by the pulse traveling out of the feed is somehow distorted as it hits the microstrip with an aprupt change in direction (e.g. z to x). Maybe it has to travel down the microstrip line for a short duration until the TEM mode has setteled? However, I don´t think that this should cause a phase shift between voltage and current. So, your explanation makes more sence.

Is there a rule of thumb for this problem? The substrate thickness is usually given and cannot be changed.

@nico-arnold Your action based on Volkers comment: Increase the distance between your measurement plane and the feed (change 'MeasPlaneShift') until the imaginary part of your port impedance is negligible small.

Also your real part of the Impedance is not 50Ohm. This explains why the return loss increases with frequency. You can experiment with the 'RefImpedance' setting of calcPort. Make sure to compare the results of HFSS and openEMS with the same reference impedance. I don´t know what is the default in HFSS. It may be either 50Ohm or the ZL of the line.

You specified a fixed impedance for normalization.
port = calcPort(port, Sim_Path, f, 'RefImpedance', 50);

So, if your line impedance is not 50Ohm you will see a miss match to your specified reference impedance. However, if you use the ZL determined by openEMS the transmisison line should be matched over the entire band but with a different reference impedance.

port = calcPort(port, Sim_Path, f);

[nico-arnold]

Hey Volker, hey Tobias,

the model I'm using currently is uploaded here:
Basically still the same as before, but with some room into the x and -x direction - this produces the ripples seen in the HFSS simulation and makes the S11 match pretty well. The S21, however, still persists to be a problem as it exceeds the 0 dB line multiple times still.

I tried to change the room around the model, for example by adding some padding on the y-axis, which I removed again later, and also enlarged the x-padding; no change.
Afterward, I played with the port length. I think the length of the ports shouldn't be a problem, as it appears to me that the more I reduce the length from 5000 units, the worse the problem with the S21 gets because the 0dB-excisions keep increasing. Example of reducing the port length from 5000 to 2000:

However, if I enlarge MSL.port_dist, then the only thing that changes is the frequency of the ripples and the impedance "ringing"/"overshoot" (don't know how to call that - what's the correct term here?) at the start frequency of 1 GHz decreases.
Moving the measurement plane only changed the frequency of the ripples:

I also tried reducing the feed shift from 10*resolution down, but that also didn't make things better.

The wrong impedance was the solution I think - I noticed I accidentally swapped the "height" and "thickness" parameters in TXLine so it was giving me strange values there. I matched it for 50 Ohms impedance (MSL.with = 470 µm) now, and results look great:


There is still a part of the S11 that keeps sneaking above the 0 dB. I will try to further take a look at that, but that's a big improvement already.

Furthermore, I also didn't know that it was possible to automatically adapt the impedance instead of giving fixed values like I did here - thanks for the tip! Will try to play around with that.

best wishes and have a great weekend,
Nico

[VolkerMuehlhaus]

Hi Nico,
can you upload the latest model file that you used? I want to have a look at the S11>0dB effect.
Best regards and have a good weekend,
Volker

PS:
Based on your initial model above with 3mm line width, the CSXCAD view below might help to understand the modelling mistake. You have used 5mm reference plane shift, which is measured from the simulation boundary.
You have also specified a feed_shift to move the excitation away from the boundary.
However, both values combined place your measurement plane = voltage sensors very close to the excitation, resulting in strong fringing fields at the port 1 voltage sensors. You really need more distance there! With a larger distance between excitation and measurement plane, the error decreases by a large amount.

You noticed a dependency from line width - that is an indirect effect because the fringing fields are even worse here with the large 3mm line width.

[toammann]

Hello Nico,
in your latest plot has still an imaginary part of up to 5Ohm. The strong fluctuations in the real part are also not normal. I think something is still not right.

Can you increase the measurement plane shift by a significant amount? Maybe 5000um.

You can also have a look at the measured line impedance of port 2. If the imaginary part of port 2 is zero, there is a good chance that increasing the measurement plane might help.

I think (hope) that this should help to bring the imaginary part towards zero.

Regards,

[nico-arnold]

Hello everyone,

sorry for taking so long. There are several cases I tried; to make ientification easier, I will enumerate them.

@VolkerMuehlhaus That's interesting, didn't know that. Thanks for the tip! I thought it might be okay as it was done like that in this OpenEMS example. However, moving the feed indeed gave a slight improvement. I moved it all the way to the beginning of the port now (by removing the 'feed_shift' parameter):

Case 1

Still there's a imaginary part on the impedance and also the values of S21 are not multiple dB into the negative, but stay around the 0 dB line.

You can find that model here: https://datashare.tu-dresden.de/s/JycX7ejx53mqwzT

Case 2

@toammann Sadly, moving the probes away from the feed (feed_shift is 10 mm now) makes the situation worse again:

It's interesting to see a phase shift in the fluctuations of the Real part of the line impedance Though caused by the shift of the measurement planes.

Case 3

For the ports impedance, I tried removing the 'feed_R' parameters, but that leaves the simulation running forever because of the wave travelling along the strip getting reflected back and forth without actual decay.
Removing just the reference impedance on the calc_ports function gives the following results:

So as you see, no more reflections from the ends, much smoother curve on the S11 (maybe even too smooth? especially when compared to the HFSS results). But the imaginary part of the impedance still persists. But... S21 stays well unter the 0 dB line all the time! Even if it might be too small and should be a few mor dB into the negative.

(Reminder: This is all for a line terminated by 50 Ohm at each end with the feed and so also the impeance sitting at the diret end. Ports are 5mm off the ends at a overall line length of 40mm)

Case 4

I also tried to decrease the impedance values (2x feed_R of ports, 1x calc_ports) to 45 ohms as that's what the simulation suggests. Now it looks as follows:

Impedance-wise, that looks pretty well right now. Note the small "ringing" at the beginning of the Z_analytic plot. From the cases before, I would have thought that by removing the fixed impedance from calc_ports should give no values above 0 dB for S21. And from the better impedance match at the transmission line of 45 Ohms I would have thought the imaginary part of the line impedance should stay around 0; seems to be the case. Also, note that the S11 curve looks again like the one before with 50 Ohm ports and no impedance provided as reference to calc_ports (case 3):


Also the impedance plot looks pretty much different from HFSS again, but also more like a "real" one.

I uploaded this case here: https://datashare.tu-dresden.de/s/LtsKtYdEMGSRbJk

Case 5

To evaluate that, I checked against that case also in HFSS:

Getting there. The shape looks more similar, maybe the rest is more or less fine-tweaking of the port length. I noticed that the deep cuts from reflections at both ends are much less defined now, though not as deep as in the OpenEMS model in case 4. Also, the lowest point of S21 is around -3 dB here while the OpenEMS model never goes even below -0.5 dB.

@VolkerMuehlhaus you said that the problem is the stringing fields at the probes caused by the broad stripe, and making it thinner reduces that error here - so it's not because of the better matcing between the feed impedance(s) and the line impedance?
Is there a way to make an automatic termination of the microstrip at both ends with a fitting impedance, or does that one always needs to be adjusted manually like I did here?

Ah, and is it better/easier for you if I upload and link a model for each separate case in the future?

best wishes and have a great week,
Nico

[VolkerMuehlhaus]

Hi Nico,

yes, it will make things a lot easier if you always upload the model for each testcase. I am working in EM support of commercial FDTD tools for many years now, and it always helps to reproduce customers issues with the exact model that they use. The issue is often in small details that they didn't even mention.

I will now look at your model. In the testcase that I had modified with more spacing between excitation and measurement plane, the resulting Zline looks fine. Model is attached.

Best regards
Volker

MSL_Losses_Comp_feeddist15mm.zip

[VolkerMuehlhaus]

Hello again Nico,

I looked at your model file and found a few issues and misunderstandings. For example, you try to calculate S12 and S22 without running a simulation where port 2 (and ONLY port 2) is excited.

Another misunderstanding seems to be line length in this example: the line length parameter should be the "net" length of your device under test, excluding additional length added for the feed. The "trick" here is to shift the port reference plane (=measurement plane, the location of the port's voltage probe) to the interface where the DUT line length starts/ends. In your model, you messed up DUT line length by subtracting port_dist.

Regarding the MUR boundary in your model: I had poor results with MUR boundary when I tested openEMS, it sometimes didn't converge and often enough I had strange results. My conclusion for my work was that PML are more reliable, so I only use that for absorbing walls in openEMS.

My proposal is that you start all over again, based on the lossy line example. I have already modified that example for your line dimensions, see attachment. This now runs with meaningful S21 values.

MSL_Losses_start_from_example_Nico_linedimensions.zip

For S11, you need to consider that this model runs the line into the PML boundary, which means that there is never any reflection from the end of the line at port 2. What you see for S11 reflection is only the jump in impedance from the 50 Ohm port to the line impedance. You could use that to calculate Zline directly from Zin at port 1.

Best regards
Volker

PS: Take my description above with a grain of salt. I am very experienced with commercial EM solvers (FDTD and other methods) but quite new to openEMS, I only did some openEMS benchmarking and model development for this project.

[nico-arnold]

Hello @VolkerMuehlhaus ,

thanks a lot for your help! It indeed solved many points. I will answer back thoroughly next week as I'm on a road trip right now (:

best wishes,
Nico

[VolkerMuehlhaus]

Yeah, getting some theory on FDTD sounds like a good plan! This will also help to understand why low frequency is rather difficult, especially if the physical model dimensions are small.

When I looked at your model yesterday, I couldn't figure out why it breaks at DC. But I noticed that the CPW tutorial example uses port resistors instead of placing the port at the absorbing boundary, and that simulated with no such DC issue. Overall, port with "real" discrete resistors seems the better model anyway, because you will get the expected reflections from ports that are not matched to the line impedance.
There are always some small port parasitics, so don't expect to see -60dB return loss as you do for the line into PML boundary, but overall these ports should perform fine.

Best regards
Volker

[nico-arnold]

Hello Volker - have a happy new year! (:

Small update from me. I have 3 books and an eBook here now about FDTD. So far, I like the eBook the most as it appears more engineering-directed, better understandable and not mostly about the mathematical background of the FDTD method and fields. I'm not too good with the latter one, sadly.

Good point, that makes sense indeed. So for smaller frequencies, I will have to look for a more suited method to do the simulations then. We're speaking about a range of up to a few hundreds MHz here, so that should maybe still be fine, though. As I noticed, the 20 MHz I tried to simulate are already getting out of hand.

I tried to compare my model to the CPW_Line.m official example and noticed that it seems to have a similar problem here. I changed the last few lines so that the impedance values get calculated, the rest is the same:

Octave/Matlab file

When taking a closer look, you can see that the impedance also has a bigger imaginary part:

Closeup of the DC breakdown:

That appears a bit weird to me. I will reinstall OpenEMS later and try to find out why I have that dip around DC and you don't. Maybe I messed some things up while playing around.

best wishes,
Nico

PS: I'm thinking about changing the title to "Comparing OpenEMS and HFSS results" as it appears more fitting and not like "something's terribly wrong". Is that okay for you?

[VolkerMuehlhaus]

Hi Nico,

happy new year to you!

The ebook that you found looks interesting, I have saved the link for future use.

Regarding the plot with ripple and imanginary part, that is exepcted because you now simulate the "real" S-parameters of the line which is not perfectly matched, terminated into 50 Ohm port, and your code line

ZL = port{1}.uf.tot./port{1}.if.tot;

gives the input impedance into port 1 of the line. Now that we have terminated the line into a 50 Ohm port instead of running it into a PML, this value is no longer the transmission line impedance Zline=sqrt(L'/C') !! The input impedance circles around ~ 52 Ohm in Smith chart, resulting in the very typical pattern that you showed.

Regarding low frequency: yes, strictly speaking we can't get the true low frequency (or DC) response from the very limited time period that we evaluate after excitation. The commercial time domain solvers have a feature called "resonance estimate" (Empire XPU) or "AR filter" (Microwave Studio) for better extrapolation down to DC assuming that there are no unexpected resonances at very low frequency. But even without that feature, many of my openEMS models had a smooth response towards DC, so I'm not sure what is different here.

Regarding the thread title, no worries, do whatever you consider best. It is very common that users need some time to adjust to a different solver method, and all the methods have their specific strengths and weaknesses and gotchas.

Best regards
Volker

[nico-arnold]

Hey Volker,

thanks! (:

Yeah, that book is a good lecture. There'a also a link on the page where you can download the whole PDF.

Indeed, the fact with the port resistances also hit me yesterday. I had tried to remove them before, but the simulation ran much longer. Only after submitting my last comment, I realized that it was running forever because the line wasn't ending in a PML, so there is no way to decay the excitation with the wave getting reflected back and forth. Stupid me....
In the evening, I had a small test at home that I also just re-run on the bigger computer at work, with the same results. I took the above example again and just changed the if 1 in line 30 to if 0 so it was running the "else" part there, removing the port resistances and also the airspace in x-direction, making the line end in the PML. What I expected was

• less reflections leading to a more smooth response
• no imaginary part on the line impedance due to a perfect match
  But, instead, I get this result:
  
  I verified this in ParaView, and indeed, you can see the wave get reflected at the end of the CPW and travel back. But why's that? In the given example, in the line pml_add_cells = [0 0 8 8 8 8]; it is specified that there should be no clearance to the PML in x-direction. I also tried to add 8 cells of space in the x-direction there, but that didn't make things better.
  I re-checked everything, but it doesn't make sense to me. PMLs to decay waves? Check. No problems with port length? I think so, it's the official example.

Octave file

[nico-arnold]

Okay, my mistake. The BCs are defined as [2 2 2 2 2 2] which is MUR - changing all to 3 (PML) resolves the problem: