Imported polyhedra (STL) are not excited by active port (Python Interface)

[andredunford]

I'm trying to conduct some antenna simulations with custom radiating element geometry created in FreeCAD. I have no issue importing STL files and adding them to a Metal property via the AddPolyhedronReader() method. However, these are apparently not excited by the active port when the simulation is run. If I create the exact same primitive geometry via the AddBox() method, e.g. for the simple patch antenna tutorial example, the patch is excited and the simulation results are as expected.

My method of import is as follows:

And the summary for the Metal property at run time looks to be correct:

The geometry is also confirmed visually in the CSXCAD viewer, and there are no apparent differences between geometry created via the two methods. The only difference being that one primitive is a Polyhderon and the other a Box.

Is there something simple that I am missing?

I've returned to this problem several times, combing through the available documentation with no luck so far. Any help is greatly appreciated.

[LubomirJagos]

Can you please attach your FreeCAD file and python simulation script? It seems like there could be some grid error, like port placement or so, seems what you see in CSXCAD is what will you got :D With attached files it will be easy to debug, without them it's hard.

[andredunford]

@LubomirJagos, thank you for the response. I'm attaching the STL file patch.stl with an example script based on the Simple_Patch tutorial file as a minimum reproducible example.

stl_import_example.zip

In the script you'll find a boolean called polyhedron_patch which toggles between using the STL import for Polyhedron primitive, or using a simple Box primitive. Again, these geometries are exactly the same, as you'll be able to confirm in CSXCAD, and in the runtime summary of properties.

I believe the possibility of the issue being related to mesh grid or port placement can be excluded, as these are kept identical in both cases. That's why I'm wondering if there is some other parameter I'm missing which needs to set when using polyhedron geometry?

When you run the provided example with polyhedron_patch = False (i.e. using Box primitive), you should get a successful simulation, with a directivity plot. However, when you run with polyhedron_patch = True (i.e using STL imported geometry), the simulation will very quickly go below the power threshold and will fail to produce a far field calculation at all.

For further comparison, here are the impedance plots for the two cases:

Box Primitive (successful simulation)

Polyhedron Primitive (failed simulation)

I imagine this must either be something simple that I've overlooked, or an issue specific to the Python Interface, as I have seen other examples of people successfully using STL imports from the Matlab interface.

I could find no complete example using the Python Interface, but perhaps there were some on the previous forum, which is no longer accessible?

[LubomirJagos42]

I did the same what you, in FreeCAD 0.20 did sketch and extrude it in Z and then in File > Export choosed STL. I have similar problem when exporting STL from Blender, don't know what is the issue, but with FreeCAD it's always ok. Not sure if that STL is binary or text, can you run compare on them and post it here?

[andredunford]

There's no real meaningful insight running diff directly since they are binary files; but if I run a hex dump on them first, essentially everything beyond the "MESH" header is different.

Here's the results of a compare on the hex dumps:

It makes me wonder if it's some sort of encoding issue, since the hex patterns are nearly identical, but individual values are different. For example, you can use A and ? as general markers, which all seem to share the same positions. I might have to look more into the STL format to see if there are different encoding standards or something.

I do find it quite odd though that we get different results from the same CAD software, where one result is readable, and the other isn't. And I did originally create the file in v0.20 as well.

Are you by chance using Windows? Perhaps this is platform specific to Linux?

[LubomirJagos42]

yes, FreeCAD 0.20 on Windows 11 :D

[LubomirJagos42]

maybe try to create patch in FreeCAD and use that make solid in Part menu on top window it's somewhere, shouldn't change anything as all bodies in FreeCAD are solids, this is really strange, but if you figure out what is causing this, it really helps, since I got similar problem on my side in Blender and one guy using Blender doesn't face this issue and I have no clue why

[andredunford]

A direct conversion from body to solid fails with the message: ... is ignored because it is already a solid.

However, I've tried a few other things like that as well: I converted to mesh, and tried exporting that... tried creating shape from mesh... tried converting that to solid. Same result every time, unfortunately.

My next step will be to spin up a Windows 10 virtual machine, and install FreeCAD on that to see if the platform makes a difference.

[andredunford]

So, I've finally had success getting my original model to work, but the root cause is pretty odd and frustrating.

