Have the script write all coordinates using variables as opposed to numbers

[dom11990]

Instead of having:

CSX = AddBox(CSX, 'Sub1.substrate', 1, ...
    [12.82, -55.6328, -Sub1.substrate.h], ...
    [106.242, -12.82, 0]);

have:

CSX = AddBox(CSX, 'Sub1.substrate', 1, ...
    [start_offset_x, start_offset_y, start_offset_z -Sub1.substrate.h], ...
    [start_offset_x + Sub1.substrate.W, start_offset_y + Sub1.substrate.L, start_offset_z+ 0]);

or something similar. I've found that since you almost always have to modify the mesh by hand, searching out all the different coordinates can be a bit of a pain (even though it is already organized very well in the script). By having access to these variables I could delete the entire section with the mesh lines and just create the few lines that I know to be the source of the problem.

[thomaslepoix]

First using named variable is possible only for rectangle boxes, not really for polygons. so it could be implemented for substrates as in your example, which are always rectangles but not for components which are mix of rectangles and polygons.

Then I am not sure what you want to achieve. You are not supposed to manually modify components shapes so I assume the benefit would be to have more explicit mesh lines that currently looks like that :

mesh.y = [mesh.y, ...
    (-16.1) ... % P1 : Pac
    (-26.5 - 2*metal_res/3), (-26.5 + metal_res/3), ... % MS1 : MLIN
    (-26 + 2*metal_res/3), (-26 - metal_res/3), ... % MS1 : MLIN
    (-36.5 - 2*metal_res/3), (-36.5 + metal_res/3), ... % MS2 : MLIN
    (-16 + 2*metal_res/3), (-16 - metal_res/3), ... % MS2 : MLIN
    (-66.6) ... % P2 : Pac
    ];

I should add a comment about it but for now each row describes an edge. The number is the edge position. If the thirds rule apply, the first column is the outer line and the second column is the inner line. And the comment is the component reference.

Knowing that, it is easier to work with mesh. Also if you have to remove lines produced by an edge, searching for the edge coordinate in the script will help to remove lines produced at the same coordinate by other components.

IMHO what is missing is an indication about which line of a component it is, like "top edge", "bottom edge", etc. but the problem is it is relevant only for rectangular components..

Maybe you have an other idea in mind? I don't understand why you want to remove the whole mesh section.

[dom11990]

Hi,

I want to remove the component lines completely because they are causing unnecessarily long simulation times. If you consider a filter that has many similar width mlins connected in series you'll find that you often get lines very close to one another. I found it easier to just remove all the mesh lines and do a fine mesh over the entire substrate. It would be even better if I could easily do it over just the metals. I'll post some pictures once Im at my computer..

[thomaslepoix]

Would you find it easier if mesh lines were sorted by the edge coordinate rather than by the component reference?

About removing all lines and using a fine mesh, I had this idea in mind while creating the --no-metalresmesh script argument but I just realize that ports lines should be kept anyway, I will do something.

[dom11990]

I just thought it would be easier to make your own mesh if you had access to each of the components coordinates directly. I could delete the default mesh and write things like mesh.x = [MS1.x.max, MS2.x.min] etc

Because there are so often duplicates of mesh lines from different components, search and deleting what you need tends to be tedious. I think the tool would be most useful for giving the user the infrastructure (variables etc) to make their own mesh, as opposed to just applying the thirds rule and nearly always having something that does not simulate efficiently.

[thomaslepoix]

I dont think producing the mesh manually is easier nor the way to go. Also it is neither a good practice to avoid the thirds rule.

Wrapping components coordinates in correctly named variables seems to me really difficult because half of the components are polygons with sometimes different possible shapes.

I implemented a mesh sorter. Use --oems-sort-metalresmesh. It is easier to remove all identical lines at once but more difficult to understand from which edge a line comes from.

I would rather anotate mesh lines. A thing I could anotate really easy (compared to a component type relative indication about "which" line it is) is the "direction of the thirds rule", that is for an edge the direction "from inner side to outer side". It could be a little ambiguous for complicated shapes but it might do the job I think. (I used arrow like ascii symbols <>v^ but it could probably be better.)

If you check the doc oems_mesh_<component>.pdf files, you will see those directions represented by arrows

[dom11990]

