Node: Plane Wave Source #63

New Issue

Closed

opened 2024-05-05 20:52:10 +02:00 by so-rose · 3 comments

so-rose commented

2024-05-05 20:52:10 +02:00

Owner

Simple infinite-extent plane wave.

Orient using injection axis as expanded enum, also spherical parameters.
Visually indicate the injection axis and spherical parameters w/a clever GN viz construction.

Simple infinite-extent plane wave. - [x] Orient using injection axis as expanded enum, also spherical parameters. - [x] Visually indicate the injection axis and spherical parameters w/a clever GN viz construction.

so-rose added the

physical

feature

labels 2024-05-05 20:52:10 +02:00

so-rose self-assigned this 2024-05-05 20:52:41 +02:00

so-rose referenced this issue

2024-05-05 20:52:50 +02:00

Implementation Tracker #27

so-rose added a new dependency 2024-05-05 20:53:18 +02:00

#27 Implementation Tracker

so-rose started working 2024-05-05 20:53:22 +02:00

so-rose stopped working 2024-05-05 22:17:28 +02:00

1 hour 24 minutes

so-rose commented

2024-05-05 22:17:49 +02:00

Poster

Owner

Node works fine - just getting the visualization right. Spherical coordinates should always be respected.

so-rose started working 2024-05-06 11:29:28 +02:00

so-rose commented

2024-05-06 22:09:31 +02:00

Poster

Owner

Well, Tidy3D's spherical coordinates made me cry...

I managed to reverse engineer (over the last 12 hours) how to interpret the orientation of the plane wave through (eventually) pure brute-force. Then, I implemented a (as far as I can tell) accurate representation of Tidy3D's spherical coordinate implementation in the nodes of the plane wave sim, in such a way that it can be reused for the other angled sources.

"Is it so important with a pretty visualization?" After trying to work a little without, I came to the conclusion that yes, it is absolutely important to know which direction the angled source is going. Unfortunately this required the reverse engineering, if I didn't want to check my work in the Tidy3D web interface all the time.

For each signed injection axis (\pm x,y,z), I manually clicked around in the Tidy3D web interface to determine:

0 polarization angle direction (\theta > 0)
\frac{\pi}{2} polarization angle direction (\theta > 0)
\theta^+ clockwise/counterclockwise orientation (co/contravariance of \theta to CCW axis-angle rotation on positive half-axis)
\varphi^+ clockwise/counterclockwise orientation (co/contravariance of \varphi to CCW axis-angle rotation on positive half-axis)
s polarization base direction (\theta = 0)
p polarization base direction (\theta = 0)
Polarization angle clockwise/counterclockwise orientation (\theta = 0)

By \theta = 0, I'm referring to Tidy3D's special-case designed so that when \theta=0, the polarization angle maps s to 0 and p to \frac{\pi}{2} in the particular expected directions.

Remarks on Implementation

In Tidy3D, the zenith is generally aligned to the injection axis in some way, while the azimuth seems to be chosen somewhat arbitrarily.

The mapping is not perfect, due in part to the special case, but also due to the difficulty of characterizing such a zenith-independent piecewise-discontinuous spherical coordinate system. Things will seem to match, until something jumps, and whether it's a deeper logical flaw or a new on-purpose discontinuity is not something that the documentation, nor the behavior itself, is so quick to speak up about.

While the propagation direction ended up generally matching up, the nuances of how the polarization angle is impacted by the rest of the parameters - including, for example, that there is an axis-dependent "jump" right as \theta is nudged above exactly 0, with a \pi offset.

I'm not sure if it's perfect yet, but I've checked all kinds of angles and I've been unable to find inconsistencies. Mind you, I constrained \theta and \phi to proper range (0..\pi-0.01 to simulate open end and -\pi..\pi).

With that said, there is a bug that seems to be a gimbal-lock thing (\frac{pi}{4} for all of \theta, \phi, and pol angle precisely seems to only within a narrow epsilon improperly offset the polarization angle by about 90 degrees), but its conditions are rare enough that the Ostrich methodology is an effective solution for now.

