Résultats des anomalies (LHC)

[fzs600]

 

Est-ce possible de traduire ce texte ?J'espere qu'il n'est pas trop long.

Well, here I am sitting by the pool, looking at the
same problem I found while sitting here 4 months
ago! Let me remind you I am/was running two very
dense intensity scans, each consisting of a dozen
or so studies, each with a different beam intensity
i.e bunch charge ranging from 0 to a maximum of that of
400,000,000,000 protons. In turn each study had up to
100,000 different cases with different initial amplitudes,
angles, and magnet errors, each attempting one million turns.
The result of each case is a file fort.10 (gzipped)
containing one line of 60 double precision precision
numbers for each pair of particles being tracked
(typically 30 lines). The BOINC validations checks that
50 or so of these numbers are identical, excluding a few
values like the SixTrack Version number and the CPU time.
While re-running a few cases in a study to clear the tail
of incomplete cases I found I had two VALIDATED results for
one case which were DIFFERENT!!! For me this is a big problem
and I have been really worried trying to find an explanation.

The (very) good news is that the differences are small and that
the physics results are not seriously affected. The bad news is
that I have not (yet) found out how this can happen or the number
of cases affected. In this particular case each of the 30 lines
had 20 differences (the first 9 numbers on each line reflect the
input and prove that it was identical in all runs). The numbers
which are different are the same at roughly the level of single
precision BUT I expect and normally obtain 0 ULP difference in all
caes i.e. NO difference at all.

I remind you we run each case twice and accept results when we have
two identical results, re-running as necessary, until that is true.
The odd man (men) out are rejected and are normally attributable to
hardware error e.g. an overclocked CPU. We assume that the probability
of getting the same wrong answer twice is very very small and can be
ignored.

I now reran this case (known as PROBLEM) on various systems at CERN and
with different compilers and always got the same result. I also reran
the case on BOINC several times and also got the same answer. I also ran
with my new SixTrack Version 4446 instead of 4441 and again got the ame
answer. With some help I checked the BOINC validation logs and looked
for the two hosts which returned the same wrong result but they seemd
to be OK hosts (my detailed notes are in Geneva).

I then ran into problems with disk space and the power suppy on my
desktop Linux box failed. However I had copied one scan to another Linux box
and continued that intensity scan from there (WLXSCAN0) an suspended activity
on WLSCAN2 with the PROBLEM.

This scan WLXSCAN0 is now pretty much complete after adjustment of the
initial amplitude ranges, lower bounds for high intensity studies,
higher bounds for low intensity studies. As a check I took a subrange of
initial amplitudes of one study and ran those cases again on BOINC.
(Now my other deskside Linux box is down so I can't check the number of
cases right now, but it is of the order of a few tens of thousands.)
Crosschecking now found 5 result discrepancies, which I call PROB1, PROB2,
..., to PROB5.

PROB1 has one/line pair different out of 30, words 12, 14, 19, 20 etc.
PROB2 gives an I/O error because two bytes on one line which should be
"00" are "o_". This has probably been overwritten subsequent to BOINC
validation and can be ignored as I reject it automatically.
PROB3 has one word different, Word 10, on one line.
PROB4 has ALL lines/pairs different from Word 10, 12, 13, 14 onwards.
PROB5 has one line, one word 10 different.

So, all results apart from PROB2 are acceptable (and it is rejected so
no problem) because the lost turn number is the same. Hence physics should
be OK. However I wonder if there are other cases I haven't double checked.
The number of errors detected is (very) small but is still a big worry.
I have never seen this before. I have made a search for the hosts concerned
but so far cannot find a common factor. I CANNOT reproduce the errors at CERN or
on BOINC despite running these 5 cases many times. I (strongly) suspect an
error in the SixTrack post-processing which has been changed recently. I also
have ideas about the results depending on the date/time!!! Variable length strings
might cause alignment problems leading to a different code path. Strange
but has happened. I cannot reproduce the problems even with three other
compilers here at CERN. All results are correct and identical down to the
last bit.

I am reluctant to rerun an entire study as I feel it is a "waste" of your
computer time, but it may come to that in the end. I also get correct
results with the latest SixTrack version 4446 which I may therefore install
anyway.

All this to keep you informed, if you are interested, and to explain my
reluctance to finish of the intensity scans right now. So back to desk
checking the post-processing and back to CERN on Wednesday.

Finally, if you have read or skipped here, I quote from the latest press
release from the DG:

From rolf.heuer@cern.ch Thu Mar 14 10:30:39 2013
New results indicate that particle discovered at CERN is a Higgs boson.
At the Moriond Conference today, the ATLAS and CMS
collaborations at CERN?s Large Hadron Collider (LHC) presented preliminary new
results that further elucidate the particle discovered last year. Having
analysed two and a half times more data than was available for the discovery
announcement in July, they find that the new particle is looking more and more
like a Higgs boson, the particle linked to the mechanism that gives mass to
elementary particles. It remains an open question, however, whether this is the
Higgs boson of the Standard Model of particle physics, or possibly the lightest
of several bosons predicted in some theories that go beyond the Standard Model.
Finding the answer to this question will take time.
etc etc etc.
The detection of the boson is a very rare event - it takes around 1 trillion
(1012) proton-proton collisions for each observed event. To characterize all
of the decay modes will require much more data from the LHC.

