Meetings / Skype conferences

[kloppstock]

As most results will probably be achieved irregularly, we would prefer irregular meetings when big changes occur. Feel free to reply to this issue if you think a meeting is necessary and we will do the same if we would like another Skype conference.

[kloppstock]

As I wrote in the mail to @sredford and @lopez-c, we would like to have another Skype conference and discuss the questions stated in the mail. I have created a doodle here.

[kloppstock]

I would suggest a meeting at 10 AM on Friday next week (25.5.). Would this work for you?

[sredford]

Fine for me.

[kloppstock]

What about the others? @mbrueckner-psi @lopez-c

[lopez-c]

Hi all!

Yes, tomorrow is also fine for me. We tried to get some people from the DAQ team as well, but they have a meeting tomorrow. One option could be to meet again on 08/06 in case there are open points left.

Cheers, Carlos

[mbrueckner-psi]

Tomorrow at 10 is fine for me, too.. Cheers, Martin

[kloppstock]

That's great! Could one of you provide a Skype name?

[lopez-c]

My username is "the.salmon". We can also try to reach you on "kilroymb"

[kloppstock]

Michael unfortunately is busy today, so we will try reach you via the Skype account from Heide. Her Skype name is "heide.meissner".

[kloppstock]

Is another Skype meeting with the DAQ team planned for this Friday?

[lopez-c]

We had a first talk with the DAQ team and got some input from them, although nothing was concluded.

The main topic under discussion is if there will always be a computing node dedicated to a certain number of JF modules or if the data from a specific JF module will be transmitted to different nodes. The feedback we got is that this first situation will be the best, but it is not possible for them to guarantee that this will always be the case at this stage. We will have further discussions and we will need to carry out more tests as well.

We could still have the meeting on Friday or postpone it a bit until we can collect more information. In any case, I will be available on Friday morning.

Cheers, Carlos

[kloppstock]

I would postpone the meeting until further information is available.

Cheers, Jonas

[heidemeissner]

Dear colleagues,

we think it would be nice to have a skype meeting to talk about the current status of the software. Do you have time next Monday for example?

Best regards, Heide

[kloppstock]

Here is the drift map mentioned today (after the 9950th frame; scaled logarithmically):

And here is the gain stage map (for the 9951st frame; 0, 1 and 2 represent the gain stages and 4 means masked):

[sredford]

Hi Jonas,

This drift map doesn't look how I expected. To make sure I understood correctly, you calculate the initial pedestal from the pedestal files, and then you track the pedestal through the data file, until the 9950th frame, and this map shows the difference between the 0th and the 9950th frame pedestals? Is the y-axis in ADU? What is your threshold for adding the pixel reading to the threshold calculation?

The first unexpected thing is that in this map there should be no beam features (no circular symmetry). The fact that there are rings makes me worried that photon signals are affecting the tracking of the pedestal, biasing it.

The second unexpected thing is the magnitude of the change. 1000 (ADU?) is larger than typical pedestal drifts which we saw so far, which might be 100-200 ADU for the worst affected pixels over 10,000 frames.

As a disclaimer, there are some cases where tracking will not work. Imagine a pixel is always hit with one/more photons. You will never be able to update that pedestal. And in cases of high occupancy, a bias can be unavoidable. But I would be surprised if your dataset was like this.

Ideas to check what's going on:

• tighten the threshold. Does the magnitude of the drift change? (Bad sign, means photon signal is biasing the pedestal)
• make a map of how many times the pedestal of each pixel is updated. Are all pixels updating every frame? (Bad sign). In this map, you should see a beam feature (= circular structure / rings).
• concentrate on one pixel, and make a graph against time of every ADC output and the current pedestal. With these plots we would understand the situation more. I added some example plots below, from datasets I have tracked. I could also run my tracker over this dataset, so we can compare results.

Cheers, Sophie

Sample plot of two JF modules, showing pedestal drift over the first 10,000 frames of a measurement. Typical features are gradients across the whole module, gradients in the corners, and the double lines top and bottom of the module where there is more leakage current.

Pedestal updates over the first 10,000 frames of a measurement. Behind the beamstop (horizontal structure around row 525) the pedestal is always updated (photons never land here), but in the blurry ring and inside individual Bragg spots the number of updates drops (photons land here and prevent the tracking)

ADC outputs from a single pixel (black dots) vs frame number. The black line is the tracked pedestal. The red lines show the threshold. The green line shows the expected level above pedestal of signal photons

[kloppstock]

Hello Sophie,

thanks for the Feedback! Your assumptions are correct. We will definitely look into the problem.

Cheers, Jonas

[kloppstock]

Hi all!

We think it would be nice to have another Skype meeting to discuss the current state of the software and clear up some open questions. We created a dudle for the date.

The agenda would include the following points:

