Comment by Didier Vibert on 2023-08-24 16:21:01:
ah ça fait 2 tickets ça ! un pour vizu et un pour la lib...
je rajoute @fdufresne en watcher, je me demande si ça concerne pas des modifs qu'elle a faite ?
Comment by Pierre-yves Chabaud on 2023-08-25 14:30:20:
L'erreur @Failed to identify a range including the candidate [...]@ n’apparaît qu'une fois sur l'ensemble des tests de validation de la RC4.
L'erreur apparaît pour la première fois sur la RC3 en date du 3 août.
Comment by Vincent Le Brun on 2023-09-08 12:44:32:
j'ai eu un mail avec un commentaire de Fanny qui n'apparait pas ici, à propos du parameters.json. comme ce n'est pas moi qui ai fait tourner le run je ne sais pas, Pierre-Yves ?
Comment by Didier Vibert on 2023-09-08 12:55:33:
Vincent Le Brun wrote in #note-5:
> j'ai eu un mail avec un commentaire de Fanny qui n'apparait pas ici, à propos du parameters.json. comme ce n'est pas moi qui ai fait tourner le run je ne sais pas, Pierre-Yves ?
moi aussi j'ai eu le mail et pas de trace du msg ici... sinon le parameters.json utilisé est toujours sauvegardé dans le run. Donc ici @/net/CESAM/amazed/validation_tests/release_0.44/output_pfs_0.44-RC4/parameters.json@
Comment by Pierre-yves Chabaud on 2023-09-08 13:39:07:
Je pense que Fanny a supprimé son commentaire pour ne pas vous déranger car elle s'est rendu compte qu'il n'était plus a propos. Nous avons échangé par Mattermost.
C'était sans compté sur les notifications par email 
Comment by Fanny Dufresne on 2023-09-11 08:29:19:
héhé exactement ! La prochaine fois je mettrai un petit message pour prévenir que c'est out of date ^^
Comment by Fanny Dufresne on 2023-09-13 12:37:42:
A priori le candidat est bien hors range, à cause d'une modif faite pour éviter que les ranges ne se marchent dessus
L'intervalle dans du redshift le plus haut commence plus bas que l'intervalle du reshift le plus bas (en gros le range du zlow est contenu dans le range du zhigh), du coup les calculs suivants ne fonctionnent pas comme prévu (la partie ranges[candidateKeyLow].SetEnd(ranges[candidateKeyHigh].GetBegin() - 1E-4) fait sortir le candidat low de son range)
- On a au départ :
low : redshift 1.088509 - range [1.088372, 1.088646]
high: redshift 1.093318 - range [1.085216, 1.101420]
- Puis après la première partie de calcul qui supprime l'overlap :
tout pareil sauf range redshift qui devient [1.088577, 1.101420] -> il y a encore un overlap
- Puis avec ranges[candidateKeyLow].SetEnd(ranges[candidateKeyHigh].GetBegin() - 1E-4:
on "éjecte" le redshift low de son range
Voilà, à voir comment on décide de corriger ça !
Comment by Vincent Le Brun on 2023-09-13 13:06:54:
dans cette situation pourquoi on ne fusionne pas les intervalles pour laisser la deuxième pass se débrouiller toute seule ?
Comment by Didier Vibert on 2023-09-13 13:19:07:
Vincent Le Brun wrote in #note-10:
> dans cette situation pourquoi on ne fusionne pas les intervalles pour laisser la deuxième pass se débrouiller toute seule ?
ça se passe après la deuxième passe. Les ranges dont parle @fdufresne sont les ranges d'intégration de la pdf sous le pic. Donc là on a 2 candidats, avec donc deux ranges second pass disjoints, mais in fine, quand on évalue la largeur des pics de chacun, y en a un qui se retrouve à l'intérieur de l'autre !
Comment by Vincent Le Brun on 2023-09-13 13:21:12:
Ok mais avec un intervalle de seconde pass adaptable en fonction de la largeur du pic le probleme ne doit pas se produire ?
Comment by Didier Vibert on 2023-09-13 13:32:31:
Vincent Le Brun wrote in #note-12:
> Ok mais avec un intervalle de seconde pass adaptable en fonction de la largeur du pic le probleme ne doit pas se produire ?
Certes, c'est l'objet du ticket #6508. Pour l'instant quand on trouve un pic trop large par rapport à la taille de la fenêtre seconde passe on fait un warning, l'objet de #6508 est de recommencer la 2nd pass (on abandonne l'idée d'un proxy sur la largeur du pic à l'issue de la première passe, car pas concluant). Ce développement un peu complexe.
Comment by Fanny Dufresne on 2023-09-14 14:05:32:
Après discussion avec Didier on va probablement dans un premier temps modifier la manière dont sont séparés les ranges quand il y a overlap.
- Ce qui est fait actuellement:
- si les deux redshift sont "suffisamment distants": on les sépare, en raccourcissant le range du redshift le plus grand
- sinon on ajoute le redshift le plus bas aux "duplicates"
- Ce qu'on souhaite faire: changement de la condition:
- si l'overlap est inférieur à 30% de la taille des chacun des range, on les sépare en mettant la frontière des range au milieu de l'overlap
- sinon on ajoute le redshift le plus bas aux "duplicates"
Comment by Vincent Le Brun on 2023-09-14 14:48:21:
ça me va, en plus ça fait une décision un peu plus symétrique entre les deux candidats
Comment by Didier Vibert on 2023-09-15 07:02:59:
Fanny Dufresne wrote in #note-16:
> Après discussion avec Didier on va probablement dans un premier temps modifier la manière dont sont séparés les ranges quand il y a overlap.
> * Ce qui est fait actuellement:
> - si les deux redshift sont "suffisamment distants": on les sépare, en raccourcissant le range du redshift le plus grand
> - sinon on ajoute le redshift le plus bas aux "duplicates"
>
> * Ce qu'on souhaite faire: changement de la condition:
> - si l'overlap est inférieur à 30% de la taille des chacun des range, on les sépare en mettant la frontière des range au milieu de l'overlap
> - sinon on ajoute le redshift le plus bas aux "duplicates"
Je viens de regarder: les candidats listés dans "duplicates" sont ensuite supprimés. Il faudrait donc choisir entre les deux, celui qu'on supprime. Choisir le plus bas z est totalement arbitraire. Comme on n'a pas encore calculé l'intégrale de la proba, et pour cause, je propose de conserver celui dont le max de la pdf est le plus élevé.
Je rappelle aussi qu'avec l'adaptation de la seconde passe on ne devrait plus avoir de problème à ce niveau:
- l'adaptation proposée dans #6508 est d'agrandir la fenêtre suffisamment pour contenir tout le pic, une fois sa largeur calculée. Donc le range d'intégration devrait être contenu dans la fenêtre.
- lors du calcul des fenêtres 2nd passe, les fenêtres qui se chevauchent sont fusionnées, et un seul candidat est retenu par fenêtre.
Comment by Vincent Le Brun on 2023-09-15 08:51:19:
donc est ce que ça vaut la peine de faire une correction qui ne sera plus utile après la 6508 (sauf si celle là est prévue en meme temps que Kalman ?)
Comment by Pierre-yves Chabaud on 2023-09-15 09:03:44:
(coup bas...)
Comment by Fanny Dufresne on 2023-09-15 14:20:29:
Pour le moment ce que je propose de faire (enfin que j'ai déjà fait):
- Les modifs indiquées dans la note #16
- En effet il serait plus logique de garder candidat dont le max de la proba est plus élevé mais ça demande un petit peu plus de travail, et si ça a vocation a être jeté prochainement je serais partante pour ne pas le faire. OK pour toi Didier ?
Comment by Didier Vibert on 2023-09-15 14:33:17:
Fanny Dufresne wrote in #note-21:
> Pour le moment ce que je propose de faire (enfin que j'ai déjà fait):
> - Les modifs indiquées dans la note #16
> - En effet il serait plus logique de garder candidat dont le max de la proba est plus élevé mais ça demande un petit peu plus de travail, et si ça a vocation a être jeté prochainement je serai|s partante pour ne pas le faire. OK pour toi Didier ?
ça dépend du temps qu'on met à implémenter #6508. Si tu te sens de la faire rapidement ok, sinon fixe celle là .
C'est pas bien compliqué, tu as directement la val de la proba dans le candidat: @candidates[candidateKeyLow|candidateKeyHigh]->ValProba@ et il suffit de push dans @duplicates@ celui qui a la plus faible.
sinon, tes modifs ne seront pas "à jeter", même après #6508, on ne sait jamais...
Comment by Fanny Dufresne on 2023-09-15 15:36:10:
ça marche
Comment by Pierre-yves Chabaud on 2023-09-20 12:41:03:
Merged into @develop@ (@864219aa@)