Added NonlinearSusceptibility with chi3 support

[caseyflex]

Known limitations:

• Currently only supports non-dispersive Medium

[tylerflex]

Thanks @caseyflex, I think both of these will be super exciting to have. I suggest having @momchil-flex chime in specifically on how we do interpolation of the custom source time as I'm a bit concerned about edge cases using nearest interpolation. Also, is it possible to split this into two PRs? they seem quite separate no? or at least two commits if possible. Otherwise it will be a bit confusing to have both somewhat orthogonal changes in a single commit.

[tylerflex]

Regarding this:

Can we make this subclass something that could be either Medium or DispersiveMedium?

I dont see why not. currently the Kerr Medium assumes linear medium properties of vacuum? or is this a WIP?

[caseyflex]

CustomSourceTime moved here: #994

[caseyflex]

Regarding this:

Can we make this subclass something that could be either Medium or DispersiveMedium?

I dont see why not. currently the Kerr Medium assumes linear medium properties of vacuum? or is this a WIP?

Currently, it is a subclass of Medium, so permittivity and conductivity can be set, or take default values of vacuum. I wasn't sure how we wanted to make it be either a Medium or a DispersiveMedium. So that KerrMedium(chi3=1, permittivity=2) would work, but also KerrMedium(chi3=1, poles=poles) would work.

[tylerflex]

Hm, maybe we can stick with Medium as the superclass until someone requests dispersive nonlinear? Otherwise we could I guess consider two KerrMedium and KerrPoleResidue which both inherit from the abstract nonlinear medium and then Medium, PoleResidue respectively? For now probably just Medium is fine.

[tylerflex]

This looks good to me pending two minor rewordings, thanks @caseyflex!

[momchil-flex]

Looks good!

Backend supports dispersive KerrMedium but frontend currently does not. Can we make this subclass something that could be either Medium or DispersiveMedium?

This goes back to our discussion on slack today... It really does feel like our medium subclassing is becoming quite a mess. One option is to treat the nonlinear susceptibility (and the time-modulated permittivity in the future @weiliangjin2021 ) as something that can be added to any medium where it's supported, e.g.

td.Medium(permittivity=..., nonlinearity=KerrNonlinearity(chi3=1))

Then we can pick which media have a nonlinearity Field. In fact this could still be done through subclassing, something like

# this would probably still subclass from some abstract nonlinearity class
class KerrNonlinearity():
    chi3: float
    numiters: pd.PositiveInt

class AbstractNonlinearMedium(AbstractMedium, ABC):
    nonlinearity: Union[KerrNonlinearity, ...]

# now AbstractNonlinearMedium can be added anywhere we support, e.g.
class Medium(AbstractMedium, AbstractNonlinearMedium):
    ...

class DispersiveMedium(AbstractMedium, AbstractNonlinearMedium, ABC):
    ...

In the case of nonlinearity, can it pretty much be added on top of any medium, including custom?

[momchil-flex]

Note: this is just a suggestion, not saying you should implement this right now. But we should decide on something (@tylerflex )

[momchil-flex]

Whatever way we introduce the nonlinear medium, we should make sure the mode solver issues a warning that the nonlinearity is not used if someone tries a mode solve in a plane that contains a nonlinear medium. I forget, how do we handle 2D media in the mode solver now?

[tylerflex]

This goes back to our discussion on slack today... It really does feel like our medium subclassing is becoming quite a mess. One option is to treat the nonlinear susceptibility (and the time-modulated permittivity in the future @weiliangjin2021 ) as something that can be added to any medium where it's supported
But we should decide on something (@tylerflex )

In principle it makes sense to be able to add nonlinearity to any medium. However, with the way things are set up with subclassing, I think it might make things a bit complicated. My thinking is just make KerrMedium [and eventually KerrDispersiveMedium], let the class type do the work regarding what properties the medium has, but eventually we should just separate all of the categories of effects in the medium:

• Linear properties
• Nonlinear properties
• Dispersion
• Time dependence

into their own fields of a Medium class, each determined by their own specs, and handle custom medium by overloading any fields with data arrays. but this seems like a 3.0 change.

I think how Casey has it here is good for now and we can always add the nonlinearity fields into the AbstracMedium class without breaking backwards compatibility if we change our minds?

[caseyflex]

Whatever way we introduce the nonlinear medium, we should make sure the mode solver issues a warning that the nonlinearity is not used if someone tries a mode solve in a plane that contains a nonlinear medium. I forget, how do we handle 2D media in the mode solver now?

We use volumetric_structures in Simulation.epsilon_on_grid and related functions, so the mode solver should work correctly for 2D materials. To handle nonlinear case, I'll put a warning in Simulation.epsilon_on_grid. Of course there's no way to know epsilon a priori for nonlinear materials.

[caseyflex]

This goes back to our discussion on slack today... It really does feel like our medium subclassing is becoming quite a mess. One option is to treat the nonlinear susceptibility (and the time-modulated permittivity in the future @weiliangjin2021 ) as something that can be added to any medium where it's supported
But we should decide on something (@tylerflex )

In principle it makes sense to be able to add nonlinearity to any medium. However, with the way things are set up with subclassing, I think it might make things a bit complicated. My thinking is just make KerrMedium [and eventually KerrDispersiveMedium], let the class type do the work regarding what properties the medium has, but eventually we should just separate all of the categories of effects in the medium:

• Linear properties
• Nonlinear properties
• Dispersion
• Time dependence

into their own fields of a Medium class, each determined by their own specs, and handle custom medium by overloading any fields with data arrays. but this seems like a 3.0 change.

I think how Casey has it here is good for now and we can always add the nonlinearity fields into the AbstracMedium class without breaking backwards compatibility if we change our minds?

Yeah, let's save the restructuring for 3.0. I'll leave it this way with KerrMedium for now, and introduce other classes like KerrDispersiveMedium as needed later.

[tylerflex]

This will be a better way to do things, I can already tell. Thanks @caseyflex !

[tylerflex]

Looks good to me. Can @dbochkov-flexcompute and @weiliangjin2021 take a quick look to make sure this is in line with our 3.0 thinking regarding mediums?

[dbochkov-flexcompute]

Looks good to me too!

[caseyflex]

I added AbstractNonlinearSpec for convenience later, and I also changed AbstractMedium.nonlinear_spec to take NonlinearSpecType, but then validate it as needed for different medium types. I think this addresses Daniil's concern and is more robust for the future.

I also reintroduced the cap on numiters, which was needed based on benchmarking results

[tylerflex]

Approve pending the units kwarg in pd.Field(). thanks @caseyflex