Issue with potential boundary conditions and cpu acceleration

[AGreatDayForReal]

Hi everyone,I am working on a Hall thruster simulation, and the geometry looks like this:

I use EB to describe the geometry:
eb_expr = f"max( min({x_exit} - x, {z_lower} - z), min({x_exit} - x, z - {z_upper}) )"
Here, x_exit = 0.5 * lx (2.5 cm), z_lower = 0.25 * lz (1.5 cm), and z_upper = 0.75 * lz (3.5 cm).
I shifted the whole coordinate system downward because I set the origin of the z-axis to lie on the x-axis. With this coordinate choice, is the EB setup above correct?
I would also like to know whether this EB definition will affect the wall potential boundary condition. I only want to impose a potential on part of the middle region, but WarpX seems to apply the potential boundary condition along the entire boundary by default. How should I handle this?Can the EB setup directly enforce this, or does it only define the geometry?
Also, are the EB boundaries treated as absorbing boundaries and Dirichlet boundaries by default? If not, what is the proper way to impose the potential boundary conditions? I know that callbacks can also be used for boundary-condition handling.
Finally, I am currently running on CPUs, but the speed is lower than I expected. Are there any recommended ways to improve performance? In particular, are there any important CPU-related settings in WarpX that should be configured carefully?
Thank you very much for any suggestions.

[shreyanshjain1]

Seeing the plot helps a lot.

At least from the image, the EB geometry itself looks mostly right to me — it does look like the channel opens up around x ~ 2.5 cm, so I dont think the main problem is the basic wall shape.

What stands out more is that the potential / field behavior seems to extend through the larger region, so this feels less like “the EB shape is wrong” and more like “the BC tied to that geometry is not being applied the way you expect”.

So my guess would be:

• the embedded boundary shape is probly fine, or at least close
• but EB geometry != automatically the exact wall-potential treatment you want
• if WarpX is applying the potential across more of the wall / domain than expected, then the issue is more likely in the electrostatic BC setup layered on top of the EB, not just the eb_expr

So for your questions, I’d split it like this:

1. Does the eb_expr match the intended shape?
   From the figure, mostly yes — visually it seems to produce the expected channel / expansion geometry.

2. Does that automatically mean the wall potential is only applied to the exact section you want?
   I would not assume that. The geometry can be right while the BC handling is still broader than intended.

3. Are the EB boundaries automatically absorbing / Dirichlet the way you want?
   I’d be carefull there too. I wouldnt assume the default EB behavior exactly matches your intended physical wall treatment unless the docs or input settings say so explicitly.

So based on the image, I’d focus less on rewriting the EB expression and more on checking:

• how the electrostatic BC is attached to the EB
• whether the solver is treating the entire embedded wall uniformly
• whether particle and field BCs are being controlled separately

The geometry plot makes me think you’re already pretty close on the shape part — the bigger issue is probly how the BCs are being imposed on top of it.

[AGreatDayForReal]

Thanks, that makes sense.
After going back to the EB documentation, I realized that it does explicitly mention the potential setting for the embedded boundary.That was my oversight.
From the Cartesian2DGrid parameter description, my current understanding is that bc_xmin only specifies the boundary-condition type at the lower x boundary, while warpx_potential_lo_x sets a single electrostatic potential value for the entire lower x boundary. I could not find anything in this interface that explicitly allows the potential to be applied only to part of that boundary.
Is that understanding correct?
What I would like to do is to impose a nonzero potential only on part of the left boundary, while keeping the rest of the left boundary at zero potential. Is this possible directly through the domain-boundary settings, or would this need to be implemented in another way, for example through embedded boundary or a callback-based treatment?
If there are any examples or recommended approaches for this kind of partially biased boundary, I would greatly appreciate it

[shreyanshjain1]

Yeah, that’s how I’d read it too.

My understanding is that the regular domain-boundary settings there are basically face-level, not “apply this value to only part of the same face”.

So for the left boundary:

• bc_xmin tells WarpX what kind of BC is used on the xmin boundary
• warpx_potential_lo_x sets the electrostatic potential value for that xmin boundary
• but not just for a selected segment of it

So if you want:

• one part of the left boundary at nonzero potential
• and the rest of that same left boundary at 0 V

then I wouldnt expect the plain domain-boundary interface by itself to express that directly.

That sounds more like something that would need to be represented through:

• an embedded boundary treatment
• or some more custom / callback-style handling
• or another geometry-based way of separating the biased surface from the unbiased one

So yeah, I think your reading is probly correct:
the normal xmin boundary settings look like they apply to the whole boundary plane/edge, not a sub-region of it.

If the goal is a partially biased boundary, I’d personally stop looking for it in the simple domain-boundary params and instead look for:

• EB-based examples
• geometry-based boundary setup
• or any callback / custom boundary handling the code supports

That feels much closer to the kind of thing you’re trying to model.