simulation box size and boundary conditions

[Alfven17]

Hi, I’m new to WarpX and trying to use it to model the field evolution of a plasma after ionization, and the impact on a low charge electron beam traveling through the plasma (focusing effect). The plasma electron is assumed to gain some excess kinetic energy and begin to diffuse after ionization. I started with the plasma-only simulation and have a few questions on the setup,

1. What is the implication of setting initialize_self_fields=1 or 0. I see it set to 1 only in the space charge examples but not in PWFA or plasma physics examples.

2. How do I set the size of simulation box? In my case, the plasma is not uniform. Should I have the plasma fully contained by the box, or use a smaller box to model the region of interest that affects the electron beam.

3. Again on size of simulation box. I've two input files with the same initial beam distribution but different simulation box size (see file attached for the one with bigger box). At the same t (different iteration), the transverse E field looks quite different. Is this an artifact of the incorrect simulation setting?
   
   inputs_gasonly_gaussian_ux_2e-3.txt

4. Correspondingly, what is the right boundary condition to use? Physically it has open boundary so I’d assume ‘pml pml pml’ should be fine. Under what condition ‘periodic’ is okay? Also I’m a bit confused by the ‘pec’ boundary used in space charge examples. Is it simulating the space charge field of a beam in metallic beam pipes?

And eventually I’d like to inject the main electron beam, with its RMS transverse size slightly smaller than the plasma electrons. In that case (moving window simulation),

5. If I set do_continuous_injection=1, will WarpX start to model the diffusion of plasma electron before the main beam arrives, Or does it start the plasma simulation only when the simulation box reach there? The main difference between my physics case and PWFA is that in my case the density perturbation of the plasma is not only induced by the electron, and will start right after ionization.
6. Do I need rigid injection when I'm not using boosted-frame simulation?

To provide context, the length of plasma is around 2mm, with transverse size around 200um.

[ax3l]

Hi @Alfven17, thank you for your questions!

1. What is the implication of setting initialize_self_fields=1 or 0. I see it set to 1 only in the space charge examples but not in PWFA or plasma physics examples.
   https://warpx.readthedocs.io/en/latest/usage/parameters.html#particle-initialization

initialize_self_fields will perform an initial Poisson solve for electromagnetic simulations in case you initialize a non-neutral plasma (including locally non-neutral). This is usually only needed if one initializes external charged particle beams in a simulation.

If you initialize a plasma or gas and place the macro-particles on top of each other (by using the same number of particles per cell) using a quiet start (not random in-cell), and carefully check that electrons and ions are compensated in charge then this is not needed. If you start with a fully neutral species (that is to-be-ionized), then an initial Poisson solve is also not needed, because also then initial fields are zero.

2. How do I set the size of simulation box? In my case, the plasma is not uniform. Should I have the plasma fully contained by the box, or use a smaller box to model the region of interest that affects the electron beam.

That depends a bit on your science case and we have a variety of field and particle boundary conditions to handle this. In your case, you could start with a large enough plasma in the center, leave a bit of vacuum to the simulation boundary and apply open/absorbing (e.g., PML or silver-mueller) field boundaries and absorbing particle boundaries.
https://warpx.readthedocs.io/en/latest/usage/parameters.html#domain-boundary-conditions

You could also make the gas/plasma up to thee boundary.

As always, when you see effects from the boundary that are non-physical "creeping" into the simulation over time then make the domain bigger to avoid that they influence the real physic at play.

3. Again on size of simulation box. I've two input files with the same initial beam distribution but different simulation box size (see file attached for the one with bigger box). At the same t (different iteration), the transverse E field looks quite different. Is this an artifact of the incorrect simulation setting?

The simulation box size should not effect the physics, otherwise there is an issue in the simulation input file. I assume the problem is likely that your initial gas is not neutral (question 1.) and thus a larger box gives you a different initial potential when solving the Poisson equation a t=0 with initialize_self_fields=1.

I checked your linked inputs file and it looks like the two gaussian_beam you initialize are compensated in particle species charge, but since they are individually sampled randomly they are not microscpially perfectly on top of each other.
Let's use initialize_self_fields=1 on them and increase the resolution (cell resolution and particle number in both beams) to see if the initial condition converges?

