Introduce SubpixelSpec to allow for selecting subpixel averaging methods on different materials

[weiliangjin2021]

New API

subpixel = td.SubpixelSpec(
    dielectric = True,
    metal = td.Staircasing()/td.VolumetricAveraging(staircase_normal_component=True),
    pec = td.Staircasing()/td.HeuristicPECStaircasing()/td.PECConformal(timestep_reduction=0.1),
)

Metal is defined as Re[eps]<1 at the central frequency.

You can still set subpixel=True/False:

• True using the default SubpixelSpec(): dielectric subpixel averaging on dielectric interface, staircasing on metal interface, and conformal (previously called Benkler) scheme on PEC;
• False: staircasing on any material interface.

TODO

• Fix failed adjoint tests, test_IO, etc.
• Update API in doc
• Various places validating subpixel field

Note

• The default subpixel method for PEC is now Benkler (renamed to MetalConformal). The default setting will decrease the time step size by 30%. But this deduction will only take effect if we find any material is PEC in scene.mediums.
• In Volumetric Averaging, it has a field staircase_normal_component. When True, apply staircasing if the field component is mostly normal to the interface, since volumetric averaging won't help there.

Open question:

• For dielectric materials, it's always worse to apply volume averaging. So currently, dielectric still only take boolean values. I'm not sure if it's better to be consistent with other materials (pec, metal) for dielectric to also take Staircasing and detailed subpixel method name.

[tylerflex]

I think the API looks pretty good. Nothing stands out to me as an issue.

One thing is that we should choose the class names carefully. Specifically,

BenklerSubpixel
HeuristicSubpixel

are both not clear from the title what exactly they are and when to use them. I'm not sure about the specific details, eg maybe these are commonly used names in the field, but if there are any more intuitive names for these, we should consider using them? Or even making up our own.

[weiliangjin2021]

One thing is that we should choose the class names carefully. Specifically,

BenklerSubpixel
HeuristicSubpixel

are both not clear from the title what exactly they are and when to use them. I'm not sure about the specific details, eg maybe these are commonly used names in the field, but if there are any more intuitive names for these, we should consider using them? Or even making up our own.

Good point. I have concerns about the names as well, but forgot to bring it up. E.g. Benkler is too specific. How about a general name ConformalSubpixel, since people usually refers to it as conformal mesh in RF?

Regarding Heuristic, how about HeuristicStaircasingSubpixel? @momchil-flex

[momchil-flex]

Yeah, I agree with both of those suggestions. Conformal is commonly used. Heuristic is just something Victor had implemented a long time ago that we are keeping for backwards compatibility. :D It is not in any way commonly known in the literature.

[weiliangjin2021]

One more question on names: is it necessary for each of them ending inSubpixel? StaircasingSubpixel and ConformalSubpixel sounds strange, because the two words in the former are contradictory; while the two in the latter mean the same.

[momchil-flex]

One more question on names: is it necessary for each of them ending inSubpixel? StaircasingSubpixel and ConformalSubpixel sounds strange, because the two words in the former are contradictory; while the two in the latter mean the same.

Yeah, I think dropping Subpixel makes sense.

For dielectric materials, it's always worse to apply volume averaging. So currently, dielectric still only take boolean values. I'm not sure if it's better to be consistent with other materials (pec, metal) for dielectric to also take Staircasing and detailed subpixel method name.

I think it's probably better in the long run yeah. You don't have to allow volumetric to be an actual option if it requires more effort on the backend. What should we call the dielectric subpixel?

[weiliangjin2021]

Still haven't figured out a good name for dielectric subpixel averaging, so it remains as boolean for now. Docstrings have been updated. Now the new API looks like this

subpixel = td.SubpixelSpec(
    dielectric = True,
    metal = td.Staircasing()/td.VolumetricAveraging(),
    pec = td.Staircasing()/td.HeuristicPECStaircasing()/td.MetalConformal(timestep_reduction=0.1),
)

@tylerflex how do I fix the failing test_IO.py that loads an incompatible tests/sims/simulation_sample.h5 and tests/sims/simulation_sample.json from 2.7.0rc1 and rc2?

[tylerflex]

