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

Add PECInsulator boundary condition #4943

Merged
merged 34 commits into from
Nov 5, 2024

Conversation

dpgrote
Copy link
Member

@dpgrote dpgrote commented May 21, 2024

This PR adds a mixed PEC and insulator boundary condition. This allows an insulator to be placed on a portion of the boundary. The rest of that boundary will be PEC. Within the insulator portion, the tangential fields can be specified on the boundary (as functions of space and time). The normal fields and fields not specified are extrapolated to the guard cells from the valid cells. The fields are specified in pairs, the two tangential electric fields, and the two tangential magnetic fields. In each pair, if one is set, the other will be zeroed if not set.

A use case is the simulation of a dynamic pinch, driven by an external current, represented as a time dependent B field on the boundary.

PECinsulatorBC_warpX_summaryOnly.pdf

@dpgrote dpgrote added enhancement New feature or request component: boundary PML, embedded boundaries, et al. labels May 21, 2024
@ax3l ax3l requested a review from RemiLehe May 29, 2024 22:07
@RemiLehe RemiLehe self-assigned this May 29, 2024
@EZoni
Copy link
Member

EZoni commented Oct 8, 2024

@RevathiJambunathan @roelof-groenewald
I added you as reviewers of this PR as well, since you did extensive work on PEC boundary conditions in WarpX in the past.

Docs/source/usage/parameters.rst Outdated Show resolved Hide resolved
Docs/source/usage/parameters.rst Outdated Show resolved Hide resolved
Source/BoundaryConditions/PEC_Insulator.H Outdated Show resolved Hide resolved
Source/BoundaryConditions/PEC_Insulator.H Outdated Show resolved Hide resolved
Comment on lines 29 to 36
* \param[in,out] Efield
* \param[in] ng_fieldgather number of guard cells used by field gather
* \param[in] geom geometry object of level "lev"
* \param[in] lev level of the Multifab
* \param[in] patch_type coarse or fine
* \param[in] ref_ratios vector containing the refinement ratios of the refinement levels
* \param[in] time current time of the simulation
* \param[in] split_pml_field whether pml the multifab is the regular Efield or
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add the docstrings for field_boundary_lo and field_boundary_hi as well?

Comment on lines 72 to 99
* \param[in,out] field
* \param[in] ng_fieldgather number of guard cells used by field gather
* \param[in] geom geometry object of level "lev"
* \param[in] lev level of the Multifab
* \param[in] patch_type coarse or fine
* \param[in] ref_ratios vector containing the refinement ratios of the refinement levels
* \param[in] time current time of the simulation
* \param[in] split_pml_field whether pml the multifab is the regular Efield or
* split pml field
* \param[in] E_like whether the field is E like or B like
* \param[in] set_F_x_lo whether the tangential field at the boundary was specified
* \param[in] set_F_x_hi whether the tangential field at the boundary was specified
* \param[in] a_Fy_x_lo the parser for the tangential field at the boundary
* \param[in] a_Fz_x_lo the parser for the tangential field at the boundary
* \param[in] a_Fy_x_hi the parser for the tangential field at the boundary
* \param[in] a_Fz_x_hi the parser for the tangential field at the boundary
* \param[in] set_F_y_lo whether the tangential field at the boundary was specified
* \param[in] set_F_y_hi whether the tangential field at the boundary was specified
* \param[in] a_Fx_y_lo the parser for the tangential field at the boundary
* \param[in] a_Fz_y_lo the parser for the tangential field at the boundary
* \param[in] a_Fx_y_hi the parser for the tangential field at the boundary
* \param[in] a_Fz_y_hi the parser for the tangential field at the boundary
* \param[in] set_F_z_lo whether the tangential field at the boundary was specified
* \param[in] set_F_z_hi whether the tangential field at the boundary was specified
* \param[in] a_Fx_z_lo the parser for the tangential field at the boundary
* \param[in] a_Fy_z_lo the parser for the tangential field at the boundary
* \param[in] a_Fx_z_hi the parser for the tangential field at the boundary
* \param[in] a_Fy_z_hi the parser for the tangential field at the boundary
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add the docstrings for field_boundary_lo and field_boundary_hi as well?

