src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2019-08-20T10:44:45+02:00https://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/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/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/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/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/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/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.0krausgsellkraushttps://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/200Optimiser throws unexpected Exceptions and later die2018-01-04T18:14:26+01:00adelmannOptimiser throws unexpected Exceptions and later dieAfter 3ed381f8 I see more Exceptions (merlinl01:/gpfs/home/adelmann/scratch/awa-optim/code/optLinac_40nC.o78706)
I am now a bit more confused:
- the *.data file should only read once (but we have over 600 Exeptions)
- we again have di...After 3ed381f8 I see more Exceptions (merlinl01:/gpfs/home/adelmann/scratch/awa-optim/code/optLinac_40nC.o78706)
I am now a bit more confused:
- the *.data file should only read once (but we have over 600 Exeptions)
- we again have directories that seams to exists
The real problem is reported in merlinl01:/gpfs/home/adelmann/scratch/awa-optim-0/code/optLinac_40nC.o78651
**░░░░░terminate called after throwing an instance of 'OpalException**OPAL 2.0.0krausadelmannYves Ineichenkraushttps://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/182Autophasing gives unexpected results2017-11-19T13:26:34+01:00adelmannAutophasing gives unexpected resultsThe attached lattice works perfect in OPAL 1.4.0 and does not show autophasing information on the *master*.
IN xxxDesignPath.dat we only have NaN's.
[csu_linac.in](/uploads/d8df65871270d3d1f51bf62ca2498266/csu_linac.in)[UOF20LFCell1_B....The attached lattice works perfect in OPAL 1.4.0 and does not show autophasing information on the *master*.
IN xxxDesignPath.dat we only have NaN's.
[csu_linac.in](/uploads/d8df65871270d3d1f51bf62ca2498266/csu_linac.in)[UOF20LFCell1_B.T7](/uploads/0518005dfebb87560f7d4d796e4c683b/UOF20LFCell1_B.T7)[UOF20LHCell1_B.T7](/uploads/050945818499b0fa4b79b3fbd7c5310c/UOF20LHCell1_B.T7)
[UOF20LFCell2_B.T7](/uploads/a0d905e3e6908b712fa2daa96307e650/UOF20LFCell2_B.T7)
[UOF20S1.T7](/uploads/aa07e8534f8cec72e47148db6d45e196/UOF20S1.T7)OPAL 2.0.0krauskraushttps://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/173optimiser run has two times the tmpl file specified2018-01-10T21:15:13+01:00adelmannoptimiser run has two times the tmpl file specifiedargv[1] is a mandatory argument for OPAL, however in case of a optimiser run there is an
additional argument --inputfile=$TEMPLATES/$FNBASE.tmpl. This can be removed and the argv[1] used.argv[1] is a mandatory argument for OPAL, however in case of a optimiser run there is an
additional argument --inputfile=$TEMPLATES/$FNBASE.tmpl. This can be removed and the argv[1] used.OPAL 2.0.0adelmannadelmannhttps://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/171OPAL-t wrong results2017-10-22T10:10:53+02:00adelmannOPAL-t wrong resultsThe attached input files give a consistent solutions in V1.4 and V1.6 as
demonstrated in regtest.pdf.
[regtest.pdf](/uploads/57c7e0d924b6ae43095fe9b0ca133088/regtest.pdf)
With 1.9.x depending on the BFREQ we get a different set of so...The attached input files give a consistent solutions in V1.4 and V1.6 as
demonstrated in regtest.pdf.
[regtest.pdf](/uploads/57c7e0d924b6ae43095fe9b0ca133088/regtest.pdf)
With 1.9.x depending on the BFREQ we get a different set of solutions:
![v1.9err_2](/uploads/221e8b0cd7f810cc8eafaa1c8ac85fa9/v1.9err_2.png)
In case of Hz as units the energy is correct in case of MHz (as it should be)
the energy is wrong.
In both cases Autophase finds the correct energy.
[M_440.T7](/uploads/01c55ee8da1bcbc085eafbf42c7d9338/M_440.T7)
[DriveGun.T7](/uploads/015112fe7906c295a044d37b941c673a/DriveGun.T7)
[BF_550.T7](/uploads/1b31be08c1ea892ed0bfb23110e2310d/BF_550.T7)
[RFphotoinjector-1.9.in](/uploads/7bd8b3675626b4f84e2816f19bea1c74/RFphotoinjector-1.9.in)OPAL 2.0.0krauskraushttps://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/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/166Placement of elements with PSI different from 0 and pi2017-10-15T22:12:10+02:00krausPlacement of elements with PSI different from 0 and piThe elements between dipoles are placed incorrectly when the dipoles have e.g. PSI = pi/2.The elements between dipoles are placed incorrectly when the dipoles have e.g. PSI = pi/2.OPAL 2.0.0krauskraus