GMSH plugin and ports

[simbilod]

Is your feature request related to a problem? Please describe.

The GMSH plugin is currently used by femwell, DEVSIM, Palace, and Elmer. These plugins rely on some automatic way to "tag" different parts of the Component to set boundary conditions.

A hack was implemented in the form of get_component_with_net_layers (now get_component_with_new_port_layers) to quickly enable this by converting polygons touching a list of ports into new layers, and hence new mesh entities. But this is not fully satisfactory as it results in a volume instead of a surface.

Describe the solution you'd like

We should leverage the new edgeports #135 instead. These could readily be extended to appear at the top/bottom of the simulation. Howeer, in their current form, edgeports would limit boundaries to be at the edge of the simulation.

This issue exists to discuss possible solutions.

[yaugenst]

Hey @simbilod, sorry for being ignorant about meshing details, but what prevents you from drawing a 2d rectangle that represents a port at arbitrary locations?

[simbilod]

It's easy to draw it

It's not easy, in the GMSH API, to draw it, and then make its mesh conformal with the (possibly arbitrary) 3D CAD that represents your geometry, while simultaneously keeping track of the "physical names" of your entities

[simbilod]

It might in fact be easier to define the 3D geometry, perform the meshing, and then tag mesh nodes in the 2D rectangle shape, where the port is to be defined. But then we lose control on the initial meshing parameters of the port (we could probably remesh it, however)

[yaugenst]

I see, thanks for the clarification! Yes, defining the geometry first is along the lines that I was thinking, because this is something that would also be compatible with a component base (#139, #142). And any additional logic required could then go on top of that. I don't know enough about meshing to judge whether this is a feasible approach, but just from a high-level view this would make things more uniform I guess.

[simbilod]

Geometry definition should be left to the solvers right? The component base should only provide polygon vertices extracted from the Component and LayerStack, right?

Different solvers may have different volume representations, but they can all take in coordinates like this

[yaugenst]

Yes that's what I mean, sorry if I wasn't being clear. I was mostly referring to what get_component_with_new_port_layers() in #140 is doing. It it takes a Component and a LayerStack and returns a modified LayerStack. If we move to a common interface, then no one except for the component base should come into contact with (and especially modify!) the raw LayerStack and Component, rather this should be handled (if really necessary) in its derived classes.

Some pseudocode for what I mean:

class MeshedComponent(SimulationComponentBase):
    @property
    def mesh(self):
        ...  # calculate mesh from port info and geometry vertices provided in base
        return mesh

c = MeshedComponent(component, layerstack)
my_mesh = c.mesh

Note however that probably we won't want a MeshedComponent class but rather components that relate to particular simulators, so something like ElmerComponent, MeepComponent etc., and the ones that require meshing would inherit from e.g. a GMSHComponent defined in the gmsh plugin (that itself derives from the SimulationComponentBase, for example.

[simbilod]

Yes that's what I mean, sorry if that was ambiguous. I was mostly referring to what get_component_with_new_port_layers() in #140 is doing. It it takes a Component and a LayerStack and returns a modified LayerStack. If we move to a common interface, then no one except for the component base should come into contact with (and especially modify!) the raw LayerStack and Component, rather this should be handled (if really necessary) in its derived classes.

Some pseudocode for what I mean:

class MeshedComponent(SimulationComponentBase):
    @property
    def mesh(self):
        ...  # calculate mesh from port info and geometry vertices provided in base
        return mesh

c = MeshedComponent(component, layerstack)
my_mesh = c.mesh

Note however that probably we won't want a MeshedComponent class but rather components that relate to particular simulators, so something like ElmerComponent, MeepComponent etc., and the ones that require meshing would inherit from e.g. a GMSHComponent defined in the gmsh plugin (that itself derives from the SimulationComponentBase, for example.

Yes I agree with this.

The "net_layer" thing was a hack: the GMSH module works by creating GMSH CAD entities from LayerLevel attributes (GDS layer + zmin, zmax, sidewalls, etc.), and using the LayerStack key as the GMSH physical name.

The physical name is critical, because it allows the simulator to act on all the mesh nodes associated with a physical name. So you can easily assign material values, set boundary conditions, and extract solutions from different parts of the mesh without having to slice by position or something not generalizable like that.

So what's the filthiest thing to do if you want to independently access two different things on the same GDS Layer? You create a new GDS Layer, put the polygons you want on it, and make a new entry in the LayerStack with the new name you want, and then your meshing algorithm works the same :)

[github-actions]

This issue is stale because it has been inactive for 60 days. Remove stale label or comment or this will be closed in 7 days.