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

[weiliangjin2021]

The docstrings are yet to be written. Before that, it'll be good to see if the new API looks reasonable.

One 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.

Note:

• The default subpixel method for PEC is now Benkler. 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.

[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

[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.

[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.