[trARPES] Fwd: Re: METIS: current status and to-do list

Laurenz Rettig rettig at fhi-berlin.mpg.de
Fri Jun 29 10:05:17 CEST 2018




-------- Forwarded Message --------
Subject: 	Re: METIS: current status and to-do list
Date: 	Mon, 25 Jun 2018 11:41:52 +0200
From: 	Martin Ellguth <ellguth at surface-concept.de>
To: 	Laurenz Rettig <rettig at fhi-berlin.mpg.de>



Dear Laurenz,

A multidimensional buffer for 4 axes is either unflexible or too big to 
hold in memory.
Therefore, we went a different route.
I had implemented a large ring buffer of events from which projections 
can update their contents.
This is internally called "history ring buffer" and in the custom 
projections it can already be used.
The size of this "history ring buffer" is configured in the file
/opt/epics/synApps_5_8/support/areaDetector/ADSurfaceConceptDLD/iocs/SurfaceConceptDLDIOC/iocBoot/iocDLDDetector/st.cmd
in the line that reads
epicsEnvSet("HISTORY_BUFFER",  "1")
(this example means 1GB). Each event in this buffer takes up 8 Bytes, so 
a 1GB buffer can store 128 million events.
It is currently configured to a larger value in your setup, so it should 
be able to store several minutes worth of events.
This is the best and most flexible you can do to have the functionality 
of changing integration ranges of any axis and recalculating
projections from events that have been recorded in the last few minutes.
These projections are really only useful for live adjustments. For 
longer acquisitions, they will lose the oldest events (since the
storing of events into the ring buffer will eventually wrap around and 
overwrite the oldest events).
However, several GBs of events should suffice to give enough statistics 
to judge whether you want to continue
your ongoing measurement. Once you have finished setting up an 
experiment, the full measurement data can be
captured by the HDF5 event stream with "no upper limit" on the 
acquisition time except hard drive space.

What I wanted to improve next is to make this history-buffer-mode 
projections available for the standard xy,xt,yt images
as well as the standard 1D cuts.

Best regards,
Martin

