Skip to content
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

Open
wants to merge 82 commits into
base: main
Choose a base branch
from

Conversation

simlapointe
Copy link
Contributor

@simlapointe simlapointe commented Dec 13, 2024

Add support for Floquet periodic boundary conditions and improve flexibility of periodic boundary conditions specifications.

  • Support Floquet boundary conditions by incorporating the phase delay into Maxwell's equations and solving the modified PDE with periodic boundary conditions.
  • Automatically detect periodic boundary transformations.
  • Support both translation and rotation transformations.

@simlapointe simlapointe marked this pull request as ready for review December 31, 2024 01:55
@simlapointe simlapointe requested a review from hughcars December 31, 2024 01:55
Copy link
Collaborator

@hughcars hughcars left a 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

  1. FP should be part of K, given it has no omega dependence in its construction unlike A2. This will simplify loads of things
  2. The muinv kx should be in the MaterialOperator, (doing this neatly will mean adding the ability to use transpose coefficients in the ceed context)
  3. 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.

docs/src/config/boundaries.md Outdated Show resolved Hide resolved
docs/src/config/solver.md Outdated Show resolved Hide resolved
Comment on lines +266 to +268
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.
Copy link
Collaborator

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.

Copy link
Contributor Author

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
Copy link
Collaborator

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.

Copy link
Contributor Author

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.

palace/fem/libceed/operator.hpp Outdated Show resolved Hide resolved
palace/utils/configfile.cpp Outdated Show resolved Hide resolved
palace/utils/configfile.hpp Outdated Show resolved Hide resolved
palace/utils/geodata.cpp Outdated Show resolved Hide resolved
palace/drivers/drivensolver.cpp Show resolved Hide resolved
palace/linalg/floquetcorrection.cpp Outdated Show resolved Hide resolved
Copy link
Collaborator

@hughcars hughcars left a 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.

Comment on lines +325 to +326
// B = -1/(iω) ∇ x E + 1/ω kp x E.
floquet_corr->AddMult(E, B, 1.0 / omega);
Copy link
Collaborator

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);
    }

Copy link
Contributor Author

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/fem/integrator.hpp Outdated Show resolved Hide resolved
palace/models/spaceoperator.cpp Outdated Show resolved Hide resolved
Comment on lines 335 to 344
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;
}
Copy link
Collaborator

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}.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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>
Copy link
Collaborator

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.

Copy link
Contributor Author

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/utils/geodata.cpp Outdated Show resolved Hide resolved
palace/fem/integrator.hpp Show resolved Hide resolved
Comment on lines 936 to 938
void SpaceOperator::AddPeriodicCoefficients(double coeff, MaterialPropertyCoefficient &fm,
MaterialPropertyCoefficient &fwc,
MaterialPropertyCoefficient &fc)
Copy link
Collaborator

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.

Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Periodic boundary conditions
2 participants