Comment on lines +62 to +67
void ApplyPEC_InsulatortoBfield (std::array<amrex::MultiFab*, 3> Bfield,
amrex::Array<FieldBoundaryType,AMREX_SPACEDIM> const & field_boundary_lo,
amrex::Array<FieldBoundaryType,AMREX_SPACEDIM> const & field_boundary_hi,
amrex::IntVect const & ng_fieldgather, amrex::Geometry const & geom,
int lev, PatchType patch_type, amrex::Vector<amrex::IntVect> const & ref_ratios,
amrex::Real time);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why don't we need a split_pml_field argument for B, as for E? In other words, why is the splitting of B, which I think occurs in the PML, not relevant in this case?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question. I copied this pattern from the PEC boundary conditions. Do you know why the split is done there?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah interesting, I don't know. I think this would be a question for @RevathiJambunathan or @roelof-groenewald.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pinging @RevathiJambunathan and @roelof-groenewald just to make sure that the PR doesn't get stalled.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the slow response. It looks like the flag was introduced in #2541 to fix an observed bug when one boundary is PEC and an adjacent one is PML. @RevathiJambunathan would know better but I expect it is not needed to apply the same to the B-field since the update to the E-field ensures that the B-field values come out appropriately in the B-field push.

Source/BoundaryConditions/PEC_Insulator.cpp Outdated Show resolved Hide resolved
// Upper radial boundary
amrex::Real const rguard = ijk_vec[idim] + 0.5_rt*(1._rt - is_nodal[idim]);
if (icomp == 0) {
// Add radial scale so that drFr/dr = 0.
Copy link
Member

@EZoni EZoni Oct 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the formula in this inline comment? Is it $dF_r/dr=0$ or $d(rF_r)/dr=0$? In the second case I would maybe write

Suggested change
// Add radial scale so that drFr/dr = 0.
// Add radial scale so that d(rF_r)/dr = 0.

or at least

Suggested change
// Add radial scale so that drFr/dr = 0.
// Add radial scale so that d(rFr)/dr = 0.

Comment on lines +34 to +42
add_warpx_test(
test_2d_pec_field_insulator # name
2 # dims
2 # nprocs
inputs_test_2d_pec_field_insulator # inputs
analysis_default_regression.py # analysis
diags/diag1000010 # output
OFF # dependency
)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the complexity of the new feature, is there a physics analysis that can be done, beyond the checksums analysis?

Also, is this intentionally tested only in 2D? The implementation seems to be general for all dimensions, so maybe it could be worth adding tests for those as well. What do you think?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test was copied from the test case for the same boundary condition in the picnic code. That code's primary use is 2D. I don't know of any physics analysis that could be done beyond checking that the fields at the boundary are as expected. I could add other cases that do that simple check.

dpgrote and others added 3 commits October 10, 2024 11:56
@EZoni EZoni self-requested a review October 18, 2024 21:12
@EZoni EZoni changed the title Add PEC_insulator bc Add PECInsulator boundary condition Oct 18, 2024
@EZoni
Copy link
Member

EZoni commented Nov 4, 2024

@dpgrote

Sorry that this got stalled for so long. I was waiting for feedback from other developers on some of the questions I asked in my review, but if this is working for you we can go ahead and merge as is. There seems to be conflicts now unfortunately, so those would have to be fixed first.

@dpgrote
Copy link
Member Author

dpgrote commented Nov 4, 2024

@dpgrote

Sorry that this got stalled for so long. I was waiting for feedback from other developers on some of the questions I asked in my review, but if this is working for you we can go ahead and merge as is. There seems to be conflicts now unfortunately, so those would have to be fixed first.

No problem. Though something weird has happened to the commit history. There are a number of commits from the development branch listed here but with different hash tags. I'll see if I can clean this up. Otherwise I'll have to copy the changes to a different branch and submit a new PR.

@dpgrote
Copy link
Member Author

dpgrote commented Nov 4, 2024

@dpgrote
Sorry that this got stalled for so long. I was waiting for feedback from other developers on some of the questions I asked in my review, but if this is working for you we can go ahead and merge as is. There seems to be conflicts now unfortunately, so those would have to be fixed first.

No problem. Though something weird has happened to the commit history. There are a number of commits from the development branch listed here but with different hash tags. I'll see if I can clean this up. Otherwise I'll have to copy the changes to a different branch and submit a new PR.

Ok, that worked. I locally removed all of the duplicated commits, redid the merge, and then did a force push.

Copy link
Contributor

@JustinRayAngus JustinRayAngus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me. Thanks for the PR Dave!

@JustinRayAngus JustinRayAngus enabled auto-merge (squash) November 5, 2024 19:54
@JustinRayAngus JustinRayAngus merged commit a4d5631 into ECP-WarpX:development Nov 5, 2024
37 checks passed
@dpgrote dpgrote deleted the add_insulator_BC branch November 5, 2024 23:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: boundary PML, embedded boundaries, et al. enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants