src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2020-04-22T11:41:42+02:00https://gitlab.psi.ch/OPAL/src/-/issues/170SurfacePhysics in OPAL-Cyc2020-04-22T11:41:42+02:00Valeria RizzoglioSurfacePhysics in OPAL-CycI ran a small test using OPAL-Cyc - RINGDEFINITION with a CCOLLIMATOR. I applied the SURFACEPHYSICS on the CCOLLIMATOR but the Monte Carlo was not performed. The beam colliding with the CCOLLIMATOR was simply lost and not scattered. This...I ran a small test using OPAL-Cyc - RINGDEFINITION with a CCOLLIMATOR. I applied the SURFACEPHYSICS on the CCOLLIMATOR but the Monte Carlo was not performed. The beam colliding with the CCOLLIMATOR was simply lost and not scattered. This is related to the
Issue #149
```
Coll: SURFACEPHYSICS, TYPE="DEGRADER", ENABLERUTHERFORD=TRUE, MATERIAL="GraphiteR6710";
Quad1_BP: CCollimator, XSTART=-1000, XEND=-1000, YSTART=1800, YEND=1810, ZSTART=70, ZEND=170, WIDTH=200.0, SURFACEPHYSICS=Coll;
```
I tried to change TYPE with "COLLIMATOR" and "CCOLLIMATOR", but the results did not change.
Attached the input file and the output.
[MonteCarlo_Cyc.in](/uploads/013bde1e7b0452d5fbbe266d0a7026ed/MonteCarlo_Cyc.in)[TYPE_COLLIMATOR.out](/uploads/a33c60beb640faccc6353c882565d3a8/TYPE_COLLIMATOR.out)
I ran on Merlin with the following settings:
```
1) gcc/5.4.0 3) OPAL/1.6.0 5) root/6.08.02 7) Tcl/8.6.4 9) Python/2.7.12 11) gsl/2.2.1 13) psi-python27/2.2.0
2) openmpi/1.10.4 4) OPAL/1.6 6) openssl/1.0.2j 8) Tk/8.6.4 10) boost/1.62.0
```OPAL 2.0.0adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/350CMAKE add on NERSC2019-08-20T10:44:45+02:00adelmannCMAKE add on NERSC### Summary
Compilation fails on cori.nersc.gov
### Steps to reproduce
(How one can reproduce the issue - this is very important)
On cori01.nersc.gov try to compile OPAL/master
### What is the current *bug* behavior?
Compilation fai...### Summary
Compilation fails on cori.nersc.gov
### Steps to reproduce
(How one can reproduce the issue - this is very important)
On cori01.nersc.gov try to compile OPAL/master
### What is the current *bug* behavior?
Compilation fails
### Relevant logs and/or screenshots
none
### Possible fixes
For any one else who might be compiling soon.
Adding one line to CMakeLists.txt allowed me to use the defaults on NERSC:
```
cookbg@cori01:~/consult/INC0141785/src> ls
diff --git a/CMakeLists.txt b/CMakeLists.txt
index c60179a4..29d64821 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -126,6 +126,7 @@ if (USE_STATIC_LIBRARIES)
endif ()
set (Boost_USE_MULTITHREADED OFF)
set (Boost_USE_STATIC_RUNTIME OFF)
+set (Boost_NO_BOOST_CMAKE ON)
find_package (Boost
REQUIRED COMPONENTS chrono filesystem iostreams regex serialization system timer)
if (Boost_INCLUDE_DIRS)
```OPAL 2.0.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/323could not find node responsible for particle2019-06-28T15:00:23+02:00adelmanncould not find node responsible for particleThis happens running a big sampler job (17'000 cores), maybe I find the
input file responsible for that.
```
Error{0}>
Error{0}> *** Runtime-error ******************
Error{0}> could not find node responsible for particle;
Error{0}...This happens running a big sampler job (17'000 cores), maybe I find the
input file responsible for that.
```
Error{0}>
Error{0}> *** Runtime-error ******************
Error{0}> could not find node responsible for particle;
Error{0}> mesh does not seem correctly adapted to particle distribution
Error{0}> Assertion 'touchingVN.first != touchingVN.second' failed in
Error{0}> /users/adelmann/git/opal/ippl/src/Particle/ParticleSpatialLayout.h on line 1203.
Error{0}>
Error{0}> ************************************
Error{0}>
```
However, in such a situation, instead of giving up can we
a) try to re-grid if enough particles available
or
b) exit nicely i.e. such that the parallel job is not failingOPAL 2.0.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/319SAMPLER should write json file on the fly and not at the end2019-06-28T14:45:13+02:00adelmannSAMPLER should write json file on the fly and not at the endThe SAMPLER should write json file on the fly (update) and not only at the end. Hence,
if the simulation does not make it to the end, we have still have a dataset that can be used.The SAMPLER should write json file on the fly (update) and not only at the end. Hence,
if the simulation does not make it to the end, we have still have a dataset that can be used.OPAL 2.0.0frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/174optimiser run hasResultsAvailable()2019-04-06T10:08:12+02:00adelmannoptimiser run hasResultsAvailable()it seams that hasResultsAvailable() is sometimes true after I removed
the pid from the hash string. This was necessary when more than
one $CORE is used for a worker.
I probable need to add this back but not with the pid but with an
id ...it seams that hasResultsAvailable() is sometimes true after I removed
the pid from the hash string. This was necessary when more than
one $CORE is used for a worker.
I probable need to add this back but not with the pid but with an
id that represents the "worker with more than one core"
@ineichen can you point me to that structure.OPAL 2.0.0adelmannYves Ineichenadelmann2017-10-28https://gitlab.psi.ch/OPAL/src/-/issues/92ENABLERUTHERFORD and DKS2019-03-15T13:40:02+01:00Valeria RizzoglioENABLERUTHERFORD and DKSI am testing the attribute **ENABLERUTHERFORD=FALSE** using the new OPAL module OPAL/1.5.2.
Analysing the particle distribution, I have noticed that phase space is different with and without DKS.
* **Run without DKS:** ` mpirun -np 8...I am testing the attribute **ENABLERUTHERFORD=FALSE** using the new OPAL module OPAL/1.5.2.
Analysing the particle distribution, I have noticed that phase space is different with and without DKS.
* **Run without DKS:** ` mpirun -np 8 opal Degrader_1Slab_230.in`
![OPAL_1.5.2_nodks](/uploads/135423a9df3842bc730cd54969389a75/OPAL_1.5.2_nodks.png)
* **Run with DKS:** ` mpirun -np 8 opal --use-dks Degrader_1Slab_230.in`
![OPAL_1.5.2_dks](/uploads/13a3731c8b3871d1e88630ab08d851cf/OPAL_1.5.2_dks.png)
It seems that running with DKS the attribute **ENABLERUTHERFORD** has not been implemented.
Here the input file: [Degrader_1Slab_230.in](/uploads/de37f170435fcdda5e621019974dda1e/Degrader_1Slab_230.in)OPAL 2.0.0baumgartenchristian.baumgarten@psi.chbaumgartenchristian.baumgarten@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/172All Fields in an expression must be aligned. (Do you have enough guard cells...2018-12-10T14:33:40+01:00adelmannAll Fields in an expression must be aligned. (Do you have enough guard cells?) OPAL-cyclmerlin-l-01:/gpfs/home/adelmann/scratch/UQ/isodar-1-O3/
Accelerated_BEAMCURRENT=0.0075_HW1=8.344454524637621_HL1=2.542497630448107_HW2=8.344454524637621_HL2=2.607642038949257
slurm-12130.out
```
OPAL{0}> *** Finished turn 23, Total num...merlin-l-01:/gpfs/home/adelmann/scratch/UQ/isodar-1-O3/
Accelerated_BEAMCURRENT=0.0075_HW1=8.344454524637621_HL1=2.542497630448107_HW2=8.344454524637621_HL2=2.607642038949257
slurm-12130.out
```
OPAL{0}> *** Finished turn 23, Total number of live particles: 330298
OPAL{0}> * Cavity RF1B Phase= 8.1602 [deg] transit time factor= 0.99972 dE= 0.091803 [MeV] E_kin= 15.05 [MeV]
OPAL{0}> * Cavity RF2A Phase= 17.119 [deg] transit time factor= 0.99972 dE= 0.089672 [MeV] E_kin= 15.14 [MeV]
OPAL{0}> * Cavity RF2B Phase= 8.4183 [deg] transit time factor= 0.99972 dE= 0.092922 [MeV] E_kin= 15.233 [MeV]
Error{4}> All Fields in an expression must be aligned. (Do you have enough guard cells?)
Error{4}> This error occurred while evaluating an expression for an LField with domain {[8:15:1],[0:8:1],[0:7:1]}
slurmstepd: error: *** JOB 12130 ON merlin-c-07 CANCELLED AT 2017-10-13T15:39:58 ***
```
*AND*
Accelerated_BEAMCURRENT=0.0075_HW1=7.655545475362379_HL1=2.607642038949257_HW2=8.344454524637621_HL2=2.542497630448107]
slurm-12492.out
```
OPAL{0}> * Cavity RF3B Phase= -1.6424 [deg] transit time factor= 0.99995 dE= 0.20723 [MeV] E_kin= 94.092 [MeV]
OPAL{0}> * Cavity RF4A Phase= 9.16 [deg] transit time factor= 0.99995 dE= 0.20493 [MeV] E_kin= 94.297 [MeV]
OPAL{0}> *** Finished turn 92, Total number of live particles: 289527
OPAL{0}> * Cavity RF2A Phase= 8.5664 [deg] transit time factor= 0.99995 dE= 0.20576 [MeV] E_kin= 95.123 [MeV]
OPAL{0}> * Cavity RF3A Phase= 8.5013 [deg] transit time factor= 0.99995 dE= 0.20631 [MeV] E_kin= 95.537 [MeV]
OPAL{0}> * Cavity RF3B Phase= -1.9567 [deg] transit time factor= 0.99995 dE= 0.2086 [MeV] E_kin= 95.746 [MeV]
Error{3}> All Fields in an expression must be aligned. (Do you have enough guard cells?)
Error{3}> This error occurred while evaluating an expression for an LField with domain {[0:5:1],[8:15:1],[8:15:1]}
slurmstepd: error: *** JOB 12492 ON merlin-c-40 CANCELLED AT 2017-10-16T03:25:28 DUE TO TIME LIMIT ***
```
*Go from 8 to 4 cores* in order to find out if the job is terminating nicely.OPAL 2.0.0adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/122Attempt to create IpplInfo with argc, argv again.2018-11-25T16:01:27+01:00adelmannAttempt to create IpplInfo with argc, argv again.Brach: scalable-emission and use OPAL in optimiser mode
Warning> Attempt to create IpplInfo with argc, argv again.
Warning> Using previous argc,argv settings.
merlinl01:/gpfs/home/adelmann/scratch/opt-pilot-week/ANL/optLinac-1
use ru...Brach: scalable-emission and use OPAL in optimiser mode
Warning> Attempt to create IpplInfo with argc, argv again.
Warning> Using previous argc,argv settings.
merlinl01:/gpfs/home/adelmann/scratch/opt-pilot-week/ANL/optLinac-1
use runopt-opal.sgeOPAL 2.0.0adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/252Optimizer: Mutation + CrossOver at runtime2018-10-28T22:39:57+01:00frey_mOptimizer: Mutation + CrossOver at runtimeThe cross over and mutation are template parameters. Currently, we only use "BlendCrossover" and "IndependentBitMutation". It would be nice to select this at runtime.The cross over and mutation are template parameters. Currently, we only use "BlendCrossover" and "IndependentBitMutation". It would be nice to select this at runtime.OPAL 2.0.0frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/139Replace length given in input file with length of field map2018-09-22T15:45:42+02:00krausReplace length given in input file with length of field mapOPAL 2.0.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/224CollimatorPhysics not working with Flexcol2018-06-22T11:11:14+02:00krausCollimatorPhysics not working with FlexcolHave to adapt CollimatorPhysics class to support FlexibleCollimator.Have to adapt CollimatorPhysics class to support FlexibleCollimator.OPAL 2.0.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/47Erice Work List2018-06-12T10:12:45+02:00adelmannErice Work ListWe should start with a list of things we want to achiveWe should start with a list of things we want to achiveOPAL 2.0.0adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/207Virtual memory exhausted2018-06-05T09:22:31+02:00adelmannVirtual memory exhaustedDoes anybody know this error?
```
*** Error:
Error{3}> *** in line 76 of file "opal_FermiD.in":
Error{3}> RUN,METHOD="PARALLEL-T",BEAM=BEAM1,FIELDSOLVER=FS1,DISTRIBUTION=DIST1;
Error{3}> Sorry, virtual memory exhausted.
```
I’...Does anybody know this error?
```
*** Error:
Error{3}> *** in line 76 of file "opal_FermiD.in":
Error{3}> RUN,METHOD="PARALLEL-T",BEAM=BEAM1,FIELDSOLVER=FS1,DISTRIBUTION=DIST1;
Error{3}> Sorry, virtual memory exhausted.
```
I’m trying to simulated a NONEQUIL- emission from a cathode.
The files are at merlin-l-01:~adelmann/KuskeOPAL 2.0.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/195Strange element positions RINGDEFINITION2018-05-18T16:22:00+02:00Valeria RizzoglioStrange element positions RINGDEFINITIONI tried to run my simulation using the RINGDEFINITION and Sbend3D with OPAL/1.9.
Starting from the input file properly running with OPAL/1.6, I have
* update the version number
* replace DISTRIBUTION=FROMFILE with TYPE=FROMFILE
all t...I tried to run my simulation using the RINGDEFINITION and Sbend3D with OPAL/1.9.
Starting from the input file properly running with OPAL/1.6, I have
* update the version number
* replace DISTRIBUTION=FROMFILE with TYPE=FROMFILE
all the rest of the input file is unchanged.
I realized that there is a problem with the element position:
* OPAL1.6 (correct)
```
OPAL> * Added OFFSET to Ring
OPAL> * Start position (-1547.1, 9.47297e-14, 0) normal (6.12303e-17, 1, 0), phi 6.12303e-17
OPAL> * End position (-1547.1, 1800, 0) normal (6.12303e-17, 1, 0)
OPAL> * Added MAPS to Ring
OPAL> * Start position (-1547.1, 1800, 0) normal (6.12303e-17, 1, 0), phi 6.12303e-17
OPAL> * End position (1297.51, 2642.61, 0) normal (0.544639, -0.838671, 0)
```
* OPAL1.9
```
OPAL> * Added OFFSET to Ring
OPAL> * Start position (-1.5471e+06, 9.47297e-11, 0) normal (6.12303e-17, 1, 0), phi 6.12303e-17
OPAL> * End position (-1.5471e+06, 1800, 0) normal (6.12303e-17, 1, 0)
OPAL> * Added MAPS to Ring
OPAL> * Start position (-1.5471e+06, 1800, 0) normal (6.12303e-17, 1, 0), phi 6.12303e-17
OPAL> * End position (-1.54426e+06, 2642.61, 0) normal (0.544639, -0.838671, 0)
```
Are there modification also to RINGDEFINITION element between OPAL/1.6 and OPAL/1.9? I don't get any warning or error message.OPAL 2.0.0ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/157Cyclotron trim coil has discontinuous derivative2018-04-26T15:35:40+02:00snuverink_jjochem.snuverink@psi.chCyclotron trim coil has discontinuous derivativefollow up from issue #110 as discussed there.
![image](/uploads/b10d3189af1733a1fefaecdff531d423/image.png)
As can be seen in the figure the derivative of the B field is discontinuous in the middle of the trim coil. This comes by [cons...follow up from issue #110 as discussed there.
![image](/uploads/b10d3189af1733a1fefaecdff531d423/image.png)
As can be seen in the figure the derivative of the B field is discontinuous in the middle of the trim coil. This comes by [construction of the calculation](https://gitlab.psi.ch/OPAL/src/blob/9118749a7c5ffa2657ff9d11393f3b839171e2b2/src/Classic/AbsBeamline/Cyclotron.cpp#L118).
I think it would be good to:
* find out where the calculation comes from (see also comment https://gitlab.psi.ch/OPAL/src/issues/110#note_2391)
* get some measured trim coil profiles to see how important the effect could be.
Task list added 26 March (from https://gitlab.psi.ch/OPAL/src/issues/157#note_5500):
* [x] PSI-trim coils polynomial fit (with minimal order) (@frey_m)
* [x] OPAL trim coil polynomial input (@snuverink_j)
* [x] Comparison with current implementation for TC15, make polynomial input default (@frey_m, @snuverink_j)
* [x] Documentation
* [x] Regression/Unit testOPAL 2.0.0snuverink_jjochem.snuverink@psi.chfrey_msnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/210Check that entrance and exit fringe fields of dipoles don't overlap2018-04-23T12:49:55+02:00krausCheck that entrance and exit fringe fields of dipoles don't overlapThe particles can either be in the entrance fringe field, the exit fringe field or in the constant field inbetween. Overlapping fringe fields (in a single dipole) isn't supported. We should check that the fringe fields comply to this con...The particles can either be in the entrance fringe field, the exit fringe field or in the constant field inbetween. Overlapping fringe fields (in a single dipole) isn't supported. We should check that the fringe fields comply to this constraint.OPAL 2.0.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/167Proper parsers of optPilot commands that is based on OpalParser2018-04-11T11:39:52+02:00krausProper parsers of optPilot commands that is based on OpalParserSofar the parser for optPilot within OPAl is rather a hack than properly done.Sofar the parser for optPilot within OPAl is rather a hack than properly done.OPAL 2.0.0kraussnuverink_jjochem.snuverink@psi.chkraushttps://gitlab.psi.ch/OPAL/src/-/issues/202Scan-1 regression test is broken2018-03-30T19:06:21+02:00snuverink_jjochem.snuverink@psi.chScan-1 regression test is brokenNow that the Scan option is fixed (issue #2) the regression test [Scan-1](https://gitlab.psi.ch/OPAL/regression-tests/tree/master/RegressionTests/Scan-1) looks [better](http://amas.web.psi.ch/opal/regressionTests/master/results_2018-01-0...Now that the Scan option is fixed (issue #2) the regression test [Scan-1](https://gitlab.psi.ch/OPAL/regression-tests/tree/master/RegressionTests/Scan-1) looks [better](http://amas.web.psi.ch/opal/regressionTests/master/results_2018-01-08.xml#Scan-1_rms_x), but is still broken.
@kraus: do you perhaps understand why?OPAL 2.0.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/212Cyclotron example in manual is broken2018-03-19T15:17:59+01:00adelmannCyclotron example in manual is brokenThe example (https://gitlab.psi.ch/OPAL/src/wikis/Cyclotron). in the Wiki manual does not work as pointed out by Kengo-sanThe example (https://gitlab.psi.ch/OPAL/src/wikis/Cyclotron). in the Wiki manual does not work as pointed out by Kengo-sanOPAL 2.0.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/203Structure/H5PartWrapper.cpp Error2018-01-11T08:45:06+01:00adelmannStructure/H5PartWrapper.cpp ErrorOn merlin: */gpfs/home/adelmann/scratch/opal-scaling/Merlin/test* check **scaling-1.o92428**
`Error{91}> H5 rc= -2 in /gpfs/home/adelmann/opal/opal-1.9/src/Structure/H5PartWrapper.cpp @ line 94`
The simulation does not crash maybe als...On merlin: */gpfs/home/adelmann/scratch/opal-scaling/Merlin/test* check **scaling-1.o92428**
`Error{91}> H5 rc= -2 in /gpfs/home/adelmann/opal/opal-1.9/src/Structure/H5PartWrapper.cpp @ line 94`
The simulation does not crash maybe also because **OPTION, PSDUMPFREQ = 1E9;**OPAL 2.0.0krausgsellkraus