Login

Beam-Beam and Luminosity Studies meeting

→ Europe/Zurich
6/2-004 (CERN)

6/2-004

CERN

40
Show room on map
Yannis Papaphilippou (CERN)
Hide

Participants:

Foteini Asvesta, Hannes Bartosik, Michele Carla’, Ilias Efthymiopoulos, Ozgur Etisken, Nikos Karastathis, Parthena Stefania Papadopoulou, Yannis Papaphilippou, Axel Poyet, Kyriacos Skoufaris, Guido Sterbini, Natalia Triantafyllou, Michail Zampetakis, Panagiotis Zisopoulos (video conference)

Guido opened the meeting informing that the Axel's presentation has been postoned to the next Beam-Beam and Luminosity Meeting (8th March).

Kyriacos presented the code NAFF_UV (and Upgrade Version of NAFF in FORTRAN 2008).
After having introduced the motivations and the historical background, he described the algorithm implemented in the code. 

Yannis asked if a version of the original NAFF code was also written in FORTRAN 90. Kyriacos answered that, even if the code can be compiled in FORTRAN 90, the software architecture was using a FORTRAN 77 approach. 

Yannis asked about the difference between the original NAFF (J. Laskar) and for FortNAFF (M. Ehrlichman).  Kyriacos explained the FortNAFF is based on some of the Numerical Recipes modules, such as the brent and four1.

Kyriacos presented the result of the compartison between PyNAFF and NAFF_UV. He pointed out that NAFF_UV can give, as first harmonic, the second one. This hiccup can be simply addressed by sorting by amplitude the N-harmonics frequency extracted by NAFF_UV.  Yannis  asked why PyNAFF/NAFF_UV behaves differenly in that respect. Kyriacos explained that it could be related to the FFT routine used. A similar behaviour was also observed in PyNAFF.  Sofia suggested to test the impact of the windowing on the ordering of the harmonics.

Guido asked if a significant computational cost is associated to the flexibility of having two different window functions (the first for the determination of the frequencies and the second for the determination of the amplitudes). Kyriacos answered that the computational cost is negligible.

Kyriacos showed that, in the proximity of the resonance, the NAFF_UV code is performing significnalty better than the PyNAFF. Yannis pointed out that this is surprising since this limit is related to the physics of the problem and inherent to the KAM theory limits. Kyriacos agreed that this point deserves additional investigations.

Kyriacos pointed out that the NAFF_UV is presently implementing orthogonalization. Comparing results with and without orthogonalization, does not show significant differences. Kyriacos asked if the orthogonalization is strictly needed. Panos commented that it ensure the conservation of the spectral energy of the signal during the iteration of the NAFF algorithm. Yannis commented that the orthogonalization was introduced in the NAFF algorithm for the peculiar physics problem J. Laskar was facing at that time: for the purpose of code generality, it should be maintained. Sofia added that the orthogonalization in presence of noise could have an impact on the final results.

Panos presented an hands-on ipynb showing:

1. a pratical example of the installation and use of PyNAFF.

2. A comparison between PyNAFF and PySUSSIX performance based on a PyHEADTAIL simulation (from A. Oeftiger). The comparison showed a very similar behaviour of the two codes but, including transverse feedback damping,  PySUSSIX performed significantly better than PyNAFF. Yannis asked it PySUSSIX is postprocessing the signal to remove the damping effect and commented that this could explain the difference of the performance. Panos asked that he has to investigate it.

There were no AOBs.

FOLLOW-UPs

  1. After the publication of the note on PyNAFF, we will follow-up the PyNAFF code upload on the LCG (Nikos?).
  2. Clarify the performance of NAFF_UV in the case of resonance (Kyriacos?).
  3. Test the impact of the windowing on the harmonics ordering in NAFF_UV (Kyriacos?).
  4. Clarify if the PyNAFF/PySUSSIX difference (bettern PySUSSIX perfomance) is due to the fact PySUSSIX take into consideration the damping (Panos?).
  5. Can we also consider Harpy (https://cas.web.cern.ch/sites/cas.web.cern.ch/files/lectures/thessaloniki-2018/slidesbeamer.pdf, IPAC2018-THPAF045)?
  6. Prepare some reference signals, possibly user case driven, to have a standard benchmark between codes.

 

There are minutes attached to this event. Show them.
    • 1
      An update on LHC wire compensation simulations (15 min +15 min)
      Speaker: Axel Poyet (Universite Grenoble-Alpes (FR))
    • 2
      An update on the NAFF tool (15 min +15 min)
      Speakers: Kyriacos Skoufaris (University of Crete (GR)), Panagiotis Zisopoulos
      An update on the NAFF tool.pdf
      Intro_to_PyNAFF.ipynb
    • 3
      AOB

      Follow-ups

      1. After the publication of the note on PyNAFF, Nikos will follow-up the PyNAFF code upload on the Stack.
      2. Clarify if the PyNAFF/PySUSSIX difference (bettern PySUSSIX perfomance) is due to the fact PySUSSIX take into consideration the damping.
      3. Can we also consider Harpy (https://cas.web.cern.ch/sites/cas.web.cern.ch/files/lectures/thessaloniki-2018/slidesbeamer.pdf, IPAC2018-THPAF045)
      4. Prepare some user cases to have a standard and agreed benchmark between codes (taking into also noise and coupling).

      AOB

      There were no AOBs.