src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2021-07-06T10:08:36+02:00https://gitlab.psi.ch/OPAL/src/-/issues/119Periodic BC's2021-07-06T10:08:36+02:00winklehner_dPeriodic BC'sIt seems that when I set BCFFTT = PERIODIC, not only the z-direction but all directions are automatically set to periodic boundary conditions. @uldis_l I am assuming "UL" in the comment of PartBunch::setBCForDCBeam() is you. Was there a ...It seems that when I set BCFFTT = PERIODIC, not only the z-direction but all directions are automatically set to periodic boundary conditions. @uldis_l I am assuming "UL" in the comment of PartBunch::setBCForDCBeam() is you. Was there a particular reason to do this? In my understanding, a DC beam would have open BC in x and y and periodic BC in z.
In addition, the manual calls the parameters "BCFFTZ" and "PARFFTZ" but OPAL tells me those don't exist and throws an Exception, I have to use "BCFFTT" and "PARFFTT". Just a minor bug.adelmannkrausadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/131Segmentation fault - dks - SurfacePhysics Collimators2021-06-10T19:15:02+02:00Valeria RizzoglioSegmentation fault - dks - SurfacePhysics CollimatorsI got segmentation fault running this input file [PROSCAN-G3-230.in](/uploads/7820209c33311fcdd68601832deacf30/PROSCAN-G3-230.in). It includes SurfacePhysics on 3 consecutive collimators.
The error message:
```
ParallelTTracker {0}> ...I got segmentation fault running this input file [PROSCAN-G3-230.in](/uploads/7820209c33311fcdd68601832deacf30/PROSCAN-G3-230.in). It includes SurfacePhysics on 3 consecutive collimators.
The error message:
```
ParallelTTracker {0}> Coll/Deg statistics: bunch to material 2 redifused 0 stopped 1
[opalrunner:20589] *** Process received signal ***
[opalrunner:20589] Signal: Segmentation fault (11)
[opalrunner:20589] Signal code: Address not mapped (1)
[opalrunner:20589] Failing at address: 0x1b70f000
[opalrunner:20589] [ 0] /lib64/libc.so.6[0x32e9632660]
[opalrunner:20589] [ 1] opal(_ZN14ParticleAttribI6VektorIdLj3EEE7destroyERKSt6vectorISt4pairImmESaIS5_EEb+0x1f0)[0xe531d0]
[opalrunner:20589] [ 2] opal(_ZN16IpplParticleBaseI21ParticleSpatialLayoutIdLj3E16UniformCartesianILj3EdE24BoxParticleCachingPolicyIdLj3ES2_EEE14performDestroyEv+0xc2)[0xdac9e2]
[opalrunner:20589] [ 3] opal(_ZN21ParticleSpatialLayoutIdLj3E16UniformCartesianILj3EdE24BoxParticleCachingPolicyIdLj3ES1_EE6updateER16IpplParticleBaseIS4_EPK14ParticleAttribIcE+0x45)[0xdae095]
[opalrunner:20589] [ 4] opal(_ZN16IpplParticleBaseI21ParticleSpatialLayoutIdLj3E16UniformCartesianILj3EdE24BoxParticleCachingPolicyIdLj3ES2_EEE6updateEv+0x1a)[0xdae60a]
[opalrunner:20589] [ 5] opal(_ZN9PartBunch6boundpEv+0x406)[0xe225e6]
[opalrunner:20589] [ 6] opal(_ZN16ParallelTTracker21computeExternalFieldsEv+0xf19)[0x107ec79]
[opalrunner:20589] [ 7] opal(_ZN16ParallelTTracker21executeDefaultTrackerEv+0x637)[0x1084b77]
[opalrunner:20589] [ 8] opal(_ZN16ParallelTTracker7executeEv+0x1f)[0x108566f]
[opalrunner:20589] [ 9] opal(_ZN8TrackRun7executeEv+0x751)[0x104c4b1]
[opalrunner:20589] [10] opal(_ZNK10OpalParser7executeEP6ObjectRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x35)[0xcb57e5]
[opalrunner:20589] [11] opal(_ZNK10OpalParser11parseActionER9Statement+0x143)[0xcb9803]
[opalrunner:20589] [12] opal(_ZNK10OpalParser5parseER9Statement+0x186)[0xcb9196]
[opalrunner:20589] [13] opal(_ZNK10OpalParser3runEv+0x2c)[0xcba7ec]
[opalrunner:20589] [14] opal(_ZN8TrackCmd7executeEv+0x343)[0xd6ccc3]
[opalrunner:20589] [15] opal(_ZNK10OpalParser7executeEP6ObjectRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x35)[0xcb57e5]
[opalrunner:20589] [16] opal(_ZNK10OpalParser11parseActionER9Statement+0x143)[0xcb9803]
[opalrunner:20589] [17] opal(_ZNK10OpalParser5parseER9Statement+0x186)[0xcb9196]
[opalrunner:20589] [18] opal(_ZNK10OpalParser3runEv+0x2c)[0xcba7ec]
[opalrunner:20589] [19] opal(_ZNK10OpalParser3runEP11TokenStream+0x6a)[0xcb9cea]
[opalrunner:20589] [20] opal(main+0x8e8)[0xc48658]
[opalrunner:20589] [21] /lib64/libc.so.6(__libc_start_main+0xfd)[0x32e961ed1d]
[opalrunner:20589] [22] opal[0xc3fab5]
[opalrunner:20589] *** End of error message ***
--------------------------------------------------------------------------
mpirun noticed that process rank 1 with PID 20589 on node opalrunner exited on signal 11 (Segmentation fault).
--------------------------------------------------------------------------
```
I tried with two different time steps (1 ps and 5 ps) and I got the same error. The same file runs up to end without the option `--use-dks`.
Run configuration: opalrunner with 8 cores
Modules load:
```
Currently Loaded Modulefiles:
1) gcc/5.4.0 3) OPAL/1.6.0rc3 5) root/6.08.02 7) Tcl/8.6.4 9) Python/2.7.12 11) gsl/2.2.1
2) openmpi/1.10.4 4) OPAL/1.6 6) openssl/1.0.2j 8) Tk/8.6.4 10) boost/1.62.0 12) H5root/1.3.2rc4-1
```adelmannkrausadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/137Segmentation fault - Degrader 70 MeV2021-06-10T19:14:40+02:00Valeria RizzoglioSegmentation fault - Degrader 70 MeVI am trying to test the influence of the time step on the results of the OPAL Monte Carlo using the Multi-Slabs degrader for 70 MeV ([Degrader_70.in](/uploads/bc2a35adc56108066470d475851794f4/Degrader_70.in))
I set the time step to 1e-1...I am trying to test the influence of the time step on the results of the OPAL Monte Carlo using the Multi-Slabs degrader for 70 MeV ([Degrader_70.in](/uploads/bc2a35adc56108066470d475851794f4/Degrader_70.in))
I set the time step to 1e-10 s and I got a segmentation fault. So I did few tests, trying different configurations of time steps, n. of cores and options (ENABLERUTHERFORD = TRUE/FALSE or with/without GPU)
-- **Configuration 1**
- protons = 1e5, DT = 1e-10 s, cores = 4, with dks and ENABLERUTHERFORD = TRUE
- result: segmentation fault [Config1.out](/uploads/e22237cd275e223eafc1f393b7f00c3f/Config1.out)
-- **Configuration 2**
- protons = 1e5, DT = 1e-10 s, cores = 4, with dks and ENABLERUTHERFORD = FALSE
- result: OK [Config2.out](/uploads/e1744843830b2f7480ec1d210f9100e2/Config2.out)
-- **Configuration 3**
- protons = 1e5, DT = 1e-10 s, cores = 4, without dks and ENABLERUTHERFORD = TRUE
- result: segmentation fault [Config3.out](/uploads/1729b7c9fa264b2d19ef0b2ab8a30d2a/Config3.out)
-- **Configuration 4**
- protons = 1e7, DT = 1e-10 s, cores = 4, without dks and ENABLERUTHERFORD = TRUE
- result: OPAL stops at 4.4 mm with 4 protons while the ZSTOP is 4.3 m [Config4.out](/uploads/cd16cc8612b11ca5a93c4d2838406fab/Config4.out)
-- **Configuration 4.b**
- protons = 1e5, DT = 1e-10 s, cores = 8, without dks and ENABLERUTHERFORD = TRUE
- result: segmentation fault [Config4b.out](/uploads/2fe58a350447fc863a07bdf0f398bb93/Config4b.out)
-- **Configuration 5** (on Merlin)
- protons = 1e7, DT = 1e-10 s, cores = 32, without dks and ENABLERUTHERFORD = FALSE
- result: OK
-- **Configuration 6**
- protons = 1e5, DT = 1e-11 s, cores = 4, with dks and ENABLERUTHERFORD = FALSE
- result: OK [Config6.out](/uploads/85b27a193d0e9de8d463b99502220dfa/Config6.out)
-- **Configuration 7**
- protons = 1e5, DT = 1e-11 s, cores = 4, with dks and ENABLERUTHERFORD = TRUE
- result: OK [Config7.out](/uploads/89264c89f20abc3bfc933de6acaf2e52/Config7.out)
Run on opalrunner and Merlin with these settings:
```
Currently Loaded Modulefiles:
1) gcc/5.4.0 4) OPAL/1.6 7) Tcl/8.6.4 10) boost/1.62.0
2) openmpi/1.10.4 5) root/6.08.02 8) Tk/8.6.4 11) gsl/2.2.1
3) OPAL/1.6.0rc3 6) openssl/1.0.2j 9) Python/2.7.12 12) H5root/1.3.2rc4-1
```gselladelmanngsellhttps://gitlab.psi.ch/OPAL/src/-/issues/146Rewrite the ArbitraryDomain class.2021-06-09T18:40:56+02:00krausRewrite the ArbitraryDomain class.Currently the ArbitraryDomain class only works when it is partitioned in z-direction. Rewrite it such that the global linear indexing works also with PARFFTX=TRUE and/or PARFFTY=TRUE.Currently the ArbitraryDomain class only works when it is partitioned in z-direction. Rewrite it such that the global linear indexing works also with PARFFTX=TRUE and/or PARFFTY=TRUE.winklehner_dfrey_mwinklehner_dhttps://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/557Optimizer gets stuck2021-06-10T19:16:54+02:00snuverink_jjochem.snuverink@psi.chOptimizer gets stuckAs reported by Finn O'Shea: the optimizer get stuck from time to time with the following example:
[fdopt.in](/uploads/e8ef7cb47cc60dcfbb8daab723b461df/fdopt.in)
[fdopt.data](/uploads/2f965a6b27a71ba36ab64519a5d8c74d/fdopt.data)
[fdopt.t...As reported by Finn O'Shea: the optimizer get stuck from time to time with the following example:
[fdopt.in](/uploads/e8ef7cb47cc60dcfbb8daab723b461df/fdopt.in)
[fdopt.data](/uploads/2f965a6b27a71ba36ab64519a5d8c74d/fdopt.data)
[fdopt.tmpl](/uploads/6e7dc37c7fe54832e01c0d7a41755e2f/fdopt.tmpl)snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/583Particles miss step in element with particle / matter interaction2023-11-30T15:49:00+01:00krausParticles miss step in element with particle / matter interactionIf two elements with particle / matter interaction are closer to each other than a single time step then the particles drift for one time step after leaving the first element and before entering the second element. In #308 the variable `...If two elements with particle / matter interaction are closer to each other than a single time step then the particles drift for one time step after leaving the first element and before entering the second element. In #308 the variable `tau` was introduced in the class `CollimatorPhysics` in order to get rid of a time structure. The quantity `tau` is computed for the first and the last time step. The meaning of `tau` is the fraction of a time step the current position of a particle is away from the edge. `tau` has to between `0.0` and `1.0`. However this isn't true if a particle hops from one element with particle / matter interaction to another. Currently this isn't handled correctly yet. Instead the particles drifts for at least one time step before it can enter another element with particle / matter interaction.krausext-calvo_ppedro.calvo@ciemat.eskraushttps://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/625Fix exceptions in parallel2021-06-09T21:19:42+02:00ext-calvo_ppedro.calvo@ciemat.esFix exceptions in parallelThe following discussion from !458 should be addressed:
- [ ] @snuverink_j started a [discussion](https://gitlab.psi.ch/OPAL/src/-/merge_requests/458#note_28753): (+5 comments)
> If I understand correctly the file is only read by ...The following discussion from !458 should be addressed:
- [ ] @snuverink_j started a [discussion](https://gitlab.psi.ch/OPAL/src/-/merge_requests/458#note_28753): (+5 comments)
> If I understand correctly the file is only read by node 0, so this check can be done by node 0 only (as it was before).
>
> But to be honest, I don't understand why it was not working before in the parallel environment. Can you elaborate a bit?
@ext-calvo_p
> I thought in the same way, but when OPAL is run in the parallel environment and the distribution file doesn't exist, OpalException is not thrown.
>
> I think that checking if the file exists before opening it does not have to be done exclusively by node 0.
@snuverink_j
> I can reproduce it: the simulation hangs.
>
>But this seems something more fundamental to me, because I would also have expected that a throw by a single node would be enough to stop the simulation. @gsell: Should that not be the case?
@kraus
> In Main.cpp we catch the exception and then call MPI_Abort on MPI_COMM_WORLD. I thought that this should also stop the other nodes but this isn't the case. So we try to throw the exception on all nodes.https://gitlab.psi.ch/OPAL/src/-/issues/717Writing initial distribution fails in multicore case2022-05-19T14:35:52+02:00ext-calvo_ppedro.calvo@ciemat.esWriting initial distribution fails in multicore caseWriting the initial distribution to file (making use of `WRITETOFILE` attribute) fails for injected distributions when the simulation is run in a parallel environment. The output file only saves the particles of the first nodeWriting the initial distribution to file (making use of `WRITETOFILE` attribute) fails for injected distributions when the simulation is run in a parallel environment. The output file only saves the particles of the first nodehttps://gitlab.psi.ch/OPAL/src/-/issues/792OPAL Monitor Memory Usage2023-11-29T17:22:02+01:00adelmannOPAL Monitor Memory Usage### Summary
(Summarize the bug encountered concisely)
One thing I ran into recently is an out-of-memory issue when I run it with many "monitor" elements. What seems to be happening is that the memory allocated while saving the particles...### Summary
(Summarize the bug encountered concisely)
One thing I ran into recently is an out-of-memory issue when I run it with many "monitor" elements. What seems to be happening is that the memory allocated while saving the particles to disk doesn't get freed after the file is output. In my case, I was using 2 million particles and I could see the memory usage rise by 200MB as the first monitor output is saved to disk and then rise by another 200MB at the second and so on. Since I was producing video-like output with 48 monitors, it didn't take long to exceed our cluster's 4GB per core limit.
### Steps to reproduce
Run simulation with 2E6 particles and 48 monitors
### What is the current *bug* behavior?
out of memory
### What is the expected *correct* behavior?
no out of memory
### Relevant logs and/or screenshots
I did some digging in the source code and on line 367 in `src/Classic/Structure/LossDataSink.cpp` I saw that the vectors storing particle information in the monitor objects do get cleared. Reading online, though (since I'm not a C++ expert) I saw some people saying this might not free memory (https://stackoverflow.com/questions/13944886/is-stdvector-memory-freed-upon-a-clear). I implemented their suggestion, ie the following code to replace all of the clear methods.
### Possible fixes
std::vector<OpalParticle>().swap(particles_m);
std::vector<size_t>().swap(turnNumber_m);
std::vector<size_t>().swap(bunchNumber_m);
std::vector<double>().swap(spos_m);
std::vector<double>().swap(refTime_m);
std::vector<Vector_t>().swap(RefPartR_m);
std::vector<Vector_t>().swap(RefPartP_m);
std::vector<h5_int64_t>().swap(globalTrackStep_m);2023.1adelmannadelmann