Allow multiple lumped ports on the same boundary attribute (for co- and cross-polar analysis)

[krono-i2]

🪪 Title

Allow multiple lumped ports on the same boundary attribute (for co- and cross-polar analysis)

---

📝 Description

Currently, Palace does not allow assigning more than one LumpedPort to the same boundary attribute.
This limitation triggers the following verification error:

Verification failed: (!data.active || !port_marker[attr - 1]) is false:
 --> Boundary attribute is assigned to more than one lumped port!
 ... in function: void palace::LumpedPortOperator::SetUpBoundaryProperties(const palace::IoData&, const palace::MaterialOperator&, const mfem::ParMesh&)
 ... in file: /tmp/krono/spack-stage/spack-stage-palace-develop-uv64y6xpn4v5w6kqisdxkgm7pzwxjeot/spack-src/palace/models/lumpedportoperator.cpp:343

This behavior prevents users from modeling configurations where two ports share the same physical surface but differ in excitation direction — for instance, when evaluating co-polar and cross-polar reflected components (only one port would be excited at a time).

---

🧩 Minimal JSON Example

{
  "Boundaries": {
    "LumpedPort": [
      {
        "Index": 1,
        "Attributes": [7],
        "Direction": [0.0, 1.0, 0.0],
        "Excitation": true,
        "R": 50
      },
      {
        "Index": 2,
        "Attributes": [7],
        "Direction": [-0.7071, 0.0, 0.7071],
        "Excitation": false,
        "R": 50
      }
    ]
  }
}

---

⚙️ Expected Behavior

It should be possible to define multiple LumpedPort objects on the same boundary attribute, provided that:

• only one is active ("Excitation": true), or
• all are passive (for reciprocity or scattering analysis).

This would allow users to:

• define co- and cross-polar ports on the same surface,
• avoid duplicating geometry or mesh elements just to represent different port directions.

---

💡 Proposed Enhancement

• Allow multiple lumped ports to share a boundary attribute if only one is active.
• Relax validation so it only fails when multiple excited ports are assigned to the same attribute.
• Optionally, support a compound port definition for multi-polarization setups.

---

🧪 Steps to Reproduce

1. Define two lumped ports using the same attribute in the JSON input.
2. Run palace -i example.json.
3. The verification step fails with the error above.

---

🖇️ Environment

• Palace version: develop branch
• OS: Linux (Spack environment)
• Problem type: Driven (Lumped Port)

---

🙏 Suggested Priority

Medium — this improvement would simplify polarization and scattering studies without geometry duplication.

[hughcars]

Hi @krono-i2,

I am slightly confused by this request, but that's probably on me.

"this improvement would simplify polarization and scattering studies without geometry duplication." -- if I understand correctly, there is no need to duplicate geometry here, you would need different configuration files?

If you are wanting to apply two different boundary conditions on the port simultaneously, then that seems ill-defined, what is the impedance on that surface supposed to be? a linear combination of both?. If each is only used in one simulation or another, then two configuration files for a given mesh, and thus two separate simulations, seems easy to do. A port can't be both co and cross planar simultaneously? Or is this for postprocessing only? I.e. you'd want to drive one and then compute quantities at the same port under the same field but a different impedance? Multiple postprocessings can occur on the same attribute, without introducing any ambiguity.

Is the idea that exciting on one of these lumped ports will effectively excite the other one at the same location? If you could point me to this being specified in some other solver I might be able to better understand what you are suggesting. My current suspicion is that this is ill-defined, as driving one port coincident with the other effectively prescribes the field directly on top of the other, but I'm really guessing.

[krono-i2]

It’s mainly a postprocessing matter. Let me clarify.
Consider, for example, a periodic structure in the (x,y) plane illuminated by a plane wave propagating in a given direction. The wave vector is directly derived from the Floquet vector defined in the periodic boundaries, while the field polarization can be controlled by properly setting the direction of a lumped port.
Suppose you are interested in evaluating the reflection coefficient (S11) at the port along the same direction as the incident field (co-polar reflection); that’s straightforward.
Now imagine that you also want to evaluate the reflection coefficient at the same port but along the cross-polar direction.
In other software (e.g., COMSOL), you can define two orthogonal “plane wave ports” and compute S11 (co-polar reflection) and S21 (cross-polar reflection).
What would be the equivalent approach in Palace?

[hughcars]

It’s mainly a postprocessing matter. Let me clarify. Consider, for example, a periodic structure in the (x,y) plane illuminated by a plane wave propagating in a given direction. The wave vector is directly derived from the Floquet vector defined in the periodic boundaries, while the field polarization can be controlled by properly setting the direction of a lumped port. Suppose you are interested in evaluating the reflection coefficient (S11) at the port along the same direction as the incident field (co-polar reflection); that’s straightforward. Now imagine that you also want to evaluate the reflection coefficient at the same port but along the cross-polar direction. In other software (e.g., COMSOL), you can define two orthogonal “plane wave ports” and compute S11 (co-polar reflection) and S21 (cross-polar reflection). What would be the equivalent approach in Palace?

Ok, I'll take a closer look and try frame it into the Palace scheme. Do you have a link to a comsol example/documentation making use of this particular feature? Searching for "plane wave port" doesn't turn anything specific up.

If I understand you correctly, this is for differentiating polarity in the scattering, so hypothetically there might be a cavity with a single lumped port, which is driven on that port with polarity +X, then you'd want to see how much of that signal comes back to that port at the same polarity, S_11, and how much comes back to that port at a 90 degree shifted polarity, S_21. Effectively dividing the original S_11 signal into two oriented pieces. I'll have to think a little bit on the implications for this, as I'm not sure 100% how that will play into the formulas for the scattering matrices, but I suspect it might be ok to do so, though need some changes to predicates we assume in mesh preprocessing. This might also be a possibility for wave ports too, where the port is driven with mode 1, then can look for the scattering from that mode into mode 2 on the same port, to measure how much that drive signal "converts" out back into the driving port. This starts to get pretty weird however, as it suggests asking the question "how many output modes on a waveport do you need to scatter into?"

[krono-i2]

I realize I was mistaken — the software that supports this kind of setup is actually CST Studio Suite.
In CST you can place two orthogonally oriented Floquet ports on the same boundary to capture co- and cross-polar reflection (see, for example, the implementation in OpenRIS).
In practice, I think CST handles these as orthogonal Floquet modes on the same periodic boundary, may be it is how the scattering matrix including cross-polar terms is evaluated.
My interest is mainly in doing the same for arbitrary incidence angles, not just normal incidence, on Palace.

[krono-i2]

I have just realised the functionality I mentioned only could work for normal incidence.
The most general case can be efficiently implemented by a Floquet port (see #563).