how to add uniform electric field in addition to self-consistent EM field at each time step?

[tsikd]

Hi Tom,
Can you please help with the following:
I need to split Ex into two parts:
First is the usual self-consistent field that comes from the EM solver;
2nd is added background Ex_fixed=const at each time step.

when I use

SUBROUTINE drive_field(time)
REAL(num), INTENT(IN) :: time
REAL(num), PARAMETER :: ex_fixed = 4.8e6_num
ex=ex+ex_fixed
END SUBROUTINE drive_field
it obviously keeps summing ex_field and Ex goes through the roof. :(
There must be a way to self-consistently update Ex at half and full time steps and then simply to add constant electric field ex_fixed in the whole domain. I just cannot get my head around this at first sight. Thanks for any help.
Best,
David

[tsikd]

I think instead of making any changes src/fields.f90 in order to impose constant electric field at each time step what is needed is to add ex_fixed to the equation of motion for particles.

Can you please advise which file .f90 contains equation of motion for particles? i.e. particle-push stage

With developer manual out of sight one is clearly lost! even outdated one would have been useful for this task.

Thanks.

[TomGoffrey]

The push_particles routine is located in the src/particles.F90 file. Most files in EPOCH have similarly descriptive names.

Before jumping into modifying that file I would suggest writing down the equation you want to actually solve for the field evolution. From your basic description it sounds like you could achieve what you want by just initialising the electric field to your required value, rather than modifying the particle push, or indeed the field solve.

[tsikd]

Yes, this is the first thing I tried, BUT when dense enough parcel of localized electron-ion mixture starts to move in the initially applied (set in the input.deck) Ex field, it gets quickly destroyed. I want to have plasma inside glow discharge tube with constant voltage applied. To me this is setting Ex fixed at each time step. I came up with the following solution: inside src/fields I have

SUBROUTINE drive_field(time)
REAL(num), INTENT(IN) :: time
REAL(num), PARAMETER :: ex_fixed = 1.0e7_num
ex=ex_fixed
END SUBROUTINE drive_field
...
CALL drive_field(time+0.5_num*dt)
CALL update_e_field
! Now have E(t+dt/2), do boundary conditions on E
CALL efield_bcs
...
CALL drive_field(time+dt)
CALL update_e_field
CALL efield_bcs
i.e. I apply Ex_fixed before efield update.
Do you think such approach is consistent? Thanks!

[TomGoffrey]

Honestly: I don't know.

Here's how I envisaged the proposed modification to the particle push routine:

1. Start with E_{Maxwell} = 0, E_{applied} = X.
2. Solve particle push subject to E_{Tot.} = E_{Maxwell} + E_{applied}. This gives the current density, j.
3. Solve for E_{Maxwell} subject to the current density, j, from step 2.
4. Repeat steps (2) & (3).

So at each step you push the particles due to a total field, the sum of that from solving Maxwell's equations and constant fixed value, but I think this is exactly equivalent to initialising E_{Maxwell} to E_{applied} at t=0, isn't it?

As it stands, the fact that a large plasma current "destroys" the initial field is just the solution to the equations you're solving, i.e. E_{Maxwell} >> E_{applied}.

If you want to keep E = E_{applied} you have two options:

1. Don't evolve the field at all
2. Add some driving term which pushes the field back towards the "applied" value.

The trouble with both of these approaches is that I don't think they are physically meaningful. With (1) you're saying that the self-consistent fields from Maxwell are negligible, but we know that not to be true, and I don't know what physics (2) would correspond to.

Edit to add: I've assumed here that E_{applied} is constant, which I think is true for your case. If you have spatially varying applied field, then you would get a different answer, depending on initialising your field for Maxwell's equations, or adding on the applied field in the particle push.

[keithbennett]

Since this is a support request rather than a potential bug report, it has been moved to the Q&A discussion section.