src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2022-02-14T09:42:39+01:00https://gitlab.psi.ch/OPAL/src/-/issues/668Different initial distribution with same input file2022-02-14T09:42:39+01:00albajacas_aarnau.albajacas@psi.chDifferent initial distribution with same input file### Summary
When running regression tests multiple times, some parameters of the initial distribution are different at each run, even though `SEED` is the default. Initial differences are small, but they diverge with time and can yield ...### Summary
When running regression tests multiple times, some parameters of the initial distribution are different at each run, even though `SEED` is the default. Initial differences are small, but they diverge with time and can yield larger-than-machine-precision errors in the final time-step, which makes it harder to reproduce results and run regression tests (e.g. see OPAL/src#658).
### Steps to reproduce
By running the regression test [`Distribution-Gauss-1.in`](https://gitlab.psi.ch/OPAL/regression-tests/-/blob/master/RegressionTests/Distribution-Gauss-1/Distribution-Gauss-1.in) several times one can see that the initial bunch is not the same at each run (see image below).
However, this only happens when I run the tests on 4 cores. When running the test on 1 or 2 cores the initial distribution is the same at every run. So I suspect that this might be due to differences in timing of communication between processors.
Comparison of the initial bunch between three runs on 4 cores:
![comparison](/uploads/dd69f637b7e16b6b39cdd4ff2e2aeb5e/comparison.png)2022.1krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/663Clang compiler errors with c++172021-06-28T09:48:49+02:00snuverink_jjochem.snuverink@psi.chClang compiler errors with c++17In c++17 `std::bind2nd` has been deprecated resulting in compiler errors with clang version 12:
```
OPAL/src/src/Classic/Algebra/Matrix.h:194:25: error: no member
named 'bind2nd' in namespace 'std'
std::bind2nd(...In c++17 `std::bind2nd` has been deprecated resulting in compiler errors with clang version 12:
```
OPAL/src/src/Classic/Algebra/Matrix.h:194:25: error: no member
named 'bind2nd' in namespace 'std'
std::bind2nd(std::multiplies<T>(), val));
~~~~~^
```OPAL 2021.1snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/659Some regression tests broken2021-06-16T14:05:43+02:00ext-calvo_ppedro.calvo@ciemat.esSome regression tests brokenAfter implementing #657, EGunCTF3-1, EGunCTF3-2, GasStripping, PROSCAN-1 and PSI-Gun-1 tests are broken (see [link](http://amas.web.psi.ch/opal/regressionTests/master/results_2021-06-14_22-30.xml)).
In case of GasStripping test, there i...After implementing #657, EGunCTF3-1, EGunCTF3-2, GasStripping, PROSCAN-1 and PSI-Gun-1 tests are broken (see [link](http://amas.web.psi.ch/opal/regressionTests/master/results_2021-06-14_22-30.xml)).
In case of GasStripping test, there is an error in `OPTION` statements (OPAL/regression-tests#105).
In other cases, the errors are duplicate file names for output. The element names or `OUTFN` are not repeated, so it seems to be because the element is called twice during the tracking.OPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/657Element output files must not be overwritten2021-06-15T09:57:28+02:00ext-calvo_ppedro.calvo@ciemat.esElement output files must not be overwrittenOutput file names defined by `OUTFN` must not be repeated to avoid data loss. In that case, an exception must be thrown.
In addition, to ensure correct writing of output files by LossDataSink, we should check if `ASCIIDUMP` or `ENABLEHD...Output file names defined by `OUTFN` must not be repeated to avoid data loss. In that case, an exception must be thrown.
In addition, to ensure correct writing of output files by LossDataSink, we should check if `ASCIIDUMP` or `ENABLEHDF5` are `TRUE`OPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/656Logical error in Boundarygeometry2021-06-10T18:33:19+02:00snuverink_jjochem.snuverink@psi.chLogical error in Boundarygeometryclang 12.0.0 reports compiler warnings that sound like a serious bug:
```
src/Structure/BoundaryGeometry.cpp:600:50: warning:
operator '?:' has lower precedence than '|'; '|' will be evaluated first
[-Wbitwise-conditional-p...clang 12.0.0 reports compiler warnings that sound like a serious bug:
```
src/Structure/BoundaryGeometry.cpp:600:50: warning:
operator '?:' has lower precedence than '|'; '|' will be evaluated first
[-Wbitwise-conditional-parentheses]
(A[2] < EPS) ? 1 : 0 | (A[2] > -EPS) ? 8 : 0);
~~~~~~~~~~~~~~~~~ ^
```OPAL 2021.1snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/653Octupole magnet strengths are set using the formula for Decapoles2021-06-10T10:07:15+02:00adelmannOctupole magnet strengths are set using the formula for Decapoles### Summary
In the course of trying to get Opal to agree with another code, Finn O'Shea discovered that the normal component of the octupole strength
is set using the formula for decapoles. Line 114 of Multipole.cpp shows that the OCT...### Summary
In the course of trying to get Opal to agree with another code, Finn O'Shea discovered that the normal component of the octupole strength
is set using the formula for decapoles. Line 114 of Multipole.cpp shows that the OCTUPOLE case is combined with the DECAPOLE case:
### Steps to reproduce
will ask for input file(s)
### What is the current *bug* behavior?
OCTUPOLE behaves like a DECAPOLE, see also the attached file with the trace win "reference" solution, provided by Finn O'Shea.
### What is the expected *correct* behavior?
see below
### Relevant logs and/or screenshots
```
case OCTUPOLE:
case DECAPOLE:
NormalComponents[n - 1] = (v + vError) / 24;
NormalComponentErrors[n - 1] = vError / 24;
break;
```
### Possible fixes
```
case OCTUPOLE:
NormalComponents[n - 1] = (v + vError) / 6;
NormalComponentErrors[n - 1] = vError / 6;
break;
case DECAPOLE:
NormalComponents[n - 1] = (v + vError) / 24;
NormalComponentErrors[n - 1] = vError / 24;
break;
```
[octupoles.tar.gz](/uploads/6cb3061fbe6619e5563a275bf3eb1fca/octupoles.tar.gz)OPAL 2021.1snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/652DumpFieldsTest and DumpEMFieldsTest failed2021-06-11T08:06:22+02:00ext-calvo_ppedro.calvo@ciemat.esDumpFieldsTest and DumpEMFieldsTest failedAfter implementing OPAL/src#651 the DumpFieldsTest and DumpEMFieldsTest failed (see [output](http://amas.web.psi.ch/opal/master/output/2021-05-10_22-30.txt)).
- The dumped fields tests must be modified to write the files into OPAL auxil...After implementing OPAL/src#651 the DumpFieldsTest and DumpEMFieldsTest failed (see [output](http://amas.web.psi.ch/opal/master/output/2021-05-10_22-30.txt)).
- The dumped fields tests must be modified to write the files into OPAL auxiliary output directory
- `COORDINATE_SYSTEM` is defined now as UpperCaseStringOPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/649INPUTMOUNITS is now eV/c instead of eV2021-10-13T17:11:54+02:00albajacas_aarnau.albajacas@psi.chINPUTMOUNITS is now eV/c instead of eVAs pointed out by Hui Zhang, when we updated the momentum conversion formula in #475, the input units for momentum became [eV/c] instead of [eV].
Accordingly, the command for changing units
```
INPUTMOUNITS=EV
```
should be changed to s...As pointed out by Hui Zhang, when we updated the momentum conversion formula in #475, the input units for momentum became [eV/c] instead of [eV].
Accordingly, the command for changing units
```
INPUTMOUNITS=EV
```
should be changed to something like
```
INPUTMOUNITS=EV/c
```
And it should also be corrected in the manual in section 15.1
- [x] Update code OPAL/src!490
- [x] Update documentation OPAL/documentation/manual!126
- [x] Update regression tests OPAL/regression-tests!29OPAL 2021.1albajacas_aarnau.albajacas@psi.chalbajacas_aarnau.albajacas@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/645Fix turnNumber in loss output file2021-04-06T09:21:34+02:00ext-calvo_ppedro.calvo@ciemat.esFix turnNumber in loss output fileAfter implementing OPAL/src#503, loss files in ASCII format is not considering `turnNumber` info when simulations are performed in parallel environment unless all nodes has particles.
`hasTurnInformations()` could be modified to fix itAfter implementing OPAL/src#503, loss files in ASCII format is not considering `turnNumber` info when simulations are performed in parallel environment unless all nodes has particles.
`hasTurnInformations()` could be modified to fix itext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/644Sampler cleanup with KEEP option not working when directory is present2021-06-11T10:53:01+02:00snuverink_jjochem.snuverink@psi.chSampler cleanup with KEEP option not working when directory is present### Summary
Reported by @ext-piot_p on the OPAL mailing list. With the option `SAMPLE, KEEP` non-empty, non-wanted files should be deleted, but an error message is shown instead when a non-empty subdirectory is present in the simulation...### Summary
Reported by @ext-piot_p on the OPAL mailing list. With the option `SAMPLE, KEEP` non-empty, non-wanted files should be deleted, but an error message is shown instead when a non-empty subdirectory is present in the simulation directory.
### Steps to reproduce
An OPAL Sampler simulation whereby also files in the auxiliary directory (`/data`) are produced together with the `KEEP` option of the `SAMPLER`.
### What is the current *bug* behavior?
An error message is shown and the unwanted files are not (all) deleted.
### What is the expected *correct* behavior?
No error message and all but the files with extensions in the `KEEP` option should be deleted.
### Relevant logs and/or screenshots
```
OPAL{0}> opal varyTDCphase.in --inputfile=varyTDCphase.tmpl --outfile=phiscan --outdir=phiscan --num-masters=1 --num-coworkers=2 --restartstep=-2147483648 --jsonDumpFreq=1 --nsamples=11 --simtmpdir=/home/piot/OpalSandBox/scan_example/phiscan --templates=/home/piot/OpalSandBox/scan_example/template
7 (PID: 214335) ▶ Worker
1 (PID: 214329) ▶ Sampler
2 (PID: 214330) ▶ Worker
3 (PID: 214331) ▶ Worker
4 (PID: 214332) ▶ Worker
5 (PID: 214333) ▶ Worker
6 (PID: 214334) ▶ Worker
✔ 40 objectives
✔ 1 dvars
0 (PID: 214328) ▶ Pilot
Warning: argument "one-pilot-converge" not found! Using default value (0).
Warning: argument "restartfile" not found! Using default value ().
Warning: argument "restartfile" not found! Using default value ().
Ippl> CommMPI: Started job 1 on host `localhost.localdomain'.
Ippl> CommMPI: Parent process waiting for children ...
Ippl> CommMPI: Child 1 ready.
Ippl> CommMPI: Initialization complete.
Warning: argument "restartfile" not found! Using default value ().
Warning: argument "restartfile" not found! Using default value ().
Ippl> CommMPI: Started job 1 on host `localhost.localdomain'.
Ippl> CommMPI: Parent process waiting for children ...
Ippl> CommMPI: Child 1 ready.
Ippl> CommMPI: Initialization complete.
Warning: argument "restartfile" not found! Using default value ().
Warning: argument "restartfile" not found! Using default value ().
Ippl> CommMPI: Started job 1 on host `localhost.localdomain'.
Ippl> CommMPI: Parent process waiting for children ...
Ippl> CommMPI: Child 1 ready.
Ippl> CommMPI: Initialization complete.
Can't remove file in directory '/home/piot/OpalSandBox/scan_example/phiscan/1', (boost::filesystem::remove: Directory not empty: "/home/piot/OpalSandBox/scan_example/phiscan/1/data")
```
### Possible fixes
The function [`OpalSimulation::Cleanup(const std::vector<std::string>& keep)`](https://gitlab.psi.ch/OPAL/src/-/blob/f3d1060a910e9f46f67bfb6807db1ea9e992c57a/src/Optimize/OpalSimulation.cpp#L632)
does not take into account the possibility that a subdirectory might be present. It could check if the path is a directory and if so use `boost::filesystem::remove_all` (or [the c++17 equivalent](https://en.cppreference.com/w/cpp/filesystem/remove)) instead of `boost::filesystem::remove` to remove these non-empty subdirectories. Possibly even better would be if the subdirectories are traversed and files with proper extensions are kept.OPAL 2021.1krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/641UndulatorAWA-Test yielding different results2021-10-13T09:30:38+02:00krausUndulatorAWA-Test yielding different resultsAfter implementing OPAL/src#503 the UndulatorAWA-Test yields slightly different results.After implementing OPAL/src#503 the UndulatorAWA-Test yields slightly different results.OPAL 2021.1krausalbajacas_aarnau.albajacas@psi.chkraushttps://gitlab.psi.ch/OPAL/src/-/issues/639unused variable in ippl/test/particle/p3m3dMicrobunching.cpp2021-03-23T09:39:02+01:00gsellunused variable in ippl/test/particle/p3m3dMicrobunching.cppCompilation fails with an `unused variable` warning in `ippl/test/particle/p3m3dMicrobunching.cpp` if compile type is set to `Release`.Compilation fails with an `unused variable` warning in `ippl/test/particle/p3m3dMicrobunching.cpp` if compile type is set to `Release`.OPAL 2021.1gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/638Fix algorithm for computation of standard deviation2021-10-13T09:30:21+02:00krausFix algorithm for computation of standard deviationFrom a discussion on MR 477 (https://gitlab.psi.ch/OPAL/src/-/merge_requests/477#note_30754):
> I think the equation for stdTime_m is not correct. It should be std::sqrt((localMoments[l++] - totalNumParticles_m *
> std::pow(meanTime_m, ...From a discussion on MR 477 (https://gitlab.psi.ch/OPAL/src/-/merge_requests/477#note_30754):
> I think the equation for stdTime_m is not correct. It should be std::sqrt((localMoments[l++] - totalNumParticles_m *
> std::pow(meanTime_m, 2)) * perParticle). However, this way of calculating can be numerically unstable (see also
> https://en.wikipedia.org/wiki/Algorithms_for_calculating_variance).
>
> I usually do a double loop, but that might be not so easy here. Perhaps with "Computing shifted data" with the first value
> taken as preliminary mean (this seems valid since the particle times are not expected to lie very far away from each other,
> or Welford's algorithm can be tried?OPAL 2021.1krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/637Segmantation fault with BoundaryGeometry2021-02-17T11:21:51+01:00ext-calvo_ppedro.calvo@ciemat.esSegmantation fault with BoundaryGeometrySince MR OPAL/src!464, I got a segmentation fault running opal-cycl with geometry
```
*** Process received signal ***
Signal: Aborted (6)
Signal code: (-6)
[ 0] /lib64/libpthread.so.0[0x30b520f130]
[ 1] /lib64/libc.so.6(gsignal+0x39)[0...Since MR OPAL/src!464, I got a segmentation fault running opal-cycl with geometry
```
*** Process received signal ***
Signal: Aborted (6)
Signal code: (-6)
[ 0] /lib64/libpthread.so.0[0x30b520f130]
[ 1] /lib64/libc.so.6(gsignal+0x39)[0x30b4a359d9]
[ 2] /lib64/libc.so.6(abort+0x148)[0x30b4a370e8]
[ 3] opal(_ZNSt6vectorIN7Message7MsgItemESaIS1_EE7reserveEm+0x0)[0x64af30]
[ 4] opal[0x80121b]
[ 5] opal(_ZN16BoundaryGeometry10initializeEv+0x2e62)[0x8044e2]
[ 6] opal(_ZN16BoundaryGeometryC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPS_+0x348)[0x805468]
[ 7] opal(_ZN16BoundaryGeometry5cloneERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x25)[0x8055e5]
[ 8] opal(_ZN8TrackRun21setupCyclotronTrackerEv+0xeb0)[0x81ea60]
[ 9] opal(_ZN8TrackRun7executeEv+0xc8)[0x8211d8]
[10] opal(_ZNK10OpalParser7executeEP6ObjectRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x3a)[0x6f197a]
[11] opal(_ZNK10OpalParser11parseActionER9Statement+0xfd)[0x6f5ced]
[12] opal(_ZNK10OpalParser5parseER9Statement+0x173)[0x6f4933]
[13] opal(_ZNK10OpalParser3runEv+0x4e)[0x6f214e]
[14] opal(_ZN8TrackCmd7executeEv+0x97c)[0x81b50c]
[15] opal(_ZNK10OpalParser7executeEP6ObjectRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x3a)[0x6f197a]
[16] opal(_ZNK10OpalParser11parseActionER9Statement+0xfd)[0x6f5ced]
[17] opal(_ZNK10OpalParser5parseER9Statement+0x173)[0x6f4933]
[18] opal(_ZNK10OpalParser3runEv+0x4e)[0x6f214e]
[19] opal(_ZNK10OpalParser3runEP11TokenStream+0x70)[0x6f6260]
[20] opal(main+0x1f5d)[0x6443cd]
[21] /lib64/libc.so.6(__libc_start_main+0xf5)[0x30b4a21b45]
[22] opal[0x6356a9]
```
cc: @kraus, @gsellOPAL 2021.1https://gitlab.psi.ch/OPAL/src/-/issues/636Loss files overwritten for collimators2021-02-08T13:30:30+01:00ext-calvo_ppedro.calvo@ciemat.esLoss files overwritten for collimatorsThe particles hitting the collimator and lost particles by energy loss in the material are saved in the same file because the file name are equal.
Renaming the file for lost particles by particle-matter interactions according to the lab...The particles hitting the collimator and lost particles by energy loss in the material are saved in the same file because the file name are equal.
Renaming the file for lost particles by particle-matter interactions according to the label of `PARTICLEMATTERINTERACTION` command, we'll be able to distinguish both casesOPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/635Get correct output of VALUE, OPTION->AUTOPHASE2021-10-13T09:30:59+02:00krausGet correct output of VALUE, OPTION->AUTOPHASEWhen querying the value of Options the user gets the default value but not the actual value. E.g. after
```
OPTION, AUTOPHASE=4;
VALUE, OPTION->AUTOPHASE;
```
one would expect to get
```
value: {OPTION->AUTOPHASE} = {4}
```
as output. B...When querying the value of Options the user gets the default value but not the actual value. E.g. after
```
OPTION, AUTOPHASE=4;
VALUE, OPTION->AUTOPHASE;
```
one would expect to get
```
value: {OPTION->AUTOPHASE} = {4}
```
as output. But this isn't the case.OPAL 2021.1krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/627Add -Wp,-D_GLIBCXX_ASSERTIONS to the build flags2021-10-13T09:30:48+02:00krausAdd -Wp,-D_GLIBCXX_ASSERTIONS to the build flagsAs reported by Rob from Radiasoft (see below) Fedora (and also RHEL and derivatives?) adds "-Wp,-D_GLIBCXX_ASSERTIONS" to the build flags. This results, among other things, in checking the memory access in STL containers. In Opal we ofte...As reported by Rob from Radiasoft (see below) Fedora (and also RHEL and derivatives?) adds "-Wp,-D_GLIBCXX_ASSERTIONS" to the build flags. This results, among other things, in checking the memory access in STL containers. In Opal we often use `&someVector[0]` which can cause an assertion if the vector has no elements. Where it isn't guaranteed that the vector has elements we have to handle this situation (e.g. as in [Boost::mpi](https://www.boost.org/doc/libs/1_75_0/boost/mpi/detail/antiques.hpp) ) to avoid an assertion failure in combination with `_GLIBCXX_ASSERTIONS`.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: Rob Nagler <opal-rtnkh@q33.us>
Date: Tue, 22 Dec 2020 17:04:55 -0700
Subject: Re: [Opal] Compiling issues (Fedora 32/gcc10)
Ran into another issue with Fedora 32. They've turned on code hardening (
discussion
<https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/TMDJMX2OYE7Z2WHKXMOMTOBDHJKZJ3NV/>)
so wrappers like mpicxx automatically include flags like
"-Wp,-D_GLIBCXX_ASSERTIONS", which in this case causes opal to fail to run,
because of an assertion failure in stl_vector. I've included the stack
below. I've worked around this by patching mpicxx & company, but I suspect
it might be useful to turn on _GLIBCXX_ASSERTIONS to find some latent bugs
in the code.
Cheers,
Rob
(gdb) run opal.in
Starting program: /home/vagrant/.local/bin/opal opal.in
Missing separate debuginfos, use: dnf debuginfo-install
glibc-2.31-4.fc32.x86_64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Ippl> CommMPI: Parent process waiting for children ...
Ippl> CommMPI: Initialization complete.
> ____ _____ ___
> / __ \| __ \ /\ | |
> | | | | |__) / \ | |
> | | | | ___/ /\ \ | |
> | |__| | | / ____ \| |____
> \____/|_| /_/ \_\______|
OPAL>
OPAL> This is OPAL (Object Oriented Parallel Accelerator Library) Version
2.4.0
OPAL> git rev. unknown
OPAL>
OPAL>
OPAL> (c) PSI, http://amas.web.psi.ch
OPAL>
OPAL>
OPAL> The optimiser (former opt-Pilot) is integrated
OPAL>
OPAL> Please send cookies, goodies or other motivations (wine and beer ... )
OPAL> to the OPAL developers opal@lists.psi.ch
OPAL>
OPAL> Time: 23:59:38 date: 22/12/2020
OPAL>
OPAL> Couldn't find startup file "/home/vagrant/init.opal".
OPAL> Note: this is not mandatory for an OPAL simulation!
OPAL>
OPAL> * Reading input stream "opal.in".
OPAL> *
**********************************************************************************
OPAL> * Selected Tracking Method == PARALLEL-T, NEW TRACK
OPAL> *
**********************************************************************************
/usr/include/c++/10/bits/stl_vector.h:1045: std::vector<_Tp,
_Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp,
_Alloc>::size_type) [with _Tp = char; _Alloc = std::allocator<char>; \
std::vector<_Tp, _Alloc>::reference = char&; std::vector<_Tp,
_Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n <
this->size(), true)' failed.
Program received signal SIGABRT, Aborted.
0x00007ffff683e9e5 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install
blas-3.9.0-3.fc32.x86_64 bzip2-libs-1.0.8-2.fc32.x86_64
gsl-2.6-2.fc32.x86_64 hdf5-mpich-1.10.5-6.fc32.x86_64
hwloc-libs-2.0.4-3.fc32.x86_64 lapack\
-3.9.0-3.fc32.x86_64 libaec-1.0.4-3.fc32.x86_64 libgcc-10.2.1-6.fc32.x86_64
libgfortran-10.2.1-6.fc32.x86_64 libicu-65.1-2.fc32.x86_64
libquadmath-10.2.1-6.fc32.x86_64 libstdc++-10.2.1-6.fc32.x86_64 libt\
ool-ltdl-2.4.6-33.fc32.x86_64 mpich-3.3.2-4.fc32.x86_64
xz-libs-5.2.5-1.fc32.x86_64 zlib-1.2.11-21.fc32.x86_64
(gdb) bt
bt
#0 0x00007ffff683e9e5 in raise () from /lib64/libc.so.6
#1 0x00007ffff6827895 in abort () from /lib64/libc.so.6
#2 0x0000555555e9cb38 in std::__replacement_assert
(__file=__file@entry=0x5555578604d0
"/usr/include/c++/10/bits/stl_vector.h", __line=__line@entry=1045,
__function=__function@entry=0x555557880338 "std::vector<_Tp,
_Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp,
_Alloc>::size_type) [with _Tp = char; _Alloc = std::allocator<cha\
r>; std::vector<_Tp, _Alloc>::reference = cha"...,
__condition=__condition@entry=0x555557860370 "__builtin_expect(__n <
this->size(), true)")
at /usr/include/c++/10/x86_64-redhat-linux/bits/c++config.h:2560
#3 0x0000555556329045 in std::vector<char, std::allocator<char>
>::operator[] (__n=0, this=0x7fffffffb750) at
/usr/include/c++/10/bits/ios_base.h:170
#4 Distribution::createDistributionFromFile (this=0x5555585afe50,
massIneV=<optimized out>) at
/home/vagrant/src-OPAL-2.4.0/src/Distribution/Distribution.cpp:1109
#5 0x00005555563295f0 in Distribution::create (this=0x5555585afe50,
numberOfParticles=@0x555558616c70: 10000, massIneV=510998.95000000001,
charge=-1)
at /home/vagrant/src-OPAL-2.4.0/src/Distribution/Distribution.cpp:290
#6 0x000055555632a015 in Distribution::createOpalT (this=0x5555585afe50,
beam=0x5555585b3bb0, numberOfParticles=@0x7fffffffc228: 10000) at
/usr/include/c++/10/bits/stl_vector.h:1092
#7 0x00005555560a403c in PartBunchBase<double, 3u>::setDistribution
(np=@0x7fffffffc228: 10000, addedDistributions=..., d=<optimized out>,
this=0x5555585b3bb0)
at /usr/include/c++/10/bits/stl_algobase.h:560
#8 TrackRun::setDistributionParallelT (this=0x5555585b5ba0,
beam=0x5555585af8d0) at
/home/vagrant/src-OPAL-2.4.0/src/Track/TrackRun.cpp:680
#9 0x00005555560a9282 in TrackRun::setupTTracker (this=0x5555585b5ba0) at
/home/vagrant/src-OPAL-2.4.0/src/Track/TrackRun.cpp:353
#10 0x00005555560aa482 in TrackRun::execute (this=0x5555585b5ba0) at
/home/vagrant/src-OPAL-2.4.0/src/Track/TrackRun.cpp:174
#11 0x0000555555f3a46f in OpalParser::execute (this=<optimized out>,
object=0x5555585b5ba0, name="RUN") at
/home/vagrant/src-OPAL-2.4.0/src/OpalParser/OpalParser.cpp:139
#12 0x0000555555f3e054 in OpalParser::parseAction (this=0x5555585b2870,
stat=...) at /home/vagrant/src-OPAL-2.4.0/src/OpalParser/OpalParser.cpp:172
#13 0x0000555555f3e6a4 in OpalParser::parse (this=0x5555585b2870, stat=...)
at /home/vagrant/src-OPAL-2.4.0/src/OpalParser/OpalParser.cpp:90
#14 0x0000555555f3e42e in OpalParser::run (this=0x5555585b2870) at
/home/vagrant/src-OPAL-2.4.0/src/OpalParser/OpalParser.cpp:607
#15 0x00005555560a25b0 in TrackCmd::execute (this=<optimized out>) at
/home/vagrant/src-OPAL-2.4.0/src/Track/TrackCmd.cpp:211
#16 0x0000555555f3a46f in OpalParser::execute (this=<optimized out>,
object=0x5555585b2050, name="TRACK") at
/home/vagrant/src-OPAL-2.4.0/src/OpalParser/OpalParser.cpp:139
#17 0x0000555555f3b3b0 in OpalParser::parseDefine (this=0x7fffffffd850,
stat=...) at /home/vagrant/src-OPAL-2.4.0/src/OpalParser/OpalParser.cpp:356
#18 0x0000555555f3e65c in OpalParser::parse (this=0x7fffffffd850, stat=...)
at /home/vagrant/src-OPAL-2.4.0/src/OpalParser/OpalParser.cpp:82
#19 0x0000555555f3e42e in OpalParser::run (this=0x7fffffffd850) at
/home/vagrant/src-OPAL-2.4.0/src/OpalParser/OpalParser.cpp:607
#20 0x0000555555f3a9f8 in OpalParser::run (this=0x7fffffffd850,
is=<optimized out>) at
/home/vagrant/src-OPAL-2.4.0/src/OpalParser/OpalParser.cpp:632
#21 0x0000555555e6e4b7 in main (argc=<optimized out>, argv=<optimized out>)
at /home/vagrant/src-OPAL-2.4.0/src/Main.cpp:349
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~OPAL 2021.1krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/622Check read of FROMFILE distribution2020-12-01T09:03:37+01:00ext-calvo_ppedro.calvo@ciemat.esCheck read of FROMFILE distributionThere is an `OpalException` in `Distribution::createDistributionFromFile` to check if the external file of the initial distribution exists. But it is not working in parallel environment.There is an `OpalException` in `Distribution::createDistributionFromFile` to check if the external file of the initial distribution exists. But it is not working in parallel environment.OPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/620Header of loss files2020-11-30T16:49:59+01:00ext-calvo_ppedro.calvo@ciemat.esHeader of loss files### Summary
Bad implementation of the header in ASCII files
### What is the current *bug* behavior?
The header of loss files in ASCII format is bad written when simulations are performed in parallel environment and the time variable ...### Summary
Bad implementation of the header in ASCII files
### What is the current *bug* behavior?
The header of loss files in ASCII format is bad written when simulations are performed in parallel environment and the time variable is considered. If the node 0 has no particles, the header is incomplete
### What is the expected *correct* behavior?
The header should include `turn`, `bunchNum` and `time` variables
### Possible fixes
Make use of `hasTimeAttribute()` functionOPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/615Opal version in master branch2020-10-09T13:30:32+02:00ext-calvo_ppedro.calvo@ciemat.esOpal version in master branchOPAL VERSION should be change to 2.5 in master branch (CMakeLists.txt actually shows 2.3)OPAL VERSION should be change to 2.5 in master branch (CMakeLists.txt actually shows 2.3)ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.es