1st plot is of Sigma vs Freq for 186Hf72+ setting. The green vertical line is at 411.843MHz.
2nd plot is of Sigma vs Freq for 186Hf72+ setting from april 4th 20:00 to April 5th 09:00 with time cut 0.14, shift tracking applied and pwr-limit 100. About 5200 Injections.

We stop taking beam at 10:47 for tuning a new setting. 

Team PLEIADES is wanting to get access for 10 mins to install a remote oscilloscope, so entry to the ESR has been requested. 

At 10:45 we will enter the ESR and install a remote oscilloscope for the PLEIADES outside detector. Should take only 10 "GSI" minutes ;-)
After that, ESR tuning to 192Pb can start.

Beam is gone since 7:02. Control room is notified. Beam is back since 7:14. FRS started taking spills.

FRS started taking beam from 6:00 Am

mesycontrol process starts but shows no GUI at all.

Around 02:51 we wanted to record leakage currents for PLEIADES. 
The windows of the mesycontrol were not present on the screens. 

We followed the instructions for restart:
-ssh -X into x86l-128 (-X is important, otherwise qt will not be initialized)
-mesycontrol

as a result we see nothing but the terminal is busy, and the process exists. 
We noticed that ssh connection establishes very slow, the terminal after the connection responds to typing with a delay of several seconds(one press 'm', after 1-2 sec that letter appears on 
the screen).
 
htop hanged the terminal entirely without showing a thing. Several minutes before we started htop and 12th thread(processor?) has been fully busy, 100%.

our assumption is that GUI has been closed because computer had not enough resources for sustaining it. We would not expect such a slow response even in terminal. 
Could anybody have a look on x86l-128 and figure out why is it so slow? 

UPD: started mesycontrol around 03:40, until 04:02 nothing happened except first two commands. 
Tried to start it from x86l-124 and everything works fine except that the connection to /dev/tty/USB0 can't be established (because it is occupied by x86l-128?)
So we are not able to read leakage currents. 

 

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!