Plugin material for an off-diagonal anisotropic material

Dear Support Team,

I would like to implement the following permittivity tensor as a plugin material.
source: Eq.1 and Eq.2

I know that Lumerical does not allow off-diagonal elements. Hence I applied a matrix transformation to diagonalize the permittivity as follows. (source:

The problem is that when the diagonalized tensor is converted into a time domain differential equation, an additional imaginary number “i” pops up as one of the coefficients in the equation.

Is there a workaround to get rid of the complex number, or should I incorporate the complex number into the plugin code (I am not sure if that is allowed. I mean can I import the “complex” library and convert every variable into complex variables, which would mean modifying the imaterialplugin.h file)?
But I guess the main algorithm calls the plugin functions separately for the real and imaginary parts of the field components. So there is no way to make the functions complex, right?

In case you wonder why I am not simply using a “sampled material” to import the dispersion, I am planning to have a time varying tensor (which cannot be done without custom material plugins) as a future work.


Hello @zh337,

Thank you for this interesting application. I double checked your math and it seems to work out, but there may be assumptions in place that make this implementation incompatible with our updates. Admittedly I do not understand the physics of these materials very well, but I suspect that this imaginary component is introduced into the update equations due to the non-reciprocity. It may be that there is a constraint equation on P that enforces.

$$ \ddot{P_x}(t) - i \omega_c \dot{P_x}(t) \in \mathbb{R} $$

Unfortunately the update equations would not be valid if you just imported the C++ complex library into the code. I don’t doubt that the the magnetized plasma permittivity dispersion, can be described by the non-diagonal tensor in the paper. It is likely possible to find an alternative representation. Maybe try solving for a very particular orientation/polarization, and then develop the general orientation once you are confident in that model?

It is helpful to remind ourselves that the fields can be completely described using classical physics and real values; although, we often use a complex representation this strictly for the sake of convenience. This page on on bi-isotropic media has some helpful information. Also you may want to refer to this paper which discusses the symmetry of the constitutive relations. Likely you will have to write update equations that couple the field components for this exotic class of materials.

Note that the flexible material plugin assumes.

$$ \vec{P} \propto \epsilon \vec{E} $$

Whereas in general the displacement and magnetic field need not be parallel to E, and H.

$$ P \propto D = \epsilon E + (\chi -i \kappa) \sqrt{\epsilon \mu}H$$

These other user also seemed to be interested in this application, maybe reach out to see if they were successful.

How to define a complex medium in Lumerical?
How to define a “bi-anisotropic” material in Lumerical FDTD?

Best Regards,

Dear @trobertson,

Thank you for the answer.
Yes you are right. The complex representation is merely a convenient form of writing the EM equations. The imaginary part in this particular case is to account for the 90 degree phase shift between Dx and Ey (or Dy and Ex). Perhaps, as you said, an alternative form of the tensor can be found which does not include imaginary numbers and deals only with real valued fields.
However, I am planning to use the plugin material in conjunction with Bloch boundary conditions (which must use complex fields in Lumerical). Therefore, I would necessarily need to include complex fields in my update equations. I would like to also note that the tensor equation I gave is already derived for a specific configuration (magnetic field is parallel to the magnetic bias and propagation direction is perpendicular to the bias, aka “Voigt configuration”). Hence, unfortunately, one cannot further solve it for a very particular orientation/polarization. Also there aren’t any assumptions regarding P to be real as you have speculated in your first equation. I would assume that the incompatibility stems mostly from the code workflow of Lumerical’s plugin material implementation.

At this point perhaps it is better to ask you how the update equations work with complex fields, rather than to ask how to implement the specific material.

The custom polarization update functions in the plugin C++ code deals only with floating point variables (U, V, Ex, Ey, Ez etc.). Hence one cannot simply input complex variables into these functions as we have discussed. However, in this case, how are these custom functions getting called when one uses time-complex fields (like when Bloch BC’s are used or when “always use complex fields” is enabled). I was thinking that maybe the real and imaginary parts of the variables are individually being sent into the functions and the resulting complex custom polarization would be the combination of these individual results.

Obviously for this to happen the equations have to be linear. But most of the time (actually almost always) they are not, so the above method would not work. Despite this, plugin materials do still work with time-complex fields (like when one uses Bloch BC’s with a Lorentz plugin material).

My question is how does Lumerical send the time-complex field variables into the custom update functions (which apparently only admit real variables). What is the code workflow behind this?


Hello @zh337,

The plugins use real fields and so are incompatible with bloch BC or setting ‘use complex fields’ to enabled. If you are using bloch BC at zero incidence angle then they would revert to periodic, but I believe that you would see errors if you increased the angle. It may work in the sense that you don’t get an error, but I would encourage you to convince yourself that the results are incorrect. As you suggest this is a result of how the code is implemented internally, but since this feature is not supported the only way of proceeding would be to submit this idea to IX. I believe that this would extend the capabilities of advanced material plugins and I would encourage you to do so.

Best Regards,

Dear @trobertson,

I see. Just out of curiosity, are “standard” optical permittivity material models (such as " Plasma (Drude)", " Debye", “Lorentz” [1]) also incompatible with time-complex fields (eg. bloch BC or setting ‘use complex fields’ to enabled)? I guess they use a similar type of polarization update functions. Or do they use a separate code workflow than the custom plugin material implementation workflow, which makes it possible to use time-complex fields in conjunction with these material models? I am quite acquainted with the documentation of Lumerical, and I never saw any notice or warning regarding this.

Now, I did a simple test to compare the “standard plasma (Drude)” model with a “plugin plasma (Drude)” that I just wrote. I excited a slab of plasma (one case with “standard plasma” another case with my “plugin plasma”) with a Bloch BC at a large incidence angle (70 degrees) and measured the transmission. The results were not identical but still close.
Does that mean “standard plasma” models and other models are also incompatible with time-complex fields? Or does it mean that the slight difference is due to the fact that the “plugin plasma” does not support time-complex fields, whereas “standard plasma” does?


Update: now I did another simulation with zero incidence angle (reverting to periodic BC and real fields).
Again, the results were not identical but still close. That means the discrepancy in the previous case was likely not because of the incompatibility with time-complex fields.

Any thoughts?


Hello @zh337,

The standard materials are implemented differently, than the plug-ins. The complex field values on the boundaries are associated with the phase and this may not be important when measuring the Transmission values? I believe that when you inject the complex fields into the plugin material the imaginary part is simply thrown away. I suppose, for some phenomenon this may not be important. I appreciate these results, but I do not believe that the topological material you cited can be described using strictly real fields. That being said you could probably get a flavor of the physics without including the off diagonal elements, and adapting Magnetic-Electric Lorentz material.

Again I think that it would be a nice feature, so I would support your IX request.

Best Regards,

Hello @trobertson,

Thank you for the response.

I have submitted the IX request months ago but I did not hear anything back. Do you perhaps know if there is any update with my submission?
In any case re-submitted the idea again.


Hello again @trobertson

I have submitted the idea again 3 weeks ago. But, again, I have not received any feedback at all regarding it (whether it will be opened for voting or not, or if it is not implementable etc.). Frankly, I do not think it will be implemented ever in the future (as the demand for this kind of future is probably negligibly small), but it would be great to see it open for voting or at least to get an feedback from the team regarding the idea.