-
Notifications
You must be signed in to change notification settings - Fork 60
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
Support Floquet periodic boundary conditions #314
base: main
Are you sure you want to change the base?
Conversation
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.
Looking pretty good, I think there are a few larger changes to take care of first
- FP should be part of K, given it has no omega dependence in its construction unlike A2. This will simplify loads of things
- The muinv kx should be in the MaterialOperator, (doing this neatly will mean adding the ability to use transpose coefficients in the ceed context)
- The geodata.cpp can be shortened and simplified some, I have some initial work on doing this in
hughcars/periodic-bc
, but I'm sure once you get started you'll probably see even more things to do. The basic thing is a mixing assumptions on sdim and no assumptions on sdim.
distance between them is given by the `"Translation"` vector in mesh units. In `floquet.json`, | ||
an additional `"FloquetWaveVector"` specifies the phase delay between the donor and receiver | ||
boundaries in the X/Y/Z directions. |
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.
Given the relative simplicity of this example, it would be great if we can derive the expected modes analytically. I suspect it'll be possible to map them to an equivalent set of modes on a full length cylinder without phase shift, at which point analytic results can be compared against like for the waveguide case.
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 compared the cylindrical waveguide modes (as well as a rectangular waveguide and a nail/pillar) against Comsol and they all matched so I feel confident about it, but I'll see if I can derive analytical modes for the Floquet case.
@@ -74,7 +74,7 @@ Periodic boundary conditions on an existing mesh can be specified using the | |||
["Periodic"](../config/boundaries.md#boundaries%5B%22Periodic%22%5D) boundary keyword. This | |||
boundary condition enforces that the solution on the specified boundaries be exactly equal, | |||
and requires that the surface meshes on the donor and receiver boundaries be identical up to | |||
translation. Periodicity in *Palace* is also supported through meshes generated | |||
translation or rotation. Periodicity in *Palace* is also supported through meshes generated |
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.
How have you tested the rotational case? Might make for a cool example, thinking plausibly the waveguide cylinder could be split into wedges maybe and analyzed.
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 tested the pure rotation with an annulus wedge and the rotation + translation case with a helical case.
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.
Some minor typos, and one further simplification of the coefficient handling for the floquet hermitian term then we're good to go.
// B = -1/(iω) ∇ x E + 1/ω kp x E. | ||
floquet_corr->AddMult(E, B, 1.0 / omega); |
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.
Why is the sign of the correction here different to that in the driven case?
Curl.Mult(E.Real(), B.Real());
Curl.Mult(E.Imag(), B.Imag());
B *= -1.0 / (1i * omega);
if (space_op.GetMaterialOp().HasWaveVector())
{
// Calculate B field correction for Floquet BCs.
// B = -1/(iω) ∇ x E - 1/ω kp x E
floquet_corr->AddMult(E, B, -1.0 / omega);
}
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.
Should be the same (+) everywhere, forgot to change one of the driven ones.
palace/models/materialoperator.cpp
Outdated
if (has_wave_attr && local_wave_vector.Norml2() > tol) | ||
{ | ||
mfem::Vector diff(sdim); | ||
diff = wave_vector; | ||
diff -= local_wave_vector; | ||
MFEM_VERIFY(diff.Norml2() < tol, | ||
"Conflicting definitions of the Floquet wave vector in the " | ||
"configuration file."); | ||
wave_vector = local_wave_vector; | ||
} |
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.
This implies a weird non-additive effect:
{
bdr_a : {Floquet: 1,0,0},
bdr_b : {Floquet: 0,1,0},
Floquet: {0,0,1}
A user might intend to mean {1,1,1}
, but this would error. I'm inclined to say either they add, or only one can be specified. I'm biased towards allowing the sum because this implies a non-present value is equivalent to {0,0,0}
.
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 good with allowing the sum.
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 good with allowing the sum.
@@ -1721,6 +1706,350 @@ double RebalanceMesh(const IoData &iodata, std::unique_ptr<mfem::ParMesh> &mesh) | |||
namespace | |||
{ | |||
|
|||
// Compute the centroid of a container of vertices. | |||
template <typename T> |
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.
Might no longer need these templates, I had only put them in whilst I was playing with going to general containers and was moving back and forth.
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.
It's still used in two places with different inputs (array and unordered_set) so I kept the template.
palace/models/spaceoperator.cpp
Outdated
void SpaceOperator::AddPeriodicCoefficients(double coeff, MaterialPropertyCoefficient &fm, | ||
MaterialPropertyCoefficient &fwc, | ||
MaterialPropertyCoefficient &fc) |
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.
The only reason there needs to be two coefficients here, is because they are being added in with +1 and -1 coefficients. If you change the MixedVectorWeakCurlIntegrator
to a(u, v) = - (Q u, curl v)
similar to how MixedVectorWeakDivergenceIntegrator
uses the negative Q
, then there only needs to be one coefficient and the hermitian nature of the operators is really apparent. This would mean adding the -1
coefficent to the PopulateCoefficientContext
call similar to MixedVectorWeakDivergenceIntegrator
. This would mean changing some of the unit tests against mfem most likely too, but will reduce the LOC further.
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 good with that, made the changes.
Add support for Floquet periodic boundary conditions and improve flexibility of periodic boundary conditions specifications.