http://lhcathomeclassic.cern.ch/sixtrack/forum_thread.php?id=3732&postid=25507#25507

Merci.

[Fred VW]

J'ai essayé de te traduire les 2er paragraphe, des gens ayant un meilleur niveau en anglais et une connaissance techniques du sujet pourrons corrigé mes erreurs

Eh bien! Je suis assis près de la piscine, en regardant le même problème que j'ai trouvé déja trouvé, il y a  4 mois de cela.
Permettez-moi de vous rappeler que je balaye des intensité denses, constitués chacune d'une dizaine de faisceau différent allant de 0 à un maximum de 400 000 000 000 protons.
A son tour chaque étude avait jusqu'à 100.000 cas différents avec chacune des amplitudes initiales, des angles et des erreurs d'aimant...
Le résultat de chaque cas est un fichier fort.10 (gzip) contenant une ligne de 60  chiffre a double précision pour chaque paire de particules étant suivis (typiquement 30 lignes).
BOINC vérifie que 50 de ces numéros sont identiques, à l'exception de certaines valeurs comme que le numéro de version de SixTrack et le temps CPU.
Alors que j'essayais de ré-exécuter quelques cas dans une étude visant à dégager des cas incomplets, j'ai trouvé que j'avais deux résultats validés différents pour un cas identique
Pour moi, c'est un gros problème et je suis inquiet, car je ne trouve pas de solution

La bonne nouvelle est que les différences sont minimes et que les résultats finaux ne sont pas fortement affectés.

La mauvaise nouvelle est que je n'ai pas encore trouvé comment cela peut se produire ou le nombre d'UT touché par ce problème.
Dans ce cas particulier, chacune des 30 lignes avaient 20 différences. Les chiffres qui sont différents sont les mêmes à peu près au niveau du calcul en simple précision, mais normalement  je m'attendais à obtenir 0 différence ULP dans tous les CAES, soit aucune différence.

[zerizno]

Salut,

Je veux bien me lancer dans le reste de la traduction. Est-ce toujours d'actualite?

[ousermaatre]

 
oui, tous les textes se trouvant dans cette section sont encore à traduire, donc tu peux te lancer.....

[zerizno]

Bon, ca a ete plus complique que ce que j'imaginais. L'auteur n'est pas tres clair sur certains points, et semble supposer que l'on connaisse les ficelles de l'application SixTrack - ou alors c'est moi qui n'ai pas tout integre.

Voici mon premier jet 

