Excitation of port 2 (coaxial) - unexpected results

[toammann]

Hello,

first of all tank you for providing this incredable software! At first I could not belive something like this was availble in open source :),

I am trying to simulate a Coaxial (SMA) to Microstip RF Transition. The the following steps were taken to build the model:

1. Create a parametric model of the transistion and the Connector (approximate) in FreeCAD
2. Export the model as *.stl files
3. Export the parameter values as a textfile
4. Import the parameter values and 3D model files in a openEMS script
5. Create parametric meshing based on the FreeCAD model parameters

At first I was quite happy with the results by exciting port 1 (Microstrip). The model could be tuned to to achieve decent matching.

Now (to finalize the model) I tried to generate all four S-paramter values for a touchstone file export. This is the point where I am struggeling. The exciation of port 2 (the coaxial one) produces completely different s-parameter results than the port 1 excitation.

The scatting parameters of this model should be at least approximately symetrical / reciprocal.

I ckecked the calculated port impecances. They look fine (around 50R). The meshlines were placed at the outer most coordinates of the coaxial outer and inner conductor.

Some Questions:

1. Are there certain rules how to set the feed shift?
2. Is there a minmum port length that must be specified?
3. Can you recommend some literature on the port topic?
4. Is it possible to change which port should be excited inside of the CSX object? How can excite multiple ports sequentially without re-reunning the entire script?

Any suggestions how to narrow this down any further? I can share the model and the openEMS script. However it is rather lengthy and runs for about 20min.

Thank you in advance

[toammann]

Hello,
the problem may be related to the PLM boundary at the microstrip. I was focused on the exciation of port 2 for quite some time. However it seems that the PML at the Microstrip port fails for some reason and provides a bad match.

Here is a simulation result unsing a "MUR" Boundary at port 1 (mircostrip) while exciting port 2 (coaxial). This result is much better!

What is the deal here with the PML at the microstrip port?

[toammann]

I was able to solve the last two remaining problems.

1) Cylindrical STL imported bodies are not recoginzed by openEMS.
The issue was related to the export in FreeCAD. So no blame on openEMS here! When exporting the cylindrical shapes as *.stl file a mesh is generated. The process performs an arc approximation of the cylinder surface.The curvature is broken down to straight line sections which effectively remove portions of the circle. Therefore, even though the mesh lines are placed at the correct radius/diameter they may not hit the cylinder boundary which yields into the above warnings (AppCSXCAD shows the *.stl mesh without further simplification, this is very useful if you are aware of this fact...).

I now use the Mesh workbench in FreeCAD to export the *.stl files. The workbench allows control of the arc approximation. In a python script this can be achieved by the following lines using the standard Mesher:

mesh_ld = 1 # mm
mesh_ad = 20*math.pi/180  # 20°

label = "conn_outer_body"
body.append(App.ActiveDocument.getObjectsByLabel(label)[0])
Mesh.export(body, "./" + label + ".stl")

label = "conn_inner_cond"
shape =  Part.getShape(App.ActiveDocument.getObjectsByLabel(label)[0])
mesh=MeshPart.meshFromShape(Shape=shape, LinearDeflection=mesh_ld, AngularDeflection=mesh_ad, Relative=True)
mesh.removeDuplicatedPoints()
mesh.write("./" + label + ".stl")

2) How to excite two ports sequentially (one after another)
It actually works like described above. It is possible to create two separate simulation folders for port1 and port2. The *.xml file for the first excitation can be placed in the folder of port1. Then the excitation section of the CSX structure can be changed CSX.Properties.Excitation to excite port two. Finally a second *.xml file is generated from the modified CSX into folder two.

I will mark this as solved now!

[0xCoto]

When exporting the cylindrical shapes as *.stl file a mesh is generated. The process performs an arc approximation of the cylinder surface.The curvature is broken down to straight line sections which effectively remove portions of the circle. Therefore, even though the mesh lines are placed at the correct radius/diameter they may not hit the cylinder boundary which yields into the above warnings (AppCSXCAD shows the *.stl mesh without further simplification, this is very useful if you are aware of this fact...).

I do it this way with FreeCAD - think I'd run into the problem you mentioned, or does this look OK?

# Correct relative origin
obj = FreeCAD.getDocument("Unnamed").getObject(str(object.Name))
__shape = Part.getShape(FreeCAD.getDocument("Unnamed").getObject(parent),part_name+str(object.Name)+".",needSubElement=False,refine=False)
FreeCAD.ActiveDocument.addObject("Part::Feature",str(object.Name)+"_transformed").Shape=__shape
obj = FreeCAD.getDocument("Unnamed").getObject(str(object.Name)+"_transformed")

# Export STL
Mesh.export([obj], dir + str(object.Label) + ".stl")

[toammann]

Hello,
using Mesh.export() was actually also my first attempt to export which caused the "unused primitive" warning.

There is a short article (Export_to_STL_or_OBJ) in the FreeCAD documentation which describes the two available options to export a *.stl. When using Mesh.export() you end up in Method 1 mentioned in the documentation where you have no control about the arc approximation.

In addition the results are dependent on the FreeCAD import/export settings of the particular FreeCAD instance. So two installations with different settings will produce variying results which is - in my opinion - undesired. I use therefore the mesh workbench from now on.

The pyton FreeCAD script lines in my above reply use the mesh workbench directly. Several meshers are available in the Mesh workbench using "Create Mesh from Shape".

---

Visualization of the problem:

The grey shapes are the *.stl exported mesh files. Parts in yellow color are the ideal representations of the shapes.

This is the standard setting of the "displayed angular deflection" which is used when you call Mesh.export():

What we want for proper meshing is that the *.stl meh has one point on each edge of the cylinder bounding box. With a very coarse max. angular deflection of 90° this is rather obvious:

Now let´s have a look at a result of the standard *.stl export with the 28.5° max. angular deflection setting:

On the right and left side the circle get´s cropped because the outer most point is not located on the bounding box. The mesh I specified at diameter/2 can never hit the circle because the *.stl export has cropped the it!

To fix this one have to choose an angular deflection that produces a suitable number of segments and ensures points on the bounding box at every 4 edges. E.g. for an max. angular deflection setting of 20°:

This can be achieved by either changing the "Part Design Shape view" setting (Method 1) or using the preferred Mesh workbench (Method 2, see python lines above).

So the short answer is: It depends on your "displayed angular deflection" FreeCAD preference settings.

Regards!

[0xCoto]

Thanks for the detailed explanation!!

[toammann]

Hello Thorsten,
i have experimented with the "floating point / meshing" issue you described above.

In order to have the edges in the z-dimension correctly recognized by the PEC-dumps I have to undersize the mesh line by about 100e-9 units. This value is unexpectedly large. Ok to be fair I have no idea how big such floating point deviations can become. However there was a slight difference in the simulation result.

Can you explain a little what happens during the meshing in this case? I would also be interested why this "should not matter so much" for non-PEC materials as mentioned this above.

Is the under sizing necessary in all three dimensions (x, y, z)? I suppose that this should be done in every case when using a *.stl import? This can become cumbersomepretty quickly and impossible in some cases where two metal parts are located on top on each other.

Thank you very much!