src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2018-11-06T14:33:17+01:00https://gitlab.psi.ch/OPAL/src/-/issues/242Cleanup some OPAL-CYCL units2018-11-06T14:33:17+01:00ext-rogers_cCleanup some OPAL-CYCL unitsJust a quick note to record that I cleaned up units in the following places (it has been on my nag list for many months so finally I did it!)
* DumpEMFields -> RADIANS
* VariableRFCavity -> METRES
* Offset (Cartesian/Cylindrical) -> RAD...Just a quick note to record that I cleaned up units in the following places (it has been on my nag list for many months so finally I did it!)
* DumpEMFields -> RADIANS
* VariableRFCavity -> METRES
* Offset (Cartesian/Cylindrical) -> RADIANS and METRES
I note that the PROBE still is in MMext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/240Remove wrappers2020-07-08T23:21:06+02:00frey_mRemove wrappersDoes anyone know why all elements, e.g. OpalQuadrupole, call ```makeWrappers``` (see here [OpalQuadrupole](https://gitlab.psi.ch/OPAL/src/blob/master/src/Elements/OpalQuadrupole.cpp#L74))? In this case an ```AlignWrapper``` is instantiat...Does anyone know why all elements, e.g. OpalQuadrupole, call ```makeWrappers``` (see here [OpalQuadrupole](https://gitlab.psi.ch/OPAL/src/blob/master/src/Elements/OpalQuadrupole.cpp#L74))? In this case an ```AlignWrapper``` is instantiated. Therefore, it will call ```visitAlignWrapper``` instead of e.g. here ```visitMultipole``` in the different tracker implemenations.OPAL 2.4.0frey_msnuverink_jjochem.snuverink@psi.chfrey_mhttps://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/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/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/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/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/213Phase output in OPAL-Cycl2018-04-19T10:30:32+02:00baumgartenchristian.baumgarten@psi.chPhase output in OPAL-CyclThe output of the phases in a multiprocessor run involving N nodes is not reliable.
a) if you run the simulation with one core you get all the information about the phases.
b) with more than one core the situation is different: becaus...The output of the phases in a multiprocessor run involving N nodes is not reliable.
a) if you run the simulation with one core you get all the information about the phases.
b) with more than one core the situation is different: because we sample this information always at the same particle (the one with ID==0) and only node==0 is writing, you only see phase information iff particle with ID==0 is on node 0.OPAL 1.6.1adelmannadelmannhttps://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/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`.adelmannkrausadelmannhttps://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/197Scan-1 regression test is broken2017-12-21T12:07:54+01:00snuverink_jjochem.snuverink@psi.chScan-1 regression test is brokenThe [Scan-1 regression test](https://gitlab.psi.ch/OPAL/regression-tests/tree/master/RegressionTests/Scan-1) is broken since the beginning of the year.
It seems there were no significant changes to the test.
One thing I don't understan...The [Scan-1 regression test](https://gitlab.psi.ch/OPAL/regression-tests/tree/master/RegressionTests/Scan-1) is broken since the beginning of the year.
It seems there were no significant changes to the test.
One thing I don't understand is why in master the simulation starts at a later s-position, s=0.15m instead of the reference of s=0.0m.
The regression plots show it best:
http://amas.web.psi.ch/opal/regressionTests/master/results_2017-12-19.xml#Scan-1_rms_x