Mode normalization in mode/solver.py introduces phase shift

[l-berg]

tidy3d/tidy3d/components/mode/solver.py

Line 1334 in 5a41d86

norm_factor = 1.0 / np.sqrt(self_dot)

EigSolver's _normalize_modes normalizes each mode's self-dot to +1. For backward modes (direction="-") this is negative, so it multiplies the entire mode by ±i via the sqrt. The effective index is unaffected, but the fields no longer follow the usual phase convention (real transverse components for lossless modes).

Potential fix: normalize the self-dot to −1 for backward modes, keeping the norm factor real.

            # Normalize self-dot to +1 for forward modes, -1 for backward modes
            target = -1.0 if self_dot.real < 0 else 1.0
            norm_factor = 1.0 / np.sqrt(self_dot / target)

Is there a reason for strictly normalizing to +1, or are you happy with me creating a PR?

[momchil-flex]

Thanks for pointing this out. I think this is for the most part a boundary ambiguity around EigSolver - it looks like a public class, but for the large part / original intention was to use this internally. The officially supported normalization path is through ModeSolver / ModeSolverData, where backward modes are already handled with a signed self-overlap normalization. EigSolver._normalize_modes() is a lower-level implementation step used before degenerate-mode orthogonalization, and its +1 convention is tied to that internal overlap-basis construction. In fact as far as I can tell, before this was introduced there was no special normalization applied, so the fields from EigSolver could have come out with arbitrary phase, although probably that was not the case in typical cases because the scipy modes would come out relatively deterministically.

A PR changing only the line that you point out would be dangerous as it was introduced on purpose for the degenerate mode handling. We have some backend tests we can run about this, but I don't think it's top priority as the modes can always be renormalized and the output of EigSolver was previously not expected to come with a meaningful gauge. fyi @dmarek-flex if you have more to say.

[dmarek-flex]

@l-berg Yea, it normalizes to 1 for the degenerate-mode orthogonalization step, but later _process_fields should be called which should fix the phase issue. Are you interacting with compute_modes directly and skipping _process_fields ? If not, it might be an issue.