src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2018-09-18T16:29:27+02:00https://gitlab.psi.ch/OPAL/src/-/issues/234Option CLOTUNEONLY to be implemented2018-09-18T16:29:27+02:00snuverink_jjochem.snuverink@psi.chOption CLOTUNEONLY to be implementedFrom discussion in Manual-2.0#1: the option CLOTUNEONLY needs to be implemented:
`CLOTUNEONLY: If set to true stop after CLO and tune calculation.`From discussion in Manual-2.0#1: the option CLOTUNEONLY needs to be implemented:
`CLOTUNEONLY: If set to true stop after CLO and tune calculation.`cortes_ccortes_chttps://gitlab.psi.ch/OPAL/src/-/issues/233Optimiser: Parsing of expressions2018-12-10T14:34:25+01:00frey_mOptimiser: Parsing of expressionsI added the new function ```infNormRadialPeak```. However, it's not recognized. It crashes with ```Parsing failed!```. I do not see a difference to other expressions.
According to [line 180](https://gitlab.psi.ch/OPAL/src/blob/master/op...I added the new function ```infNormRadialPeak```. However, it's not recognized. It crashes with ```Parsing failed!```. I do not see a difference to other expressions.
According to [line 180](https://gitlab.psi.ch/OPAL/src/blob/master/optimizer/Expression/Expression.h#L180) it checks
```
if (success && iter != end) {
std::cout << "Parsing failed!" << std::endl;
throw new OptPilotException("Expression::parse()",
"Parsing failed!");
}
```
I think it should be ```!success``` and ```ìter == end``` instead. A first test confirms my proposal, i.e. it still works with
e.g. ```sumErrSqRadialPeak``` but now also with ```infNormRadialPeak```.frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/232Add argument DISTRIBUTIONDIR to Optimizer and Sample Command2018-07-30T08:36:17+02:00snuverink_jjochem.snuverink@psi.chAdd argument DISTRIBUTIONDIR to Optimizer and Sample CommandFrom @ext-bershanska_a: "It would be nice to add OPTIMIZER attribute for distribution directory (like for runOPAL.py)"From @ext-bershanska_a: "It would be nice to add OPTIMIZER attribute for distribution directory (like for runOPAL.py)"frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/231Add z coordinate to stat file2018-07-11T16:57:17+02:00snuverink_jjochem.snuverink@psi.chAdd z coordinate to stat fileProposal from @winklehner_d and @ext-bershanska_a:
Add the z coordinate of the reference particle to the stat file (seems like only s is given, which probably stems from the mismatch between OPAL-T and OPAL-cycl coordinate systems).Proposal from @winklehner_d and @ext-bershanska_a:
Add the z coordinate of the reference particle to the stat file (seems like only s is given, which probably stems from the mismatch between OPAL-T and OPAL-cycl coordinate systems).snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/230Non-existing objective gives segfault2018-06-22T11:11:14+02:00snuverink_jjochem.snuverink@psi.chNon-existing objective gives segfaultAs seen with @frey_m: in the `OPTIMIZE` command, a non-existing objective gives a segfault. Rather a warning should be printed.
```
OPAL{0}> opal opt-pilot/optRing.in --inputfile=template/Ring.tmpl --outfile=RingOpt --outdir=RingOpt --i...As seen with @frey_m: in the `OPTIMIZE` command, a non-existing objective gives a segfault. Rather a warning should be printed.
```
OPAL{0}> opal opt-pilot/optRing.in --inputfile=template/Ring.tmpl --outfile=RingOpt --outdir=RingOpt --initialPopulation=31 --num-masters=1 --num-coworkers=1 --num-ind-gen=31 --maxGenerations=30 --gene-mutation-probability=0.5 --mutation-probability=0.5 --recombination-probability=0.5 --simtmpdir=/home/scratch/AMAS-BDSModels/PSI-Ring/tmp --templates=/home/scratch/AMAS-BDSModels/PSI-Ring/template
[pc12290:09252] *** Process received signal ***
[pc12290:09252] Signal: Segmentation fault (11)
[pc12290:09252] Signal code: Address not mapped (1)
[pc12290:09252] Failing at address: 0x10
[pc12290:09249] *** Process received signal ***
[pc12290:09249] Signal: Segmentation fault (11)
[pc12290:09249] Signal code: Address not mapped (1)
[pc12290:09249] Failing at address: 0x10
[pc12290:09252] [ 0] [pc12290:09249] [ 0] /lib64/libpthread.so.0[0x3ab660f7e0]
[pc12290:09249] [ 1] /lib64/libpthread.so.0[0x3ab660f7e0]
[pc12290:09252] [ 1] opal(_ZNK9Objective13getExpressionB5cxx11Ev+0x1)[0x710301]
[pc12290:09252] opal(_ZNK9Objective13getExpressionB5cxx11Ev+0x1)[0x710301]
[pc12290:09249] [ 2] [ 2] -------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
-------------------------------------------------------
opal(_ZN11OptimizeCmd7executeEv+0x24cb)[0x6d679b]
[pc12290:09249] [ 3] opal(_ZN11OptimizeCmd7executeEv+0x24cb)[0x6d679b]
[pc12290:09252] [ 3] opal(_ZNK10OpalParser7executeEP6ObjectRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x3a)[0x6c8b1a]
[pc12290:09249] [ 4] opal(_ZNK10OpalParser11parseActionER9Statement+0x142)[0x6cce92]
[pc12290:09249] [ 5] opal(_ZNK10OpalParser5parseER9Statement+0x173)[0x6cc733]
[pc12290:09249] [ 6] opal(_ZNK10OpalParser3runEv+0x2c)[0x6c87bc]
[pc12290:09249] [ 7] opal(_ZNK10OpalParser3runEP11TokenStream+0x70)[0x6cd5b0]
[pc12290:09249] [ 8] opal(main+0x1e8f)[0x618bef]
[pc12290:09249] [ 9] /lib64/libc.so.6(__libc_start_main+0xfd)[0x3ab5e1ed1d]
[pc12290:09249] [10] opal[0x60b559]
[pc12290:09249] *** End of error message ***
opal(_ZNK10OpalParser7executeEP6ObjectRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x3a)[0x6c8b1a]
[pc12290:09252] [ 4] opal(_ZNK10OpalParser11parseActionER9Statement+0x142)[0x6cce92]
[pc12290:09252] [ 5] opal(_ZNK10OpalParser5parseER9Statement+0x173)[0x6cc733]
[pc12290:09252] [ 6] opal(_ZNK10OpalParser3runEv+0x2c)[0x6c87bc]
[pc12290:09252] [ 7] opal(_ZNK10OpalParser3runEP11TokenStream+0x70)[0x6cd5b0]
[pc12290:09252] [ 8] opal(main+0x1e8f)[0x618bef]
[pc12290:09252] [ 9] /lib64/libc.so.6(__libc_start_main+0xfd)[0x3ab5e1ed1d]
[pc12290:09252] [10] opal[0x60b559]
[pc12290:09252] *** End of error message ***
```snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/229All Fields in an expression must be aligned.2018-06-01T07:42:41+02:00adelmannAll Fields in an expression must be aligned.When running the attached Cyclotron simulation with 8 cores we get after 13 turns the following error:
`Error{0}> All Fields in an expression must be aligned. (Do you have enough guard cells?)
Error{0}> This error occurred while evalu...When running the attached Cyclotron simulation with 8 cores we get after 13 turns the following error:
`Error{0}> All Fields in an expression must be aligned. (Do you have enough guard cells?)
Error{0}> This error occurred while evaluating an expression for an LField with domain {[0:6:1],[0:6:1],[0:7:1]}
Warning{0}> CommMPI: Found extra message from node 1, tag 20996: msg = Message contains 6 items (0 removed). Contents:
Warning{0}> Item 0: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 1: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 2: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 3: 1 elements, 4 bytes total, needDelete = 0
Warning{0}> Item 4: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 5: 49 elements, 1176 bytes total, needDelete = 0
Warning{0}>
Warning{0}> CommMPI: Found extra message from node 2, tag 20996: msg = Message contains 6 items (0 removed). Contents:
Warning{0}> Item 0: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 1: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 2: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 3: 1 elements, 4 bytes total, needDelete = 0
Warning{0}> Item 4: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 5: 56 elements, 1344 bytes total, needDelete = 0
Warning{0}>
Warning{0}> CommMPI: Found extra message from node 3, tag 20996: msg = Message contains 6 items (0 removed). Contents:
Warning{0}> Item 0: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 1: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 2: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 3: 1 elements, 4 bytes total, needDelete = 0
Warning{0}> Item 4: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 5: 7 elements, 168 bytes total, needDelete = 0
Warning{0}>
Warning{0}> CommMPI: Found extra message from node 4, tag 20996: msg = Message contains 6 items (0 removed). Contents:
Warning{0}> Item 0: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 1: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 2: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 3: 1 elements, 4 bytes total, needDelete = 0
Warning{0}> Item 4: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 5: 56 elements, 1344 bytes total, needDelete = 0
Warning{0}>
Warning{0}> CommMPI: Found extra message from node 5, tag 20996: msg = Message contains 6 items (0 removed). Contents:
Warning{0}> Item 0: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 1: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 2: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 3: 1 elements, 4 bytes total, needDelete = 0
Warning{0}> Item 4: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 5: 7 elements, 168 bytes total, needDelete = 0
Warning{0}>
Warning{0}> CommMPI: Found extra message from node 6, tag 20996: msg = Message contains 6 items (0 removed). Contents:
Warning{0}> Item 0: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 1: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 2: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 3: 1 elements, 4 bytes total, needDelete = 0
Warning{0}> Item 4: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 5: 8 elements, 192 bytes total, needDelete = 0
Warning{0}>
Warning{0}> CommMPI: Found extra message from node 7, tag 20996: msg = Message contains 6 items (0 removed). Contents:
Warning{0}> Item 0: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 1: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 2: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 3: 1 elements, 4 bytes total, needDelete = 0
Warning{0}> Item 4: 3 elements, 12 bytes total, needDelete = 0
Warning{0}> Item 5: 1 elements, 24 bytes total, needDelete = 0
Warning{0}>
`
Notes:
1. with a restart the error disappears
2. same errors are also visible with OPAL-t
3. related issues #172 and #226
[guard-cell-error.tgz](/uploads/fc096c1c03654c8cd5cad3d21a962870/guard-cell-error.tgz)https://gitlab.psi.ch/OPAL/src/-/issues/228Restart optimizer from generation file2019-02-23T10:03:25+01:00frey_mRestart optimizer from generation file@snuverink_j and I discussed that it would be a nice feature of restarting the optimizer from a generation file. If the user put the generation number too low, this feature would help to continue computation instead of starting from scra...@snuverink_j and I discussed that it would be a nice feature of restarting the optimizer from a generation file. If the user put the generation number too low, this feature would help to continue computation instead of starting from scratch.frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/226Error{0}> All Fields in an expression must be aligned2018-05-14T09:13:01+02:00adelmannError{0}> All Fields in an expression must be alignedhttps://gitlab.psi.ch/OPAL/src/-/issues/225SCAN option adapted from OPTIMIZE command2018-06-22T11:11:14+02:00snuverink_jjochem.snuverink@psi.chSCAN option adapted from OPTIMIZE commandFrom a discussion in runOPAL#7 with @rizzoglio_v suggested by @adelmann. The optimiser mechanism of running with a master core that spawns several opal jobs can be adapted to run a scan through a parameter list. Compared to the scan opti...From a discussion in runOPAL#7 with @rizzoglio_v suggested by @adelmann. The optimiser mechanism of running with a master core that spawns several opal jobs can be adapted to run a scan through a parameter list. Compared to the scan option of runOPAL, an advantage is a single job in a batch system, and possibly better grouping of results.
E.g.
```
dv0: DVAR, VARIABLE="P0", LOWERBOUND=-10.0, UPPERBOUND=0.0, STEP = 0.5;
dv1: DVAR, VARIABLE="P1", LOWERBOUND=-10.0, UPPERBOUND=0.0, STEP = 1.0;
SCAN, INPUT="tmpl/model.tmpl",
OUTPUT="model",
OUTDIR="results",
DVARS = {dv0, dv1},
NUM_MASTERS=1,
NUM_COWORKERS=8,
SIMTMPDIR="tmp",
TEMPLATEDIR="tmpl",
FIELDMAPDIR="fieldmaps";
```
cc: @frey_mfrey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/223The flexible collimator yields different results on different computers2018-04-19T09:16:01+02:00krausThe flexible collimator yields different results on different computersThe regression tests slit-1 and slit-2 fail on opalrunner while they yield correct results on my laptop.The regression tests slit-1 and slit-2 fail on opalrunner while they yield correct results on my laptop.krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/222Warnings and notes for OPAL V 2.x.x2018-05-02T22:33:28+02:00adelmannWarnings and notes for OPAL V 2.x.xThis is a summary of warnings to be addressed with very low priority:
nsga2, C build:
`Scanning dependencies of target wfgHypervolume
cc1: warning: command line option '-ftemplate-depth=1024' is valid for C++/ObjC++ but not for C
cc1: ...This is a summary of warnings to be addressed with very low priority:
nsga2, C build:
`Scanning dependencies of target wfgHypervolume
cc1: warning: command line option '-ftemplate-depth=1024' is valid for C++/ObjC++ but not for C
cc1: warning: command line option '-ftemplate-depth=1024' is valid for C++/ObjC++ but not for C
cc1: warning: command line option '-ftemplate-depth=1024' is valid for C++/ObjC++ but not for C`
`/gpfs/home/adelmann/opal/opal-1.9/optimizer/extlib/nsga2/nsga2_functions.c: In function 'initialize':
/gpfs/home/adelmann/opal/opal-1.9/optimizer/extlib/nsga2/nsga2_functions.c:67:9: warning: variable 'result' set but not used [-Wunused-but-set-variable]
int result;`
^~~~~~
`In file included from /gpfs/home/adelmann/opal/opal-1.9/src/Classic/FixedAlgebra/FTpsData.h:25:0,
from /gpfs/home/adelmann/opal/opal-1.9/src/Classic/FixedAlgebra/FTps.h:23,
from /gpfs/home/adelmann/opal/opal-1.9/src/Classic/Algorithms/Mapper.h:25,
from /gpfs/home/adelmann/opal/opal-1.9/src/Algorithms/LieMapper.h:21,
from /gpfs/home/adelmann/opal/opal-1.9/src/Algorithms/LieMapper.cpp:21:
/gpfs/home/adelmann/opal/opal-1.9/src/Classic/FixedAlgebra/FArray1D.h: In static member function 'static int DragtFinnMap<N>::orderModes(FMatrix<double, (2 * N), (2 * N)>&, FVector<std::complex<double>, (2 * N)>&) [with int N = 3]':
/gpfs/home/adelmann/opal/opal-1.9/src/Classic/FixedAlgebra/FArray1D.h:163:16: warning: array subscript is above array bounds [-Warray-bounds]
return data[i];
~~~~^
/gpfs/home/adelmann/opal/opal-1.9/src/Classic/FixedAlgebra/FArray1D.h:163:16: warning: array subscript is above array bounds [-Warray-bounds]`
`In file included from /gpfs/home/adelmann/opal/opal-1.9/optimizer/Util/HashNameGenerator.h:5:0,
from /gpfs/home/adelmann/opal/opal-1.9/src/Optimize/OpalSimulation.cpp:18:
/opt/psi/Compiler/boost/1.66.0/gcc/7.3.0/include/boost/uuid/sha1.hpp:13:97: note: #pragma message: This header is implementation detail and provided for backwards compatibility.
#pragma message("This header is implementation detail and provided for backwards compatibility.")`https://gitlab.psi.ch/OPAL/src/-/issues/221Trajectory in Dipole Parallel-T2018-04-16T14:40:52+02:00ganz_pTrajectory in Dipole Parallel-T# Observation
In the comparison of the created maps form ``Thick Tracker`` (which I am working on) and the maps of [Cosy Infinity](http://bt.pa.msu.edu/index_cosy.htm) , I have noticed a difference between the dipole maps.
>>>
The COSY ...# Observation
In the comparison of the created maps form ``Thick Tracker`` (which I am working on) and the maps of [Cosy Infinity](http://bt.pa.msu.edu/index_cosy.htm) , I have noticed a difference between the dipole maps.
>>>
The COSY 10.0 input:
[CompBend.fox](/uploads/37e610e2157229a00e7d9ed442661a22/CompBend.fox)
[cosy.fox](/uploads/6f9436e131a003fd80cb80cf53989f0d/cosy.fox)
>>>
In the closer look: the ``Thick Tracker`` algorithm uses the parameter ``ElementLength``, which is the value ``L`` of the ``Input.in``- file.
```c++
class ElementBase
...
/// Get design length.
// Return the design length defined by the geometry.
// This may be the arc length or the straight length. <-----
inline
double ElementBase::getElementLength() const
{ return getGeometry().getElementLength(); }
```
The ``ElementLength`` in a ``SectorBend`` is the **straight** Trajectory in between the entrance and exit point of the ref particle, as documented.
![sbend](/uploads/89b975bd285550ee2e8f833bc159f914/sbend.png)
>>>
form: https://gitlab.psi.ch/OPAL/src/wikis/Manual/elements
>>>
**BUT** if I now compare the ``THICK TRACKER`` with ``PARALLEL-T``, like in the issue #215, it won't match this smoothly.
![2018-04-11_20_16_45](/uploads/1763d402c4bfff3bd95c3a1fe4988181/2018-04-11_20_16_45.png)
>>>
[70MeV_Gantry2.in MAPS](/uploads/8d0344b5620a46a39d2e15e24eb101c6/70MeV_Gantry2.in)
[70MeV_Gantry2.in TRACK](/uploads/e8b7c52945171277d9b81e92a7826833/70MeV_Gantry2.in)
>>>
The two map generated Codes differ in the use of either the **straight** or the **curved** trajectory for the creation of the dipole map. (In the curved implementation I just changed the map, but not its position to visualize the effect of this change.)
# Suggested Solution
After that comparison, I think that there might be a bug in the ``SectorBend``, which probably is just the use of the straight instead of the curved trajectory.https://gitlab.psi.ch/OPAL/src/-/issues/218Optimizer not saving expected data2018-05-10T10:31:44+02:00ext-neveu_nOptimizer not saving expected dataWhen running a 100 generation optimization, we see some behavior we aren't sure of
(maybe the two are related):
1. The number of feasible solutions does not match the total number of simulations saved in the json files.
Total number...When running a 100 generation optimization, we see some behavior we aren't sure of
(maybe the two are related):
1. The number of feasible solutions does not match the total number of simulations saved in the json files.
Total number of individuals saved in json files = 65288
Number of accepted individuals is about half:
"Statistics: individuals accepted = 33135"
2. We use the following population numbers:
INITIALPOPULATION=656,
NUM_IND_GEN=328,
We thought the later attribute would reduce the number of individuals in later generations.
The majority of generations (90%) still have 656 individuals.
Any help understanding this behavior would be appreciated.
Input files are attached:
[ga-model.in](/uploads/025dd6b7513f64e1f0882b17135d82a9/ga-model.in)
[ga-model.data](/uploads/1dba26888233de527b0781dad3a6b088/ga-model.data)
[fieldmaps.tar.gz](/uploads/f5432f4247b91ab4777f2fa9cbad5678/fieldmaps.tar.gz)
[ga-model.tmpl](/uploads/289cebef8c25912f61ae2aea21e743b2/ga-model.tmpl)adelmannYves Ineichenext-neveu_nkraussnuverink_jjochem.snuverink@psi.chadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/217SAAMG-Test-1 regression test broken in 1.62018-04-24T11:34:31+02:00snuverink_jjochem.snuverink@psi.chSAAMG-Test-1 regression test broken in 1.6The SAAMG regression test broke in 1.6.
* [23 March](http://amas.web.psi.ch/opal/regressionTests/1.6/results_2018-03-23.xml)
* [4 Jan](http://amas.web.psi.ch/opal/regressionTests/1.6/results_2018-01-04.xml)
Especially, the energy incre...The SAAMG regression test broke in 1.6.
* [23 March](http://amas.web.psi.ch/opal/regressionTests/1.6/results_2018-03-23.xml)
* [4 Jan](http://amas.web.psi.ch/opal/regressionTests/1.6/results_2018-01-04.xml)
Especially, the energy increase has increased significantly:
![image](/uploads/de2c9c324a52d718ce5d114e1f03c53e/image.png)https://gitlab.psi.ch/OPAL/src/-/issues/215Dipole negative K02018-04-11T21:28:21+02:00ganz_pDipole negative K0When I compare (opal 1.6 and opal 1.9) the beam line of the PSI Gantry 2, I have noticed the problem, that negative K0 values of the Dipole AMF2 cause troubles (maybe in the creation of the reference trajectory). Even, an alternative Imp...When I compare (opal 1.6 and opal 1.9) the beam line of the PSI Gantry 2, I have noticed the problem, that negative K0 values of the Dipole AMF2 cause troubles (maybe in the creation of the reference trajectory). Even, an alternative Implementation with a positive K0 and a rotation (PSI) of pi doesn't solve the problem and gives the same output.
The Implementation of the dipole is:
```c++
AMF2: SBEND,
K0=-0.804017, //<--- negative magnetic field strength
L=1.4929,
ELEMEDGE=42.6615,
FMAPFN="HardEdge.T7",
//PSI = Pi, //<---- Rotate like that
DESIGNENERGY=7.381e+01, GAP=.1;
```
![Normal_AMF2](/uploads/040c0bc9a418bc65691233d99b4444c2/comparison2018-03-21_13_25_44.png)
>>>
**NOTE:** Why do I think, that the negative K0 causes the problem? Because just some elements before the dipole AMF1 has precisely the same attributes, except a positive K0 and matches the with OPAL 1.6.
>>>
The complete .in are here.
[70MeV_Gantry2_OPAL1.6.in](/uploads/635ac5effa1c612a0b2ef35c7be0c436/70MeV_Gantry2.in) &
[70MeV_Gantry2_OPAL1.9.in](/uploads/e62bf4bab484e594f32c55c8d89f7f2c/70MeV_Gantry2.in)
The Fieldmap:
[HardEdge.T7](/uploads/e79acf500ec6870db72281661be4f5dd/HardEdge.T7)
If I use positive K0 values, the rms of OPAL 1.6 and OPAL 1.9 match again.
Plot below (made out of .stat file made with pyOPAL Tools)
![positive_K0_AMF2](/uploads/cca6c8b1674498e668b475fb24cf241e/comparison2018-03-21_13_00_11.png)
Does someone has an idea where this missmatch come from?krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/214Typo in CMakeLists.txt, line 532018-03-22T16:33:27+01:00ext-neveu_nTypo in CMakeLists.txt, line 53Line 53: ` add_comile_options (-diag-disable 383 -diag-disable 981)`
There's a missing 'p' in compile on this line.Line 53: ` add_comile_options (-diag-disable 383 -diag-disable 981)`
There's a missing 'p' in compile on this line.https://gitlab.psi.ch/OPAL/src/-/issues/209Compiling OPAL using OPAL package2020-04-22T11:42:20+02:00krausCompiling OPAL using OPAL packageIn the past it was possible to build OPAL using the OPAL package downloaded from the wiki (then it was still on trac not gitlab). Furthermore there was a description on the wiki how this can be done.
Currently I face the problem that I'...In the past it was possible to build OPAL using the OPAL package downloaded from the wiki (then it was still on trac not gitlab). Furthermore there was a description on the wiki how this can be done.
Currently I face the problem that I'd like to build OPAL on the servers of Helmholtz-Zentrum Berlin. They use a version of a Linux distro that is outdated (several years old). Modules that provide newer versions such as at PSI are, as far as I know, not supported. That means I would have to build a lot of tools (gcc, cmake, openmpi and possibly many more) before I could build OPAL.
With the current package, OPAL-1.6.1-3, building OPAL isn't supported. Among others cmake and mpicxx/mpicc are missing.
I would propose to reenable this feature since it lowers the barrier to build and develop OPAL. This applies especially to those that aren't yet used to build software from source.gselladelmanngsellhttps://gitlab.psi.ch/OPAL/src/-/issues/206Cyclotron elements require end position to have larger radius than start posi...2018-12-10T14:30:45+01:00snuverink_jjochem.snuverink@psi.chCyclotron elements require end position to have larger radius than start positionFound with @nesteruk_k:
In the [current implementation](https://gitlab.psi.ch/OPAL/src/blob/master/src/Classic/AbsBeamline/Probe.cpp#L195) it is assumed that the Probe (x,y) end position has a larger radius than the (x,y) starting posit...Found with @nesteruk_k:
In the [current implementation](https://gitlab.psi.ch/OPAL/src/blob/master/src/Classic/AbsBeamline/Probe.cpp#L195) it is assumed that the Probe (x,y) end position has a larger radius than the (x,y) starting position.
If not, almost no particles are recorded. This is not documented and without warning not very user-friendly, therefore labelling this a bug. For 1.6 perhaps a documentation update would be enough.
EDIT (23 April): (C)Collimator, Septum, Stripper make the same assumption.snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/205ippl/tests2018-02-09T10:58:07+01:00adelmannippl/testsI need to build IPPL tests for benchmarking purposes.
How do we build these day's?I need to build IPPL tests for benchmarking purposes.
How do we build these day's?krausfrey_mkraushttps://gitlab.psi.ch/OPAL/src/-/issues/204rename opt-Pilot function sameSDDSVariableAt to statVariableAt2018-01-20T14:15:19+01:00krausrename opt-Pilot function sameSDDSVariableAt to statVariableAtI think the name `sameSDDSVariableAt` isn't a good choice (if I remember correctly it was my own...). This function uses the results of the `.stat` file. Accordingly it should be called `statVariableAt`.I think the name `sameSDDSVariableAt` isn't a good choice (if I remember correctly it was my own...). This function uses the results of the `.stat` file. Accordingly it should be called `statVariableAt`.adelmannkrausadelmann