• state of the software
• open tasks (on our side)
• online display
• online/test system
• clustering
• possible benchmark publication

Cheers, Jonas

[kloppstock]

Dear colleagues,

Friday the 15th at 10 o'clock seems to be the most suitable date and time for the meeting.

Cheers, Jonas

[lopez-c]

Hello Jonas, Friday 15th at 10 is fine for us as well, let's have the meeting on that day Cheers, Carlos

[TheFl0w]

Dear colleagues, we will have to use my Skype account for the meeting today. It's live:florian.warg I have Carlos' contact info, so I should be able to call you.

Cheers, Florian

[kloppstock]

Dear colleagues,

as discussed in the last Skype meeting, we have prepared a version of the code that should work on your systems and merged it into the master branch. Additionally we updated the documentation which should provide sufficient guidance to installing, running and modifying the code. If you have any questions or problems, feel free to let us know!

Cheers, Jonas

[lopez-c]

Hi Jonas,

Thank you so much. I will follow your new instructions, since I had problems installing Alpaka in our server. I'll keep you updated. Cheers, Carlos

[lopez-c]

Hi all,

We have found some problems when we tried to get the jungfrau-photoncounter application compiled. Attached to this message you will find the log of the compilation process plus the settings we used to configure this project. The last thing we tried was to use a newer version of gcc (v7.3.0) still compatible with Alpaka, but it did not help.

Let us know what we can do to help you find the problem.

Best regards, Carlos

CMakeCache.txt log.txt

[kloppstock]

Hello Carlos,

this looks like a problem with the GCC installation. Could you provide the steps you took to install GCC? I could reproduce the error with the already installed GCC 7.3.0 on the system but it worked after I installed GCC 7.3.0 with spack.

Cheers, Jonas

[lopez-c]

Hi Jonas,

It is good that you could reproduce the issue. As I said in the e-mail , we also tried to install it with spack, but the result was still the same:

Spack installation: ./spack install gcc@7.3.0 ./spack install alpaka

And then we set the configuration settings of jungfrau-photondetector project to use the spack installed versions of GCC and Alpaka: CUDA_HOST_COMPILER /home/l_msdetect/tools/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/gcc-7.3.0-xsbc5gb4yzetqm4tjaxg5sdry6y23hzb/bin/gcc alpaka_DIR /home/l_msdetect/tools/spack/opt/spack/linux-rhel7-x86_64/gcc-7.3.0/alpaka-develop-ty4miyhtrv3srem66idnig235wo2y4k5

For the installation of GCC using the source files, we did the following: _./contrib/downloadprerequisites ./configure --disable-multilib --enable-languages=c,c++ make -j 4 make install

Thanks for your help, Carlos

[kloppstock]

Hi Carlos,

it looks like the way you set the CUDA_HOST_COMPILER doesn't work as intended so the system still uses the default compiler and not the one you installed with spack.

Spack provides the ability to load modules which were installed using spack. The module system can be installed by executing /home/l_msdetect/tools/spack/spack bootstrap. Afterwards the environment has to be set by using . /home/l_msdetect/tools/spack/share/spack/setup-env.sh . After this is done, the alpaka and GCC modules are loadable:

spack load gcc@7.3.0
spack load alpaka

Since the modules are unloaded after the end of a session and the environment is lost after a logout, these commands have to be executed after every login:

. /home/l_msdetect/tools/spack/share/spack/setup-env.sh
spack load gcc@7.3.0
spack load alpaka

This method removes the need to manually set the alpaka_DIR at the start of each session.

I hope this helps.

Cheers, Jonas

[lopez-c]

Hi Jonas,

Thanks for your help. We could compile the application and run it.

Cheers, Carlos

[kloppstock]

Hi Carlos,

That is great to hear! How are the execution times compared to your reference code on your system?

Cheers, Jonas

[lopez-c]

Hi Jonas,

yes, this is one thing we would like to check with you. The first tests we ran showed a rather low performance compared to what we saw before, as well as a greater usage of device RAM. We would like to track and find where the bottleneck is, and see if there is something apart from the application we need to optimize.

Would you be available for a phone call this week (or next one), or should we continue the discussion per e-mail?

Cheers, Carlos

[kloppstock]

Hi Carlos,

if it suits you, we can have a call on Monday morning (around 10) next week. Did you compare it to the reference code you sent us or a earlier version of our code?

Cheers, Jonas

[lopez-c]

Hello Jonas,

Monday morning sounds good. I compared the numbers with the code we have here, which is basically an earlier version of your code in CUDA, and we have only run the conversion algorithm. It could be a problem with the setup configuration, since the difference in terms of throughput is very high. Let's have a look on Monday then

Cheers, Carlos

[kloppstock]

Dear Colleagues,

please find the meeting notes attached.

Cheers, Jonas meeting_may20.pdf