Medium Evaluations

[smartalecH]

A first attempt at adding medium evaluation functionality (see #415).

Added the function, chi1, that evaluates a susceptibility at a given frequency point. An optional conductivity term can be passed (defaults to 1).

Once we add more features, I'll work on a SWIG interface.

[stevengj]

I would do std::complex<double>(-freq*freq, gamma*freq) here rather than sqrt(-1).

[stevengj]

Merge conflict. Can we have a test?

[stevengj]

Fixed the merge conflict. A test might be tricky to implement before we have a higher-level interface that gets ε(x,ω) or similar.

[smartalecH]

Thanks for the conflict fix. I agree, it makes more sense to implement a test with slightly more functionality.

On that note, which direction would you like to go from here?

From a python perspective, it would be great to be able to do the following:

from meep.materials import SiO2
freq = np.linspace(1,2,100)
eps  = SiO2.getEps(freq)

where getEps is obviously a member function of the Medium() class and loops through all of the defined susceptibilites and returns the relative permitivity (similar to what you proposed).

If we develop some simple C++ functions to do this and simply wrap them, I'm hoping we can use the same C++ functions to build mode sources and perform eigenmode decomposition with dispersive materials.

[stevengj]

I agree that it would be nice to have this higher-level functionality.

We might end up having to copy these χ(ω) formulas to more than one place, however, because when you have a Medium object in Python you haven't yet instantiated a susceptibility object.

[smartalecH]

As suggested, I copied the formulas over directly to the Python interface. I compared the MEEP output with the corresponding refractiveindex.info database, and they appear to align really well.

Loading the refractive index data is as easy as the following:

    from meep.materials import Ag, Au, Cu, Si
    wavelength = np.linspace(1/f0,1/f1,1000)
    freq = 1/wavelength
    eps  = Au.get_eps(freq)

get_eps() outputs a list of Vector3 objects to work with anisotropic materials. It takes into account the diagonal of the permittivity tensor and the conductivity tensor.

I've attached the script and data used to generate the above plot.
Archive.zip

[smartalecH]

My latest commit modifies the get_chi1inv routine to account for possible structure_chunk susceptibilities (so long as the susceptibility has a chi1 function defined). This new functionality enables dispersion compensation within the mode source and mode expansion features for "arbitrarily" dielectric materials only (i.e Si, SiO2, etc.).

In order to enable all materials, including metals, MPB's eigenmodemode solver would need to change slightly.

I'm working on a number of tests to verify:

Test 1
I create a simulation domain with a uniform dispersive medium and find the eigenmode k vectors for a variety of omegas for an arbitrary subdomain. With the calculated k vectors and the corresponding omegas, I find the effective index, which simply corresponds to Silicon's index of refraction (since there is no geometric dispersion). I compare it to the analytic refractive index profile (labeled 'Python'). As seen below, the results align well.

Test 2
I form a typcial silicon photonic waveguide (500nm width, 220 nm thickness) and find the effective index across the frequency band. I compare the results with a corresponding Lumerical simulation. While the results don't align perfectly, these kinds of simulations are typically sensitive to the mesh type and resolution.

I'm working on extracting the S parameters of a silicon photonic device from the SIEPIC toolbox (like the DC tutorial) and comparing them to the previously calculated results. This is my ultimate goal, and should attract the attention of several PIC designers. I'm debugging some weird issues that arise with higher resolutions.

cc @stevengj @HomerReid

[coveralls]

Coverage decreased (-0.2%) to 82.226% when pulling c4ac3cd on smartalecH:susceptibility_eval into 8e409b7 on stevengj:master.

[stevengj]

I just merged a PR #662 that reformats everything with clang-format, which creates lots of conflicts.

To rebase this PR onto master without having to deal manually with these formatting conflicts, follow the exact procedure given in the instructions of #662.

[stevengj]

In the short term, can we at least pull out the Python portion of this PR as a separate PR that we can merge?

[smartalecH]

Working on C implementation in a separate pull request. Will update with more details.