Drift-diffusion simulation for 3D produces higher currents than expected

models
,
7

Hello @GLuek

I have adopted an old script here:
https://github.com/devsim/devsim_misc/tree/main/misc

which shows bad tetrahedra in the block mesh. Running as default

python check_tetrahedra.py

shows the worst mesh element. Where the black lines go from each node of the tetrahedra to the circumcenter.

image
image686×622 85 KB

Unfortunately this center is outside of the tetrahedra, and is what leads to high current levels.

If uncomment line 69 of the script to show the first tetrahedra, instead of the worst, you see an example of where the circumcenter is inside of the element:

It also prints out the actual volume of the cube versus the volume if bad tetrahedra are present:

2.9185709233348095e-15	Volume calculated from tetrahedra edge volumes
9.999999999999989e-16	Volume from tetrahedra

Perhaps this could be tailored in your quest for a good mesh.

8

Thanks for the conversion and tetrahedra evaluation script @Juan. I tinkered a little with gmsh generation, tetgen meshing and the tetrahedra evaluation. Since it is a bit more code I put up an example project on github:

The tool flow in generell is: gmsh .stl → tetgen → convert to .msh → attach contacts via gmsh → check tetrahedra or devsim. Here is an image of a really simple mesh I generated with only 24 tetrahedra:

nVolume_contacts
nVolume_contacts863×990 123 KB

I am now at a point where I am a little lost how to proceed. The following image shows one tetrahedron of a mesh from the project which has a good quality:
good_tetrahedron
In the next step I scale the model by a factor of 10 without changing anything else, so the mesh basically stays the same, only the distance between the points changes:
bad_tetrahedron
The tetrahedra looks exactly as the one above as expected, but now the check_tetrahedra script shows a ratio between the devsim volume and tetrahedron volume of about 20.
When you plot the worst tetrahedra it looks like this:
worst_tetrahedron
As far as I understood this tetrahedron should not be too bad since the black lines do not extend beyond the blue volume.

Any ideas where to look next?

9

Hi @GLuek

I’m not sure. Potentially there could be a bug in the check_tetrahedra.py or somewhere else. Visually, the 2 figures look like they are scaled by a factor of 10. If the black lines meet somewhere inside or on the surface of the tetrahedron, then the ratio should be calculated as 1. This is since the 6 element edges should have there element node volumes sum up to the volume calculated from the 4 nodes

Are the Gmsh algorithms deterministic, and always write out the elements in the same order?

It is possible that meshing algorithms have problems with numerical precision, if you use mesh lengths that are too big or too small. For example, this one is Windows specific:
https://onelab.info/pipermail/gmsh/2007/002408.html

I would recommend reading and writing files with full precision, which it appears that you are already doing.

Use mesh lengths that don’t cause issues. For example, if the meshing algorithm has some hard coded bias against numbers like 1e-10, or 1e-15, then consider using lengths on the order of 1 or .1 and then scaling at the end.

Are the STL, gmsh, and Tetgen files each written out in full precision? Looking at your repo, they seem ok to me.

That is a really cool idea using STL, which I have never attempted before. Can you add the contacts before sending them to Tetgen?

Are you able to change the characteristic lengths in Tetgen so that the more tetrahedra are being used?

I can send you a tetgen input file that can create a good 3d block. However, it may depend on sizes you choose.

I am about ready to share with you an old tetgen example I used in a publication. I hope to have it up in a few hours, but it appears that my calculation of actual tetrahedral volume is giving weird results on macOS, but not Linux. I need to check if this is occuring on windows as well.

10

Hi @GLuek

It looks like there is a bug somewhere in devsim for the macOS and Windows platform. It is not occurring on Linux.

If you check out:
https://github.com/devsim/devsim_misc/tree/main/tetgenmesh
and run

python check_tetrahedra.py

it will say 100% of the tetrahedra are bad on Windows and macOS, but they are 0% on Linux.

11

I checked this on my site with the same results. With WSL2 the check_tetrahedron gives good results for my simple mesh above and the electrical simulation gives the expected result of 1A as well.

12

As far as I know the STL format has no support for defining entities beyond the surface mesh, so I think contacts and region have to be defined either in tetgen or afterwards in gmsh. But gmsh is quite helpful as it can “autodetect” the entities and define physical groups, but I have to take a deeper look if it changes the mesh even if I do not execute gmsh.model.msh.generate.

13

Thanks for the explanation. In gmsh, I am used to having many surfaces creating a closed surface for each region. Some of these surface are then also able to be treated as contact.

I have created a new release version 2.6.5. Please update and check to see if this resolves some of your meshing issue.

14

I updated the package and results on my windows installation look good now aswell. Thanks for your support! I will put some more work in the meshing toolchain and try to mesh more complex models, thanks again for the examples and scripts, they are really helpful.

1 Like
15

Thanks again for finding that bug on Windows and macOS.

