OPAL issueshttps://gitlab.psi.ch/groups/OPAL/-/issues2018-04-09T12:19:50+02:00https://gitlab.psi.ch/OPAL/src/-/issues/201Stat file dumping in ParallelCyclotronTracker2018-04-09T12:19:50+02:00frey_mStat file dumping in ParallelCyclotronTrackerThis issue is related to the discussion in #196. I'd like to fix the dumping and reference particle in the cyclotron tracker such that it works and gives reasonable results for single as well as multi bunch simulations. My idea is to wri...This issue is related to the discussion in #196. I'd like to fix the dumping and reference particle in the cyclotron tracker such that it works and gives reasonable results for single as well as multi bunch simulations. My idea is to write a stat-file per bunch. What do you think?OPAL 1.9.xfrey_mfrey_mhttps://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/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/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/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/148Check that Enge function goes from 1 to 02017-08-13T10:13:16+02:00krausCheck that Enge function goes from 1 to 0OPAL 1.9.xkrauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/144Fixed reference point for inside check2020-06-05T18:34:47+02:00krausFixed reference point for inside checkIn the class ArbitraryDomain globalIsInside_m is hard coded. This should be computed automatically for any domain and shouldn't be hard coded or needed from the input file. Possibility:
1. compute the bounding box
2. pick one corner a...In the class ArbitraryDomain globalIsInside_m is hard coded. This should be computed automatically for any domain and shouldn't be hard coded or needed from the input file. Possibility:
1. compute the bounding box
2. pick one corner and move from there away from the opposite corner by an arbitrary length
3. pick an arbitrary triangle from the surface mesh
4. compute its balance point and move a small distance from it in normal direction
5. test whether the connecting line crosses an odd number of times
- if the test is positive then you're done
- otherwise move the same distance from the triangle to the other side
- compute number crosses with surface
- if the test is still negative then diminish distance from the triangle by factor 2 and try on both sides if necessaryOPAL 1.9.xgsellgsellhttps://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/124Reimplementation of ParallelCyclotronTracker2020-04-22T12:01:54+02:00frey_mReimplementation of ParallelCyclotronTrackerWe should re-implement the tracker such that it is independent of the integrator in order to avoid duplicated code. Adding new integrators is then also simplified.We should re-implement the tracker such that it is independent of the integrator in order to avoid duplicated code. Adding new integrators is then also simplified.OPAL 1.9.xfrey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/115Emission2017-06-17T20:38:35+02:00adelmannEmissionEmission is very slow and hardly can be used above 1E7 particles. Reason the algorithm does not scale.Emission is very slow and hardly can be used above 1E7 particles. Reason the algorithm does not scale.OPAL 1.9.xadelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/113Static cuda libraries2017-07-24T10:29:38+02:00Uldis LocansStatic cuda librarieslink to static cuda libraries when compiling with DKSlink to static cuda libraries when compiling with DKSOPAL 1.9.xhttps://gitlab.psi.ch/OPAL/src/-/issues/111Move download page from Trac to gitlab2017-07-24T10:29:38+02:00krausMove download page from Trac to gitlabCurrently the download page is a page in the old Trac instance. Move it to gitlab.Currently the download page is a page in the old Trac instance. Move it to gitlab.OPAL 1.6.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/99When APVETO=TRUE set phase relative to arrival time2017-07-24T10:29:38+02:00krausWhen APVETO=TRUE set phase relative to arrival timeThe phase of a cavity at time $`t`$ is given by
```math
\varphi (t) = \omega \cdot t + \varphi_{\text{LAG}} + \varphi_0.
```
When running the auto-phasing algorithm we set the phase of a cavity relative to the phase at which a cavity...The phase of a cavity at time $`t`$ is given by
```math
\varphi (t) = \omega \cdot t + \varphi_{\text{LAG}} + \varphi_0.
```
When running the auto-phasing algorithm we set the phase of a cavity relative to the phase at which a cavity yields maximal energy. Thus $`\varphi_0 = \varphi_{\text{max}}`$. In some cases we want or have to set APVETO=TRUE. Currently we set $`\varphi_0 = 0`$ but we should set it such that $`\varphi (t_{\text{ELEMEDGE}}) = 0`$. Here $`t_{\text{ELEMEDGE}}`$ is the time at which the reference particle enters the element (either physically or alternatively the region in which field of the cavity is non-zero).OPAL 2.0.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/97Collimator/Probe2018-08-14T07:51:06+02:00adelmannCollimator/ProbeSuggestions from @zhang_h :
Distinguish between probes and collimator and name the collimators on the stdout.
Write probe and collimator data in one line for easy post processing
Add angles back per defaultSuggestions from @zhang_h :
Distinguish between probes and collimator and name the collimators on the stdout.
Write probe and collimator data in one line for easy post processing
Add angles back per defaultOPAL 1.9.xadelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/89Bunch Printing Format2017-04-12T16:12:15+02:00frey_mBunch Printing FormatThe format of printing the charge should be changed from ```std::fixed``` to ```std::scientific``` in the function ```getChargeString(double charge, unsigned int precision = 3)``` (file src/Classic/Utilities/Util.h) because otherwise rea...The format of printing the charge should be changed from ```std::fixed``` to ```std::scientific``` in the function ```getChargeString(double charge, unsigned int precision = 3)``` (file src/Classic/Utilities/Util.h) because otherwise really small charges are printed as zero.OPAL 1.9.xfrey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/87OPAL master does not compile with NOCPLUSPLUS11_NULLPTR=ON2017-05-01T09:05:17+02:00snuverink_jjochem.snuverink@psi.chOPAL master does not compile with NOCPLUSPLUS11_NULLPTR=ONOPAL master does not compile (gcc 4.8.5) with build option NOCPLUSPLUS11_NULLPTR=ON with the following error:
`src/Classic/AbsBeamline/RFCavity.cpp:152:27: error: call of overloaded ‘unique_ptr(NULL)’ is ambiguous
frequency_td_m(nu...OPAL master does not compile (gcc 4.8.5) with build option NOCPLUSPLUS11_NULLPTR=ON with the following error:
`src/Classic/AbsBeamline/RFCavity.cpp:152:27: error: call of overloaded ‘unique_ptr(NULL)’ is ambiguous
frequency_td_m(nullptr)`
This comes from:
`RNormal_m(nullptr)`
which is defined as
`std::unique_ptr<double[]> RNormal_m;`
With NOCPLUSPLUS11_NULLPTR this is translated to RNormal_m(NULL), for which multiple constructors are possible.
Since there is already quite a bit of C++11 in OPAL, instead of fixing I would suggest (but with caution as I don't know the reason for the build option) to remove the NOCPLUSPLUS11_NULLPTR (and perhaps also the similar NOCPLUSPLUS11_FOREACH).OPAL 1.9.xhttps://gitlab.psi.ch/OPAL/src/-/issues/79ArbitraryDomain::globalToLocalQuaternion_m also defined in its parent class '...2017-05-01T09:05:17+02:00snuverink_jjochem.snuverink@psi.chArbitraryDomain::globalToLocalQuaternion_m also defined in its parent class 'IrregularDomainFrom issue #62. `[src/Solvers/ArbitraryDomain.h:84] -> [src/Solvers/IrregularDomain.h:123]: (warning) The class 'ArbitraryDomain' defines member variable with name 'globalToLocalQuaternion_m' also defined in its parent class 'IrregularDo...From issue #62. `[src/Solvers/ArbitraryDomain.h:84] -> [src/Solvers/IrregularDomain.h:123]: (warning) The class 'ArbitraryDomain' defines member variable with name 'globalToLocalQuaternion_m' also defined in its parent class 'IrregularDomain'.`
Shadowing members is very error-prone and was probably not intended.
A quick look at the code seems to show that the derived ArbitraryDomain uses its globalToLocalQuaternion_m as a read-only copy of its parent member. So ArbitraryDomain::globalToLocalQuaternion_m can be safely substituted for a local variable since there is a public getter method (and even the actual parent member is directly accessible (protected)).OPAL 1.5.3adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/76Make normalization of 3D fieldmaps optional2017-06-17T20:38:35+02:00krausMake normalization of 3D fieldmaps optionalCurrently the z-component of the (electric, if present) field of a 3D fieldmaps is normalized. The user should be able to disable this normalizaton to simulate e.g. transverse deflecting cavities.Currently the z-component of the (electric, if present) field of a 3D fieldmaps is normalized. The user should be able to disable this normalizaton to simulate e.g. transverse deflecting cavities.OPAL 2.0.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/74Ring::getSectionsAt()2017-05-01T09:05:16+02:00snuverink_jjochem.snuverink@psi.chRing::getSectionsAt()From issue #62. The current implementation of Classic/AbsBeamline/Ring::getSectionsAt() is as follows:
```c++
std::vector<RingSection*> Ring::getSectionsAt(const Vector_t& r) {
return section_list_m;
double phi = atan2(r(1), -r(...From issue #62. The current implementation of Classic/AbsBeamline/Ring::getSectionsAt() is as follows:
```c++
std::vector<RingSection*> Ring::getSectionsAt(const Vector_t& r) {
return section_list_m;
double phi = atan2(r(1), -r(0))+Physics::pi;
// std::cerr << "GetSectionsAt " << phi << " " << phiStep_m << " " << int((phi)/phiStep_m) << " " << ringSections_m.size() << std::endl;
if (phi >= 2.*Physics::pi)
phi -= 2.*Physics::pi;
return ringSections_m[(phi)/phiStep_m];
}
```
The second part of the function is never reached due to the first return. From a coding point of view the second part might seem correct since otherwise the input is not used. If the first return is correct however, could the second part be removed or commented out? Assigning to @ext-rogers_c who [committed the code](https://gitlab.psi.ch/OPAL/src/blame/master/src/Classic/AbsBeamline/Ring.cpp).OPAL 1.5.3ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/regression-tests/-/issues/27define toolchain in configuration file2019-05-06T16:28:58+02:00gselldefine toolchain in configuration fileThe tool-chain to build and run OPAL should be defined in a configuration file.The tool-chain to build and run OPAL should be defined in a configuration file.OPAL 1.9.xgsellgsell