hm, try running this script?
https://github.com/flexcompute/tidy3d/blob/pre/2.7/scripts/sample.py

[weiliangjin2021]

hm, try running this script? https://github.com/flexcompute/tidy3d/blob/pre/2.7/scripts/sample.py

Thanks, that fixes it.

[weiliangjin2021]

Sorry another question @tylerflex: it seems that allowing a simulation field to be the union of a basic type (e.g. bool in subpixel and float in run_time) and a class is causing issues in test_log here: the warning list is empty when subpixel or runt_time take an object although I can see the warning on screen. It's not empty if the two fields take bool/float.

[tylerflex]

Sorry another question @tylerflex: it seems that allowing a simulation field to be the union of a basic type (e.g. bool in subpixel and float in run_time) and a class is causing issues in test_log here: the warning list is empty when subpixel or runt_time take an object although I can see the warning on screen. It's not empty if the two fields take bool/float.

Hm, not sure about this, sorry. Maybe @dbochkov-flexcompute has some idea?

[dbochkov-flexcompute]

Sorry another question @tylerflex: it seems that allowing a simulation field to be the union of a basic type (e.g. bool in subpixel and float in run_time) and a class is causing issues in test_log here: the warning list is empty when subpixel or runt_time take an object although I can see the warning on screen. It's not empty if the two fields take bool/float.

It seems to be related to the fact that pydantic tries to initialize a field with all possible options, if no guidance for it is given. That is, adding discriminator=TYPE_TAG_STR into metal and pec fields of SubpixelSpec resolves the issue

[weiliangjin2021]

Sorry another question @tylerflex: it seems that allowing a simulation field to be the union of a basic type (e.g. bool in subpixel and float in run_time) and a class is causing issues in test_log here: the warning list is empty when subpixel or runt_time take an object although I can see the warning on screen. It's not empty if the two fields take bool/float.

It seems to be related to the fact that pydantic tries to initialize a field with all possible options, if no guidance for it is given. That is, adding discriminator=TYPE_TAG_STR into metal and pec fields of SubpixelSpec resolves the issue

That is working! thanks

[dbochkov-flexcompute]

looks good to me! just one thing: would it make sense to rename MetalConformal to PECConformal since it goes into pec: but not metal: field?

[weiliangjin2021]

looks good to me! just one thing: would it make sense to rename MetalConformal to PECConformal since it goes into pec: but not metal: field?

We plan to add good conductor handling in the near quarter (a new field good_conductor in SubpixelSpec). I hope I can reuse MetalConformal class in the field.

[weiliangjin2021]

looks good to me! just one thing: would it make sense to rename MetalConformal to PECConformal since it goes into pec: but not metal: field?

We plan to add good conductor handling in the near quarter (a new field good_conductor in SubpixelSpec). I hope I can reuse MetalConformal class in the field.

Now as I read more about good conductor subpixel, it's likely to have quite different fields compared to PEC-type conformal. In that regard, there is no need to share this class between PEC and metal, so it's a good idea to rename it to PECConformal.

[momchil-flex]

Few minor comments about the current code. Otherwise, two more questions to discuss further:

• for dielectric, should we avoid using boolean but define an explicitly named spec instead (also in view of defining different ones in the future)
• are we eventually going to have a good_conductor kind of field in SubpixelSpec too, and how is that going to interact with metal?

[momchil-flex]

I think we need to flip this message around and say what SubpixelSpec does; then say what setting subpixel=True corresponds to in terms of a SubpixelSpec (dielectric subpixel, everything else staircased).

[weiliangjin2021]

when subpixel=True, now conformal is also applied to PEC, as it is in general much more accurate than staircasing.

[weiliangjin2021]

• are we eventually going to have a good_conductor kind of field in SubpixelSpec too, and how is that going to interact with metal?

In the 1st release, we might just limit good_conductor to Medium type, as surface-impedance model is usually applied to approximate the permittivity as purely imaginary coming from DC conductivity. In the next step, maybe we can add a field to medium to indicate whether it's allowed to be handled as surface-impedance model. If allowed and the material has Im[ep]/Re[ep] larger than a threshold, it'll be approximated as Medium type at the central frequency.