TL;DR

Ultimately if the STL model and the active port meet precisely at a mesh grid line with certain coordinates the simulation will fail. If they are displaced even marginally off from such mesh lines, the simulation will run successfully.

The frustrating part is that the coordinates of such mesh lines appear to be arbitrary. In my case, if the line was at Z-coordinate 1.524 mm (as provided in the tutorial example), the simulation would fail. However, if I adjust the setup ever so slightly so that the common boundary and mesh line was at 1.525 mm instead, the simulation would succeed.

This behaviour is made even more strange by the fact that there is no such issue with precisely the same geometry and mesh lines when created from a Box primitive (or presumably any other scripted CSX primitives). Perhaps this is a bug in the import precision that needs to be addressed.

Suggested working solution:

Avoid creating mesh lines at common boundaries between active ports and other properties/primitives which are meant to be excited by the port. This would mean generally avoiding the use of the AddEdges2Grid() helper function, or using it only sparingly when it doesn't coincide with port boundaries. This may also be another good reason to follow the 1/3 <> 2/3 rule of thumb for placing mesh lines.

@LubomirJagos, thank you very much for all the help and suggestions working through this. Copying the STL to the sim data directory was very helpful, as otherwise the first attempt would fail to find the model, which would only be found on the second attempt. Your suggestion fixed that.

Interestingly, the only way I could get to the root of the issue was through closely examining the STL that you provided. I tried using FreeCAD in Windows; tried several different versions; tried exporting from Blender; and a plethora of other variations. But it wasn't until I examined the precise coordinates of your model, that I found it was very slightly off from my original geometry (on the order of micrometers). I used the export function of the CSXCAD viewer to export the STLs with ASCII formatting (rather than binary), and could then read through the vertex coordinates.

I'm assuming that you may have created yours by eye and made it approximately the same as my original without using a shape binder to snap it precisely to the original bounds? This was very fortunate, because if it had exactly the same geometry as my original it would not have worked, and I would still be pulling my hair out.

Many thanks!

[LubomirJagos42]

:D :D yes I have to adjust Z coord and dimensions so it was moved little and therefore working, I haven't spent much time on mesh since it was working and I know this that you have to dive them into metal, so at least you learned it and now you will remember it :D
main problem with models it's people try to model them too perfect, like lines on edges and so, but it really doesn't matter, if you move lines inside model, doesn't have exact patch dimensions it will give you right simulation
I made GUI addon for FreeCAD where you can define simulation similar way like in CST or HFSS and you can define there mesh and it automatically generate octave/python array based on object boundaries so I always put lines by eye and haven't problem with this, but yes I learned it same way like you :D

[LubomirJagos42]

and I forgot, you have to dive port into metal and set him highest priority, priorities are also little confusing at beginning

[andredunford]

Thank for the added context. Although I am glad to have learned more about the openEMS setup, there are still some points that I think reveal a bug in the STL import/processing:

a) the official tutorial is setup with mesh lines coinciding precisely with metal edge and port edge; and it works despite that fact.

b) when the exact same geometry is replaced with an STL model, it does not work. This is inconsistent. There should be no reason that the exact same geometry succeeds or fails solely because of which method is used to define it.

c) when you keep the edges and mesh lines coincident, but simply move them 1 micrometer, the simulation works again! Clearly the issue isn't specifically the edge coincidence itself, but some other glitch happening at certain coordinates, or possibly at certain coordinate resolutions.

My intention isn't to be pedantic, but to try to reveal that something is inconsistent in the software, and can arbitrarily lead to simulation failure. I'll definitely be very cautious about my shared edges and mesh setup going forward, but one should be able to trust that software will behave in a consistent manner.

In any case, thank you again for all the help and discussion! I really appreciate your time. And I'll definitely check out your FreeCAD extension; it sounds very helpful!

[LubomirJagos42]

to b) c) and to SW working in exact way :D this all could be caused by how much float numbers are rounded, like in numerical simulations you are working with numbers and dimensions and so, so better to thought about tolerancies and so, like nothing is 100% same, never, and yeah it's not good put mesh on edges, I always put them inside object and spending some time in CSXCAD observing and zooming if they are Ok, 80% of your problems will be always vlcaused by incorrect meshing