Hi Floris,

can you make a new release with pydantic2?

Currently meow fails complaining about the A matrix being non-square here:

This can be solved as shown here:
https://github.com/Jan-David-Black/meow/tree/lstsq

which is analogous to the approach by emepy (taking the pseudo-inverse):
https://github.com/BYUCamachoLab/emepy/blob/b22bd7e07a58b50d65be75569e5269640cf3bd4e/emepy/models.py#L575

In my current branch sax however refuses to work with the resulting s-matrices and I dont really know why...
It just spits out an empty dict.

The ipython kernel crashes without an error message when specifying any num_pml unequal to (0,0) and using compute_modes subsequently on an M1 mac.
I suspect there is an incompatibility between the Tidy3D FDE solver and m1 silicon. I have however not yet traced back the origin of the crash.

The issue looks similar to microsoft/vscode-jupyter#9741
However, I do not run out of memory while the kernel crashes.

When visualizing cells I get the following error:

The number of FixedLocator locations (3), usually from a call to set_ticks, does not match the number of ticklabels (4).

Furthermore we seem to not provide a shading parameter to pcolormesh (almost everywhere). With newer versions of matplotlib it seems to assume flat, which I don't think is what we want. We rather need nearest (e.g. for plotting the eps distribution)

How can we fix the gdsfactory plugin to work with latest version of meow?

now that gdsfactory and tidy3d transitioned to gdstk what do you think of transtioning meow to gdstk?

gdstk is faster to install as we have built wheels for it

We could use a similar approach like emepy:
https://github.com/BYUCamachoLab/emepy/blob/b22bd7e07a58b50d65be75569e5269640cf3bd4e/emepy/mode.py#L622

or we could determine the portion of power in (or close to) the PMLs

Hey @flaport,
where did you download the material data, that is part of meow so far?
As far as I can see the download from refractiveindex.info does not include the imaginary part of the refractive index.

Improve Continuously Varying Cross-sectional Subcell (CVCS) method for tapers

How can we sweep the length of a taper?

import gdsfactory as gf
import numpy as np
from gdsfactory.simulation.eme import MEOW

layerstack = gf.tech.get_layer_stack_generic()

filtered_layerstack = gf.tech.LayerStack(
    layers={
        k: layerstack.layers[k]
        for k in (
            "slab90",
            "core",
            "box",
            "clad",
        )
    }
)


lengths = np.array([1, 20, 60, 100])
T = np.zeros_like(lengths, dtype=float)

for length in lengths:
    c = gf.components.taper(width2=10, length=length)
    c.plot()

for i, length in enumerate(lengths):
    c = gf.components.taper(width2=10, length=length)
    eme = MEOW(component=c, layerstack=filtered_layerstack, wavelength=1.55)
    sp = eme.compute_sparameters()
    T[i] = np.abs(sp['o1@0,o2@0'])**2

import matplotlib.pyplot as plt

plt.plot(lengths, T, '.')
plt.title('Fundamental mode transmission')
plt.ylabel('Transmission')
plt.xlabel('taper length (um)')

I would expect a short taper would have more loss

On Mac OSX M1 processor, I got as far as the visualization step, then received the following error

mw.visualize(structs, scale=(1, 1, 0.2))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/lukasc/gdsfactory/lib/python3.9/site-packages/meow/visualize.py", line 95, in visualize
    return _visualize_structures(objs, **kwargs)
  File "/Users/lukasc/gdsfactory/lib/python3.9/site-packages/meow/structures.py", line 48, in _visualize_structures
    geometry=[s._trimesh(scale=scale) for s in _sort_structures(structures)]
  File "/Users/lukasc/gdsfactory/lib/python3.9/site-packages/meow/structures.py", line 48, in <listcomp>
    geometry=[s._trimesh(scale=scale) for s in _sort_structures(structures)]
  File "/Users/lukasc/gdsfactory/lib/python3.9/site-packages/meow/structures.py", line 33, in _trimesh
    return self.geometry._trimesh(
  File "/Users/lukasc/gdsfactory/lib/python3.9/site-packages/meow/geometries.py", line 256, in _trimesh
    prism = extrude_polygon(poly, self.h_max - self.h_min)
  File "/Users/lukasc/gdsfactory/lib/python3.9/site-packages/trimesh/creation.py", line 194, in extrude_polygon
    vertices, faces = triangulate_polygon(
  File "/Users/lukasc/gdsfactory/lib/python3.9/site-packages/trimesh/creation.py", line 458, in triangulate_polygon
    faces = _tri_earcut(vertices, rings).reshape(
  File "/Users/lukasc/gdsfactory/lib/python3.9/site-packages/trimesh/exceptions.py", line 48, in failed
    raise exc
  File "/Users/lukasc/gdsfactory/lib/python3.9/site-packages/trimesh/creation.py", line 34, in <module>
    from mapbox_earcut import triangulate_float64 as _tri_earcut
ModuleNotFoundError: No module named 'mapbox_earcut'

easy fix:

pip install mapbox_earcut

perhaps you can add it as a dependancy.

Hey @flaport,
I am a big fan of meow. Besides its EME capabilities, I think it makes quite a lot of sense to use it as an abstraction layer over different FDE algorithms, as switching between "simulation backends" can otherwise necessitate significant code rework (for the structure definition alone). Maybe even interesting for gdsfactory (@joamatab) (We could also build a femwell backend for meow). With that in mind, there is a couple of things I'd like to add:

• Poynting flux: auxiliary properties to calculate the poynting flux in x,y and z.

$$ \vec{P} = \vec{E} \times \vec{H} $$

An implementation using np.cross is probably most sensible. Addressed in #7.

• Effective mode area: another auxiliary measure I tend to use relatively frequently. It is not that well defined/ agreed on in literature but I would use the definition as in lumerical's implementation:

$$ A_{eff} = \frac{\left(\int|\vec{E}|^2dA\right)^2}{\int|\vec{E}|^4dA} $$

• Implementation of the field energies for irregular meshes: At this moment the modal energies are computed by summing over the energy densities, which for equidistant meshes leads to a value proportional to the actual modal energy.:

def electric_energy(mode: Mode) -> float:
    """get the electric energy contained in a `Mode`"""
    return electric_energy_density(mode).sum()

The proportionality constant can be eliminated by normalization, as it is not dependent on the field distribution. This does however not hold for non-equidistant meshes, as finely meshed regions are over-emphasized compared to the more coarsely meshed regions. I would therefore suggest dividing by the mesh step in x and y before summing or even better do a proper integration over the energy densities e.g. using nested np.trapz evaluations.

• I would love to be able to also easily get the group index. That would however require multiple frequency points to do a finite difference differentiation on the effective index with frequency/wavelength, right?