Opening MSH files

[katzir]

Hello,

Using the gmsh_diode3d.py example code as reference, I was trying to load in a MSH file (which I have made sure runs fine in Gmsh).
However, I keep getting “ERROR: MeshFormat 4.1 0 8 not supported”. Using Gmsh, I tried changing the MeshFormat version to 208, 308, and 2.208 but I keep getting a similar error. I noticed that all the MSH files used in the DevSim examples are of MeshFormat 2.108, but I haven’t been able to make a file of that format.
Does anyone know how to deal with this issue?
Any help would be appreciated!

[Juan]

Hello @katzir
Thanks for trying devsim. Mesh formats of 2.1 0 8 and 2.2 0 8 are supported. Please check the number you are seeing in the file.

When I run:

gmsh -2 -format 'msh2' 3dblock.geo

with the latest gmsh 4.10.3 from https://gmsh.info the resulting .msh file is version “2.2 0 8”.

[katzir]

Hello @Juan
Thank you for the quick reply! And you’re right, I just realized that when I’m using the 2.2 0 8 version the error message is different, sorry about that.
When I try creating a mesh using version 2.2 0 8, I initially get an error in the $Elements section saying “ERROR: physical number 0 must be positive”. According the the Gmsh manual on section 4.3.1 where it describes the syntax for this version, the only part where I have 0’s in the Elements is in the “elementary” position, which in my case starts like this:
$Elements
6014
1 15 2 0 1 1
2 15 2 0 2 2
3 15 2 0 3 3
The file runs fine in Gmsh, so do you know why it doesn’t like the 0’s here?

[Juan]

Each element needs to be in a physical group. In your .geo file, you should have lines like:

Physical Surface("top") = {20};
Physical Surface("bot") = {16};
Physical Volume("bulk") = {26};

which maps the appropriate surfaces to contacts and interfaces, and volumes to regions. In this mode, Gmsh should automatically remove elements that are not in any group. From your example, an element type of 15 is a point, and would automatically be filtered out.

[katzir]

Okay that makes sense now, thank you so much for the help!

[katzir]

Hello @Juan
I have a new .msh file, but I am having trouble loading it into DevSim. I have made sure that every single volume entity belongs in a Physical Group, and I have also added some Plane Surfaces into groups since I will need them later.
Since I am having trouble with reading the file, I simplified my code for now to this (kind of follows the examples of example/gmsh_diode3d.py and testing/mesh3.py):

  load_device(file="gmshDiode2.msh")
  write_devices(file="gmshDiode_write.msh", type="devsim_data")

and also tried this:

  create_gmsh_mesh(mesh="mesh1", file="gmshDiode2.msh")
  write_devices(file="gmshDiode_write.msh", type="devsim_data")

The first block of code gives me the following error:

and the second block of code gives the same error but at “line: 5: syntax error” instead.

I compared my file to ‘gmsh_diode3d.msh’ (the file loaded in example/diode_common.py) but I can’t find anything different in the formatting (I changed both to MeshFormat 2.2 0 8 when comparing). For reference, this is how my .msh file starts:

$MeshFormat
2.2 0 8
$EndMeshFormat
$PhysicalNames
5
2 45 “Left Side”
2 46 “Right Side”
3 1 “Bottom V”
3 2 “Cylinder V”
3 6 “Top V”
$EndPhysicalNames
$Nodes
3256
1 0 0 0
2 0 8e-06 0
3 8e-06 8e-06 0

