src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2021-06-10T18:04:20+02:00https://gitlab.psi.ch/OPAL/src/-/issues/159STATDUMPFREQ in RING-DEFINITION2021-06-10T18:04:20+02:00Valeria RizzoglioSTATDUMPFREQ in RING-DEFINITIONIt seems that the option STATDUMPFREQ does not work as expected in OPAL-C - Ring Definition. The statistics dumped in the .stat file depends on the PSDUMPFREQ normally used for the h5.
*Example*
For a certain beamline, the expected RM...It seems that the option STATDUMPFREQ does not work as expected in OPAL-C - Ring Definition. The statistics dumped in the .stat file depends on the PSDUMPFREQ normally used for the h5.
*Example*
For a certain beamline, the expected RMSX is: ![ExpectedRMS](/uploads/f136b3679a6b4acde8dc792c29c48fa5/ExpectedRMS.png).
The plot is obtained from the .stat file (column 2 and 6) and with the following options set in the OPAL input file
```
OPTION, PSDUMPFREQ=10;
OPTION, ENABLEHDF5=FALSE;
OPTION, TELL=TRUE;
OPTION, PSDUMPFRAME=BUNCH_MEAN;
```
The STATDUMPFREQ is not specified, so the default value `STATDUMPFREQ = 10 ` should be used.
With the following options:
- reducing the PSDUMPFREQ
```
OPTION, PSDUMPFREQ=100000000;
OPTION, STATDUMPFREQ = 10;
OPTION, TELL=TRUE;
OPTION, PSDUMPFRAME=BUNCH_MEAN;
```
- disabling the .h5 files but with high PSDUMPFREQ
```
OPTION, PSDUMPFREQ=10;
OPTION, ENABLEHDF5=FALSE;
OPTION, TELL=TRUE;
OPTION, PSDUMPFRAME=BUNCH_MEAN;
```
the RMSX from the generated stat file is: ![STATDUMP](/uploads/72d86bbc755b14b5ad7fc3b86ae7adb0/STATDUMP.png)
The result does not change if the STATDUMPFREQ is specified in the input file or not.
Any suggestions?ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/274SBend3d field map not parsed2023-11-30T15:49:12+01:00ext-rogers_cSBend3d field map not parsedWhen attempting to load an SBend3D field map, the input is not parsed correctly. OPAL dies with error
> User error detected by function SectorMagneticFieldMap::IO::getInterpolator
> Ran out of field points during read operation; che...When attempting to load an SBend3D field map, the input is not parsed correctly. OPAL dies with error
> User error detected by function SectorMagneticFieldMap::IO::getInterpolator
> Ran out of field points during read operation; check bounds and ordering
> Ran out of field points during read operation; check bounds and ordering
and then the usual MPI_ABORT stuff
Files:
[Bfield.dat.gz](/uploads/ac220399c42a92b40ee8542ca208a753/Bfield.dat.gz)
[Bfield-nobump.dat.gz](/uploads/1227ca0fa9b8a501630e01298989099b/Bfield-nobump.dat.gz)
[tosca.in](/uploads/bd535625cba6ef794dfd2680e0ed7711/tosca.in)ext-rogers_csnuverink_jjochem.snuverink@psi.chext-rogers_c2020-09-23https://gitlab.psi.ch/OPAL/src/-/issues/279Trimcoil: PHIMIN and PHIMAX as arrays2021-06-10T17:57:30+02:00frey_mTrimcoil: PHIMIN and PHIMAX as arraysIn order to have one instance of a trim coil instead of multiple instances it is better having the arguments PHIMIN and PHIMAX as arrays. Otherwise one needs to specify the same trim coil n-times for n-sectors.In order to have one instance of a trim coil instead of multiple instances it is better having the arguments PHIMIN and PHIMAX as arrays. Otherwise one needs to specify the same trim coil n-times for n-sectors.snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/286Cyclotron elements geometry option: annulus sector2023-01-27T11:45:55+01:00snuverink_jjochem.snuverink@psi.chCyclotron elements geometry option: annulus sectorSuggested by @matlocha_t: provide an annulus sector as a geometry option for the cyclotron elements (CColimator, Septum, Stripper):
![image](/uploads/9cff1d89a79d8cee66dcd30aa9d21e95/image.png)
The shape can be described as in ANSYS (h...Suggested by @matlocha_t: provide an annulus sector as a geometry option for the cyclotron elements (CColimator, Septum, Stripper):
![image](/uploads/9cff1d89a79d8cee66dcd30aa9d21e95/image.png)
The shape can be described as in ANSYS (https://www.sharcnet.ca/Software/Ansys/16.2.3/en-us/help/ans_cmd/Hlp_C_CYL4.html) with a centre position (x,y), two radii (r1, r2) and two angles.snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/359CCollimator not properly implemented for horizontal cut2021-06-10T17:53:04+02:00frey_mCCollimator not properly implemented for horizontal cutAs far as I understand, the CCollimator checks the [vertical direction](https://gitlab.psi.ch/OPAL/src/blob/master/src/Classic/AbsBeamline/CCollimator.cpp#L60) in order to find out if the bunch is close to the collimator. However, this o...As far as I understand, the CCollimator checks the [vertical direction](https://gitlab.psi.ch/OPAL/src/blob/master/src/Classic/AbsBeamline/CCollimator.cpp#L60) in order to find out if the bunch is close to the collimator. However, this only works for vertical collimators (consisting of 2 CCollimator elements, i.e. upper and lower plate). In case of horizontal collimators this does not apply.frey_msnuverink_jjochem.snuverink@psi.chfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/605BANDRF fieldmaps have no effect beginning with OPAL 2.22022-02-04T10:22:01+01:00winklehner_dBANDRF fieldmaps have no effect beginning with OPAL 2.2h5hut field maps (.h5part), loaded as part of the BANDRF cyclotron type that produce the desired effect in OPAL 2.0, don't seem to have any effect in OPAL 2.2 and up. Cyclotron units used to be mm and kV/mm (same as MV/m). Have these inp...h5hut field maps (.h5part), loaded as part of the BANDRF cyclotron type that produce the desired effect in OPAL 2.0, don't seem to have any effect in OPAL 2.2 and up. Cyclotron units used to be mm and kV/mm (same as MV/m). Have these input units been changed somehow?
My current example is that of an electrostatic extraction septum that correctly pushes the final turn out by ~2 cm in OPAL 2.0, but does nothing in OPAL 2.2 and up.https://gitlab.psi.ch/OPAL/src/-/issues/749More geometries for cyclotron elements2023-01-27T17:57:31+01:00snuverink_jjochem.snuverink@psi.chMore geometries for cyclotron elementsFrom @zhang_h: It would be better if the collimators in forms other than a rectangular could also be defined in OPAL_cycl. The collimators in Ring or Injector2 or COMET could be in forms of a trapezoid, a triangle, a circle, and an ellipse.From @zhang_h: It would be better if the collimators in forms other than a rectangular could also be defined in OPAL_cycl. The collimators in Ring or Injector2 or COMET could be in forms of a trapezoid, a triangle, a circle, and an ellipse.