-
Notifications
You must be signed in to change notification settings - Fork 44
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
feat: flux and poynting properties for FieldProjectionCartesianData
#1874
Conversation
So actually I think this is going to produce the same result as the previous version (could you check?). I think the issue is that we are providing the total power going through the surface in all directions, while the user's expectation for a cartesian monitor would be to get the power that's normal to the plane, like we do for other field monitors. In the field projection cartesian monitor, this normal direction would be the @tomflexcompute fyi |
86d7626
to
16bf249
Compare
@momchil-flex yeah that's correct, they are the same. In particular, field projection power as implemented (before this) calculates But yeah we can probably close this |
Not only integrating over the area but taking the dot product of the S components with the surface normal, which is a bit inconvenient. If we don't change the definition of power, maybe add another method |
Yeah I think the point is that the cartesian projected data really looks like a regular FieldData, for which |
So should the user not call |
For angle monitor and k space monitor I think the original implementation of |
a86bed7
to
1b18a6d
Compare
FieldProjectionCartesianData
I added |
1b18a6d
to
1458823
Compare
Great, thanks. Could you try a real test where you place a FieldMonitor at some distance, and a cartesian field projection monitor to the same location, and compare the two .flux-es? There could be a small difference because of some of the colocation/integration details, but it should be almost the same. |
Note that the user-side field projector does not support I modified your script to use server-side projection, and I also modified the monitor to be 3D surrounding the box, because there could be some effects from the PML in your setup. Then I got
Increasing resolution to 30 yields
So generally, this seems good. I think the difference with resolution may be due to a couple things, like 1. the fact that fdtd field propagation is not the same as the analytical field propagation, and 2. details of the numerical integration on the far field plane. Here's the updated code:
|
1458823
to
ca53b91
Compare
Fixes #1870