Open tomflexcompute opened 4 months ago
Who worked on this before? @caseyflex @lucas-flexcompute @tylerflex ?
@tomflexcompute it would be good to have an example of the plotting being wrong.
I think we can use this notebook to test https://www.flexcompute.com/tidy3d/examples/notebooks/90OpticalHybrid/
I can't see any errors in plot()
in either develop or pre/2.7 branches. Is there a particular case that is not working?
The geometry if completely missing in plot_3d()
, indeed, but that's generated externally… I don't think we can't fix it in the front-end.
Yeah plot()
does work correctly in most cases but sometimes there is a warning about mesh being not watertight and the plot would be incorrect, even though the simulation itself is correct. I'll try to see if I can find an example of it.
Regarding the plot_3d()
issue, I've asked MC to look into it.
Maybe @dbochkov-flexcompute or @weiliangjin2021 have better insight here, but I think we cannot guarantee that getting ε from a non-watertight mesh would always succeed. A non-watertight mesh is essentially open, isn't it?
Yeah I don’t even know if this is a tolerance issue. In the backend we simply assume the mesh is exactly watertight, understanding that if it is not, this may lead to permittivity processing errors. Thus it relies on the frontend usage of trimesh library to check watertightness, only warning if it may not be watertight. We could play with the frontend tolerance (currently the trimesh default), but I’m not sure what it should be as there’s no backend tolerance to compare against.
On Thu, Mar 7, 2024 at 2:54 PM Lucas @.***> wrote:
Maybe @dbochkov-flexcompute https://github.com/dbochkov-flexcompute or @weiliangjin2021 https://github.com/weiliangjin2021 have better insight here, but I think we cannot guarantee that getting ε from a non-watertight mesh would always succeed. A non-watertight mesh is essentially open, isn't it?
— Reply to this email directly, view it on GitHub https://github.com/flexcompute/tidy3d/issues/1522#issuecomment-1983677260, or unsubscribe https://github.com/notifications/unsubscribe-auth/A3KLECJ3HU3DXGWAYR3ZEA3YXB5RFAVCNFSM6AAAAABEJ6AOCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBTGY3TOMRWGA . You are receiving this because you were mentioned.Message ID: @.***>
I think the relevant tolerance would be tol.merge
https://github.com/mikedh/trimesh/blob/main/trimesh/constants.py
But we need to be a bit careful with it as it identifies vertices. The default agrees with solidworks.
To be a bit more clear, trimesh.is_watertight does the following: "Check if a mesh is watertight by making sure every edge is included in two faces." So this could fail either because of tolerance in vertex placement or because the condition is fundamentally not satisfied. In the latter case it's not clear how to process the permittivity of the mesh.
On Thu, Mar 7, 2024 at 2:58 PM Charles Wojcik @.***> wrote:
Yeah I don’t even know if this is a tolerance issue. In the backend we simply assume the mesh is exactly watertight, understanding that if it is not, this may lead to permittivity processing errors. Thus it relies on the frontend usage of trimesh library to check watertightness, only warning if it may not be watertight. We could play with the frontend tolerance (currently the trimesh default), but I’m not sure what it should be as there’s no backend tolerance to compare against.
On Thu, Mar 7, 2024 at 2:54 PM Lucas @.***> wrote:
Maybe @dbochkov-flexcompute https://github.com/dbochkov-flexcompute or @weiliangjin2021 https://github.com/weiliangjin2021 have better insight here, but I think we cannot guarantee that getting ε from a non-watertight mesh would always succeed. A non-watertight mesh is essentially open, isn't it?
— Reply to this email directly, view it on GitHub https://github.com/flexcompute/tidy3d/issues/1522#issuecomment-1983677260, or unsubscribe https://github.com/notifications/unsubscribe-auth/A3KLECJ3HU3DXGWAYR3ZEA3YXB5RFAVCNFSM6AAAAABEJ6AOCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBTGY3TOMRWGA . You are receiving this because you were mentioned.Message ID: @.***>
Any follow up on this? What should we do?
MC is looking into it. Their schedule is pretty tight too so not sure if we will have it done within, say, a week or two, but will update here if they make progress.
Do we still need to keep this open @tomflexcompute ? I think MC fixed some things.
I think plot_3d()
still doesn't show stl structures at the moment.
For structures imported from stl files, current
plot()
andplot_3d()
can either be wrong or not show the structures at all, which led to some user frustration. Could this be fixed in the near future?A side note that in the web GUI, the structure actually shows up mostly correctly.