Well, Tidy3D's spherical coordinates made me cry... I managed to reverse engineer (over the last 12 hours) how to interpret the orientation of the plane wave through (eventually) pure brute-force. Then, I implemented a (as far as I can tell) accurate representation of Tidy3D's spherical coordinate implementation in the nodes of the plane wave sim, in such a way that it can be reused for the other angled sources. "Is it so important with a pretty visualization?" After trying to work a little without, I came to the conclusion that yes, it is absolutely important to know _which direction the angled source is going_. Unfortunately this required the reverse engineering, if I didn't want to check my work in the Tidy3D web interface all the time. **For each** signed injection axis ($\pm x,y,z$), I manually clicked around in the Tidy3D web interface to determine: - $0$ polarization angle direction ($\theta > 0$) - $\frac{\pi}{2}$ polarization angle direction ($\theta > 0$) - $\theta^+$ clockwise/counterclockwise orientation (co/contravariance of $\theta$ to CCW axis-angle rotation on positive half-axis) - $\varphi^+$ clockwise/counterclockwise orientation (co/contravariance of $\varphi$ to CCW axis-angle rotation on positive half-axis) - $s$ polarization base direction ($\theta = 0$) - $p$ polarization base direction ($\theta = 0$) - Polarization angle clockwise/counterclockwise orientation ($\theta = 0$) By $\theta = 0$, I'm referring to Tidy3D's special-case designed so that when $\theta=0$, the polarization angle maps $s$ to $0$ and $p$ to $\frac{\pi}{2}$ in the particular expected directions. # Remarks on Implementation In Tidy3D, the zenith is _generally_ aligned to the injection axis in some way, while the azimuth seems to be chosen somewhat arbitrarily. The mapping is **not** perfect, due in part to the special case, but also due to the difficulty of characterizing such a zenith-independent piecewise-discontinuous spherical coordinate system. Things will seem to match, until something jumps, and whether it's a deeper logical flaw or a new on-purpose discontinuity is not something that the documentation, nor the behavior itself, is so quick to speak up about. While the propagation direction ended up generally matching up, the nuances of how the polarization angle is impacted by the rest of the parameters - including, for example, that there is an axis-dependent "jump" right as $\theta$ is nudged above exactly $0$, with a $\pi$ offset. **I'm not sure if it's perfect yet, but I've checked all kinds of angles and I've been unable to find inconsistencies.** Mind you, I constrained $\theta$ and $\phi$ to proper range ($0..\pi-0.01$ to simulate open end and $-\pi..\pi$). With that said, there is a bug that seems to be a gimbal-lock thing ($\frac{pi}{4}$ for all of $\theta$, $\phi$, and pol angle _precisely_ seems to _only within a narrow epsilon_ improperly offset the polarization angle by about 90 degrees), but its conditions are rare enough that the Ostrich methodology is an effective solution for now.

so-rose referenced this issue from a commit

2024-05-06 22:11:21 +02:00

feat: implement plane wave node w/viz

so-rose closed this issue

2024-05-06 22:11:22 +02:00

so-rose stopped working 2024-05-06 22:11:22 +02:00

10 hours 41 minutes

so-rose commented

2024-05-07 09:57:36 +02:00

Poster

Owner

I made a bug report on Tidy3D: https://github.com/flexcompute/tidy3d/issues/1683

Reverse Engineered Table

Just for reference, here's the table:

	`+x`	`-x`	`+y`	`-y`	`+z`	`-z`
`\theta>0`: ax. `p_a=0`	`-y`	`-y`	`-x`	`-x`	`-x`	`-x`
`\theta>0`: ax. `p_a=0`	`-z`	`+z`	`+z`	`-z`	`-y`	`+y`
`\theta+` wind	`z` CCW	`z` CCW	`z` CW	`z` CW	`y` CCW	`y` CCW
`\varphi+` wind	`x` CCW	`x` CCW	`y` CW	`y` CW	`z` CCW	`z` CCW
`\theta=0`: ax. `p_a=0`	`+y`	`+y`	`+x`	`+x`	`+x`	`+x`
`\theta=0`: `p_a` wind	`x` CCW	`x` CW	`y` CCW	`y` CW	`z` CCW	`z` CW

I made a bug report on Tidy3D: https://github.com/flexcompute/tidy3d/issues/1683 # Reverse Engineered Table Just for reference, here's the table: | | $+x$ | $-x$ | $+y$ | $-y$ | $+z$ | $-z$ | |:-----------------------:|---------|---------|---------|--------|---------|---------| | $\theta>0$: ax. $p_a=0$ | $-y$ | $-y$ | $-x$ | $-x$ | $-x$ | $-x$ | | $\theta>0$: ax. $p_a=0$ | $-z$ | $+z$ | $+z$ | $-z$ | $-y$ | $+y$ | | $\theta+$ wind | $z$ CCW | $z$ CCW | $z$ CW | $z$ CW | $y$ CCW | $y$ CCW | | $\varphi+$ wind | $x$ CCW | $x$ CCW | $y$ CW | $y$ CW | $z$ CCW | $z$ CCW | | $\theta=0$: ax. $p_a=0$ | $+y$ | $+y$ | $+x$ | $+x$ | $+x$ | $+x$ | | $\theta=0$: $p_a$ wind | $x$ CCW | $x$ CW | $y$ CCW | $y$ CW | $z$ CCW | $z$ CW |