src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2019-07-25T16:45:26+02:00https://gitlab.psi.ch/OPAL/src/-/issues/343Distinguish bunches in probe2019-07-25T16:45:26+02:00frey_mDistinguish bunches in probe### Summary
It is currently not possible to distinguish single bunches in a probe in case of multi-bunch simulations. Although the ID and turn number are given it is somehow not possible to get a single bunch. Saving the bunch number (an...### Summary
It is currently not possible to distinguish single bunches in a probe in case of multi-bunch simulations. Although the ID and turn number are given it is somehow not possible to get a single bunch. Saving the bunch number (an attribute of `PartBunchBase`) will help to overcome this issue.frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/327General field map reader2022-01-26T19:47:13+01:00ext-neveu_nGeneral field map reader### Summary
Requesting capability to provide a field map with real and imaginary parts.
i.e. see field map here for LCLS TW structure (~3m long):
https://www.slac.stanford.edu/~lizh/link/lcls/sband-1d-field-map/lcls1-sband-1d-field-m...### Summary
Requesting capability to provide a field map with real and imaginary parts.
i.e. see field map here for LCLS TW structure (~3m long):
https://www.slac.stanford.edu/~lizh/link/lcls/sband-1d-field-map/lcls1-sband-1d-field-map-complex-field.datkrauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/318Optimizer: Generalizing objectives with sddsVariableAt2019-06-26T16:56:20+02:00frey_mOptimizer: Generalizing objectives with sddsVariableAt### Summary
Currently, the optimizer allows to evaluate an objective in the stat-file with ```sddsVariableAt``` according to ```spos```
only. I'd like to use other quantities as well.### Summary
Currently, the optimizer allows to evaluate an objective in the stat-file with ```sddsVariableAt``` according to ```spos```
only. I'd like to use other quantities as well.frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/297Suggestion for improvements to the Optimiser2021-06-10T17:56:24+02:00snuverink_jjochem.snuverink@psi.chSuggestion for improvements to the OptimiserSome suggestions and observations to improve usability of the optimiser by Michael Abo-Bakr (as far as not already covered in other issues):
* [ ] For 1 or 2 optimisation parameters there is no hypervolume calculation.
* [ ] It would be...Some suggestions and observations to improve usability of the optimiser by Michael Abo-Bakr (as far as not already covered in other issues):
* [ ] For 1 or 2 optimisation parameters there is no hypervolume calculation.
* [ ] It would be very nice to get at the end a final best solution in the output (defined with some cost function)
* [ ] .json format is not always ideal for reading or writing new generation files (as starting condition)
* [ ] Not all individuals appear to be really new.
* [ ] Option to adaptively change optimisation parameters (mutation, crossover etc.)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/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/278add option to load initial population for GA2019-03-15T11:13:52+01:00ext-edelen_aadd option to load initial population for GAWe'd like to be able to specify an initial population to use in the OPAL GA.We'd like to be able to specify an initial population to use in the OPAL GA.frey_msnuverink_jjochem.snuverink@psi.chadelmannkrausfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/276Specify trim coil range azimuthally2023-02-13T15:50:53+01:00snuverink_jjochem.snuverink@psi.chSpecify trim coil range azimuthallyFeature request from @matlocha_t: add an option to `TRIMCOIL` to specify besides the radial range also the azimuthal range.Feature request from @matlocha_t: add an option to `TRIMCOIL` to specify besides the radial range also the azimuthal range.snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/275OPAL-t : Transverse Distribution from Laser Profile (Under Development)2019-12-17T09:33:15+01:00adelmannOPAL-t : Transverse Distribution from Laser Profile (Under Development)What is the status of the Transverse Distribution from Laser Profile ?
How is the h5 file containing the virtual cathode image defined?
Background: there is an interest at LCLS and LCLS-IIWhat is the status of the Transverse Distribution from Laser Profile ?
How is the h5 file containing the virtual cathode image defined?
Background: there is an interest at LCLS and LCLS-IIkrauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/269Halo evaluation as objective2018-12-11T09:14:40+01:00frey_mHalo evaluation as objectiveIt would be nice having a halo evaluation as an objective for the sampler and optimizer. I also think about multi-bunch simulations. We need either the halo written to the stat-file or evaluate it using the H5 file. In case of multi-bunc...It would be nice having a halo evaluation as an objective for the sampler and optimizer. I also think about multi-bunch simulations. We need either the halo written to the stat-file or evaluate it using the H5 file. In case of multi-bunch simulations where particles are assigned to energy bins, we'd need a stat file for every energy bin. Therefore, I think, it's easier to add new objective funtion.
I suggest something like this
```c++
halo(dir, step, bin)
```
where ```dir=x,y,z``` and ```bin``` the energy bin (default: 0).frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/268Store halo in STAT-file2018-12-11T09:00:09+01:00frey_mStore halo in STAT-fileIt would be nice storing the halo per step in the stat file.It would be nice storing the halo per step in the stat file.frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/265Sampler: Delete files that are not used2018-12-02T17:06:44+01:00frey_mSampler: Delete files that are not usedWhen running the SAMPLER, it might run thounds of OPAL simulations. In each directory we will then have files like *.lbal, *.out, etc., that might not be needed. Since on clusters you sometimes / normally have quotas on number of files, ...When running the SAMPLER, it might run thounds of OPAL simulations. In each directory we will then have files like *.lbal, *.out, etc., that might not be needed. Since on clusters you sometimes / normally have quotas on number of files, I think it would make sense that we add an option to the SAMPLER command where we can specify which files to delete directly after one simulation.frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/260Implement improved and low energy CSR methods2021-06-18T11:28:29+02:00krausImplement improved and low energy CSR methodsThe formulas to compute the CSR kick that is current used workes only for high energy beams. Better formulas such as [D. Sagan's](http://accelconf.web.cern.ch/AccelConf/e06/PAPERS/THPCH024.PDF) exist and are well tested.The formulas to compute the CSR kick that is current used workes only for high energy beams. Better formulas such as [D. Sagan's](http://accelconf.web.cern.ch/AccelConf/e06/PAPERS/THPCH024.PDF) exist and are well tested.ext-neveu_next-neveu_nhttps://gitlab.psi.ch/OPAL/src/-/issues/257GA interface is appending new generation output to new json file, rather than...2019-07-04T17:15:48+02:00ext-edelen_aGA interface is appending new generation output to new json file, rather than having one generation output per json fileaccording to the input file:
```
INITIALPOPULATION=100,
MAXGENERATIONS=2,
NUM_MASTERS=1,
NUM_COWORKERS=8,
SIMTMPDIR="tmp",
TEMPLATEDIR="tmpl",
FIELDMAPDIR="fieldm...according to the input file:
```
INITIALPOPULATION=100,
MAXGENERATIONS=2,
NUM_MASTERS=1,
NUM_COWORKERS=8,
SIMTMPDIR="tmp",
TEMPLATEDIR="tmpl",
FIELDMAPDIR="fieldmaps",
NUM_IND_GEN=100,
GENE_MUTATION_PROBABILITY=0.8,
MUTATION_PROBABILITY=0.8,
RECOMBINATION_PROBABILITY=0.2;
```
It seems like this should be 200 samples (100 in population x 2 generations)
However, using mldb to convert to pk reports 300 samples:
```
OPAL ML Database Generator
Found 2 json files.
Write ML-Database 1nCGA-small-test.pk
xDim = 6 -> ['G0', 'G1', 'K0', 'K1', 'PH0', 'PH1']
yDim = 7 -> ['DE', 'EMITS', 'EMITX', 'EMITY', 'RMSS', 'RMSX', 'RMSY']
generations = 2
Data points = 300
```
Looking at the json files:
- 1_1nCGA_0.json has 100 individuals
- 2_1nCGA_0.json has 200 individuals
And if we compare the first individual in each case, they are both the same:
```
"G0": 63.7949,
"G1": 17.5757,
"K0": 474.876,
"K1": 185.284,
"PH0": -8.94274,
"PH1": -2.44182
```
So it looks like new data is just being appended to the new json file in subsequent generations rather than creating a new file for each generation with only that generation's data in it.snuverink_jjochem.snuverink@psi.chkraussnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/251Allow optimizer and sampler runs to restart from given h5 file2019-02-25T08:43:02+01:00krausAllow optimizer and sampler runs to restart from given h5 fileRestart currently doesn't work for runs when launched from the optimizer / sampler. This feature should be relatively easy to implement. Reported by M. Abo-Bakr.Restart currently doesn't work for runs when launched from the optimizer / sampler. This feature should be relatively easy to implement. Reported by M. Abo-Bakr.krausfrey_mkraushttps://gitlab.psi.ch/OPAL/src/-/issues/250Store stat files of Sampler (and Optimizer?) in a single file2021-06-10T17:58:47+02:00krausStore stat files of Sampler (and Optimizer?) in a single fileThe stat files should be stored into a single file such that all data from all runs can be evaluated in post processing. The data should be supplemented with the values of the design variables. File formats that come into considerations ...The stat files should be stored into a single file such that all data from all runs can be evaluated in post processing. The data should be supplemented with the values of the design variables. File formats that come into considerations are HDF5, SDDS, a NoSQL database, zip/tar gunzip etc.krausadelmanngsellkraushttps://gitlab.psi.ch/OPAL/src/-/issues/249Objectives for Sampler2018-12-06T11:13:03+01:00krausObjectives for SamplerThe user should be able to define quantities of interest (a la optimizer) which are written to the json file. This avoids lengthy post processing of the stat files of all runs.The user should be able to define quantities of interest (a la optimizer) which are written to the json file. This avoids lengthy post processing of the stat files of all runs.krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/245Re-enable Slice tracker2020-04-23T11:01:30+02:00krausRe-enable Slice trackerThe ParallelSliceTracker was disabled since it relied heavily on ParallelTTracker which has been reimplemented with 3D placement of the elements.The ParallelSliceTracker was disabled since it relied heavily on ParallelTTracker which has been reimplemented with 3D placement of the elements.krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/239Remove requirement of data file for SAMPLER and OPTIMIZER2020-06-22T09:42:35+02:00adelmannRemove requirement of data file for SAMPLER and OPTIMIZERWe still use the runOPAL.py scheme with template / data file. However the design variables could be easily looked up in the dictionary or we invent new types: DvarReal etc.
[Edit: this has been moved to a separate issue, see #249! If we...We still use the runOPAL.py scheme with template / data file. However the design variables could be easily looked up in the dictionary or we invent new types: DvarReal etc.
[Edit: this has been moved to a separate issue, see #249! If we could define quantities of interest (a la optimizer) and write them to the json file lengthly post processing would be avoided.]
Edit:
- [x] remove the need for a data file (!288)
- [x] write a json file containing the values of the DVARs and objectives (#249)OPAL 2.4.0frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/238Extend language for FlexibleCollimator2018-08-13T15:59:16+02:00krausExtend language for FlexibleCollimatorAdd additional commands such as
- [x] polygon
- [x] difference
- [x] intersection
- [x] trigonmetric functions
- [x] simple calculations (multiplication, summation, subtraction)
- [ ] 3D operations and shapesAdd additional commands such as
- [x] polygon
- [x] difference
- [x] intersection
- [x] trigonmetric functions
- [x] simple calculations (multiplication, summation, subtraction)
- [ ] 3D operations and shapeskrauskraus