src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2023-05-16T14:46:42+02:00https://gitlab.psi.ch/OPAL/src/-/issues/655Remove real variable P02023-05-16T14:46:42+02:00krausRemove real variable P0The attribute `PC` of the `BEAM` command gets `P0` as default value. `P0` is defined to create a `1 GeV` beam. If a user forgets to set the energy of the beam then Opal should throw an exception. Using a default value here results in unn...The attribute `PC` of the `BEAM` command gets `P0` as default value. `P0` is defined to create a `1 GeV` beam. If a user forgets to set the energy of the beam then Opal should throw an exception. Using a default value here results in unnecessary mistakes. When `PC` doens't have default value then we can also remove `P0` which is created in a rather strange way.OPAL 2021.1krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/654Add Attribute Type PredefinedString2023-09-26T11:56:07+02:00krausAdd Attribute Type PredefinedStringAttributes of type `PredefinedString` should only accept strings which are contained in a predefined set of strings. For each such attribute the set of accepted strings have to be provided to the constructor. The input of the user is the...Attributes of type `PredefinedString` should only accept strings which are contained in a predefined set of strings. For each such attribute the set of accepted strings have to be provided to the constructor. The input of the user is then checked and if the provided string isn't contained in the predefined set an exception is thrown. Examples for such attributes are the attribute `FSTYPE` of the `FIELDSOLVER` command which accepts `FFT`, `FFTPERIODIC`, `SAAMG` and `NONE` or the attribute `EMISSIONMODEL` of the `DISTRIBUTION` command which accepts `NONE`, `ASTRA` and `NONEQUIL`.
The list of accepted strings as well as the default value, if any, are added to the help message.
The type of most `UpperCaseString` attributes can be change to `PredefinedString`.OPAL 2021.1krauskraushttps://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/651Printing info of DumpFields and DumpEMFields2021-05-11T10:45:39+02:00ext-calvo_ppedro.calvo@ciemat.esPrinting info of DumpFields and DumpEMFieldsDumpFields and DumpEMFields statements must print information about their attributes to stdout.DumpFields and DumpEMFields statements must print information about their attributes to stdout.OPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/650Define OUTFN as common attribute2022-03-17T08:55:14+01:00ext-calvo_ppedro.calvo@ciemat.esDefine OUTFN as common attributeThe `OUTFN` attribute to set the output file name of some elements could be fixed as a common attribute for all elements to avoid code duplication.The `OUTFN` attribute to set the output file name of some elements could be fixed as a common attribute for all elements to avoid code duplication.OPAL 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/648File header for BasicActions classes2021-04-22T15:31:14+02:00ext-calvo_ppedro.calvo@ciemat.esFile header for BasicActions classesThis issue fixes the coding style and adds the file header for BasicActions classesThis issue fixes the coding style and adds the file header for BasicActions classesOPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/647Add option to write VTK file2021-04-23T11:25:53+02:00ext-calvo_ppedro.calvo@ciemat.esAdd option to write VTK fileWriting the VTK file of the voxel mesh increases the time consumption. To speed up boundary geometry initialization I propose to add an option to disable VTK files. In addition, as @gsell suggested, VTK files should only be written if th...Writing the VTK file of the voxel mesh increases the time consumption. To speed up boundary geometry initialization I propose to add an option to disable VTK files. In addition, as @gsell suggested, VTK files should only be written if they do not exist or are older than the geometry file.OPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/646Extend the list of symbolic constant2021-04-16T09:57:33+02:00ext-calvo_ppedro.calvo@ciemat.esExtend the list of symbolic constantThe physical constants recognized by OPAL must include all the particle masses defined in the `Beam` command. This prevents the user from defining a value for the mass that differs from the value considered internally by OPAL.
- [x] Def...The physical constants recognized by OPAL must include all the particle masses defined in the `Beam` command. This prevents the user from defining a value for the mass that differs from the value considered internally by OPAL.
- [x] Define masses as standard constants (see !487)
- [x] Update documentation (see OPAL/documentation/manual!124)OPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://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/643Remove unnecessary condition in CCollimators2021-03-26T11:52:31+01:00ext-calvo_ppedro.calvo@ciemat.esRemove unnecessary condition in CCollimatorsCCollimator is currently restricted only for `REGULAR` particles, but all the `ParticleOrigin` must be consideredCCollimator is currently restricted only for `REGULAR` particles, but all the `ParticleOrigin` must be consideredOPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/642Stop particles in probe2021-03-26T08:27:43+01:00ext-calvo_ppedro.calvo@ciemat.esStop particles in probeAdds a user option to stop particle tracking in the probe elementAdds a user option to stop particle tracking in the probe elementext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://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/640Update time unit in loss output file of some elements2021-03-24T09:09:01+01:00ext-calvo_ppedro.calvo@ciemat.esUpdate time unit in loss output file of some elementsFrom a [discussion](https://gitlab.psi.ch/OPAL/src/-/merge_requests/477#note_30392) on MR !477, and in agreement with #357, the unit of time should be unified to `s` in some elements to avoid inconsistencies in the `LossDataSink` output ...From a [discussion](https://gitlab.psi.ch/OPAL/src/-/merge_requests/477#note_30392) on MR !477, and in agreement with #357, the unit of time should be unified to `s` in some elements to avoid inconsistencies in the `LossDataSink` output file.OPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://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.es