I think the issue is that application of the thirds rule becomes irrelevant/counterproductive when you have many similar but not identically sized series components. Their third's rule mesh lines come so close to each other that the simulation time goes through the roof so you have to manually customize the mesh. Since that is the case, for me it is easier to look at the structure, see which components have lines are that critical, and mesh those explicitly. It sort of comes back to the automatic mesher discussion. If we don't have a mesher that produces useable results by default, I think it only brings limited value. I see your point about the polygons and I don't have a good solution. I think the only viable solution, in general, is to significantly boost the intelligence of the mesher. I think it needs to adapt the mesh based on the structure as a whole. For example, go through each plane and determine if there are transitions that need finer resolution such as metal boundaries or shape changes, then apply a adaptive mesh resolution scaling. Also, per the third's rule, it is not so critical if you already have a fine mesh for whatever reason. In general, it lets you get by with a coarser mesh but if you have 20 cells in your metal (for example) then the benefit of the thirds rule accuracy is marginal. When I have a fine mesh, I tend to skip placing every third's line since I know I will have many cells in the conductor and surrounding substrate in a sufficiently small volume.

[thomaslepoix]

Okay I understand..

I think I should release a first version with OpenEMS support and an automatic meshing solution will be worked on for the next one.

So for now I will make possible to keep ports lines while removing the whole metal resolution mesh, and hope the patch above will make it a little more usable.

[dom11990]

Yeah that makes sense. I'll give it a try sometime this week and see how it feels.

[dom11990]

Here is a little schematic that unfortunately doesnt work at all (bunch of mesh errors). I don't think I'm doing anything extreme. I think before calling the smoothmesh, the mesh needs to be cleaned up i.e. remove lines that are too close. That would be an interim solution. 9500MHz_Coupler.zip

[thomaslepoix]

Ok I took a look and I spotted some bugs :

• An edge is not meshed on MCOUPLED. I already spotted it but I forgot to fix.
• The conducting sheet option does not work for all components so for now it is better to use --no-conductingsheet

---

So first you will probably want to remove high resolution mesh lines from MMBENDs --no-highresmesh.

Then, if you disable smoothmesh --no-smoothmesh, you will see the problem comes from the MCOUPLED / MMBEND step, since it produce an edge meshed with thirds rule in both directions. (might be possible to resolve this case by merging these lines to a symetrical non thirds rule model)

Chosing a conflicting thirds rule over the other seems to me quite arbitrary, I would chose to preserve the vertical MLINs ones and remove the MSTEP ones.

So let's remove the MSTEP (MS13, MS15, MS16, MS17) vertical lines, directed respectively <, <, >, >.

Now you can reenable smoothmesh, it will look better :

---

Alternatively, you can --no-highresmesh --no-metalresmesh --keep-portlines and grow up the substrate mesh divisor but that's true the missing distinction between air mesh and substrate mesh become problematic..

[dom11990]

Thanks for looking into these issue so quickly. I don't understand why this is a problem at all. Seems like smoothmesh should be able to fill lines in between to make it an actual "smooth mesh". Perhaps tuning the parameters of the function could help?

Also, I noticed the right angle turn does not look like it is optimally mitered. Was this intentional? There are closed form equations that compute an "optimal" shape of a turn to achieve better return loss than a traditional 90 degree turn.

[thomaslepoix]

I never really investigated inside but SmoothMesh is not a robust function.. It is easy to make it crash and sometimes difficult to understand why is there a problem with the fixed mesh lines we provide to it. From what I tried, arguments does not change that much the result.

About the mitered bend, its ratio is 50%. It is not optimal but it is the one that is modelled by Qucs equations. A variable ratio mitered bend would be a good thing to implement in Qucs.

[dom11990]

I tried your solution on a different structure just now and realized with no-metalresmesh the whole simulation box gets the same mesh! Would it be possible to limit this to perhaps the area covered by the microstrips? In the image, everything in the red box gets the metalresdiv and everything outside it the substrate (and hopefully eventually, the air mesh). Otherwise you end up wasting a lot of time on a fine mesh of the air. Thoughts?

[thomaslepoix]

Finally I have a better idea. Qucs-RFlayout knows the dimension of the copper minimal bounding box you drawed in red, so I could simply add a script argument like --no-thirdsrule. So it will still use the metal mesh resolution and it will be a more natural interface than the --no-metalresmesh --keep-portlines etc.

And so I am not sure about the benefit to add an air mesh resolution since the substrate meshing in the Z direction does not depends on the substrate mesh resolution and there won't be a need anymore to use a really tight substrate mesh resolution as a hack. There would still be the speed benefit when far field is not needed but a smaller simulation box could be a better solution, don't you think?