About overlapping structures generating

[ustwc]

Well, happy to see that devicegen can parse 2D gds files and turn them into gmsh graphs. But I'm confused about whether devicegen can deal with some overlapping structures such as the gate stacks as the picture below (extracted from article: Appl. Phys. Lett. 116, 080501 (2020); doi: 10.1063/5.0002013 ). Also, in MOS structures, sometimes it is need to define some areas that are implanted and etched within several layers, so it is important if devicegen could combine different shapes of layers and allow some areas in the same layer having different materials/properties. Remind that in the examples given at this website, the gds file did have two different layers（the base is a rectangle）, so I wonder whether it is feasible to extrude layers with different shapes? Or, is there a simpler way?

[pphili]

In principle, devicegen can be used to generate a gmsh model of the device from the article, as long as a .gds of the gate layout is available (regardless of the number of layers in the .gds file). Are you having issues using devicegen with a .gds file in particular? If so, maybe you can post a minimal example?

When you say combine different shapes of layers and allow some areas in the same layer having different materials/properties, do you mean that you would like for a given layer to be made from different materials (or gmsh physical groups)? If so, unfortunately devicegen cannot currently handle such cases. However, you can also post an example of a typical situation you are interested in and we can see if we can accommodate your case with a simple fix.

[ustwc]

1. I tried to convert .gds files into .msh2 files using devicegen, using both the example you gave and the layout we designed. It seems that the 2D .gds pattern(the electrodes) are stretched vertically to generate the 3D-mesh. Of course it is straight to put a .gds file in and derive a mesh. But when some electrodes overlap (typically first layer 20nm, second layer 40 nm, third layer 60nm thick, and isolated with oxidation), I'm worried about if this approach makes sense. See the two files attached at last, first is the central part of our four-dots design. Each layer has a different thickness in practical，and the dots are designed to sit underneath the layer2. The second file is pre-edited by me to reduce it into a plane graph in case some issues appear when converted into gmsh format. And its 3D mesh is like:

2. In MOS structure, it is 2D electron gas confined at the interface of Si and SiO2 that is of research importance, so I'm curious about why the shapes of electrodes are stretched down to the substrate when converted into meshes. Because the dots are right underneath the electrodes in fact. Besides,as the picture below, different from heterostructure, it is needed to implant and etch some areas and form ohmic contacts(source and drain ) to lead the electron below the central gates(which has different properties from implanted areas) in MOS quantum dots. That's why I asked if some area can have different properties .

3-layer_electrodes.txt 3-layer-reduced.txt

[pphili]

1. devicegen currently works under the assumption that the .gds file provides a gate pattern on which boundary conditions can be applied for a simulation (e.g. a QTCAD simulation, https://nanoacademic.com/solutions/qtcad/). It neglects any 3D features of the gates. Although these features can be important, in our experience they are often less important for understanding e.g. dot wavefunctions than the voltages applied to the gates closest to the confined electrons or holes. In your case, if I understand correctly, your first and second gate layers are ~ 50 nm from the region which will house the confined particles. Maybe it is a decent first approximation to neglect these layers in a simulation and start by considering only the third layer? It could be sufficient to use a .gds file like this: 3-layer-reduced_bottom_layer.txt and apply relevant gate boundary conditions to each of the gates in layer 3. In this case, layer 1 would correspond to the simulation domain.

2. From the picture, I understand that in your device the confined electrons are located below a central gate at an interface, however the oxide layer is split into 3 regions: source, drain, and central, and each of these regions is potentially composed of a different material. Thus, you wish to consider a system where one of the layers does not have uniform properties. While devicegen cannot currently account for non uniform properties within a layer, it should be possible to build upon it to account for these design rules without too much difficulty. One possibility would be to attempt this yourself using the gmsh python API (https://gitlab.onelab.info/gmsh/gmsh/blob/master/api/gmsh.py). We would be happy to help you make such an update in any way we can.

[fbeaudo]

I would also like to mention that your uniform mesh has a very large amount of nodes in regions far away from the gates, which is probably not necessary. You will save a lot of time and memory if you use adaptive meshing. Adaptive meshing is explained in the second tutorial of the device simulator, here.

[fbeaudo]

If you use adaptive meshing, you can start with a very coarse mesh when creating the structure which should significantly speed up visualization in Gmsh. Running the Poisson solver, it will probably not converge with the very coarse mesh, but the mesh will then be refined until convergence is achieved, as explained in this paper.

[ustwc]

1. In your case, if I understand correctly, your first and second gate layers are ~ 50 nm from the region which will house the confined particles. Maybe it is a decent first approximation to neglect these layers in a simulation and start by considering only the third layer? It could be sufficient to use a .gds file like this: 3-layer-reduced_bottom_layer.txt and apply relevant gate boundary conditions to each of the gates in layer 3. In this case, layer 1 would correspond to the simulation domain.

Actually, layer 1 is the confine gate, which is at the bottom of the gate stack, defined to confine electron gas within its channel, so its channel shape is very important. Can I define the simulation domain to be the shape of the channel of layer 1? While layer 2 is the plunger and layer 3 is the barrier, they may appear to have similar characteristics to control the potential and set the transition time. If layer 1 could be set as the simulation domain, layer 2 and layer 3 being the explicit surface gates, it would seem much more reasonable.

[ustwc]

I would also like to mention that your uniform mesh has a very large amount of nodes in regions far away from the gates, which is probably not necessary. You will save a lot of time and memory if you use adaptive meshing. Adaptive meshing is explained in the second tutorial of the device simulator, here.

Nice idea, I will think about that. Thank you!

[pphili]

Maybe something like this would work better? 3-layer-reduced-layer1domain.txt

[ustwc]

Maybe something like this would work better? 3-layer-reduced-layer1domain.txt

Seems good, but what is the physical significance of the simulation domain? Do I need to attach boundary conditions onto it? In this example, the domain looks like a rectangle covering the gated area, so what is the difference between the gated area and other area in this domain?

[pphili]

The boundary conditions should be determined by the potentials applied to your gates. This subdomain/simulation domain is a subset of the entire device/domain. However, if you expect your particles to be confined in this region of space, it may not be necessary to simulate the entire domain. In other words, if the particle wavefunctions vanish (or become vanishingly small) outside the simulation domain, it may be sufficient to ignore the other areas.

[fbeaudo]

Hello again @ustwc, I was wondering if we had answered all of your questions, and if you were satisfied with the answers. Is there anything else that we can do to help you moving forward with your project, or should I close this issue ?

[ustwc]

Sure you can close this issue, I'm getting familiar with this newly developed software with your answers now. Thank you for your patiently explanation.

[fbeaudo]

@ustwc you are welcome, and please do not hesitate to reach out here or on our forum if you have any further question or comment. https://forum.nanoacademic.com/t/qtcad