Am 24.06.2018 um 18:47 schrieb Laurenz Rettig:
>
> Dear Martin,
>
> I'm continuing to update here a bit on our progress and on new 
> problems that we came across, I hope that is fine.
>
> On Friday we were finally testing the ADC input and the custom 1D and 
> 2D histograms. This indeed seems to work pretty nicely along the lines 
> as we had intended, encoding our pump-probe delay axis as voltages in 
> the ADC chanel. The calibration from voltage to signal seems to be 
> however somwhat off from 0-10V -> 0-2^15 (more like 0-12 or 0-15 V or 
> so, but we did not test it).
>
> However, also here it appears that only the 2D/1D histograms are 
> filled and no real multidimensional histogram is filled in the 
> background (similar as for A3). I know that this is maybe a bit much 
> to ask and might limit our flexibility, because certainly you cannot 
> do this for all the axis in a good binning and high number of points.
>
> But let me explain a bit how we do our experiments and what we need 
> for them to be efficient, with the example of real data from Friday:
>
> What you see here is an TOF vs. ADC histogram, where the ADC encodes 
> pump-probe delay, and the weak signal at TOF~4300 and starting at 
> ADC~300 is our excited state signal from the conduction band of a 2D 
> semiconductor. To see this weak signal, we need to integrate for ~20 
> min. or so, and now we want to define more clearly where this signal 
> starts and how fast it rises. For this, you would like to have a 1D 
> histogram integrating the intensity from TOF~4280 to ~4310 and plot 
> this along ADC. This can well be done with the custom 1D histogram, 
> however, if I set this now, this histogram does not contain any data, 
> and I have to integrate again for 20 min before I get the histogram. 
> If I had the data in a 4D kx, ky, TOF, ADC histogram, and would just 
> cut slices and display them, I would not lose the already accumulated 
> information.
>
> Similarly, during accumulation of band structures there are often 
> different positions where you want to look at to inspect how things 
> are looking like currently to decide if statistics are good enough to 
> stop or to continue measureing. This can also only be done online 
> during measurements if the binning step and the "slicing" step are 
> independent.
>
> During the last days, we also had several occasions where the TDC ioc 
> crashed with a segmentation fault:
>
>
> For the h5 writer it would be nice if one could configure a maximum 
> file size above which it would atomacially start a new file.
>
> Best, Laurenz
>
> Am 21.06.2018 um 14:01 schrieb Martin Ellguth:
>> Dear Ralph,
>>
>> I am working on the list of issues and so far have solutions for A1, 
>> A2, A7, A12, B14, B15.
>> A8 is a small fix, but best done interactively (i.e. either 
>> TeamViewer or service at your site ---
>> the extent of necessary software updates will eventually require a 
>> visit at your site, anyways).
>> B18 does not require a solution since the independent time histogram 
>> is already provided in form of the
>> 1D Custom Projections in the current software version.
>>
>> A3 is a big task and I cannot predict how much time it will take 
>> (could be anything from 2 weeks to several months)
>> but I think it is important to fix this first, since it will 
>> potentially change parts of the EPICS interface as well (i.e. some
>> names of process variables) which might require adaptations of 
>> software that you build on top of the TDC EPICS ioc.
>> Issues B16, B17 depend on the fix for A3.
>>
>> A4 is something I was not able to reproduce yet. Does this occur for 
>> live histograms and accumulated histograms?
>>
>> There won't be any fixes for A5, since the behaviour can be avoided 
>> by first starting the servers and
>> only starting Control System Studio afterwards.
>>
>> I believe A6 can also be avoided by a proper sequence of booting up 
>> the METIS components. In particular,
>> the high-voltage supplies require 1-2 minutes of boot-up time, before 
>> the corresponding EPICS server can
>> connect to them. Even though the HV crates may become visible in the 
>> network earlier than 1 minute after boot-up,
>> launching of the device servers should be really delayed by 2 minutes 
>> after powering-on the HV crates.
>>
>> A9 (manual) will not be available in short time, but in the meantime, 
>> I can prepare some document that explains
>> the custom cuts.
>>
>> A10: the hdf5 file should be self-explanatory after the last patches 
>> that I had sent (i.e. the Streams have
>> names X, Y, t, MasterRstCtr, ADC, State Input). The range of values 
>> available for the individual event data
>> fields in the hdf5 files follows from the bit widths that the 
>> intermediate software layer (libsctdcDeviceWrapper) uses.
>> I will prepare a document which describes how these bit widths can be 
>> adapted.
>>
>> The computer freezes (D29) could be due to a bug in the AMD Ryzen CPU 
>> firmware in combination
>> with using a Linux OS. There are customer reports with a similar 
>> description (sudden freezes approximately twice a week):
>> https://community.amd.com/thread/225795
>> For the next service visit, I would try the latest BIOS update and 
>> see if afterwards the BIOS setup
>> offers a parameter "Power Supply Idle Control" that can be set to 
>> "Typical Current Idle", which the users in the
>> linked forum thread reported as fixing the freezing issues.
>>
>> Since the fix to A3 is rather urgent, I propose to dedicate attention 
>> to the remaining points of your list only
>> after I have prepared a solution to the A3 issue.
>>
>> Best regards,
>> Martin
>>
>>
>>
>> Am 21.06.2018 um 09:45 schrieb Ralph Ernstorfer:
>>>
>>> Dear all,
>>>
>>> we are curious about your thoughts on the various items on our list. 
>>> In addition, we would like to discuss a timeline on which the urgent 
>>> items are addressed as some issues are truly inconvenient and slow 
>>> our progress.
>>>
>>> Please let us know if some aspects aren't described clear enough.
>>>
>>> Cheers,
>>>   Ralph
>>>
>>>
>>> Am 14.06.2018 um 18:33 schrieb Ralph Ernstorfer:
>>>>
>>>> Dear all,
>>>>
>>>> we have gained some practical experience with the METIS by now and 
>>>> collected first data with the fs XUV (22 eV) pulses. Some of the 
>>>> data looks very nice already, see attachment. The short visit of 
>>>> Gerd and Hajo during their BESSY beam time was extremely helpful. 
>>>> We are still far from truly mastering this instrument, though.
>>>>
>>>> We also gained some experience with the software. While a lot of 
>>>> things work fairly nicely, there still is a number of issues 
>>>> ranging from bugs to aspects that are inconvenient to a wish list 
>>>> of features. We collected these in the attached document. We are 
>>>> aware that it's a fairly long list, but we have sorted it according 
>>>> to category and severeness of the issues.
>>>>
>>>> We noticed a count rate dependent electron artifact during the site 
>>>> acceptance test. It is also described in the attachment.
>>>>
>>>> Besides software and data acquisition, there is an issue with the 
>>>> magnetic shielding. There is indications that magnetic fields enter 
>>>> the spin filter replacement tube, deflecting the electrons 
>>>> vertically. When using 22 eV photon energy, we have not found an 
>>>> alignment yet where the electrons propagate on the optical axis of 
>>>> the objective lens and the subsequent lenses (A-F), arrive centered 
>>>> on the detector without being distorted in both imaging modes. This 
>>>> was already noticed during the factory acceptance test (distortions 
>>>> of the CHESSY sample images), i.e. it does not arise from our lab 
>>>> environment. Do you have suggestions for improving / fixing this issue?
>>>>
>>>> Cheers,
>>>>   Laurenz and Ralph
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>> Ralph Ernstorferernstorfer at fhi-berlin.mpg.de
>>>> Research Group Structural and Electronic Surface Dynamics
>>>> ERC project FLATLAND
>>>> Fritz Haber Institute
>>>> Faradayweg 4-6                              Tel: +49 30 8413-5117
>>>> 14195 Berlin                                Fax: +49 30 8413-5387
>>>> Germany
>>>> http://w0.rz-berlin.mpg.de/pc/ernstorfer/
>>>
>>> -- 
>>> Ralph Ernstorferernstorfer at fhi-berlin.mpg.de
>>> Research Group Structural and Electronic Surface Dynamics
>>> ERC project FLATLAND
>>> Fritz Haber Institute
>>> Faradayweg 4-6                              Tel: +49 30 8413-5117
>>> 14195 Berlin                                Fax: +49 30 8413-5387
>>> Germany
>>> http://w0.rz-berlin.mpg.de/pc/ernstorfer/
>>> ---------------------------------------------------------------------- 
>>> Das FHI verarbeitet, speichert und loescht Daten im Rahmen seiner 
>>> Geschaeftstaetigkeit gemaess der Datenschutz-Grundverordnung (DSGVO) 
>>> [General Data Protection Regulation (GDPR)] der Europaeischen Union.
>>
>> -- 
>> Dr. Martin Ellguth
>> SURFACE CONCEPT GmbH
>> Am Sägewerk 23a
>> D-55124 Mainz
>
> -- 
> Dr. Laurenz Rettig
> Fritz Haber Institute of the Max Planck Society
> Department of Physical Chemistry
> Dynamics of Correlated Materials
> Faradayweg 4-6
> 14195 Berlin, Germany
>
> phone: +49-(0)30-8413 5225
> email:rettig at fhi-berlin.mpg.de

-- 
Dr. Martin Ellguth
SURFACE CONCEPT GmbH
Am Sägewerk 23a
D-55124 Mainz


----------------------------------------------------------------------
Das FHI verarbeitet, speichert und loescht Daten im Rahmen seiner
Geschaeftstaetigkeit gemaess der Datenschutz-Grundverordnung (DSGVO)
[General Data Protection Regulation (GDPR)] der Europaeischen Union.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fhi-lists.de/pipermail/trarpes/attachments/20180629/49332673/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lfnofbicabhjbbkc.png
Type: image/png
Size: 46298 bytes
Desc: not available
URL: <http://fhi-lists.de/pipermail/trarpes/attachments/20180629/49332673/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alogmpbfbfadinpi.png
Type: image/png
Size: 91250 bytes
Desc: not available
URL: <http://fhi-lists.de/pipermail/trarpes/attachments/20180629/49332673/attachment-0003.png>


More information about the trARPES mailing list