-
Notifications
You must be signed in to change notification settings - Fork 33
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
Implement the Poynting vector calculation #115
Merged
HelgeGehring
merged 13 commits into
HelgeGehring:main
from
lucasgrjn:implement_eq_eff_area_article
Feb 21, 2024
Merged
Changes from 8 commits
Commits
Show all changes
13 commits
Select commit
Hold shift + click to select a range
890e65b
feat: add calculate_poynting to Mode
lucasgrjn d5443de
doc: implement Poynting plot for effective_area example
lucasgrjn e7615e0
fix: black refactor
lucasgrjn bb320ee
feat: poynting calc with use the same element as solved Ez
lucasgrjn dc4eb93
feat: add poynting as a Mode (cached) property
lucasgrjn b12affe
refactor: black compliant
lucasgrjn 560f627
fix: change basis name to make it more clear
lucasgrjn 5ab12bd
feat: add poynting component as Mode properties
lucasgrjn eaa5a36
fix: restore ElementTriP2 instead of Quad2 for order=2
lucasgrjn 98cb853
feat: for poynting, auto extraction of Ez elements
lucasgrjn 9f0397a
use vectorbasis instead of three individual bases for the poynting ve…
HelgeGehring bdcd730
Merge pull request #1 from HelgeGehring/use-vectorbasis
lucasgrjn 464df19
add integrals for (1) and (3)
HelgeGehring File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant as this line we should reuse the element for Ez of the basis, i.e.
would brobably do it.
Even better would be to have here a
as this way we could directly project using just one basis. This way we'd just have one field to return.
Some background:
ElementDG converts Elements in their discontinous counterpart. For example, ElementTriP1 has its degrees of freedom (DOFs) on the nodes around (Tri->Triangles->3 nodes/dofs).
As those nodes are shared with the neighboring triangles, DOFs are shared with the neighbors (just imagine the triangles's node-heights being the values and the triangles the surfaces in-between the nodes. A continuous element would lead to a continuous surface as the values at the nodes are reused.)
Here, we don't expect it to be continuous as
epsilon
makes discrete jumps as the boundaries, thus we have to consider that in how we choose the element.For maxwell's equations we know that the tangential component of the field is continuous while the normal component is not -> best choice for Ex/Ey is a H(curl)-conforming element like the Nedelec-element. For Ez we know it's continuous so we're best of with a Lagrange element.
For the pointing vector, i'd guess it's save to use a vector of Lagrangian elements. As we see in the plots that it's discontinuous at boundaries, we need the discontinuous version of it.
Here, the question would be if there's any continuity across boundaries of the poynting vector which we could have in our choice of element as that would reduce the needed number of DOFs and would probably also be a bit more precise. (@DorisReiter do you know if there's any component of the pointing vector continuous across boundaries?)
For now I think we can just get it in with the Vector of Lagrangian elements, as we don't do a solve using those elements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see for the use of
basis.elem.elems
.(In the beginning I wanted/was thinking to use
split()
and get the elements fromEn_basis
, but this way is much cleaner!)(Corrected on 98cb853)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the explanation! :)
I don't get the second part of your message to use a function like
self.basis.with_element(ElementDG(ElementVector(self.basis.elems[1],3)))
. Why will we be allowed to project using one basis? Don't we already make that with thepoynting_basis.project()
?For the Poynting vector, from what I remember, you have the Poynting theorem which is an expression for the conservation of energy:
$$-\frac{\partial u}{\partial t} = \nabla\cdot\mathbf{S} + \mathbf{J}\cdot\mathbf{E}$$ $u$ the energy density, $S$ the Poynting vector, $J$ the current density and $E$ the electric field. If we consider a mode (i.e. no source), we should obtain $\nabla\cdot\mathbf{S}=0$ but I think @DorisReiter will have better insights!
with
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
at the moment, we have three sets of DOFs as the element is a scalar element.
if we use a vector-element we can have all three components in one set of DOFs (which we can split if we need)
something like
should do it (I always forget if stack/hstack/vstack, it should be stacked as a new last axis)
alternatively, there should also be a way to combine the DOFs into one set and use it with the vector basis, but I think it's better readable if we treat it directly as a vector.
About the continuity: that equation doesn't tell us about the interface-conditions of a single component (as a discrete change in one component can be compensated in another one)
So I guess it's better to assume it's discontinuous (the pictures you posted/in the paper also show that it's not continuous across interfaces)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also wondering if treating it as a vector makes sense at all 🤔$S_x$ =$S_y$=0?
we're calculating eigenmodes, which should mean that the mode propagates only in
z
direction...That lead to
Or is it only the integral over the whole domain which needs to be zero for those two components?
Edit: seems like it can be non-zero https://doi.org/10.1364/OE.472148
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Honestly that's a good question... I also found an article which states about that. So I think it is safer to keep the 3 components :)