tidy3d
tidy3d copied to clipboard
flexcompute
Server side mode solving couldn't find the microstrip mode while the local mode solver did
I think we briefly discussed about this issue a while back but I lost track of the status of the issue. To recap, when modeling a microstrip line, the local ModeSolver finds the correct mode
However the server-side mode solving doesn't seem to find any mode thus nothing is injected in the ModeSource, resulting in field_decay = 0 in the entire simulation.
See the attached notebook:
RFCoupledLineFilter.zip
We found that it works when the number of PML layers is reduced, right?
In the near future I'll go through this notebook again and tabulate exactly when it does and does not work, so we can keep track of the various knobs that need to be turned right now. I'm not sure I'd classify this as a bug though, it seems to me to be related more fundamentally to the underlying methods?
I think @weiliangjin2021 should test this as part of his refactor / unification of the backend mode solver.
@tomflexcompute Regarding "server-side mode solving", do you mean the webservice, or the one with tidy3d backend solver?
@tomflexcompute Regarding "server-side mode solving", do you mean the webservice, or the one with tidy3d backend solver?
It's whatever the ModeSource is using to compute and inject the mode.
We found that it works when the number of PML layers is reduced, right?
I tested it a bit more and it seems still quite tricky to get the correct modes with pml layer number. Only some specific combination works for me.
Aside from issues related to fundamental mode solver method, "nothing injected" is a separate issue. The backend mode solver does find a mode, but the mode has n_eff = 0. In this case, k_eff will not be computed correctly here. Instead, k_eff should be np.sqrt(-vre). And because n_eff=0, so that the flux is 0, the normalization here will lead to "NaN" modal field profile, and therefore you see no injection in the simulation. So maybe let's at least fix those issues before resolving the more fundamental problems?
Are there any physical situations in which n_eff = 0 or zero-flux modes will actually need to be injected? Like, even if the fields were not NaN, it would have been a completely spurious mode injected.
Are there any physical situations in which n_eff = 0 or zero-flux modes will actually need to be injected? Like, even if the fields were not NaN, it would have been a completely spurious mode injected.
Yeah, cannot think of any in mode source, but might be relevant in mode monitor?
I think currently the important thing to check is that this mode can be found in the backend mode solver (and hence also in the remote once they are unified to always produce the same results). Then the discrepancy with what the local solver produces is not great (e.g. if it's a matter of mode_index setting), but we do warn users using the local solver that they should use the remote instead.
Now that the mode solver has been reorganized to always be the same between remote mode solver call and tidy3d internal mode solving, should we close this? @tomflexcompute @shashwat-sh @weiliangjin2021
This issue is tagged as 2.4 please someone comment on if something still needs to be done.
My understanding is that there were two separate issues:
- Physics: the mode solver has issues related to PECs which aren't necessarily resolved by changing the number of PML layers
- Different mode solvers being used in different cases
The second one seemed resolved, and the first one is probably not a straightforward thing, and is not something we had planned to address in 2.4, I think?
If the above is correct, then I think it might be a good idea to keep this issue open until we address the first point? But tag it for a later release / backlog?
what's the status on this?
Still waiting for better 2D PEC support I think.
what's the status on this?
Still waiting for better 2D PEC support I think.
I think it's resolved once we add mesh override structures on the PEC interface. I made a new issue for this.
Does the grid size have to be equal or smaller than the metal thickness?
Reason for backend mode solver failure:
- The PEC structure is much thinner than the grid size. The base of the PEC structure sits on the primal grid, but the dielectric substrate is added the last, which overrides the PEC base. So backend doesn't see any PEC materials at all.
Two ways to fix this:
- Shuffle substrate to the beginning of the structure list, so at least backend assigns the grids on the base as PEC
- Add mesh override structures, e.g.
td.MeshOverrideStructure(
geometry = td.Box(center=(0,0,h_trace/2), size=(td.inf, td.inf, h_trace)),
dl = (None, None, h_trace),
)
We should automate the 2nd approach. I think @dmarek-flex has some functionality in smatrix plugin already.
Isn't the fact that the substrate overrides the PEC at the primal grid a problem even beyond meshing? So just adding a mesh override won't fix this?
Or, at least in the limit when the PEC sheet is a 2D medium. We may need some validations to avoid confusion when people don't order their structures correctly? Do I remember correctly that in the original handling @caseyflex was always reshuffling 2D medium structures to the end of the list when doing volumetric discretization? Such that actually a 2D medium cannot be erased by a structure? Is this still going to happen or what's the thinking?
Isn't the fact that the substrate overrides the PEC at the primal grid a problem even beyond meshing? So just adding a mesh override won't fix this?
When adding override structures, the top of PEC structures will be on the primal grids. So even though the base is still overridden, the backend finds PEC from the top.
Although I think in some cases even volumetric PEC may be a problem. In this particular case, we're looking for modes above, so the fact that the bottom PEC is overwritten is probably ok. But in other cases (e.g. if we were looking for a mode inside the substrate in this example) it would be wrong, right? Well at the very least the the non-PEC domain will look one pixel larger.
We may need some validations to avoid confusion when people don't order their structures correctly?
You are right, currently 2D PEC has the same issue. The structure list is not reshuffled and 2D PEC is completely overridden by substrate. @dmarek-flex that's the case in the current implementation, right?
Although I think in some cases even volumetric PEC may be a problem. In this particular case, we're looking for modes above, so the fact that the bottom PEC is overwritten is probably ok. But in other cases (e.g. if we were looking for a mode inside the substrate in this example) it would be wrong, right? Well at the very least the the non-PEC domain will look one pixel larger.
That's probably fine with PEC subpixel.
We may need some validations to avoid confusion when people don't order their structures correctly?
You are right, currently 2D PEC has the same issue. The structure list is not reshuffled and 2D PEC is completely overridden by substrate. @dmarek-flex that's the case in the current implementation, right?
Although I think in some cases even volumetric PEC may be a problem. In this particular case, we're looking for modes above, so the fact that the bottom PEC is overwritten is probably ok. But in other cases (e.g. if we were looking for a mode inside the substrate in this example) it would be wrong, right? Well at the very least the the non-PEC domain will look one pixel larger.
That's probably fine with PEC subpixel.
The structure list is not shuffled as far as I know.
I think that is a correct handling, we shouldn't reshuffle, I just wonder if any validation/warning is needed. But I am not sure what to validate exactly, I think we might just have to take this as a bad setup by definition (put 2D medium first, then put substrate) but without explicitly warning.
Yeah, no reshuffling is done, this seems to be the desired behavior. There might be some situations we could detect and warn about, but I'm not exactly sure about it.
I have been looking into this issue. At the moment I experience two problems using the backend solver.
-
If discretization is improper, the PEC is missed completely and no guided mode is found. This is easy to fix with a proper use of override structures in the
GridSpec. Although this is manual right now. -
Another issue is that the placeholder value of permittivity used for PEC materials is very large, resulting in a poorly conditioned matrix describing the eigenvalue problem. The backend uses MUMPS, which seems to be susceptible to this issue, and for certain frequencies/scenarios will fail and report that the matrix is close to singular. The computed error is also quite large even when the eigenvalues are found.
The second problem can be fixed by using a double precision version of the backend solver, which fixes the abort and also the accuracy problem. Another way is by setting MUMPS to use static pivoting, which runs but it still is very inaccurate. A longer term fix would be to remove the degrees of freedom corresponding to electric field in PEC structures by deleting rows and columns associated with these electric field positions.