If you run the final.sh script in the devsim_misc/tetgenmesh directory, it starts with a mesh with bad elements and it creates a background mesh .mtr file to make all of the elements Delaunay. The check_tetrahedra.py script in the directory has a commented out function to plot the circumsphere of the 4 nodes of the element of the worst elements.

Also, the ‘test.poly’ file marks the boundaries so that they can be used for contacts.

16

Hi @GLuek , this seems like amazing work!

I’m also interested in automatically generating simulations, but starting from a GDS layout + descriptions of the layers. We can already generate relatively complex CADs that I then mesh using GMSH constructive geometry. See a relatively simple 2D example here: Troubleshooting a faulty mesh? (we have done much crazier stuff for our FEM solvers)

How mature is your toolchain? I’m wondering it I can apply it, because my geometry parser can already generate 3D models. If I initially have physicals tagged (3D volumes and 2D interfaces/contacts), can we apply your fix to the mesh, and easily retag the physicals?

17

Hi @simbilod,

sorry for the late reply, I hadnt got access to my computer for a while.

I experimented with the toolchain from the github repo above: gmsh → stl → tetgen → gmsh → devsim but for more complex meshes I achieved roughly the same mesh quality as simply using gmsh <> devsim. I think I read somewhere, that the gmsh delaunay algorithms are adapted from tetgen anyway.

Nevertheless, attaching contacts to a mesh later via gmsh works, but due to the stl step in between all “descriptive” information is lost. Therefore you need to filter the vertices for e.g. a contact afterwards via EntitiesInBoundingBox or similar approaches.

I now use gmsh with the following algorithms:

gmsh.option.setNumber("Mesh.Algorithm", 5)
gmsh.option.setNumber("Mesh.Algorithm3D", 1)
gmsh.option.setNumber("Mesh.OptimizeNetgen", 1)
gmsh.option.setNumber("Mesh.MeshSizeExtendFromBoundary", 2)

My tooling looks roughly the same as yours. I read GDS layer data which is converted to 3D geometry and meshed by gmsh. The initial mesh is fed into devsim where GDS data is read and combined with z-doping profiles to generate the overall doping structure. Afterwards, I rewrote one of @Juan mesh refinement scripts to use the doping profile for background mesh generation which is fed back to gmsh for optimization.

In my opinion, a challenge in this approach is the generated mesh size. The isotropic mesh usually leads to a huge amount of vertices for semiconductor devices, since you have very thin layers with comparitively large xy dimensions. I searched for an axis-aligned anisotropic mesher similar to the SDE module from Sentaurus TCAD, but unfortunately I havent found anything.

2 Likes
18

Hi @GLuek

Have you seen LaGrit?

https://lagrit.lanl.gov/

This paper from 1997 makes it look appealing:
Unstructured 3D Grid Toolbox for Modeling and Simulation

and this semiconductor example:
https://lanl.github.io/LaGriT/pages/semiexamples.html

However my limited attempts to work with it were unsuccessful. It looks complicated to work with.

It produces Exodus files, which I would be able to provide scripts for. I have an exodus reader here:
https://github.com/devsim/devsim_3dmos/blob/main/ieee/meshing/cubit_test.py
and could tweak it as necessary if there are significant differences between Cubit and LaGrit

1 Like
19

Alternatively, do any of you have experience with GMSH aniso meshes?

There’s a 2D example: Gmsh 4.12.2

And they say there is experimental support in 3D for “MMG3D allows to generate anisotropic tetrahedralizations.”, used with a background mesh.

20

That does look interesting. One of the requirements for devsim is an Delaunay mesh. I don’t know enough about the method to see if this is achieved. If you see a bunch of obtuse 2D triangles, that is a good sign that the Delaunay criterion is not met.

In 3D, the other Gmsh algorithms are “Constrained Delaunay”, which are only “mostly” Delaunay.

An octree mesher is interesting, as there are only right angle Triangles and Tetrahedra. Also a prism mesh is also good, where you are pulling the triangles into the 3rd dimension, but it has a lot of limitations in the type of structures you can build.

21

The images of the LaGrit meshes look pretty promising. But looking into the documentation and examples, I share your view that it looks complicated. I might give it a try anyways. For now I am experimenting with your tdr conversion tool.

Regarding the GMSH aniso meshes: I have seen the linked example but did not try anything in this direction. Unfortunately, the documentation how to create and use the background mesh files is pretty hard to figure out.

22

@GLuek thanks for your help testing the tdr convert tool. If you have any tdr files that you can share publically, it would help me in creating a test suite.

23

I would really like to help you out with some tdr files, unfortunately the Synopsys EULA is quite prohibitive in this area. It even seems that Synopsys is aware of this, as from TDR Version 17 (onwards), they modified the hdf header so standard tooling (hdfviewer, h5py) is no longer working for tdr files which makes down conversion necessary.

24

Interesting. How long has version 17 been around? Let me know if you have any dfise parsing needs.

25

It was introduced in the 2022.03 release and is the default from the 2022.12 release onwards.

1 Like
26

I’ve also stumbled upon this recently but haven’t had a chance to try it:

1 Like