OPAL issueshttps://gitlab.psi.ch/groups/OPAL/-/issues2023-11-30T16:14:16+01:00https://gitlab.psi.ch/OPAL/src/-/issues/591Compiler error2023-11-30T16:14:16+01:00frey_mCompiler errorIn `trilinos/12.18.1` we get an error `-Werror=aggressive-loop-optimizations` due to `Ifpack2`. The issue is temporarily fixed
by reducing the optimization level from `-O3` to `-O2` (see !415).
###### Toolchain (on Merlin6):
* amrex/18....In `trilinos/12.18.1` we get an error `-Werror=aggressive-loop-optimizations` due to `Ifpack2`. The issue is temporarily fixed
by reducing the optimization level from `-O3` to `-O2` (see !415).
###### Toolchain (on Merlin6):
* amrex/18.07_3d
* boost/1.73.0
* cmake/3.15.5
* gcc/9.3.0
* gsl/2.6
* hdf5/1.10.6
* H5hut/2.0.0rc6
* OpenBLAS/0.3.10
* openmpi/3.1.6
* parmetis/4.0.3
* trilinos/12.18.1
###### Error message:
```
In member function ‘void Ifpack2::Impl::InvertDiagBlocks<BlockDiagView>::operator()(Ifpack2::Impl::InvertDiagBlocks<BlockDiagView>::Size, int&) const [with BlockDiagView = Kokkos::View<double***, Kokkos::Device<Kokkos::Serial, Kokkos::HostSpace>, Kokkos::MemoryTraits<1> >]’:
cc1plus: error: iteration 2147483649 invokes undefined behavior [-Werror=aggressive-loop-optimizations]
In file included from /opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Tpetra_BlockMultiVector_def.hpp:46,
from /opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Tpetra_BlockMultiVector.hpp:2,
from /opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Tpetra_BlockCrsMatrix_def.hpp:51,
from /opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Tpetra_BlockCrsMatrix.hpp:2,
from /opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Ifpack2_Relaxation_decl.hpp:52,
from /opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Ifpack2_Relaxation.hpp:1,
from /opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Ifpack2_Details_OneLevelFactory_def.hpp:51,
from /opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Ifpack2_Details_OneLevelFactory.hpp:2,
from /opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Ifpack2_Details_Factory_def.hpp:46,
from /opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Ifpack2_Details_Factory.hpp:2,
from /opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Ifpack2_Factory_decl.hpp:48,
from /opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Ifpack2_Factory.hpp:1,
from /psi/home/frey_m/test_opal_2.4/src/src/Solvers/AMR_MG/AmrSmoother.h:28,
from /psi/home/frey_m/test_opal_2.4/src/src/Solvers/AMR_MG/AmrSmoother.cpp:27:
/opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Tpetra_BlockView.hpp:1239:34: note: within this loop
1239 | for(IndexType j = numCols-2; j >= 0; j--) {
| ~~^~~~
cc1plus: all warnings being treated as errors
```https://gitlab.psi.ch/OPAL/documentation/manual/-/issues/33Nice logo for OPAL2020-06-10T08:28:33+02:00bellotti_rNice logo for OPALI think OPAL is a very nice software and has deserved a logo of its own. That would make it much more recognisable, especially in presentations. I made a small suggestion, perhaps we can collect several and then pick the best one. :)
![...I think OPAL is a very nice software and has deserved a logo of its own. That would make it much more recognisable, especially in presentations. I made a small suggestion, perhaps we can collect several and then pick the best one. :)
![opal_logo_handmade](/uploads/b282045f548e8dee532cabc94231dce3/opal_logo_handmade.png)
What are your thoughts?https://gitlab.psi.ch/OPAL/runOPAL/-/issues/12Inconsistent handling of queue parameter2020-05-11T11:42:10+02:00bellotti_rInconsistent handling of queue parameterThe `Simulation.run()` function takes a parameter `queue`, but it is not used on Merlin6. Instead, an environment variable `SLURM_PARTITION` is used.
This should be more consistent.
I would generally advise against the use of environme...The `Simulation.run()` function takes a parameter `queue`, but it is not used on Merlin6. Instead, an environment variable `SLURM_PARTITION` is used.
This should be more consistent.
I would generally advise against the use of environment variables in `Simulation`. Currently, it is not obvious where a setting is coming from, which environment variables may/have to be set, and what their meaning is.
I suggest to read the env variables in the command line script, and pass their values to the constructor of the class or the run method.https://gitlab.psi.ch/OPAL/documentation/manual/-/issues/23Space between number and unit?2020-04-17T12:23:24+02:00snuverink_jjochem.snuverink@psi.chSpace between number and unit?The following discussion from !35 should be addressed:
@gsell started a [discussion](https://gitlab.psi.ch/OPAL/documentation/manual/merge_requests/35#note_20042): (+4 comments)
> @snuverink\_j I would prefer to write it **without** s...The following discussion from !35 should be addressed:
@gsell started a [discussion](https://gitlab.psi.ch/OPAL/documentation/manual/merge_requests/35#note_20042): (+4 comments)
> @snuverink\_j I would prefer to write it **without** space between number and unit - for a simple reason: with a space number and unit might end on two lines. Both variants are commonly used. NIST uses spaces, seehttps://physics.nist.gov/cuu/Units/checklist.html. Other recommend against, see https://www.cam.ac.uk/brand-resources/editorial-style-guide
@winklehner\_d:
> Would this be an option? https://en.wikipedia.org/wiki/Non-breaking_space
@gsell:
> in principal, yes. But without its easier to write and read. As long as the space is not a commonly used convention, I would prefer not separate number and unit with a space. But at the end consistency is more important.
@snuverink\_j:
> I would prefer with spaces, I think it is easier to read with, and it is definitely the standard in physics journals. I think the non-breaking space would be a good solution.https://gitlab.psi.ch/OPAL/documentation/manual/-/issues/12Description of PSI field map format incomplete2020-04-16T16:23:48+02:00snuverink_jjochem.snuverink@psi.chDescription of PSI field map format incompleteThe description of the PSI field map format is incomplete. Only part of the header is described, but the actual values are not described.
For each radial value not only the field values, but also the first, second and third order deriva...The description of the PSI field map format is incomplete. Only part of the header is described, but the actual values are not described.
For each radial value not only the field values, but also the first, second and third order derivatives wrt theta are read in. However, it seems that in the code the values of these derivatives are not used and instead are recalculated from the field values.
cc: @adelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/80Format of selected particle ID1 and ID22021-06-10T18:08:00+02:00Valeria RizzoglioFormat of selected particle ID1 and ID2Just a reminder for the use of the selected particles with ID1 and ID2.
From Andreas's email:
```
the ID1 and ID2 are in the format (x,y,z,px,py,pz) this is different than in the case when you read from file.
```
A coherent format ...Just a reminder for the use of the selected particles with ID1 and ID2.
From Andreas's email:
```
the ID1 and ID2 are in the format (x,y,z,px,py,pz) this is different than in the case when you read from file.
```
A coherent format for ID1 and ID2 with the distribution from file would be nicer, as well as a unique definition of the longitudinal momentum between OPAL-T and OPAL-Cyc. At the moment, they differ not only in used variable (pz for OPAL-T and py for OPAL-Cyc) but also in the meaning:
* **pz** in OPAL-T indicates the longitudinal momentum of the particle,
* **py** in OPAL-Cyc indicates the momentum offset with respect to the reference momentum