Booster-Test December 2021

TL;DR

For 'booster mode':

• timing the beam transfer from UNILAC to SIS18 works with ~98% efficiency, if rf-conditioning at UNILAC is active
• timing the beam transfer from UNILAC to SIS18 works with 100% efficiency, if rf-conditioning at UNILAC is switched off

Introduction

Shortly before Christmas, the facility is operated with a 'dry' pattern DRYRUN_202111_SIS18_FAST_HHD_BOOSTER, requesting 'dry beam' from UNILAC to SIS18 and downstream to cave HHD. The measurement scenario is identical to the first booster-mode test performed in November 2021 (click). The only other pattern operated in parallel is DRYRUN_202111_SIS18_FAST_QKICKER (but without beam request UNILAC).

Raw data are available here //.../dryRun_2021-dec/booster/booster-*-2021-12* .

Further reading:

• here, concept
• here, realization

Measurement Settings

The measurements done during the November 2021 dry-run have been repeated but with slightly different settings given in the table below. As a main difference to the November dryrun, the event CMD_UNI_BREQ_NOWAIT is scheduled earlier.

MID	start time [UTC]	end time [UTC]	delay BREQ [ms]	offset(BREQ, BPREP) [ms]	UNILAC rf-conditioning	remark
1	2021-11-24 13:27	2021-11-25 07:43	10	-40	ON	dryrun November 2021; shown here for comparison
2	2021-12-17 11:49	2021-12-20 06:40	5	-45	ON	raw data files marked by '2021-12-17_12-30'
3	2021-12-20 12:19	2021-12-21 07:24	4	-46	OFF	raw data files marked by '2021-12-20_13-15'
4	2021-12-21 11:35	2021-12-22 07:03	4	-46	ON	raw data files marked by '2021-12-20_13-15'
5	2021-12-22 07:29	2021-12-23 06:36	3	-47	ON	raw data files marked by '2021-12-20_13-15'
6	2021-12-23 08:00	2021-12-24 23:00	2	-48	ON	raw data files marked by '2021-12-23_07-32'
7	2021-12-25 12:34	2021-12-31 08:30	4	-46	ON	raw data files marked by '2021-12-25_13-34'
8	2021-12-31 08:30	2022-01-02 06:00	4	-46	ON	raw data files marked by '2021-12-31_09-30'

Table: Measurement Settings for Measurement ID (MID) 2-4. The settings of the November dryrun are shown for comparison (MID 1). Shown are the Measurement ID (MID, 1st column), time (columen 2,3), the delay of CMD_UNI_BREQ_NOWAIT with respect to the start of an UNILAC cycle (column 4), ParamModi offset for CMD_UNI_BREQ_NOWAIT and CMD_UNI_BPREP (column 5) and and information if RF-Conditioning in UNILAC is present (column 6).

Data

Snooped Timing Messages

A detailed analysis of snooped timing messages will be done in January 2022.

Diagnostic Logging

A quick analysis has been done using data written to diagnostic logging (graylog). Log messages are exported as CSV for further processing.

DM-UNIPZ Gateway

Each log message contains timing information about the 4th booster cycle. Shown below are two examples: The first one contains data for a good injection from UNILAC, while the second line contains data of a bod injection where UNILAC delivers beam one cycle too late. As a hiccup, the important time difference between CMD_UNI_BRERQ_NOWAIT and EVT_MB_TRIGGER is rounded to the full millisecond (sorry for that). Details on the output are described elsewhere (click).

good: dmunipz-daemon: dm-unipz: TRANS 00357744,  1415( 21)ms, va  6( 6)/1 | INJ 00001/00003(04/06),   55(0.008/  21/  45 -> 9.920)ms | DG 1.459ms | 1 1 1 1 1 1 1 1, OpReady    (     0), OK   (153453)
bad : dmunipz-daemon: dm-unipz: TRANS 00357020,  1424(  8)ms, va  6( 6)/1 | INJ 00001/00003(04/06),   77(0.008/  22/  67 -> 9.920)ms | DG 1.463ms | 1 1 1 1 1 1 1 1, OpReady    (     0), OK   (153453)
                                                                                                       '          '    '    ' 
                                                                                                       '          '    '    '- time difference [ms]: EVT_MB_TRIGGER - EVT_READY_TO_SIS
                                                                                                       '          '    '- time difference [ms]: EVT_READY_TO_SIS - CMD_UNI_BREQ_NOWAIT
                                                                                                       '          '- time difference [ms]: acknowledge of beam request by UNIPZ - CMD_UNI_BREQ_NOWAIT
                                                                                                       '- time difference [ms]: EVT_MB_TRIGGER - CMD_UNI_BREQ_NOWAIT <-- IMPORTANT!!!

WR-UNIPZ White Rabbit Pulszentrale

Log messages are written to diagnostic logging every 10 seconds. Shown below is an example. Details on the output are described elsewhere (click).

wrunipz-daemon: wr-unipz: ST 0026188461 1100011100000011 1111111 |DG 50.015 02089 00000 |, OpReady    (     0), OK   (     0)
                                                                          '
                                                                          '- UNIPZ cycle rate [Hz]

Results

Qualitative

Figure: Measured data for test. The UNILAC operation rate is shown in blue (left y-axis). The delay of beam injection into SIS18 following a beam request to UNIPZ is shown for timely delivery (green, right y-axis) and delayed delivery (red, right y-axis); these data are taken for the 4th booster cycle. Please note the right y-axis is reversed. Details see text.

