MC meeting

Europe/Zurich
Zoom Meeting ID
69051046012
Host
Maja Mackowiak-Pawlowska
Alternative hosts
Yehor Bondar, Przemek Adrich
Useful links
Join via phone
Zoom URL
    • 14:00 14:10
      He-beam pipe in MC 10m
      Speakers: Przemyslaw Adrich (National Centre for Nuclear Research (PL)), Przemysław Adrich (National Centre for Nuclear Research)
    • 14:10 14:20
      Xe+La MC production 10m
      Speaker: Oleksandra Panova (Jan Kochanowski University (PL))

      Different decrease of number of tracks after Track status cut is connected with V0.

       

       

      Liza needs MegaSHOE for tof analysis, but I can produce NanoSHOE with clusters, then NanoSHOEs would be okay for her, but their size would increase:

      For 40A GeV/c

      4.4 GB one NanoSHOE file without clusters for rec tracks, 34T total production

      5.6 GB one NanoSHOE file with clusters for rec tracks, 43T expected size of total production 

       

    • 14:20 14:30
      PbPb MC Production 10m
      Speaker: Mr Yehor Bondar (Jan Kochanowski University (PL))
      Attaached: BPD3 posision for 16_053 PbPb13 prod with cuts: Target in, T1(T2), +- 25 microseconds WFA S11, one Upstream BPD can miss, , MainVertex(primary BPD) z ( - 591.9 cm +-1cm)
      There is no upstream simulation in MC, we start simulation at z~-600cm
      In the database for 16_053 production target is at (0,0,-591.9)cm Maybe this info is incorrect?
      This one is Epos, PrimaryVertexPositioner tries to put PV inside the target with the proper beam direction but fails
      If it were Fritiof beam mode, there would be no hit in the target.
      Anyway beam  and target position inconsistency are bad for MC



      Dear Yehor and Kamil,

      I talked with Kamil, and the problem is that the hole in v1 was not centered at 0,0. In data, a shift is included in the trigger, and as you showed us in MC, it is not considered. Since MC does not consider it, you veto much of the beam generated in MC.

      How to proceed? (Maja should decide)

      We should put the "right position" of the V1 in MC. It has a complicated geometry, and only some measurements of the movement mechanism are available. I do not think we know this mechanism's internal geometry to recalculate it to NA61 or MC coordinate system.

      If I have to deal with it, I would check the beam position of the V1 from T1 and T2 trigger from data (BPD trajectories on the Z correspond to the V1 position) and, based on means values, set the position of the V1 in MC. But maybe there are better ideas?

      Cheers,  Szymon

    • 14:30 14:40
      PSD in PbPb - PSD energy in Pb+Pb 30 (2016) 10m
      Speakers: Andrey Seryakov (St Petersburg State University (RU)), Sergey Morozov (Russian Academy of Sciences (RU)), Mr Yehor Bondar (Jan Kochanowski University (PL))
    • 14:40 14:50
      MC size reduction 10m
      Speakers: Maja Mackowiak-Pawlowska (Warsaw University of Technology (PL)), Oleksandra Panova (Jan Kochanowski University (PL)), Mr Yehor Bondar (Jan Kochanowski University (PL)), Yuliia Balkova (University of Silesia (PL))
    • 14:50 14:55
      Services and files 5m
      Speakers: Bartosz Maksiak (National Centre for Nuclear Research (PL)), Maja Mackowiak-Pawlowska (Warsaw University of Technology (PL))

      Our EOS quota has been enlarged

      The quota on EOS has been enlarged by 1 PB. We have 4 PB now. It was agreed with Bernd Panzer-Steindel that we will be given additional 1 PB per year. At least until we reach our original request to have 6 PB...

      A recommendation for usage of FTS

      During recent large file transfer from EOS to CTA a repeating problem was occurring that many files could not reach the target directory of CTA due to error:
      Error reason: TRANSFER [40] Error on XrdCl::CopyProcess::Run(): [FATAL] Redirect limit has been reached: (destination)

      It was happening for about half of the files that were submitted for the FTS transfer job. I reported that to Service Desk. A long discussion emerged. The discussion concluded with the statement that we have been using FTS jobs wrongly by submitting so many files in one transfer job.

      The recommendation of FTS experts is, that in case of thousands of files to be transferred or staged using FTS, to have a transfer job containing 500-1000 files, definitely not more that 1000. There is no limit however per number of transfer jobs.


      So, if you were using FTS for files transfers or staging many thousands of files on CTA, please divide your file lists onto smaller ones containing not more than 1000 and submit those multiple lists in separate FTS jobs.
      I already had one opportunity to do this in the recommended way (copying 40k files from CTA to EOS, 50 jobs with 800 files each). The result was surprisingly fast and without a single failed transfer.

    • 14:55 15:00
      AOB 5m
      Speakers: Andrey Seryakov (St Petersburg State University (RU)), Brant T Rumberger (Jan Kochanowski University (PL)), Daria Prokhorova (St Petersburg State University (RU)), Evgeny Andronov (St Petersburg State University (RU)), Jakub Piotr Wlodarczyk (Warsaw University of Technology (PL)), Justyna Monika Cybowska (Warsaw University of Technology (PL)), Maja Mackowiak-Pawlowska (Warsaw University of Technology (PL)), Dr Marcin Michal Bielewicz (National Centre for Nuclear Research (PL)), Mr Yehor Bondar (Jan Kochanowski University (PL))