Periodic BC's

It seems that when I set BCFFTT = PERIODIC, not only the z-direction but all directions are automatically set to periodic boundary conditions. @uldis_l I am assuming "UL" in the comment of PartBunch::setBCForDCBeam() is you. Was there a particular reason to do this? In my understanding, a DC beam would have open BC in x and y and periodic BC in z.

In addition, the manual calls the parameters "BCFFTZ" and "PARFFTZ" but OPAL tells me those don't exist and throws an Exception, I have to use "BCFFTT" and "PARFFTT". Just a minor bug.

assigned to @adelmann

assigned to @kraus

This issues is maybe becoming relevant for: PSI B870 beamline simulation and RFQ modelling.

Notes:

a) check without fieldsolver if particles are periodic in Z.

b) for the fieldsolver disable Hockney trick in Z and use the natural periodicity of FFT

c) For the P3M solver (a mini-app based on the OPAL particle and fields classes) periodic BC for particles and fields are implemented:

• MSc thesis report Report: http://amas.web.psi.ch/people/aadelmann/ETH-Accel-Lecture-1/projectscompleted/cse/thesisBUlmer.pdf
• src/ippl/test/particle/p3m3dxxx.cpp

It was called BCFFTT, changing it to BCFFTZ.

so BCFFTT is causing the exception?

Yes, it looks like. Allowing not both BCFFTT and BCFFTZ, marking BCFFTT as deprecated.

When BCFFTZ is set to periodic then the method PartBunch::setBCForDCBeam is set. Do you understand why in all directions periodic boundary conditions are set?

void PartBunch::setBCForDCBeam() {
    //UL: set periodic BC in all dimensions
    for(int i = 0; i < 2 * 3; ++i) {
      if (Ippl::getNodes() > 1) {
        bc_m[i] = new ParallelPeriodicFace<double, 3, Mesh_t, Center_t>(i);
        vbc_m[i] = new ParallelPeriodicFace<Vector_t, 3, Mesh_t, Center_t>(i);
      } else {
    bc_m[i] = new PeriodicFace<double, 3, Mesh_t, Center_t>(i);
        vbc_m[i] = new PeriodicFace<Vector_t, 3, Mesh_t, Center_t>(i);
      }
      getBConds()[i] = ParticlePeriodicBCond;
    }
    dcBeam_m=true;
    INFOMSG(level3 << "BC set for DC-Beam, all periodic" << endl);
}

Two remarks:

1. The length of the grid has to be fixed to the wave length of the RF.
2. To simulate the steady state of emission is going to be challenging, probably needs iterative approach.

We should start with 1) from above. I agree 2) is complicated and not needed for PSI-B860 & RFQ modelling.

What do you mean with

check without fieldsolver if particles are periodic in Z.

I'm sure it won't take long before someone tries to simulate a gun with DC beam once DC beams work.

In a first step, we have to make sure the particles are periodic in z. Switching the field solve off reduces the complexity, that is all what I meant.

Oh I agree with the "DC gun" assessment, but would make it second in priority.

I may be slow-witted: do you plan to read the distribution from file? Will you have bunches or a continuous stream of particles?

The latter, for the B870 as well as for the IsoDAR RFQ (LEBT) we start with a DC beam, so no need (for now) to emit protons.

With latter you mean a continuous stream of particles? But why wouldn't they be periodic, why should we check?

Yes a continuous stream of particles modelled with periodic BC.

We should first check if OPAL is treating the particle periodic BC correctly, nothin more/less.

Ok, now I got it: particle periodic BC...

As far as I can see there isn't much present in the class FFTPoissonSolver towards DC beams except for the member bcz_m.

I will comment on that later. Some of the parallel BC are implemented in miniapps at src/ippl/test/particle. Check also http://amas.web.psi.ch/people/aadelmann/ETH-Accel-Lecture-1/projectscompleted/cse/thesisBUlmer.pdf

I have it running however without testing. I don't know whether particle periodic bc works and field solution is indeed periodic.

added ~115 and removed Bug ~48 labels

changed milestone to %OPAL 2.4.0

added 1 deleted label and removed 1 deleted label

added Bug label

I think the label Bug is wrong here, I didn't remove the label accidentally. This is a feature that never worked sofar and won't work unless this is requested by one of our "clients" and someone finds time to continue the work I began.

If this feature never worked so far we should either remove it from the code or throw an exception with a note to the user and remove BCFFTZ from the manual.

changed milestone to %OPAL 2021.1

assigned to @frey_m and unassigned @kraus and @adelmann

@frey_m you could try to fix that. Would be an important feature and maybe it is already on your list.

@adelmann I won't be able to work on this before June 26. I want to finish #542 (closed) and #543 (closed) first.

This will be fixed in IPPL V 2.0

removed milestone

assigned to @adelmann

removed 1 deleted label

@adelmann change in manual @kraus fix in code

assigned to @kraus

created merge request !498 (closed) to address this issue

mentioned in merge request !498 (closed)

unassigned @frey_m

To support DC beams

• the SC field should be periodic in longitudinal direction (z in Opal-T and y in Opal-cycl(?)),
• the particles exiting in longitudinal direction should enter at the other side and
• the sampling grid for SC discretization should have a fixed length.

Do I understand this correctly?

@adelmann @winklehner_d ?

Yes on 1 and 2. I think 3 should always be beta * lambda length, where lambda is the wavelength of the RF. If there is acceleration (RFQ), then the grid length will have to change from cell to cell.

changed milestone to %OPAL 2021.1

mentioned in merge request !499 (merged)

removed milestone

Will be supported (again) with IPPL 2.0

As far as I understand IPPL 1.0 also supports periodic BC's, but the OPAL side has to be fixed.

@adelmann can you please open a new issue with label "feature request" with a clear description? So, we can get rid of the history, we don't need any more. The intention of this issue was to report a bug not a feature request.

What is the status of https://gitlab.psi.ch/OPAL/documentation/manual/-/merge_requests/128 ?