src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2017-07-27T08:32:10+02:00https://gitlab.psi.ch/OPAL/src/-/issues/118ParallelCyclotronTracker::applyPluginElements2017-07-27T08:32:10+02:00frey_mParallelCyclotronTracker::applyPluginElementsIn ParallelCyclotronTracker the particles are mapped several times from local to global coordinates and vice versa. The PartBunch::boundp() operation where the particles are redistributed among the cores is always performed in local coor...In ParallelCyclotronTracker the particles are mapped several times from local to global coordinates and vice versa. The PartBunch::boundp() operation where the particles are redistributed among the cores is always performed in local coordinates except in during the function call ParallelCyclotronTracker::applyPluginElements in case the boolean flag_stripper being true
(line 3389 ff.).
```
if(((*sindex)->first) == ElementBase::STRIPPER) {
bool flag_stripper = (static_cast<Stripper *>(((*sindex)->second).second))
-> checkStripper(itsBunch, turnnumber_m, itsBunch->getT() * 1e9, dt);
if(flag_stripper) {
itsBunch->boundp();
*gmsg << "* Total number of particles after stripping = " << itsBunch->getTotalNum() << endl;
}
}
```
The workflow of ParallelCyclotronTracker::Tracker_Generic()
```
...
ParallelCyclotronTracker::initDistInGlobalFrame(); // (line 1235) --> particle in global coordinates
ParallelCyclotronTracker::applyPluginElements(dt); // (line 1285) --> PartBunch::boundp() in global coordinates !!!
...
// start tracking
```
Shouldn't the PartBunch::bounp() operation always be performed in local coordinates?
Best,
Matthiaswinklehner_dwinklehner_dhttps://gitlab.psi.ch/OPAL/src/-/issues/117Distribution.cpp2017-07-24T10:29:37+02:00adelmannDistribution.cppCan you explain me the additional particles
we add at line 518 and the for loop starting
at line 531.Can you explain me the additional particles
we add at line 518 and the for loop starting
at line 531.OPAL 1.9.xkrauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/116CollimatorPhysics::EnergyLoss2021-02-16T08:39:33+01:00adelmannCollimatorPhysics::EnergyLossis hard coded for protons. Need also make clear in the manual (exception in code) that electrons are not supported.is hard coded for protons. Need also make clear in the manual (exception in code) that electrons are not supported.OPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://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/114Help command gives error2017-06-17T20:38:35+02:00adelmannHelp command gives error```
==>help, source;
1 help, source;
OPAL>
OPAL> The "SOURCE" element defines a Source.
Attributes:
OPAL> string TYPE The element design type (the project name)
OPAL> string APERTURE The ...```
==>help, source;
1 help, source;
OPAL>
OPAL> The "SOURCE" element defines a Source.
Attributes:
OPAL> string TYPE The element design type (the project name)
OPAL> string APERTURE The element aperture
OPAL> real L The element length in m
OPAL> real ELEMEDGE The position of the element in path length (in m)
OPAL> string WAKEF Defines the wake function
Error>
Error> *** Error:
Error> *** in line 1 of file "standard input":
Error> HELP,SOURCE;
Error> basic_string::_M_create
Error>
```OPAL 1.9.xkrauskraushttps://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/112ID0 particle replaced in the h5 file2020-07-02T08:17:04+02:00Valeria RizzoglioID0 particle replaced in the h5 filePlease check:
- if the ID0 is still replaced in the h5
- if the reference particle is stored as ID0. If yes, we could have the same problem with the beam sizePlease check:
- if the ID0 is still replaced in the h5
- if the reference particle is stored as ID0. If yes, we could have the same problem with the beam sizeOPAL 2.4.0adelmannadelmannhttps://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/109OPAL does not compile with AMR Solver and unit tests2017-07-24T10:29:38+02:00snuverink_jjochem.snuverink@psi.chOPAL does not compile with AMR Solver and unit testsCompiling OPAL with ENABLE_AMR_SOLVER=1 and DBUILD_OPAL_UNIT_TESTS=1 gives the following compile error:
```
/home/scratch/OPAL/src/tests/opal_src/Distribution/GaussTest.cpp: In member function ‘virtual void GaussTest_FullSigmaTest1_Tes...Compiling OPAL with ENABLE_AMR_SOLVER=1 and DBUILD_OPAL_UNIT_TESTS=1 gives the following compile error:
```
/home/scratch/OPAL/src/tests/opal_src/Distribution/GaussTest.cpp: In member function ‘virtual void GaussTest_FullSigmaTest1_Test::TestBody()’:
<command-line>:0:6: error: expected unqualified-id before numeric constant
/home/scratch/OPAL/src/tests/opal_src/Distribution/GaussTest.cpp:74:15: note: in expansion of macro ‘OPAL’
OpalData *OPAL = OpalData::getInstance();
^
```
This is because OPAL is defined as preprocessor macro within CMake (with value 1):
```
[ 93%] Building CXX object tests/CMakeFiles/opal_unit_tests.dir/opal_src/Distribution/GaussTest.cpp.o
g++ -DBL_FORT_USE_UNDERSCORE -DBL_Linux -DBL_NOLINEVALUES -DBL_PARALLEL_IO -DBL_SPACEDIM=3 -DBL_USE_DOUBLE -DBL_USE_MPI -DMG_USE_F90_SOLVERS -DMG_USE_FBOXLIB -DNDEBUG -DOPAL .... tests/opal_src/Distribution/GaussTest.cpp
```
This is done in [CMakeModules/CCSEOptions.cmake](https://gitlab.psi.ch/OPAL/src/blob/master/CMakeModules/CCSEOptions.cmake#L74)
:
`list(APPEND BL_DEFINES "OPAL")`
I don't see a reason to add OPAL here since afaik it is not used anywhere as such.
That said it might good to adopt [camelCase for the variable name](https://gitlab.psi.ch/OPAL/src/wikis/for-developers#28-method-argument-and-local-variable-names).https://gitlab.psi.ch/OPAL/src/-/issues/108Revise macros such as DBG_SCALARFIELD and replace them with an Option command2017-07-24T10:29:38+02:00snuverink_jjochem.snuverink@psi.chRevise macros such as DBG_SCALARFIELD and replace them with an Option commandCompiling OPAL with the option DBG_SCALARFIELD gives the following compiler error:
```
src/Classic/Algorithms/PartBunch.cpp: In member function ‘void PartBunch::computeSelfFields(int)’:
/home/scratch/OPAL/src/src/Classic/Algorithms/...Compiling OPAL with the option DBG_SCALARFIELD gives the following compiler error:
```
src/Classic/Algorithms/PartBunch.cpp: In member function ‘void PartBunch::computeSelfFields(int)’:
/home/scratch/OPAL/src/src/Classic/Algorithms/PartBunch.cpp:715:29: error: ‘rmin’ was not declared in this scope
*gmsg << (rmin(0) - origin(0)) / spacing(0) << "\t"
^
```
This was introduced in commit https://gitlab.psi.ch/OPAL/src/commit/595b4b83818596b5f7a72e086cbbda4325f70aa8#852edcbb7804c7416aa51f7264a7a36fc1fa3fef_781_683snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/107keyword register2017-07-24T10:29:38+02:00snuverink_jjochem.snuverink@psi.chkeyword registerThe source code contains at several locations the keyword `register`. This is of no use anymore (see e.g. http://www.drdobbs.com/keywords-that-arent-or-comments-by-anoth/184403859). And with gcc compilers this might also gives some warni...The source code contains at several locations the keyword `register`. This is of no use anymore (see e.g. http://www.drdobbs.com/keywords-that-arent-or-comments-by-anoth/184403859). And with gcc compilers this might also gives some warnings:
```
src/Solvers/TaperDomain.cpp:89:66: warning: address requested for ‘y’, which is declared ‘register’ [-Wextra]
IntersectXDir.insert(std::pair<int, double>(y, xd));
```
Therefore, I propose to remove this keyword from the code everywhere.snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/101OPAL version2017-07-24T10:29:38+02:00frey_mOPAL versionAn additional flag at runtime of OPAL would be nice that returns the current version, i.e.
```
matthias@R2-D2:~$ opal --version
```An additional flag at runtime of OPAL would be nice that returns the current version, i.e.
```
matthias@R2-D2:~$ opal --version
```2017-05-02https://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/95OpalRingTest2020-04-22T17:05:41+02:00adelmannOpalRingTestOpalRingTest new with 2x2x2 space charge grid gives of course different answers w.r.t. emittance etc.
Please check that this makes still sense. I updated the reference with the actual resultsOpalRingTest new with 2x2x2 space charge grid gives of course different answers w.r.t. emittance etc.
Please check that this makes still sense. I updated the reference with the actual resultsext-rogers_cext-rogers_chttps://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/88PSI Opal build chain failt2019-10-25T13:46:05+02:00baumgartenchristian.baumgarten@psi.chPSI Opal build chain failt`cmake ..
-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Check for working C compiler: /afs/psi.ch/sys/psi.x86_64_slp6/Programming/gcc/5.4.0/bin/gcc
-- Check for working C compiler: /...`cmake ..
-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Check for working C compiler: /afs/psi.ch/sys/psi.x86_64_slp6/Programming/gcc/5.4.0/bin/gcc
-- Check for working C compiler: /afs/psi.ch/sys/psi.x86_64_slp6/Programming/gcc/5.4.0/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done`
Ich bin wie im Wiki beschrieben vorgegangen, dh.:
`mkdir $HOME/opal
cd $HOME/opal
git clone git@gitlab.psi.ch:OPAL/src.git
git checkout OPAL-1.6
mkdir build
cd build
cmake ..`
Dann kommt leider folgende Fehlermeldung:
`-- Check for working CXX compiler: /afs/psi.ch/sys/psi.x86_64_slp6/Programming/gcc/5.4.0/bin/g++
-- Check for working CXX compiler: /afs/psi.ch/sys/psi.x86_64_slp6/Programming/gcc/5.4.0/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Build type is: RelWithDebInfo
-- Host OS System: Linux-2.6.32-642.13.1.el6.x86_64
-- Hostname: pc10758
-- Unable to determine MPI from MPI driver /afs/psi.ch/sys/psi.x86_64_slp6/Compiler/openmpi/1.10.4/gcc/5.4.0/bin/mpicc
CMake Error at /afs/psi.ch/sys/psi.x86_64_slp6/Programming/cmake/3.6.3/share/cmake-3.6/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
Could NOT find MPI_C (missing: MPI_C_LIBRARIES MPI_C_INCLUDE_PATH)
Call Stack (most recent call first):
/afs/psi.ch/sys/psi.x86_64_slp6/Programming/cmake/3.6.3/share/cmake-3.6/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE)
/afs/psi.ch/sys/psi.x86_64_slp6/Programming/cmake/3.6.3/share/cmake-3.6/Modules/FindMPI.cmake:628 (find_package_handle_standard_args)
CMakeLists.txt:33 (find_package)`
`-- Configuring incomplete, errors occurred!
See also "/home/l_baumgarten/opal/devel/src/build/CMakeFiles/CMakeOutput.log".`
Module:
`module list
Currently Loaded Modulefiles:
1) cmake/3.6.3 4) Tcl/8.6.4 7) boost/1.62.0 10) trilinos/12.10.1 13) gnuplot/5.0.0
2) gcc/5.4.0 5) Tk/8.6.4 8) gsl/2.2.1 11) hdf5/1.8.18
3) openssl/1.0.2j 6) Python/2.7.12 9) openmpi/1.10.4 12) H5hut/2.0.0rc3`gsellgsellhttps://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/84Cyclotron (COMET) does not read RFMAPFN's2020-12-07T13:27:04+01:00adelmannCyclotron (COMET) does not read RFMAPFN's```
COMET: Cyclotron, TYPE="BANDRF", CYHARMON= 2, PHIINIT= -71.649, PRINIT= pr0, RINIT= r0 , SYMMETRY= 1.0,
FMAPFN="BMap_Christian.txt",
RFPHI= {hfphi0/180*pi,hfphi0/180*pi,hfphi0/180*pi,hfphi0/180...```
COMET: Cyclotron, TYPE="BANDRF", CYHARMON= 2, PHIINIT= -71.649, PRINIT= pr0, RINIT= r0 , SYMMETRY= 1.0,
FMAPFN="BMap_Christian.txt",
RFPHI= {hfphi0/180*pi,hfphi0/180*pi,hfphi0/180*pi,hfphi0/180*pi,0.5*pi,0.5*pi,0.5*pi,0.5*pi},
RFFREQ= {frequency,frequency,frequency,frequency,0,0,0,0},
RFMAPFN={"ChimneyEB.h5part","PullerEB.h5part","M77EB.h5part","COMETRF_x850EBc.h5part",
"ehfieldTR.h5part","ehfieldTR2.h5part","ehfieldTR3.h5part","ehfieldTR4.h5part"},
ESCALE={0.84,0.84,0.84,0.4395,-4.5,+6.5,+4.5,-6.5},
MAXZ=15, MINZ=-15, MINR=0, MAXR= 881.1,
SUPERPOSE={false,false,false,false,true,true,true,true};
```
The full set of inputfiles is to large. All inputfiles can be found at: merlinl1.psi.ch:~adelmann/COMET/1.5.1-20170217OPAL 2021.1adelmannext-calvo_ppedro.calvo@ciemat.esadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/83Bethe-Bloch threshold2021-01-30T19:16:00+01:00adelmannBethe-Bloch thresholdAllow the user to specify when a particle is dead (in the Bethe-Bloch) calculationAllow the user to specify when a particle is dead (in the Bethe-Bloch) calculationOPAL 2021.1adelmannext-calvo_ppedro.calvo@ciemat.esadelmann