4. Correspondingly, what is the right boundary condition to use? Physically it has open boundary so I’d assume ‘pml pml pml’ should be fine. Under what condition ‘periodic’ is okay? Also I’m a bit confused by the ‘pec’ boundary used in space charge examples. Is it simulating the space charge field of a beam in metallic beam pipes?

See above. Yes, you could even use periodic if there is a little chance that particles actually leave the domain.

5. do_continuous_injection=1,

This means that we will continuously feed particles into the simulation at every time step, instead of only during t=0. Yes, this is mostly used with moving window sims, where the box first has to reach a certain area, e.g., if we send a beam through a background plasma.
https://warpx.readthedocs.io/en/latest/usage/parameters.html#particle-initialization

6. Do I need rigid injection when I'm not using boosted-frame simulation?

Not really. Rigid injection is a technique to inject complex particle beams and build up their fields before starting a self-consistent interaction. If you do ES simulations or one of our initial Poisson solvers for our EM solver is sufficient to init your beams, then use those.

[Alfven17]

@ax3l Thanks so much for your answers! I reran the simulation with initialize_self_fields =0 but with 3 million macro particles. The two simulations with smaller and larger boxes agree pretty well. Looks like the artifact was due to the lack of particle numbers.

A few follow-up questions:

7. For gaussian_beam , is there a general rule of thumb in terms of number of macro particle per cell to avoid those non-physical effects? Or one needs convergence test for every simulation?

8. The electric field becomes nonsymmetric when I switched to a larger plasma beam and simulation box( It should be radially symmetric). See the picture below. Is this again a resolution issue?
   

9. In my simulation case, the plasma starts to evolve before the main electron beam arrives. And I will have to use a larger simulation box that contains both main electron beam and the plasma. How can I control the delay between the main electron beam and the plasma? For example, I would like to send the electron beam in after the plasma has started evolving for 20ps. Can I achieve this with injection settings, or perform the plasma simulation first, dump the file and load into a second simulation?

[ax3l]

The two simulations with smaller and larger boxes agree pretty well. Looks like the artifact was due to the lack of particle numbers.

Awesome, that is great to read. So only a resolution (convergence) issue.

Note that you probably want to use initialize_self_fields = 1 unless your beam is charge compensated.

For gaussian_beam , is there a general rule of thumb in terms of number of macro particle per cell to avoid those non-physical effects? Or one needs convergence test for every simulation?

I think so, because it depends on your space charge in your beam. Maybe @jlvay @qianglbl @cemitch99 have a good feeling/rule of thumb, I am not aware of one.

The electric field becomes nonsymmetric when I switched to a larger plasma beam and simulation box( It should be radially symmetric). See the picture below. Is this again a resolution issue?

That looks like one, yes.

We have an option to artificially symmetrize beams on the microscopic level, which can help as well to converge faster

Just be aware that this is somewhat nonphysical and can suppress seeds of beam instabilities.

In my simulation case, the plasma starts to evolve before the main electron beam arrives. And I will have to use a larger simulation box that contains both main electron beam and the plasma. How can I control the delay between the main electron beam and the plasma? For example, I would like to send the electron beam in after the plasma has started evolving for 20ps. Can I achieve this with injection settings, or perform the plasma simulation first, dump the file and load into a second simulation?

Let's see if I got this right - you want to evolve the plasma self-consistently for 20ps and then send in an external beam.

You could do this in various ways, maybe this is the simplest without coding:
You could load everything together and deactivate for some time the beam interaction with the sim:

Checkpoint, restart and in the restart input file change those options.

[Alfven17]

Hi @ax3l , thanks for your answers! I tried to use 1D, 2D, and RZ mode and see if I can get similar fields as 3D.

When set initialize_self_fields=1, one can only use pec or neumann boundary condition. I'm not sure if pec can describe my physics case. And when I use neumann it said MLMG: Bottom solve failed. Do you have any suggestions for simulating my physics case under RZ mode (with initialize_self_fields=1)?

For 1D and 2D, does WarpX still generate a 3D distribution if I use gaussian, and only model the z axis or xz plane? Or it's really a 1D or 2D problem. When I change the initial X/Y beam size in plasma_e, the result is different for 1D mode. How do I interpret this?