(Just in case, I made sure that these Physical Groups also show up in the .geo file, like this:

Physical Surface(“Left Side”) = {21, 142};
Physical Surface(“Right Side”) = {23, 150};
Physical Volume(“Bottom V”) = {26};
Physical Volume(“Cylinder V”) = {27, 28, 29, 30};
Physical Volume(“Top V”) = {31};

Is there some issue that I am not seeing? Or could this perhaps be an error caused by something else completely and it’s just showing up as a syntax error in the console?

(PS: I also tried making a msh file where all entities were in physical groups, but that didn’t seem to make a difference)

[Juan]

Hi @katzir

Sorry for the confusion about the “.msh” extension, because it is used as either a devsim format file or a gmsh format file. If you are trying to read a gmsh format, you should use create_gmsh_mesh. You also need to map the physical groups to contacts, interfaces, and regions. From diode_common.py:

def Create3DGmshMesh(device, region):
    #this reads in the gmsh format
    create_gmsh_mesh (mesh="diode3d", file="gmsh_diode3d.msh")
    add_gmsh_region  (mesh="diode3d", gmsh_name="Bulk",    region=region, material="Silicon")
    add_gmsh_contact (mesh="diode3d", gmsh_name="Base",    region=region, material="metal", name="top")
    add_gmsh_contact (mesh="diode3d", gmsh_name="Emitter", region=region, material="metal", name="bot")
    finalize_mesh    (mesh="diode3d")
    create_device    (mesh="diode3d", device=device)

Please note that a device is not created until finalize_mesh and create_device are called. The write_devices command is for writing out a file in the devsim format, and can contain simulation data, as well as equations for the models.

When physical groups are defined, Gmsh should automatically prune out entities that are not associated with any region.

Looking at GmshScanner.l in the devsim source code, I can see that the parser is not expecting spaces in the physical names, so I would expect that to be the source of your issue on line 5.

<PHYSICALNAMES_SEC>\"([A-Za-z]|{UTF8})([A-Za-z_0-9:@]|{UTF8})*\" {

Please suggest how you would want this issue to be resolved.
At the very least, the simulator can provide a more specific error. Supporting spaces in the names may also be possible.

[katzir]

Hello @Juan
Thank you for the clarification. Since I didn’t have too many physical groups, it was easy to just change the names so they don’t have spaces and now it works, thank you!
This doesn’t seem like too big of an issue to resolve, so I guess simply adding something about naming physical groups in the documentation would be nice.

I also have a follow-up question to this. The way I understand it (please correct me if I’m wrong), in the example of gmsh_diode3d.py, only one region is created since there was only one physical group containing a volume, the “Bulk”, and then the doping within the volume is based on an equation, using node_model().

In my case, I have 3 different physical groups of volumes. When put together, they make a rectangular volume, as shown in the picture (normally there are more diodes next to each other and their volumes become part of the physical groups mentioned in the earlier post. I just simplified this image to try and make it clearer what I’m trying to do):

The “CylinderV” (the volumes of the 4 cylinders shown in the picture) would act as P-junctions and the rest of the volumes as N-junctions. So they would be made of the same material but need to have different doping.
Is there a way to do that without basing the doping on an equation, as done in gmsh_diode3d.py?
Also, since I have these different volumes within the big structure that I want to keep track of, how exactly would I need to create them, meaning would they all be created as regions? Or maybe add a physical group with the total volume to make a region that, and then somehow keep track of the smaller components?

[Juan]

Hi @katzir

For step doping like that, it may be better to have a separate region for each. Creating a Physical Surface for all of the interfaces is tedious, but you can use a script like this:
https://github.com/devsim/devsim_misc/tree/main/gmsh

One issue I ran into with Gmsh and 3d meshes was the poor quality of some of the elements. In this paper I discuss some of the issues I ran into:
https://doi.org/10.36227/techrxiv.14129081.v3

I just want to you to be aware of this when working with complicated structures. I have some ideas how to fix this, which we can discuss this further if you encounter any issues.

[katzir]

Thank you for the resources and the heads-up!
I’ll take a look at those and try to work it out. I’ll definitely let you know if I run into any other issues.

[katzir]

Hi @Juan

So I tried using the script you mentioned, but I get an error when I input my MSH file (I also double checked that I can actually run the example in the link you sent, just to make sure I’m running this right):

The furthest back that I could trace the error from the functions called is in the run() function of test_convert.py (line 384). The way I understand it, it seems like yaml_map is populated in line 391 with the new interface ‘N_junctions_P_junctions’, which is then assigned to interface_names (in line 422), which is then passed into get_interface_map (line 424-425), which is the function where the error occurs (line 258). Since ‘N_junctions’ and ‘P_junctions’ are my only volume physical groups, I think it makes sense that this interface was created, but I’m not sure how to go about dealing with this.
Do you know why this is happening?

Also, since last time, I change my Physical Groups a bit, which now are (from .geo file):

Physical Surface(“Top”) = {27, 51, 74, 97, . . .};
Physical Surface(“Bottom”) = {1};
Physical Volume(“N_junctions”) = {1, 38};
Physical Volume(“P_junctions”) = {2, 3, 4, 5, . . .};

Using the following picture as reference, ‘P_junctions’ are the cylinder volumes, ‘N_junctions’ are the rest of the volumes, ‘Bottom’ is the blue plane, and ‘Top’ are the orange planes which are made up of the circles and the plane around them.

When using DevSim, I also tried having different regions for each of the volume Physical Groups, but ran into another problem. I made ‘Bottom’ and ‘Top’ to be contacts in the region created by the ‘N_junctions’, but I get an error that many of the coordinates in the ‘Top’ contact are not on that region. I get a similar error when I try to make the contact using the region created by the ‘P_junctions’.
Do you know if this is related to why I’m getting the error when I try to use test_convert.py? Or is this a completely new problem, and if so, do you know how I can fix it?

[Juan]

HI @katzir

I think the first issue you present is a bug. The script may not be handling the case where you have one physical group made up of multiple elementary ids for surfaces.

For the second issue, the script is not handling the case where you have one plane over multiple regions. You may be able to cut holes in the plane. Alternatively, I can make the script flexible to allow you to create a contact that ignores coordinates not on the region of interest.

It should be noted that having contacts touching each other or near interface may lead to convergence problems in the simulation. In this case, you may want to add surface rings between the plane and the surface circles for the p regions.

Would you be willing to share your geo file with me? I will not redistribute it without your permission. If possible please send it to info@devsim.com.

[katzir]

Hi @Juan

I just sent an email with my geo file.

Regarding the second issue, for the purposes of the project I’m working on, unfortunately it wouldn’t make sense to make holes in the plane of the contact or add something between the P-regions and the contact.

If you could make the script flexible with the contacts like you suggested, I would really appreciate it! If that were to be adjusted however, similar to gmsh_diode3d.py, if I were to make the material of the contacts to be metal and pass a current through the Top one, would it still affect both the P and N regions, since you said it would “ignore coordinates not on the region of interest”?
Because essentially this is my goal: to have a block of silicone of P and N junctions with metal contacts at the Top and Bottom, where there is a current passing through the Top contact, affecting both the P and N junctions.