src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2023-10-05T17:49:18+02:00https://gitlab.psi.ch/OPAL/src/-/issues/765Momentum tolerance in Opal-t2023-10-05T17:49:18+02:00ext-calvo_ppedro.calvo@ciemat.esMomentum tolerance in Opal-tPart of #727
A new parameter `MOMENTUM_TOLERANCE` has recently been introduced to control fractional tolerance to deviations in the distribution compared to the reference data at initialisation. This parameter should be extended to be ...Part of #727
A new parameter `MOMENTUM_TOLERANCE` has recently been introduced to control fractional tolerance to deviations in the distribution compared to the reference data at initialisation. This parameter should be extended to be useful in Opal-t.2023.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/764RingDefinition - Beam rotation and Momentum Tolerance2023-05-16T12:15:30+02:00ext-rogers_cRingDefinition - Beam rotation and Momentum Tolerance### Summary
I would like to be able to introduce an arbitrary rotation to beams in RingDefinition, independent of the azimuthal angle at which the ring is injected. At the moment, transverse "kicks" are enabled by `BEAM_PRINIT` but this...### Summary
I would like to be able to introduce an arbitrary rotation to beams in RingDefinition, independent of the azimuthal angle at which the ring is injected. At the moment, transverse "kicks" are enabled by `BEAM_PRINIT` but this does not permit full rotation through 360 degrees.
My use case:
We decided at a recent meeting that for consistency with the ring layout on the ground in the ring we are designing, the ring should start at "12 o'clock" and proceed in a clockwise direction. OPAL-Cycl mode currently supports element placements in clockwise or anticlockwise direction but beam can only proceed in an anti-clockwise direction.2023.1ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/763ascii2h5block error reading data2023-08-24T11:15:06+02:00ext-calvo_ppedro.calvo@ciemat.esascii2h5block error reading data### Summary
I've got the following error running ascii2h5block tool
```
[proc 0] E: H5Block3dWriteVector3dFieldFloat64: Write to dataset '/Step#0/Block/Efield/0' failed.
```
In addition, the loop to save the results in the h5part for...### Summary
I've got the following error running ascii2h5block tool
```
[proc 0] E: H5Block3dWriteVector3dFieldFloat64: Write to dataset '/Step#0/Block/Efield/0' failed.
```
In addition, the loop to save the results in the h5part format is not necessary, since the input files should already be sorted in the correct format. Therefore, it is sufficient to read the data directly
An enhancement can be included to ensure that the number of data in the fields matches the grid specified in the input header.
### Possible fixes
`H5Block3dSetView` has to be adapted to each field, separately for E-field and H-field.2023.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/729dumping 6D beam matrix at each time steps2022-09-23T12:59:28+02:00ext-piot_pdumping 6D beam matrix at each time steps### Summary
Introduce an option dumpBeamMarix that enable the 21 elements (upper triangle) of the 6D beam (sigma) matrix to be written in the stat file.### Summary
Introduce an option dumpBeamMarix that enable the 21 elements (upper triangle) of the 6D beam (sigma) matrix to be written in the stat file.2022.1ext-piot_pext-piot_phttps://gitlab.psi.ch/OPAL/src/-/issues/703Fix particle definition2022-01-17T08:57:41+01:00ext-calvo_ppedro.calvo@ciemat.esFix particle definition- The `BEAM` command must verify that the particle definition (`PARTICLE` or `MASS` and `CHARGE`) has been explicitly set.
- Likewise, the proper assignment of `NPART` attribute must be checked (it must be positive).
- The `CARBON` charg...- The `BEAM` command must verify that the particle definition (`PARTICLE` or `MASS` and `CHARGE`) has been explicitly set.
- Likewise, the proper assignment of `NPART` attribute must be checked (it must be positive).
- The `CARBON` charge value is erroneous2022.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/699Redefine heavy ion beams2022-01-17T08:08:55+01:00ext-calvo_ppedro.calvo@ciemat.esRedefine heavy ion beamsThe following discussion from !548 should be addressed:
- @snuverink_j started a [discussion](https://gitlab.psi.ch/OPAL/src/-/merge_requests/548#note_35297): (+9 comments)
> Is there maybe a reference why we use these particle ch...The following discussion from !548 should be addressed:
- @snuverink_j started a [discussion](https://gitlab.psi.ch/OPAL/src/-/merge_requests/548#note_35297): (+9 comments)
> Is there maybe a reference why we use these particle charges for Xenon and Uranium? I think it would be good to add this here.
Beam particle definition for heavy ions is not well determined. Uranium and xenon beams can have different ionization states, but currently OPAL only considers a given charge state. The definition of these particles must be reviewed, establishing univocal values for the mass and the charge states as `PARTICLE` types in the `BEAM` command. If any user wants to simulate these type of ions with a different ionization state or other isotope kind, it can be done by means of the attributes `MASS` and `CHARGE`. In addition, the documentation in the Manual must be modified (see OPAL/documentation/manual#70).2022.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/691Fix units in DumpEMFields header2022-01-17T09:03:08+01:00ext-calvo_ppedro.calvo@ciemat.esFix units in DumpEMFields headerThe header of the output files `DumpEMFields` shows units in `mm` when in fact `m` is used (since 62632e45daedb236457be5909bf7144849404c8a).
The units of the input variables must be specified in the Manual (see OPAL/documentation/manual...The header of the output files `DumpEMFields` shows units in `mm` when in fact `m` is used (since 62632e45daedb236457be5909bf7144849404c8a).
The units of the input variables must be specified in the Manual (see OPAL/documentation/manual#68).2022.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/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/634Reviewing physics behind particle matter interaction models2021-04-23T11:25:39+02:00ext-calvo_ppedro.calvo@ciemat.esReviewing physics behind particle matter interaction models- Extend the energy loss calculation and beam scattering for other incoming heavy ions. It is currently only valid for protons
- Add energy loss at very low energy region (1-10 keV) (see ICRU Report 49)
- Document stopping power at Ander...- Extend the energy loss calculation and beam scattering for other incoming heavy ions. It is currently only valid for protons
- Add energy loss at very low energy region (1-10 keV) (see ICRU Report 49)
- Document stopping power at Anderson-Ziegler region
- Update atomic weight of materials according to [database 2019](https://www.qmul.ac.uk/sbcs/iupac/AtWt/) and other [material properties](https://pdg.lbl.gov/2020/AtomicNuclearProperties/)
- Add alpha particle beams
- Review energy threshold for stripper gas interactionsOPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/633Renaming particle matter interactions models and types2021-02-09T15:26:02+01:00ext-calvo_ppedro.calvo@ciemat.esRenaming particle matter interactions models and typesFollowing [discussion](https://gitlab.psi.ch/OPAL/src/-/merge_requests/466#note_29427) from !466, the types of Particle Matter Interactions should be the name of the physics models. Then, `CollimatorPhysics` will be renamed as `Scatterin...Following [discussion](https://gitlab.psi.ch/OPAL/src/-/merge_requests/466#note_29427) from !466, the types of Particle Matter Interactions should be the name of the physics models. Then, `CollimatorPhysics` will be renamed as `ScatteringPhysics`.
I also propose to rename `BeamStripping` element as `Vacuum` in order to use more intuitive element names
This issue involve updating some regression-tests (see OPAL/regression-tests#101)OPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/631Verifying particle matter interaction type2021-01-18T09:27:07+01:00ext-calvo_ppedro.calvo@ciemat.esVerifying particle matter interaction type`TYPE` of particle matter interaction in the input file must be verified through an `OpalException` to prevent misallocation`TYPE` of particle matter interaction in the input file must be verified through an `OpalException` to prevent misallocationOPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/626Add RING cyclotron fieldmap type2020-12-10T09:23:33+01:00ext-calvo_ppedro.calvo@ciemat.esAdd RING cyclotron fieldmap type`RING` fieldmap type (PSI format measured field file) for cyclotron is considered as default if one of the other types are not mentioned. I propose to add this `TYPE` explicitly to the different options, to prevent the bad assignment of ...`RING` fieldmap type (PSI format measured field file) for cyclotron is considered as default if one of the other types are not mentioned. I propose to add this `TYPE` explicitly to the different options, to prevent the bad assignment of the `TYPE` parameter.OPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/579Add option to Source element to make it transparent to backtracking particles.2020-07-23T20:54:11+02:00krausAdd option to Source element to make it transparent to backtracking particles.Add option TRANSPARENT which regulates whether backtracking particles are stopped.Add option TRANSPARENT which regulates whether backtracking particles are stopped.OPAL 2.4.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/578Place elements relative to origin and orientation of beamline2020-07-24T12:51:42+02:00krausPlace elements relative to origin and orientation of beamlineUntil now, elements that are positioned with X, Y, Z instead of ELEMEDGE were positioned absolutely in the laboratory coordinate system. It would be much more practical if these elements were placed relative to the beamline.
As far as I...Until now, elements that are positioned with X, Y, Z instead of ELEMEDGE were positioned absolutely in the laboratory coordinate system. It would be much more practical if these elements were placed relative to the beamline.
As far as I know positioning with X, Y, Z isn't used by anyone yet.OPAL 2.4.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/574P3M solver declaration is missing2021-05-26T12:54:27+02:00ext-calvo_ppedro.calvo@ciemat.esP3M solver declaration is missingP3M solver is missing as FieldSolver type (`FSTYPE`) in FieldSolver.cpp. In addition, it is not documented in the manual (OPAL/documentation/manual#41)P3M solver is missing as FieldSolver type (`FSTYPE`) in FieldSolver.cpp. In addition, it is not documented in the manual (OPAL/documentation/manual#41)OPAL-3.0https://gitlab.psi.ch/OPAL/src/-/issues/564LONG-TRANSV-SHORT-RANGE wake not implemented2020-07-23T17:25:12+02:00snuverink_jjochem.snuverink@psi.chLONG-TRANSV-SHORT-RANGE wake not implemented### Summary
As discovered by @ext\-piot\_p the `LONG-TRANSV-SHORT-RANGE` wake is not implemented.
### Steps to reproduce
`WAKE` command with `TYPE=LONG-TRANSV-SHORT-RANGE`.
### What is the current *bug* behavior?
No warning message,...### Summary
As discovered by @ext\-piot\_p the `LONG-TRANSV-SHORT-RANGE` wake is not implemented.
### Steps to reproduce
`WAKE` command with `TYPE=LONG-TRANSV-SHORT-RANGE`.
### What is the current *bug* behavior?
No warning message, no wakefield.
### What is the expected *correct* behavior?
Correctly implemented wake, or exception thrown.
### Relevant logs and/or screenshots
```c++
} else if (Attributes::getString(itsAttr[TYPE]) == "LONG-TRANSV-SHORT-RANGE") {
//FIXME: NOT IMPLEMENTED YET!!!
} else {
wf_m = 0;
INFOMSG("no wakefunction attached" << endl);
}
```
### Possible fixes
An exception can be thrown, also in the case of a non-matching type (might be a typo).
The mention of `LONG-TRANSV-SHORT-RANGE` should be removed from the manual.OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/546Bend without DESIGNENERGY gives infinite loop2020-07-09T10:48:48+02:00snuverink_jjochem.snuverink@psi.chBend without DESIGNENERGY gives infinite loop### Summary
Bend without DESIGNENERGY gives infinite loop
### Steps to reproduce
Define a bend without design energy
```
REAL bend_radius = 1;
REAL bend_angle = 0.1;
TLA_B : SBEND, ELEMEDGE=0.0, ANGLE = 25.0 / 180 * PI, FMAPFN = "1DP...### Summary
Bend without DESIGNENERGY gives infinite loop
### Steps to reproduce
Define a bend without design energy
```
REAL bend_radius = 1;
REAL bend_angle = 0.1;
TLA_B : SBEND, ELEMEDGE=0.0, ANGLE = 25.0 / 180 * PI, FMAPFN = "1DPROFILE1-DEFAULT", L = 2 * bend_radius * sin(bend_angle / 2.0), HAPERT = 2.2;
```
### What is the current *bug* behavior?
Infinite loop
### What is the expected *correct* behavior?
Either:
* Throw exception at parsing
* Track through with design energy zero
* Set design energy to initial energy of the beam
### Relevant logs and/or screenshots
```
OPAL[2]> Phase space dump frequency 1000 and statistics dump frequency 1 w.r.t. the time step.
SBend [2]> ======================================================================
SBend [2]> ===== TLA_B ==========================================================
SBend [2]> ======================================================================
SBend [2]> TLA_B using file 1DPROFILE1-DEFAULT (1D Profile type 1)
Warning> Warning: bend design energy is zero. Treating as drift.
^C
Program received signal SIGINT, Interrupt.
0x00000000008f10ee in Bend2D::calculateRefTrajectory(double&, double&) () at /home/scratch/OPAL/OPAL-fork/OPAL-src/ippl/src/PETE/PETE.h:800
800 PETE_DefineBinary(operator*, (a * b), OpMultipply)
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.212.el6.x86_64 infinipath-psm-3.0.1-115.1015_open.2.el6.x86_64 libnl-1.1.4-2.el6.x86_64 nss-pam-ldapd-0.7.5-20.el6_6.3.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) bt
#0 0x00000000008f10ee in Bend2D::calculateRefTrajectory(double&, double&) () at /home/scratch/OPAL/OPAL-fork/OPAL-src/ippl/src/PETE/PETE.h:800
#1 0x00000000008f2a4b in Bend2D::initialise(PartBunchBase<double, 3u>*, double&, double&) ()
at /home/scratch/OPAL/OPAL-fork/OPAL-src/src/Classic/AbsBeamline/Bend2D.cpp:209
#2 0x000000000088ef8c in void OpalBeamline::visit<SBend>(SBend const&, BeamlineVisitor&, PartBunchBase<double, 3u>*) ()
at /home/scratch/OPAL/OPAL-fork/OPAL-src/src/Elements/OpalBeamline.h:107
#3 0x000000000087a7ee in ParallelTTracker::visitBeamline(Beamline const&) ()
```
### Cause
In `Bend2D::calculateRefTrajectory` and `RBend3D::trackRefParticleThrough` the stepSize is defined as follows:
```c++
const double stepSize = betaGamma / gamma * Physics::c * dt;
```
without `designenergy_m` = 0, `betaGamma` = `gamma` = 0.
Here a minimal step size could be set.OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.ch2020-07-24https://gitlab.psi.ch/OPAL/src/-/issues/543SAAMG: Enable RectangularDomain2020-07-21T13:53:57+02:00frey_mSAAMG: Enable RectangularDomainThe rectangular domain is currently not added to the SAAMG.The rectangular domain is currently not added to the SAAMG.OPAL 2.4.0frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/517Outdated example in Wiki2020-04-22T08:13:03+02:00albajacas_aarnau.albajacas@psi.chOutdated example in WikiThe Rf photo injector [example](https://gitlab.psi.ch/OPAL/src/wikis/RFPhotoInjector) in the Wiki is outdated and doesn't work with the current OPAL version.
This is confusing for new users. Is this kept like this for a reason, or can w...The Rf photo injector [example](https://gitlab.psi.ch/OPAL/src/wikis/RFPhotoInjector) in the Wiki is outdated and doesn't work with the current OPAL version.
This is confusing for new users. Is this kept like this for a reason, or can we update it?
I have attached a fixed version that works with OPAL 2.3
[RFphotoinjector.in](/uploads/a52c7ffdd03f63d6ec6a14535ee47e8a/RFphotoinjector.in)adelmannadelmann