src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2019-12-13T15:41:37+01:00https://gitlab.psi.ch/OPAL/src/-/issues/402VFFA2019-12-13T15:41:37+01:00ext-rogers_cVFFAImplement analytical Vertical FFA field map in OPAL with fields as per draft note:
[vertical-ffa-note.pdf](/uploads/1010e8589a932e447794df7ea11d0fb0/vertical-ffa-note.pdf)Implement analytical Vertical FFA field map in OPAL with fields as per draft note:
[vertical-ffa-note.pdf](/uploads/1010e8589a932e447794df7ea11d0fb0/vertical-ffa-note.pdf)OPAL-2.2.0ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/353Track back in time2019-09-07T18:55:00+02:00adelmannTrack back in time### Summary
We want to track a beam given beam back in time throughout the lattice. This can either be a followup track
or a given/generated distribution.
### Motivation
From measurements or intuition you construct a final phase spac...### Summary
We want to track a beam given beam back in time throughout the lattice. This can either be a followup track
or a given/generated distribution.
### Motivation
From measurements or intuition you construct a final phase space $`P_{final}`$. One can then ask the question how would you generate $`P_{initial}`$ and transport it. By tracking back (maybe using the optimiser) one can
hope to achieve such a goal.
### Approach (so far only for a straight machine ...)
1. The TRACK command is augment with Boolean **TRACKBACK=**
2. In **ParallelTTracker** the double member **arrowOfTime_m** is set to -1 in case of **TRACKBACK=TRUE**
3. In **ParallelTTracker::invertP** itsBunch->P[ ](2) *= arrowOfTime_m and
itsBunch_m->RefPartP_m *= arrowOfTime_m; is set [invertPz](http://amas.web.psi.ch/docs/opal/master-doxygen-new/d0/d39/a01138.html#ad0851e3c7c4947981014d3989560c7e5) (need to update Doxygen)
This is as far as I have implemented it, if I remember how to do the branch/merge stuff :) I will commit.
### To Do
0. All electrostatic elements do not need to be changed
1. Space charge needs to negate its action in all 3 dimensions.
3. RF
4. Make it more general i.e. 3. in Approach above
adelmannkrausadelmannhttps://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/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/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/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/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/228Restart optimizer from generation file2019-02-23T10:03:25+01:00frey_mRestart optimizer from generation file@snuverink_j and I discussed that it would be a nice feature of restarting the optimizer from a generation file. If the user put the generation number too low, this feature would help to continue computation instead of starting from scra...@snuverink_j and I discussed that it would be a nice feature of restarting the optimizer from a generation file. If the user put the generation number too low, this feature would help to continue computation instead of starting from scratch.frey_mfrey_mhttps://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/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/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/237Pixmap image as input for collimator2018-09-22T17:14:37+02:00krausPixmap image as input for collimatorLet the users specify a black and white image that describes the hole of the collimator. An example of a black and white image is attached.
As input file format Portable Bitmap is suggested since a parser is relatively simple to implem...Let the users specify a black and white image that describes the hole of the collimator. An example of a black and white image is attached.
As input file format Portable Bitmap is suggested since a parser is relatively simple to implement and we'll avoid to rely on yet another library.
The simplest way to implement this is to extend the FlexibleCollimator and use one rectangle for each black pixel. However this isn't ideal because the number of rectangles can be big. Since we use a quadtree the performance may not be so bad. We'll have to test it.
Substantially more effort is needed if we try to minimize the number of rectangles by clustering pixels.
Submitted by @ext-roussel_r
![test_mask](/uploads/d4371d755495d590a39af25c65b93a0f/test_mask.png)krauskraushttps://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 shapeskrauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/236Arbitrary reference point for hypervolume calculation2018-08-02T17:06:51+02:00snuverink_jjochem.snuverink@psi.chArbitrary reference point for hypervolume calculationAs discussed in #235: "the ability to set an arbitrary point would also be nice, but has no priority"As discussed in #235: "the ability to set an arbitrary point would also be nice, but has no priority"snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/232Add argument DISTRIBUTIONDIR to Optimizer and Sample Command2018-07-30T08:36:17+02:00snuverink_jjochem.snuverink@psi.chAdd argument DISTRIBUTIONDIR to Optimizer and Sample CommandFrom @ext-bershanska_a: "It would be nice to add OPTIMIZER attribute for distribution directory (like for runOPAL.py)"From @ext-bershanska_a: "It would be nice to add OPTIMIZER attribute for distribution directory (like for runOPAL.py)"frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/231Add z coordinate to stat file2018-07-11T16:57:17+02:00snuverink_jjochem.snuverink@psi.chAdd z coordinate to stat fileProposal from @winklehner_d and @ext-bershanska_a:
Add the z coordinate of the reference particle to the stat file (seems like only s is given, which probably stems from the mismatch between OPAL-T and OPAL-cycl coordinate systems).Proposal from @winklehner_d and @ext-bershanska_a:
Add the z coordinate of the reference particle to the stat file (seems like only s is given, which probably stems from the mismatch between OPAL-T and OPAL-cycl coordinate systems).snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/225SCAN option adapted from OPTIMIZE command2018-06-22T11:11:14+02:00snuverink_jjochem.snuverink@psi.chSCAN option adapted from OPTIMIZE commandFrom a discussion in runOPAL#7 with @rizzoglio_v suggested by @adelmann. The optimiser mechanism of running with a master core that spawns several opal jobs can be adapted to run a scan through a parameter list. Compared to the scan opti...From a discussion in runOPAL#7 with @rizzoglio_v suggested by @adelmann. The optimiser mechanism of running with a master core that spawns several opal jobs can be adapted to run a scan through a parameter list. Compared to the scan option of runOPAL, an advantage is a single job in a batch system, and possibly better grouping of results.
E.g.
```
dv0: DVAR, VARIABLE="P0", LOWERBOUND=-10.0, UPPERBOUND=0.0, STEP = 0.5;
dv1: DVAR, VARIABLE="P1", LOWERBOUND=-10.0, UPPERBOUND=0.0, STEP = 1.0;
SCAN, INPUT="tmpl/model.tmpl",
OUTPUT="model",
OUTDIR="results",
DVARS = {dv0, dv1},
NUM_MASTERS=1,
NUM_COWORKERS=8,
SIMTMPDIR="tmp",
TEMPLATEDIR="tmpl",
FIELDMAPDIR="fieldmaps";
```
cc: @frey_mfrey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/56Multi-Slit & PEPPERPOT2018-04-14T13:30:27+02:00adelmannMulti-Slit & PEPPERPOTPEPPERPOT with rectangular slits instead of circles.PEPPERPOT with rectangular slits instead of circles.OPAL 1.9.xadelmannkrausext-edelen_aadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/201Stat file dumping in ParallelCyclotronTracker2018-04-09T12:19:50+02:00frey_mStat file dumping in ParallelCyclotronTrackerThis issue is related to the discussion in #196. I'd like to fix the dumping and reference particle in the cyclotron tracker such that it works and gives reasonable results for single as well as multi bunch simulations. My idea is to wri...This issue is related to the discussion in #196. I'd like to fix the dumping and reference particle in the cyclotron tracker such that it works and gives reasonable results for single as well as multi bunch simulations. My idea is to write a stat-file per bunch. What do you think?OPAL 1.9.xfrey_mfrey_m