The SIS kicker has failed again at 08:01.
Since this has happened already few times, the experts from the on-call duty service are now looking at the problem.

The beam is back. But, the experts have found a problem with one of the modules of the SIS kicker magnet. And, currently they have disabled this module. This fixed the problem. However, since the kicker system is not running with full power, it is not clear by how much this can affect the extracted beam intensity for the ESR. Therefore,  the ESR experts have been called and they will look at the injected beam intensity in the ring, in order to know if its still the same as before disabling the module. 
The experts will discuss at the upcoming meeting how to proceed with the damaged module, i.e. when to repair it.
In addition, the FRS started to take the beam now (again) which means that we will be getting less pulses from SIS as compared to the previous night.

Since the FRS started to take the beam again, the ESR gets 1/10 shots from SIS. But, the ESR seems to request about twice more frequently the beam from SIS which means that every second shot in the ESR is empty (it contains the remaining beam from the previous injection). This also applies to the data stored by RSAs because they also (seem to) trigger each time the ESR requests the beam.

We have the beam again the ESR since around 11:00.
The Schottky spectra look the same as before.
The ESR experts could not exactly identify the problem which caused this loss of the beam.

Operators seem to play with spill cycles, we get every 1:1 shot, then 1:10 again. During this, we noticed a few "empty injections" beeing triggered in the RSAs. They light up green, but spectrum is flat. Then it returns to normal operation again.

I added automatic shift tracking and a check for a minimum wanted power in that bin to Shahab's npz_addup.py script.
It looks for the highest bin in the projected spectrum (so after time-cut) and tracks it position. Careful, it uses the position in the very first FILE as reference. So, the ordering in the given file list affects this.

Here's Shahab's log entry about the initial script:
https://elog.gsi.de/esr/E0203_E0018/137

Created pull request in Shahabs repo:
https://github.com/xaratustrah/e0018_e0203_scripts/pull/1

Before that is accepted, find the script here:
https://github.com/mijja-koeln/e0018_e0203_scripts/blob/main/npz_addup.py


New command line options are:
  -h, --help            show this help message and exit
  -t TIME_CUT, --time-cut TIME_CUT
                        Start time as a float (optional)
  -s, --shift-track     Enable shift tracking based on strongest peak in spectrum (optional)
  -l PWR_LIMIT, --pwr-limit PWR_LIMIT
                        Set minimum power required to process file (optional)
  -v, --verbose         Print additional information (optional)


"-s" enables shift tracking and correction.

"-l" enables power limit / threshold. Only files with at least this power in the highest bin are used for summation.

"-v" prints infos abuot the tracking in each file. Optional, if you want to see how good it works.

The --time-cut option is applied in all scenarios, i.e. also before projection used for tracking.

Have fun!

186Hf, 510MeV/u of 208Pb beam, ecooling not working 

Lassie screen shots 186Hf

> Acquisition stopped at 20:36. 
> 
> First file from this setting: RSA01-2025.04.01.03.52.59.247.tiq
> 
> Last file from this setting: RSA01-2025.04.01.20.36.54.257.tiq
> 
> acq. length changed to 500 ms
> 
> acq bw changed to 50 MHz
> 
> ==> 12 MSamples
> 
> Trigger window condition set to 50%.
> 
> First file from this setting: RSA01-2025.04.01.20.45.40.053.tiq
> 
> Analysis setting the the frame length 2^16 and frame number = 190.

Last file from previous setting: RSA01-2025.04.01.21.06.30.580.tiq

Changed the RSA01,02 to 50 MSamples/s (20nsec/sample) for 500.00 ms acq. length, 25 MHz acq. BW, 33% trigger position.

First good file from this time: 21:37 04.01.2025 -- RSA01-2025.04.01.21.37.13.721.tiq