src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2017-12-08T12:25:32+01:00https://gitlab.psi.ch/OPAL/src/-/issues/190BINOMIAL distribution documentation2017-12-08T12:25:32+01:00Valeria RizzoglioBINOMIAL distribution documentationI would suggest to slightly modify the documentation concerning the Binomial distribution documentation.
In particular:
* replace the 'm' in table 15 with 'M' to be consistent with table 16
* specify that the parameters SIGMAX, SIGMA...I would suggest to slightly modify the documentation concerning the Binomial distribution documentation.
In particular:
* replace the 'm' in table 15 with 'M' to be consistent with table 16
* specify that the parameters SIGMAX, SIGMAPX, CORRX etc are still needed. From table 16 it seems that MX, MY and MZ are enough. (Maybe other users are smarter than me and they don't need this additional explanation)
* is there a reason for a default value to 10001.0?OPAL 1.9.xsnuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/189DESIGNENERGY and Field map extension2020-06-09T12:08:54+02:00Valeria RizzoglioDESIGNENERGY and Field map extensionAccording to the manual for OPAL <=1.6:
> If the bend strength is set by K0 and/or K0S, then the actual beam will be bent a different angle if its energy
> does not correspond to the DESIGNENERGY of the bend
A beam energy different fro...According to the manual for OPAL <=1.6:
> If the bend strength is set by K0 and/or K0S, then the actual beam will be bent a different angle if its energy
> does not correspond to the DESIGNENERGY of the bend
A beam energy different from DESIGNENERGY would change the bending radius and angle depending on K0. The beam trajectory matches always with the reference path inside the dipole.
The bending radius defines the extension of the field map. It is not clear to me **if and how the redefinition of bending radius (due to a beam energy different from DESIGNENERGY) impacts on the field map extension.**krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/187Unit tests Gauss and Binomial fail2017-12-02T15:04:35+01:00snuverink_jjochem.snuverink@psi.chUnit tests Gauss and Binomial failThe unit tests `GaussTest` and `BinomialTest` fail with NaNs.
I investigated a bit and this is because in Distribution::adjustPhaseSpace() totalNumberParticles_m is 0 (division by zero).
Right now the test do the following:
```c++
Dis...The unit tests `GaussTest` and `BinomialTest` fail with NaNs.
I investigated a bit and this is because in Distribution::adjustPhaseSpace() totalNumberParticles_m is 0 (division by zero).
Right now the test do the following:
```c++
Distribution dist;
... // set attributes
dist.setDistType();
dist.checkIfEmitted();
size_t numParticles = 1e7;
dist.create(numParticles, Physics::m_p);
```
Possibly these shouldn't call the private create() directly?krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/186error compiling with clang2017-12-05T09:46:01+01:00gsellerror compiling with clangClang (Apple LLVM version 9.0.0 (clang-900.0.38)) complains about several expressions in the OPAL code. One I do not know how to fix is:
```C
[ 11%] Building CXX object src/CMakeFiles/OPALib.dir/Editor/EditParser.cpp.o
In file included ...Clang (Apple LLVM version 9.0.0 (clang-900.0.38)) complains about several expressions in the OPAL code. One I do not know how to fix is:
```C
[ 11%] Building CXX object src/CMakeFiles/OPALib.dir/Editor/EditParser.cpp.o
In file included from /Users/gsell/src/OPAL/src/src/Classic/Parser/ClassicParser.cpp:39:
In file included from /Users/gsell/src/OPAL/src/src/Classic/BeamlineCore/Octupole.h:23:
/Users/gsell/src/OPAL/src/src/Classic/BeamlineCore/SingleMultipole.h:209:30: error: instantiation of variable
'SingleMultipole<4>::entries' required here, but no definition is available [-Werror,-Wundefined-var-template]
for(const Entry *entry = entries; entry->name != 0; ++entry) {
^
/Users/gsell/src/OPAL/src/src/Classic/BeamlineCore/SingleMultipole.h:60:14: note: in instantiation of member function
'SingleMultipole<4>::getChannel' requested here
explicit SingleMultipole(const std::string &name);
^
/Users/gsell/src/OPAL/src/src/Classic/Parser/ClassicParser.cpp:111:24: note: in instantiation of member function
'SingleMultipole<4>::SingleMultipole' requested here
factory.define(new Octupole("OCTUPOLE"));
^
/Users/gsell/src/OPAL/src/src/Classic/BeamlineCore/SingleMultipole.h:130:24: note: forward declaration of template entity is here
static const Entry entries[];
^
/Users/gsell/src/OPAL/src/src/Classic/BeamlineCore/SingleMultipole.h:209:30: note: add an explicit instantiation declaration to suppress
this warning if 'SingleMultipole<4>::entries' is explicitly instantiated in another translation unit
for(const Entry *entry = entries; entry->name != 0; ++entry) {
^
1 error generated.
```
What is the right "explicit instantiation declaration" here???krausgsellsnuverink_jjochem.snuverink@psi.chkraushttps://gitlab.psi.ch/OPAL/src/-/issues/185OPAL-Cyc / RINGDEFINITION: Subline definition does not work2017-12-07T15:48:51+01:00Valeria RizzoglioOPAL-Cyc / RINGDEFINITION: Subline definition does not workI am running a small test with CCollimators in OPAL-Cyc - RINGDEFINITION.
Those are the elements of the beamline:
```
OffQuad1: LOCAL_CARTESIAN_OFFSET, end_position_x=off_quad1x....
Quad1: SBEND3D, FMAPFN="3D_B_map_1st_Q.table", LENG...I am running a small test with CCollimators in OPAL-Cyc - RINGDEFINITION.
Those are the elements of the beamline:
```
OffQuad1: LOCAL_CARTESIAN_OFFSET, end_position_x=off_quad1x....
Quad1: SBEND3D, FMAPFN="3D_B_map_1st_Q.table", LENGTH_UNITS=1000.0, FIELD_UNITS=10.0;
Quad1_BP_1: CCollimator, XSTART=-950, XEND=-950, YSTART=1800, YEND=1950, ZSTART=70, ZEND=170, WIDTH=4.0;
Quad1_BP_2: CCollimator, XSTART=-1000, XEND=-1000, YSTART=1800, YEND=1950, ZSTART=168, ZEND=172, WIDTH=100.0;
Quad1_BP_3: CCollimator, XSTART=-1050, XEND=-1050, YSTART=1800, YEND=1950, ZSTART=70, ZEND=170, WIDTH=4.0;
Quad1_BP_4: CCollimator, XSTART=-1000, XEND=-1000, YSTART=1800, YEND=1950, ZSTART=68, ZEND=72, WIDTH=100.0;
```
I tried to define a subline with only collimators:
`Quad1_BP: LINE = (Quad1_BP_1, Quad1_BP_2, Quad1_BP_3, Quad1_BP_4);`
Then the beamline that I want to track is:
`BEAMLINE: LINE = (OffQuad1, Quad1, Quad1_BP);`
With this configuration, I get segmentation fault.
If I replace `Quad1_BP` with the elements that form this subline, OPAL runs without problems.
`BEAMLINE: LINE = (OffQuad1, Quad1, Quad1_BP_1, Quad1_BP_2, Quad1_BP_3, Quad1_BP_4);`
**It seems that the OPAL-Cyc - RINGDEFINITION does not support definition of sublines.**
Here my configuration
```
Currently Loaded Modulefiles:
1) gcc/5.4.0 3) OPAL/1.6.1 5) openssl/1.0.2j 7) Tk/8.6.4 9) boost/1.62.0 11) gsl/2.2.1
2) openmpi/1.10.4 4) OPAL/1.6 6) Tcl/8.6.4 8) Python/2.7.12 10) root/6.08.02 12) H5root/1.3.4
```OPAL 1.6.1adelmannext-rogers_cadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/184Unused BEAM Attributes2017-12-13T14:53:25+01:00snuverink_jjochem.snuverink@psi.chUnused BEAM AttributesWhile working on issue #183, I noticed that in [Beam.cpp](https://gitlab.psi.ch/OPAL/src/blob/master/src/Structure/Beam.cpp) there are several attributes defined that are not used nor documented:
* RADIATE
* DAMP
* QUANTUM
* EXN
* EYN
*...While working on issue #183, I noticed that in [Beam.cpp](https://gitlab.psi.ch/OPAL/src/blob/master/src/Structure/Beam.cpp) there are several attributes defined that are not used nor documented:
* RADIATE
* DAMP
* QUANTUM
* EXN
* EYN
* SPACECHARGE
* FIELDSOLVER
* BUNCHED
* KBUNCH
I propose to remove those from the code.
The following are not documented and only used in the twiss calculation (AFAICS):
* EX, EY, ETsnuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/183Attributes PC, ENERGY and GAMMA of BEAM command not described2018-01-09T18:53:22+01:00krausAttributes PC, ENERGY and GAMMA of BEAM command not describedThere are several possible definitions for PC
1. $`PC = mc^2 \frac{\sqrt{\sum_i p_{x,i}^2 + p_{y,i}^2 + p_{z,i}^2}}{N}`$
1. $`PC = mc^2 \frac{\sum_i p_{z,i}}{N}`$
Currently the second definition is implemented. This has the advantage th...There are several possible definitions for PC
1. $`PC = mc^2 \frac{\sqrt{\sum_i p_{x,i}^2 + p_{y,i}^2 + p_{z,i}^2}}{N}`$
1. $`PC = mc^2 \frac{\sum_i p_{z,i}}{N}`$
Currently the second definition is implemented. This has the advantage that mean longitudinal momentum is well defined and thereby the reference particle has the same velocity as the centroid. The disadvantage is that the kinematic energy of the bunch is to high.
The definition for PC should be chosen and the two attributes should be described in the manual for 1.6 and 1.9.adelmannsnuverink_jjochem.snuverink@psi.chadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/181timing.dat2018-01-25T12:21:49+01:00adelmanntiming.datAdd problem size to timing.dat
NP == number of particles
MX,MY,MZ == gridsizes
domain decomposition
Not shure how to cover AMR but that is a differnt topic.Add problem size to timing.dat
NP == number of particles
MX,MY,MZ == gridsizes
domain decomposition
Not shure how to cover AMR but that is a differnt topic.https://gitlab.psi.ch/OPAL/src/-/issues/180Use OPAL's native SDDS parser in the optimiser2017-11-22T22:38:09+01:00snuverink_jjochem.snuverink@psi.chUse OPAL's native SDDS parser in the optimiserAs discussed in #153. The optimiser has its own SDDS parser in opt-pilot/Util/SDDSReader. It would be better to reuse the SDDS parser from src/Structure/SDDSParser.As discussed in #153. The optimiser has its own SDDS parser in opt-pilot/Util/SDDSReader. It would be better to reuse the SDDS parser from src/Structure/SDDSParser.krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/175CSR wakes not computed correctly2017-10-26T22:30:25+02:00krausCSR wakes not computed correctlyThe behavior of the computation of the CSR wakes dramatically changed on Aug. 18 (BFREQ change from Hz to MHz). The references of the CSRBendDrift-Regtest changed since (***thanks*** to @adelmann's effort to let the reference have the sa...The behavior of the computation of the CSR wakes dramatically changed on Aug. 18 (BFREQ change from Hz to MHz). The references of the CSRBendDrift-Regtest changed since (***thanks*** to @adelmann's effort to let the reference have the same version).OPAL 1.6.1krauskraushttps://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/168MultipoleT Curvature model2019-04-18T12:21:41+02:00ext-rogers_cMultipoleT Curvature modelWell, I pushed Titus's code. I did some cleanup and checked a few things over, I note that with non-zero radius of curvature
(a) the processing time is too long. There is some recursive derivative lookup that seems to be not well-optimi...Well, I pushed Titus's code. I did some cleanup and checked a few things over, I note that with non-zero radius of curvature
(a) the processing time is too long. There is some recursive derivative lookup that seems to be not well-optimised, but I suspect it will take a bit of browsing through the maths to understand what he was trying to do.
(b) the field values come out very large when radius of curvature is large. Presumably the code should tend to the straight magnet limit, indicating a bug somewhere.
I will need some time to address these issues - but between data taking and other work I can't give a firm date when I can get into this. I would estimate that I need a good week of work (say two-three weeks in real time) to have some confidence in the code. E.g. it has taken about a week of coding time plus lots of tracking studies for me to gain confidence in the spiral sector FFAG magnet model.
On the plus side, the straight magnet routines seem okay.ext-rogers_cext-rogers_chttps://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/165opt-pilot: objectives based on design variables2021-06-10T18:03:26+02:00snuverink_jjochem.snuverink@psi.chopt-pilot: objectives based on design variablesas mentioned in https://gitlab.psi.ch/OPAL/src/issues/8#note_3112 writing objectives like (where d1 and d2 are design variables):
```
//obj1:OBJECTIVE,EXPR="fabs(d1+d2)";
```
seem not to work (not sure if it ever did). Since the optimi...as mentioned in https://gitlab.psi.ch/OPAL/src/issues/8#note_3112 writing objectives like (where d1 and d2 are design variables):
```
//obj1:OBJECTIVE,EXPR="fabs(d1+d2)";
```
seem not to work (not sure if it ever did). Since the optimiser still tries to look in the output file:
```
Exception while getting value from SDDS file: unkown column name!
```
Still such an objective could potentially be useful.
I might have a look at this eventually, or if there is a direct need for it. Right now putting a low weight on it.snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/161PSDUMPLOCALFRAME and PSDUMPFRAME2017-08-31T10:28:35+02:00Valeria RizzoglioPSDUMPLOCALFRAME and PSDUMPFRAMEIf the list of the options is:
```
OPTION, PSDUMPLOCALFRAME=TRUE;
OPTION, PSDUMPFRAME=BUNCH_MEAN;
OPTION, TELL=TRUE;
```
OPAL starts the run without any problem.
If the list of the options is:
```
OPTION, PSDUMPFRAME=BUNCH_MEAN;
O...If the list of the options is:
```
OPTION, PSDUMPLOCALFRAME=TRUE;
OPTION, PSDUMPFRAME=BUNCH_MEAN;
OPTION, TELL=TRUE;
```
OPAL starts the run without any problem.
If the list of the options is:
```
OPTION, PSDUMPFRAME=BUNCH_MEAN;
OPTION, PSDUMPLOCALFRAME=TRUE;
OPTION, TELL=TRUE;
```
OPAL returns the following error
```
Error> *** in line 5 of file "B1_MultiMaps.in" at end of statement:
Ippl>
Ippl> *** User error detected by function "Option::handlePsDumpFrame"
Ippl> OPTION,PSDUMPLOCALFRAME=TRUE;
Ippl> Either set 'PSDUMPLOCALFRAME' Option or 'PSDUMPFRAME' Option but not both.
Ippl>
```
In addition when PSDUMPLOCALFRAME = TRUE and PSDUMPFRAME removed from the input file, the statistics is dumped in the GLOBAL frame.OPAL 1.9.xadelmannfrey_madelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/160simplify gcc warning flags2017-08-29T10:18:36+02:00snuverink_jjochem.snuverink@psi.chsimplify gcc warning flagsCurrently we have the following compiler warning flags for gcc:
`-Wall -Wno-error -Wno-reorder -Wno-unused-local-typedefs -Werror=unused-variable -std=c++11`
I would like to remove the following flags if no one objects:
* `-Wno-error`...Currently we have the following compiler warning flags for gcc:
`-Wall -Wno-error -Wno-reorder -Wno-unused-local-typedefs -Werror=unused-variable -std=c++11`
I would like to remove the following flags if no one objects:
* `-Wno-error` : already default so no need to declare it.
* `-Wno-reorder` : suppresses a warning that is easy to fix and can (admittedly rarely) lead to non-intuitive code execution.
* `-Wno-unused-local-typedefs` : suppresses a warning that is easy to fix and usually points to uncleaned code or wrong logic.
Furthermore, there are very few code changes needed to fix the code (which I will do).snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/159STATDUMPFREQ in RING-DEFINITION2021-06-10T18:04:20+02:00Valeria RizzoglioSTATDUMPFREQ in RING-DEFINITIONIt seems that the option STATDUMPFREQ does not work as expected in OPAL-C - Ring Definition. The statistics dumped in the .stat file depends on the PSDUMPFREQ normally used for the h5.
*Example*
For a certain beamline, the expected RM...It seems that the option STATDUMPFREQ does not work as expected in OPAL-C - Ring Definition. The statistics dumped in the .stat file depends on the PSDUMPFREQ normally used for the h5.
*Example*
For a certain beamline, the expected RMSX is: ![ExpectedRMS](/uploads/f136b3679a6b4acde8dc792c29c48fa5/ExpectedRMS.png).
The plot is obtained from the .stat file (column 2 and 6) and with the following options set in the OPAL input file
```
OPTION, PSDUMPFREQ=10;
OPTION, ENABLEHDF5=FALSE;
OPTION, TELL=TRUE;
OPTION, PSDUMPFRAME=BUNCH_MEAN;
```
The STATDUMPFREQ is not specified, so the default value `STATDUMPFREQ = 10 ` should be used.
With the following options:
- reducing the PSDUMPFREQ
```
OPTION, PSDUMPFREQ=100000000;
OPTION, STATDUMPFREQ = 10;
OPTION, TELL=TRUE;
OPTION, PSDUMPFRAME=BUNCH_MEAN;
```
- disabling the .h5 files but with high PSDUMPFREQ
```
OPTION, PSDUMPFREQ=10;
OPTION, ENABLEHDF5=FALSE;
OPTION, TELL=TRUE;
OPTION, PSDUMPFRAME=BUNCH_MEAN;
```
the RMSX from the generated stat file is: ![STATDUMP](/uploads/72d86bbc755b14b5ad7fc3b86ae7adb0/STATDUMP.png)
The result does not change if the STATDUMPFREQ is specified in the input file or not.
Any suggestions?ext-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/154Creation of first generation not optimal when infeasible solutions exist2018-08-03T15:07:58+02:00snuverink_jjochem.snuverink@psi.chCreation of first generation not optimal when infeasible solutions existSay we have a problem where a large number of solutions do not return proper objective values. In the first generation opt-pilot dispatches `n` jobs, where `n = initialPopulation`. When say 50% give an infeasible solution, then `n/2` job...Say we have a problem where a large number of solutions do not return proper objective values. In the first generation opt-pilot dispatches `n` jobs, where `n = initialPopulation`. When say 50% give an infeasible solution, then `n/2` jobs are dispatched of which 50% fail, then `n/4` are dispatched, etc., until the full population has a solution.
This will mean that many cores are idle.
It would be better to dispatch as many jobs as possible (nr of cores) until there are more than `n` feasible solutions.snuverink_jjochem.snuverink@psi.chfrey_msnuverink_jjochem.snuverink@psi.ch