The figure above show operation rate of UNIPZ (and UNILAC) as blue curve. Typical variations are within a window of 50Hz +/- 0.1 Hz. An interesting effect is the sudden drop typically happening at full hours.

The figure also shows information on the delay of beam injection into SIS18 following a beam request at UNILAC. The data are only shown for the 4th booster cycle and the data have a precision of 1 ms only.

'Good' injections into SIS18 are marked by a green square. Here, the injection happens at about 54 ms following the beam request from SIS18 to UNILAC.

'Bad' injections into SIS18 are indicated as red rhombus. These always happen always one UNILAC cycle (20ms) too late at about 75 ms following the beam request. It is interesting to note that 'delayed injections' into SIS18 are always associated with sudden drops of the UNILAC operation rate.

As a caveat, it is sometimes observed that UNIPZ gets 'trapped' in a state, where 'late' injections happen every 28s, while all other injections are fine. This can be seen in the figure above from 2021-12-21 23:00 to 2021-12-22 00:00 ('trap' ended with negative jump) and in more detail in the figure below ('trap' ended by a positive jump). Presumably, this is caused by some interference with rf-conditioning at UNILAC and/or other patterns requesting other virtual machines at UNIPZ.

Figure: Example of 'trapped' UNIPZ. 'Trapping' manifests itself by periodic 'late' injections every 28 seconds and ends at the next positive or negative frequency jump.

Remark: UNILAC is coupled to the 50 Hz mains frequency [1]. This is achieved via the module FX 201.021 [2], which provides some smoothing of the mains 50 Hz. The drops in UNILAC operation rate can not be due to green energy harvesting. Change in solar power can be excluded as sun-set happened around 15:25 UTC and wind powered energy is unlikely the cause due to a high pressure zone across Europe with little and smooth pressure gradient during the time window shown above. According to [3, 4], the sudden drops are most likely a consequence of 'energy trading' on the stock market.

[1] https://www-acc.gsi.de/data/documentation/eq-models/pzus/gm-pzus.pdf

[2] https://www-windows.gsi.de/belab/FG_DB/

[3] P. Gerhard, private communication

[4] https://www2.ipp.mpg.de/ippcms/ep/ausgaben/ep201801/bilder/0118_netz_2_dia.html

Quantitative

MID	settings		success [%]	good					bad					UNILAC operation rate				Remark
	Delay BREQ [ms]	UNILAC RF-Conditioning		n	ave [ms]	sdev [ms]	max [ms]	min [ms]	n	ave [ms]	sdev [ms]	max [ms]	min [ms]	ave [Hz]	sdev [Hz]	max [Hz]	min [Hz]
1	10	ON	89.06	25631	48.944	0.459	50.967	46.007	3147	68.947	0.456	70.182	67.003	49.997	0.022	50.141	49.902	dryrun November 2021; shown here for comparison
2	5	ON	98.11	42034	53.404	0.536	56	51	808	73.667	0.705	75	73	49.998	0.020	50.088	49.902
3	4	OFF	100.00	12064	54.487	0.600	56	52	0	n/a	n/a	n/a	n/a	49.994	0.024	50.103	49.907
4	4	ON	98.40	12100	54.510	0.573	56	53	197	75.051	0.698	76	74	49.994	0.022	50.074	49.909
5	3	ON	94.80	13845	55.534	0.585	58	53	759	75.513	0.962	95	75	49.993	0.022	50.116	49.880	UNIPZ 'trapped' for a few hours; 50 Hz mains bumpy
6	2	ON	98.64	24295	56.386	0.702	58	54	334	76.668	0.702	78	76	50.003	0.021	50.087	49.914	UNIPZ 'trapped' on 24 December @ 23:00 UTC (stop data taking)
7	4	ON	99.64	88058	54.193	0.482	57	52	316	74.858	0.778	77	74	50.007	0.019	50.114	49.89
8	4	ON	99.43	29203	54.221	0.452	56	53	168	77.000	0.000	77	77	50.004	0.016	50.092	49.908

Table: Measured data. Shown are a variety of data for different settings of 'delay of beam request' and 'rf-conditioning'. Information on statistics is given for 'good' and 'bad' injections as well as for UNILAC operation rate.

Discussion

Two parameters are important

• delay of beam request at UNILAC
• UNILAC is operated with or without rf-conditioning

rf-conditioning OFF: With properly chosen delay, it was possible to operate the transfer from UNILAC to SIS18 without a single failure for about 19 hours.

rf-conditioning ON: Even with rf-conditioning on, an acceptable rate of good injections exceeding 98% can be achieved.

In general it is observed, that - with rf-conditioning ON - 'bad' injections are triggered by sudden drops of the UNILAC operation frequency, which is coupled to 50 Hz mains. Moreover, 'bad' injections tend to happen in groups. In between those incidents it is possible to transfer beam from UNILAC to SIS18 for hours without failure. This said, measurements for such phenomena should be done for a long time (~ one day), considering that sudden drops of the 50 Hz seem to happen more frequently in the evenings until past midnight.

Important: The data presented here is relevant for booster injection #4. For the booster injections #2 and #3 it is expected to work even better .

-- DietrichBeck - 13 Jan 2022