GitLab

The bunch offsets are taken into account; linear interpolation is implemented in fieldsolver when using H5 geometry

field and potential output to gmsg.

computeSelfFields(_cycl). Needed to have individual cell counters
for the three directions, plus last cell was missing.
Added line to take z position of beam into account when doing
fieldsolve with internal/external beam pipe. Here, the transversal
offset should be taken into account as well...TODO!

- recalculate reference trajectory in bends on node 0 after autophasing; fixes problem of BerlinPro guys; the energy of the beam that the algorithm for autophaseing calculates with a single particle is not exactly the same as we receive in a subsequent regular run with many particles. Therefore we need to readjust the magnetic fields on all cores.

- recalculate reference trajectory inside bends on node 0 after autophasing; fixes problems of BerlinPro guys

- fixing syntax error

main CMakeList.txt: cleanup messages about used compiler, fix issue with comparing used compiler and compiler used to compile Trilinos

main CMakeList.txt: review setting of compiler specific options; minimum cmake version is now 2.8.10(\!)

/gpfs/DDNgpfs1/bekas/YVES/local/bgclang/r209570-20140527/libc++/include/algorithm:2073:5: error: no matching function for call to '__fill'
    _VSTD::__fill(__first, __last, __value_, typename iterator_traits<_ForwardIterator>::iterator_category());
    ^~~~~~~~~~~~~
/gpfs/DDNgpfs1/bekas/YVES/local/bgclang/r209570-20140527/libc++/include/__config:348:15: note: expanded from macro '_VSTD'
#define _VSTD std::_LIBCPP_NAMESPACE
              ^
/gpfs/DDNgpfs1/bekas/YVES/work/OPT/opal/src/Algorithms/ParallelTTracker.cpp:2098:10: note: in instantiation of function template specialization 'std::__1::fill<ParticleAttribIterator<double>, double>' requested
      here
    std::fill(itsBunch->dt.begin(), itsBunch->dt.end(), itsBunch->getdT());
         ^
/gpfs/DDNgpfs1/bekas/YVES/local/bgclang/r209570-20140527/libc++/include/algorithm:2054:1: note: candidate function [with _ForwardIterator = ParticleAttribIterator<double>, _Tp = double] not viable: no known
      conversion from 'typename iterator_traits<ParticleAttribIterator<double> >::iterator_category' (aka 'std::__1::input_iterator_tag') to 'std::__1::forward_iterator_tag' for 4th argument
__fill(_ForwardIterator __first, _ForwardIterator __last, const _Tp& __value_, forward_iterator_tag)
^
/gpfs/DDNgpfs1/bekas/YVES/local/bgclang/r209570-20140527/libc++/include/algorithm:2063:1: note: candidate function [with _RandomAccessIterator = ParticleAttribIterator<double>, _Tp = double] not viable: no known
      conversion from 'typename iterator_traits<ParticleAttribIterator<double> >::iterator_category' (aka 'std::__1::input_iterator_tag') to 'std::__1::random_access_iterator_tag' for 4th argument
__fill(_RandomAccessIterator __first, _RandomAccessIterator __last, const _Tp& __value_, random_access_iterator_tag)
^

definition of var's '*ippl' and '*gmsg' moved from 'opal.h' to 'Main.cpp' and 'opal.cpp' (otherwise we have  a linking problem with optPilot)

Works now parallel. Remaining problems: -- does not go out out scope propperly, -- number of created particles maybe not correct

In case this goes equal or below 1 we stop tracking the bunch and integrating 
in the material until we have in minimum more than one particle on all nodes.

Works for one core (obviously) and the regression test Degarder-1, degrades a 72 MeV beam to 50.200 MeV.
This is the current benchmark, to be confirmed by FLUKA simulations. 

There is a new material Mylar (My) avaidable. 

Problems/ToDo:

-- the increase of NP from 100000 to 100072 is certainly non physical
-- check for more than one core
-- validate the regression test
-- validate Mylar parametrization

matched distribution the CARBONCYCL type has to be used. For example the PSI Ring 
header would look like: 

1800.0
20.0
8
-4.0
1440
141
......

Important: the third line describes the number of sectors AND is not 
specified in the original definition of the CARBONCYCL type. THIS needs to be 
fixed as soon as the matched distribution is working properly.

At the moment the correct sigma matrix will be produced only with the ring590_bfld.dat:

 3.859  -0.6331 0     0	     0.4538 1.324

-0.6331  0.636  0     0      0.7276 -0.2605

 0	 0      6.256 1.197  0	     0

 0	 0      1.197 0.3845 0	     0

 0.4538  0.7276 0     0	     2.396   0.172

 1.324  -0.2605 0     0	     0.172   0.8693

Check at svn+ssh://savannah02.psi.ch/repos/opal/tests/trunk/RegressionTests/RingCyclotronMatched