A nice feature of the previous iteration of this code was the ability to pass, for instance, 1D objects to a 2D mesh, and have them be conformal and properly tagged as physical. This can replace the current hack for boundary conditions, and allow e.g. sources and monitors to be defined.

This can probably be achieved here with recursive labeled entities

@HelgeGehring

https://github.com/simbilod/meshwell/blob/main/meshwell/samples/001_device.py seems to not work anymore after recent API updates

• Add base documentation with examples
• Improve documentation

makes gplugins docs fail

The changes in #21 seem to break the base_resolution part. Assuming the input is of the form

{"layer": {
    "SizeMax": ...,
    "DistMax": ...,
}}

without a resolution key, the lines in

Speedup the inner loop in _add_volume.
Ideas to try:

• Parallelise
• Numba
• Pybindings C++

It would be great, if the physicals which are defined using a port like metal2#e1 are still added to metal2

Currently, the mesh resolutions appear to work only for the main given entities and not the generated interfaces.
For example, in

resolutions = {
    "bw": {
        "resolution": 50,
    },
    'substrate': {
        "resolution": 50,
    },
    'bw___substrate': {
        "resolution": 1,
    },
}

The bw___substrate resolution is not taken into account.

Previous versions of this code had mesh size from a physical

Right now in here we only support constant characteristic length size according to the label name, see https://github.com/simbilod/meshwell/blob/main/meshwell/refinement.py

It would be nice to generalize to more types of resolutions settings

@nikosavola

Appears https://simbilod.github.io/meshwell/api/01_quickstart.html is failing to run

Collecting possible API improvements:

• Physical names could be entity attributes, as well as mesh_order, and use instead of OrderedDict?

Seems the meshing is not currently parallelized.
I think this can be done with just gmsh.option.setNumber("General.NumThreads", N). Not sure how parallelized the default algorithms are but should start here.

docs severely lag behind state of the package

@HelgeGehring

this would be useful if we wanted to generate multiple different meshes from the same resulting CAD, since sometimes the booleans take a while

It is very often the case that the we have thin layers in z with large x-y extent

It would be desirable to have a fine mesh in z, and coarser in x-y in these cases

Things to investigate:

• Structured extrusions (foregoing some flexibility with sidewalls)
• Anisotropic remeshing with mmg

It is required for some applications, after the initial meshing, to remesh according to the result of simulations

Earlier versions of this code used callbacks for this, but it is too slow and approximate, because it makes a new mesh every time. Would be great to remesh the existing mesh.

See for example:

• gmsh background mesh,
• mmg,
• DEVSIM example
• Go through skfem refinement
  

The desired API could be similar to above:

• user gives a grid of (x, y, z, lc) coordinates, with lc the desired "mesh size" at the x, y, z positions;

or

• user gives a grid of (x, y, z) coordinates where the existing mesh should be split

@SkandanC

New release has added OCC curve orientation, maybe we need to account for that

(1) We could wrap the gmsh GUI executable here, and script some useful commands (e.g. coloring entities by physical group)

(2) We could better develop notebook-based visualization

Add an argument for gmsh mesh format version.

This seems like a strange thing to do but, MFEM does not support gmsh formats newer than 2.2.

The current way of defining volumes "bottom-up" works great for small geometries

For geometries with a lot of entities, this can be very slow. We should investigate alternatives to speed this up:

• See if meshwell object definition can be parallelized
• Allow a formulation of the CAD through extrusions (ignoring arbitrary side profiles)

@HelgeGehring

Would be nice to be able to change the meshing algorithm from gdsfactory side. This would require making some sort of API here.

New interface breaks old tests, write new tests eventually

Meshwell meshing fails for me when running in Ray

    component.to_gmsh(
  File "/usr/local/home/nikosavola/dev/gdsfactory/gdsfactory/component.py", line 2548, in to_gmsh
    return xyz_mesh(padded_component, layer_stack, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/google/home/nikosavola/dev/gdsfactory/gdsfactory/simulation/gmsh/xyz_mesh.py", line 145, in xyz_mesh
    mesh_out = model.mesh(
               ^^^^^^^^^^^
  File "/usr/local/home/nikosavola/dev/meshwell/meshwell/model.py", line 289, in mesh
    gmsh.finalize()
  File "/usr/local/home/nikosavola/venv/gdsfactory/lib/python3.11/site-packages/gmsh.py", line 316, in finalize
    signal.signal(signal.SIGINT, oldsig)
  File "/usr/lib/python3.11/signal.py", line 56, in signal
    handler = _signal.signal(_enum_to_int(signalnum), _enum_to_int(handler))
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: signal only works in main thread of the main interpreter

The issue is documented in https://gitlab.onelab.info/gmsh/gmsh/-/issues/2399 and the solution is to use new initialization with gmsh.intialize(interruptible=False). This argument however is not in a release version of gmsh.

This would be useful for full-wave simulations with Palace

We should optimize the loop of cuts to better leverage the OCC parallelization

Currently, manual refinement is only possible on the physical entities

It would be good to add a new type of Prism/Polysurface that locally changes the mesh resolution settings, without disturbing the "physical" Prisms/Polysurface

Instanciating the intersection of these "refinement physicals" and the actual geometry (defining new _refined physicals) could be a simple hack to achieve this

Would be useful for better compatibility with femwell

@HelgeGehring