OPAL-Cycl - COMET

I have been using a locally compiled code with a version number 1.2.1 SVN. I have also run the program through module load with a version number 1.4.3. The loss files are basically the same.

Attached is the input file vc.in. Two phase slits CMA1 and CMA2 work quite well. However, the loss data from the vertical collimators, for example, from the pair VC7 and VC8, often register the same particles.

vc.in

changed title from OPAL-Cyclo - COMET to OPAL-Cycl - COMET

assigned to @zhang_h

Can you add the complete input files, in case they are to large please indicate where I can find them.

What version are you using?

added Bug label

assigned to @adelmann

changed milestone to %OPAL 1.6.0

added ~47 ~48 labels

The input data is in OPAL-test/COMET/vc_test.in

I also tested different versions of opal via module load gcc/4.8.3 openmpi/1.8.2 OPAL/versionNo. Here are the outcomes.

Loaded 1.4.0rc3, 1.4.0rc3 shown in out file, zstart and zend not accepted, only default -100 and +100, no loss data created.

Loaded 1.4.0rc2, 1.3.99.1 shown in out file, zstart and zend accepted, loss data created, VCO.loss contains particles in VCU.loss.

Loaded 1.4.0, 1.4.0 shown in out file, zstart and zend not accepted, only default -100 and +100, no loss data created.

Loaded 1.3.2, 1.3.2 shown in out file, zstart and zend accepted, loss data created, VCO.loss contains particles in VCU.loss.

I have run vc.in with OPAL/1.5.0-20170126 available also on merlin and found good results however due to lack of understanding the geometry/problem I am maybe wrong. However please have a look at the attached out file and give feedback if that is ok from your point of view. I removed the SURFACEPHYSICS for the moment in order to have a simpler problem.

vc.in vc-trackOrbit.dat vc.out

copy/paste from email of @zhang_h:

1. Could you exchange the position of vc7 and vc8 in the LINE command of the input file, run the simulation, check whether both vc7.loss and vc8.loss are created, and check whether vc7.loss contains particles between 2.25 and 3 mm.

2. Could you then change the E-scaling from ESCALE={ef1,ef2,ef3,ef4,3.0}, to ESCALE={ef1,ef2,ef3,ef4,0.0}, increase the NPART to 2000, run the simulation,then check whether vc7.loss and vc8.loss overlap with each other partially.

The particle number in output file is correct. Nevertheless, the particles registered by the lossDataSink are often overlapped with each other. I believe, when particles hit two collimators within the same time step, the loss data for the collimator laying behind on the LINE command will register also the particles hitting the collimator laying in front on the LINE command. This causes the partial overlapping. One may reduce the overlapping partially by reducing the time step, but not completely. There might always be some particles hitting the pair of vertical collimators within one time step.

Indeed it is possible that the same particle is stored in more than one collimator. The problem is solved testing is in progress.

A comment to begin with: using a low number of particles for example 200 is a perfect valid approach to get the simulation going. However if one is collimating tails, with 200 particles maybe none of the guys are hitting the collimator and hence the collimator is never going online. True collimation studies in the end relay on statistics i.e. a sufficient number of particles.

Quoting @zhang_h: The new version works fine. Attached is the x-z plot for the turn 3 to 8 starting with 20000 particles, as well as the boundaries of the vertical collimators, which shows the particles collected by the collimators and registered by the probe. There is now no overlapping at all.

closed