| ID: | 4243 |
| From: | ge...@igor2.repo.hu |
| Date: | Sun, 5 Jul 2020 07:24:06 +0200 (CEST) |
| Subject: | Re: [pcb-rnd] bugreport: mesh |
| in-reply-to: | 4242 from Evan Foss <ev...@gmail.com> |
| replies: | 4244 from Evan Foss <ev...@gmail.com> |
On Sun, 5 Jul 2020, Evan Foss wrote: >Ok. If since it's a missing feature I suggest another one. At the very >least there should be a warning in the log window that lets the user I disagree. We don't warn for copper text, and our arc handling is not very clever either. These are called known limitations. I know you bumped into one specific limitation with your current example so you may feel it's the important one. But in reality users won't know the internals so they will do random things and will bump into random _other_ limitations as well. Instead of trying to warn for each, we should just fix them - when we get there. Until that, users shall know the whole thing is not a generic "simulate anything for me" but a dirty hack to simulate a narrow set of things. Not only the mesher, the whole current setup. Instead of spending time on trying to enumerate all possible ways it can go wrong and fill up the code with warnings about them, I rather spend my time on a more generic fix (which is really the tinyopenems workflow effort). >know when the mesh lines don't land on the port. I have done a few >examples and I am doing more. Meshing with real life traces is harder >than the polygons of the scale in the filter I started with. I can >tell from testing that the active port causes no excitation if it >doesn't get all 3 lines. As I said, it's on the TODO. I will handle it when I get there. It's in the queue, please be patient. Regards, Igor2
Reply subtree:
4243 Re: [pcb-rnd] bugreport: mesh from ge...@igor2.repo.hu
4244 Re: [pcb-rnd] bugreport: mesh from Evan Foss <ev...@gmail.com>
4245 Re: [pcb-rnd] bugreport: mesh from N <ni...@gmail.com>
4249 Re: [pcb-rnd] bugreport: mesh from ge...@igor2.repo.hu