[NDT: source http://lhcathomeclassic.cern.ch/sixtrack/forum_thread.php?id=3732&sort=6#25507]
[25 Mars 2013]

Me voilà assis près de la piscine, examinant le même problème que j'avais trouvé il y a 4 mois! Laissez-moi vous rappeler que j'avais conduit deux gros scans, chacun consistant en une douzaine d'études sur des rayonnements d'intensité différente (des groupes de charges allant de 0 à un maximum de 400 milliards de protons). Chaque étude a comporté jusqu'à 100 000 cas différents, variant les amplitudes initiales, les angles, et les erreurs magnétiques, avec un million de tours à chaque fois. Le résultat de chaque cas est un fichier « fort.10 » (zippé) contenant une ligne de 60 nombres en double précision pour chaque paire de particules suivies (typiquement 30 lignes). La validation des unités par BOINC vérifie que pour deux résultats, environ 50 de ces nombres sont identiques, en excluant certaines valeurs comme la version de SixTrack et le temps de calcul. En recalculant quelques unités pour étudier certains cas incomplets, je me suis aperçu que pour un certain cas, j'avais deux résultats différents ayant néanmoins été validés ! Pour moi il s'agit d'un gros problème, et j'ai anxieusement cherché  une explication.

La (très) bonne nouvelle est que les différences sont petites, et que les résultats n'en sont pas sérieusement affectés. La mauvaise nouvelle est que je n'ai pas (encore) trouvé comment ça peut se produire, ou le nombre de résultats concernés. Dans ce cas particulier, chacune des 30 lignes avait 20 différences. Les 9 premiers nombres de chaque ligne sont tirés de l'unité de calcul originale et prouvent qu'elles étaient identiques pour chaque calcul. Les nombres différents sont identiques jusqu'au niveau de la simple précision, mais je m'attends et normalement obtient des nombres égaux jusqu'au dernier chiffre après la virgule, c'est-à-dire aucune différence.

Je vous rappelle que nous simulons chaque cas autant de fois que nécessaire jusqu'à ce que nous ayons deux résultats identiques. Les résultats différents sont alors rejetés. Ils sont généralement imputables à des erreurs matérielles, par exemple avec un CPU overclocké. Nous considérons que la probabilité d'obtenir la même erreur deux fois est extrêmement faible et peut être ignorée.

J'ai recalculé ce cas (le « PROBLEME ») sur divers systèmes du CERN, et avec différents compilateurs, et j'ai obtenu le même résultat. J'ai aussi eu le même résultat sur BOINC plusieurs fois. Avec la nouvelle version 4446 de SixTrack (au lieu de la 4441), j'ai encore obtenu la même réponse. J'ai vérifié les logs de validation de BOINC et retrouve les deux clients ayant retournes le même résultat incorrect, mais ils semblent être des clients fiables.

J'ai eu par la suite des problèmes d'espace disque, et une défaillance de l'alimentation de mon PC Linux. Cependant j'avais copié un des scans sur une autre machine Linux et ai continué ce scan (WLXSCAN0), tout en suspendant l'activité sur WLSCAN2, celui avec le PROBLEME.

Ce scan WLXSCAN0 est maintenant pratiquement terminé, après un ajustement de l'échelle d'amplitude initiale, des seuils plus bas pour les études en haute intensité, et des seuils plus hauts pour les études en basse intensité. A des fins de contrôle,  j'ai pris une sous-partie de l'échelle d'amplitudes initiales d'une des études et j'ai repassé ces cas sur BOINC. Mon autre machine Linux est hors service à ce moment et je ne peux pas préciser le nombre de cas étudiés, mais c'était de l'ordre de quelque dizaines de milliers. La vérification de ces résultats a montré 5 cas litigieux, que j'ai nommés de PROB1 à PROB5.

PROB1 a une paire de chiffres différente par ligne (sur 30 lignes), sur les emplacements 12, 14, 19, 20, etc. PROB2 est en erreur car deux octets sur une ligne auraient du être « 00 » mais étaient à « o_ ». La valeur a probablement été réécrite par le processus de validation de BOINC, et peut être ignorée car rejetée automatiquement. PROB3 a une valeur différente (la dixième) sur une ligne. PROB4 a toutes ses paires de valeurs différentes sur toutes les lignes, à partir des valeurs 10, 12, 13, 14 et suivantes. PROB5 a une valeur différente (numéro 10) sur une ligne.

Tous les résultats sauf pour PROB2 sont acceptables (et sont rejetés donc pas de problème) car le nombre de tours perdus reste le même. Ainsi la valeur scientifique n'est pas impactée. Cependant je me demande s'il n'y aurait pas d'autres cas litigieux. Le nombre d'erreurs détectées est (très) petit, mais reste préoccupant. Je n'ai jamais vu ça avant. J'ai examiné les ordinateurs concernés mais n'ai pas trouvé de points communs. Je n'arrive pas à reproduire ces erreurs sur les ordinateurs du CERN ou sur BOINC, malgré avoir recalcule ces 5 cas plusieurs fois. Je suspecte fortement une erreur dans le traitement des résultats par SixTrack, qui a changé récemment. J'ai dans l'idée que les résultats dépendent de la date ou de l'heure ! Des différences de longueur de chaines de caractères peuvent provoquer des problèmes d'alignement entrainant une différence de traitement. Etrange, mais c'est déjà arrivé. Je ne peux pas reproduire le problème avec trois compilateurs différents, ici au CERN. Tous les résultats sont corrects et identiques jusqu'au dernier bit.

Je suis réticent pour exécuter à nouveau l'étude en entier car ça semble un gâchis de votre temps de calcul, mais il se peut que j'en vienne à ça. J'obtiens des résultats corrects avec SixTrack version 4446, que j'installerais probablement de toute façon.

Tout ça pour vous tenir au courant, si vous êtes intéressé, et pour vous expliquer ma réticence actuelle à finir les scans d'intensité. Je reprends les vérifications des processus de validation et suis de retour au CERN Mercredi [27 Mars 2013, NDT]

Enfin, pour ceux qui aurait tout lu ou sauterais directement ici, voici un extrait du communiqué de presse du directeur général :

De rolf.heuer@cern.ch, Jeudi 14 Mars 2013, 10:30:39
De nouveaux résultats indiquent que la particule découverte au CERN est un boson de Higgs. A la conférence de Moriond aujourd'hui, les équipes ATLAS et CMS du LHC au CERN ont présenté de nouveaux résultats préliminaires qui caractérisent plus précisément la particule découverte l'année dernière. Apres avoir analysé deux fois et demi plus d'information que ce qui était disponible lors de notre annonce en Juillet dernier, ils ont déterminé que la nouvelle particule ressemble de plus en plus à un boson de Higgs, la particule lie au mécanisme qui donne leurs masses aux particules élémentaires. La question reste ouverte, cependant, de savoir s'il s'agit du boson de Higgs décrit dans le modèle standard de la physique des particules, ou bien du plus léger d'une série de bosons prédits dans des théories allant au-delà du modèle standard. Trouver la réponse prendra du temps.
Etc., etc.
La détection d'un boson est un évènement rare – il faut 1 trillion (1012) collisions proton-proton pour chaque évènement observe. La caractérisation de tous les modes de décomposition demandera bien plus de données de la part du LHC.

[JeromeC]

Dur dur sa vie. Heureusement, il y a la piscine.

[fzs600]

Merci pour la trad.