Skip to content

Fix bug when symmetry + non-symmetric boundary conditions are defined #2429

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 8, 2025

Conversation

momchil-flex
Copy link
Collaborator

This fixes a bug a user encountered which was brought to my attention by @FilipeFcp. Basically, when a simulation is created with symmetry applied along a given axis, but with boundary conditions that differ on the left and right side, physically we just ignore the left side. However, in the case of PML/Absorber boundaries with a different number of layers, the simulation grid that would be created would still use the left-side number of layers, and create a non-symmetric grid on which the "expanded fields" are defined.

The initial fix I tried (the code change here) just fixes the grid generation to use whatever number of layers is on the right. This fixes the issue that was observed in the recorded field data, however I realize that the current state can still be kind of confusing. For example, if I plot such a simulation, I get this:

image

Obviously something is going wrong here too as the overlaid "symmetry region" extends into the large absorber region on the right. Ideally, if we are neglecting the boundary definition on the left, we should actually incorporate this everywhere, and e.g. display the simulation with the right-side boundary on the left, too.

I'm afraid doing this automatically may be a bit frustrating though. For example, one option is to create a _boundary_spec property that mirrors boundary_spec, but replaces any minus-side boundaries with the plus-side ones, if a symmetry is applied - then use this everywhere internally. The issue though is that what is written to the json will not correspond to what is e.g. displayed, which can again be confusing. Maybe better is to take the route of introducing a validator that would modify the boundary_spec upon creation - but might that be confusing to the user too? Meaning that their input will be modified - but in some sense, it will be "made right".

The last alternative is to just add a validator to require that the user makes the boundary specs symmetric, if symmetry is applied. More strict from a user perspective, but at least fool- and confusion-proof.

After writing all this out, maybe the best is to add the dynamic validator that modifies boundary_spec if needed. What do you think @yaugenst ?

@FilipeFcp
Copy link
Contributor

Hi @momchil-flex,
In my opinion, users shouldn't be allowed to create this kind of configuration.

In this specific case, I believe the user intended to apply absorbers on both sides but simply assigned it to one side without realizing it. So maybe just don't allowing it, with a clear error message would be a good option.

@momchil-flex
Copy link
Collaborator Author

I guess that makes sense. I will work to update it in that direction unless @yaugenst has a different commetn.

@yaugenst-flex
Copy link
Collaborator

Yeah I agree with @FilipeFcp. I think allowing this can have a lot of unintended consequences. Physically the simulation is not symmetric in these cases so I'm not sure if we want to introduce a bunch of additional logic just to "fix" it after the fact (and we can only ever guess what the user intended).

@momchil-flex momchil-flex force-pushed the momchil/symmetry_bcs branch from 791072b to 0a5c840 Compare May 7, 2025 12:07
@momchil-flex momchil-flex requested a review from yaugenst-flex May 7, 2025 12:07
@momchil-flex
Copy link
Collaborator Author

Ok, I've updated it as discussed. I guess for completeness let me put here the reasoning why I was considering "fixing" the setup (but, generally, I agree that just validating it out as done here is likely best).

  • We already "disregard" any e.g. structures that are in the left symmetry space. When a user does a plot, those geometries would be shown. But if they are not symmetrically defined, it would not matter (the plot will be wrong in that sense) as physically the geometries in the right space are symmetrically applied. Or rather, we only compute fields in the right space, so nothing in the left space matters.
  • Some other tools consider the symmetry to be a boundary condition in itself, so you cannot simultaneously define a symmetry and a boundary condition on the left.

@momchil-flex momchil-flex merged commit 0ce2f84 into develop May 8, 2025
29 checks passed
@momchil-flex momchil-flex deleted the momchil/symmetry_bcs branch May 8, 2025 14:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants