Black mesh triangle in GPU mode

[jbelissard]

Hi Luc,

First of all thanks a lot for your amazing work on Nebula.

I'm working on a geometry editor based on GMSH to facilitate the geometry file creation. It seems to work well on simple geometries, but in some conditions (not clear which one at the moment) I have some black areas on my SEM images. The black area matches with a mesh triangle, but not the whole surface of the triangle. I can't see any problem in the .tri file though.
It is oberved only in GPU mode (no problem in CPU mode), and no matter the simulation conditions (number of electrons, energy, materials, energy_threshold, seed, etc...).

It generally happens when the generated mesh contains long and thin triangles. It seems pretty random though...

I have attached some simulated images and geometry screnoshots to illustrate the problem.

Have you ever encountered such behavior, and do you have any insight on what causes this ?

Thank you for your help,
Jordan BELISSARD.

[lvkessel]

Long and thin triangles are known to be problematic. It's very hard to avoid with single-precision floating point numbers, which we have to do to avoid a massive speed penalty on consumer GPUs. Most of these problems should be fixable by setting USE_DOUBLE to 1 in source/config/config.h and recompile the simulator, but it would make everything much slower.

But it surprises me that the CPU version appears to work well in this particular case while the GPU version does not--I would expect both to behave the same way here.

I can take a look if you send me this mesh (or another one that shows the same problem).

[jbelissard]

The .tri file is attached to this message. I'll try to recompile the simulator with the option you mentioned. Thanks again, Jordan. EDIT : I'm not sure the .tri extension is authorized by Github. Here is the file with a .txt extension. [test_01.txt](https://github.com/Nebula-simulator/Nebula/files/11980461/test_01.txt) Le sam. 1 juil. 2023 à 10:50, lvkessel ***@***.***> a écrit :

…

Long and thin triangles are known to be problematic. It's very hard to avoid with single-precision floating point numbers, which we have to do to avoid a massive speed penalty on consumer GPUs. Most of these problems should be fixable by setting USE_DOUBLE to 1 in source/config/config.h and recompile the simulator, but it would make everything much slower. But it surprises me that the CPU version appears to work well in this particular case while the GPU version does not--I would expect both to behave the same way here. I can take a look if you send me this mesh (or another one that shows the same problem). — Reply to this email directly, view it on GitHub <#5 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A67Q5ZZBU4ZEOEH3H45A5VTXN7QHFANCNFSM6AAAAAAZZ4U2AI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jbelissard]

I have modified the meshing options in order to have smaller and more regular triangles.

I still have some dark areas, with both the GPU and CPU versions, but not exactly the same result.

Here is the geometry file :
test_03.txt

[jbelissard]

Ok, I have something new :)

It seems to depend on the beam position, wich is very weird. I accidentally set the beam z coordinate to 10nm (instead of 100nm), which is dumb because the lines height is 50nm, but the black areas disappeared.

The black areas reappears for all z>= 15 for the first mesh, and for all z>=31 for the second one...

I hope it helps you understand the issue...

Thanks again,
Jordan