https://pfspipe.ipmu.jp/jira This file is an XML representation of an issue en-us 8.3.4 803005 13-09-2019 https://pfspipe.ipmu.jp/jira/browse/REDMINE1D-298 1D Redmine <p><em><font color="#505f79"> Created on 2023-09-06 12:35:46 by Vincent Le Brun. % Done: 100</font></em></p> <p>dans l'échantillon /net/CESAM/amazed/validation_tests/release_0.44/output_pfc_0.44-RC5 dans un des objets classé quasar ( 00232106 ) le paramètre StrongEmissionLinesSNR est négatif (ce qui ne devrait pas pouvoir exister), je ne sais pas si c'est un problème librairie ou vizu. </p> <p>MR: <a href="https://gitlab.lam.fr/CPF/cpf-redshift/-/merge_requests/559" class="external-link" rel="nofollow">https://gitlab.lam.fr/CPF/cpf-redshift/-/merge_requests/559</a></p> REDMINE1D-298

[RM-8259] SNR négatif under lines

Task Normal Done Done Redmine-Jira Migtation Redmine-Jira Migtation Wed, 6 Sep 2023 18:15:16 +0000 Mon, 6 Nov 2023 18:29:32 +0000 Mon, 6 Nov 2023 18:29:32 +0000 0 1 <p>Comment by Didier Vibert on 2023-10-17 08:26:49:<br/> a fix to add: the @StrongEmissionLinesSNR@ is duplicated by the output (in same HDF5 dataset ie candidate/model_parameters) @StrongELSNR@. The latter should be removed from result_specification.csv</p> <p>Comment by Didier Vibert on 2023-10-17 09:56:24:<br/> pour info: cette quantité @StrongEmissionLinesSNR@ est une somme de SNR des raies en émission avec un SNR &gt; 8 (hrad-codé) ou dont le SNR est &gt; 80% de la somme de tous les SNR des raies en émission. Le SNR de chaque raie étant calculé comme: Flux intégré du spectre moins le continu / sqrt(somme des pixels variance). </p> <p>Je trouve ça assez bizarre de faire des sommes de SNR, ça n'a pas de sens à mon avis...</p> <p>si on tient à conserver ce type d'info, je propose de calculer non pas la somme des SNR, mais le SNR de la somme des raies, c-a-d somme_des_flux / sqrt(somme_des_pixels_variance), en conservant à peu près la même sélection des raies: SNR individuel &gt; 8, ou SNR individuel &gt; 80% du SNR total (de toutes les raies en émission visibles)</p> <p>@vlebrun, ça te va ?<br/> on peut aussi virer tout ça !</p> <p>Comment by Vincent Le Brun on 2023-10-17 10:01:33:<br/> clairement la somme des SNR n'a aucun sens, et ça aurait un sens de garder le SNR calculé sur les raies strong du linecatalog (ce qui éviterait d'avoir un critère sur le SNR de chaque raie qui a une origine assez trouble pour moi)</p> <p>Comment by Didier Vibert on 2023-10-17 10:13:32:<br/> Vincent Le Brun wrote in #note-7:<br/> &gt; clairement la somme des SNR n'a aucun sens, et ça aurait un sens de garder le SNR calculé sur les raies strong du linecatalog (ce qui éviterait d'avoir un critère sur le SNR de chaque raie qui a une origine assez trouble pour moi)</p> <p>ok du coup je propose 2 sorties: </p> <ul> <li>StrongEmissionLinesSNR: SNR calculé sur les raies strong du linecatalog</li> <li>EmissionLinesSNR: SNR calculé sur toutes les raies en émission du linecatalog</li> </ul> <p>ça peut être utile, si on trouve des solutions avec un SNR total plus for que le SNR strong... </p> <p>Comment by Vincent Le Brun on 2023-10-17 10:14:25:<br/> en effet, c'est bon pour moi</p> <p>Comment by Didier Vibert on 2023-10-17 10:17:13:<br/> @aallaoui ça va sans doute conflicter un peu avec ton issue #8312</p> <p>Comment by Didier Vibert on 2023-10-17 10:35:42:<br/> "StrongEmissionLinesSNR" , strict ou pas ?<br/> dans le code actuel, pour chaque SNR individuel on agrège les raies qui se chevauchent, et par exemple pour Euclid, on comptera NII dans le SNR Ha.</p> <p>Comment by Vincent Le Brun on 2023-10-17 10:36:59:<br/> vu que c'est rien d'officiel, on va au plus simple, si les raies se chevauchent ça n'aurait pas forcément de sens de séparer..</p> <p>Comment by Ali Allaoui on 2023-10-17 12:18:43:<br/> Didier Vibert wrote in #note-10:<br/> &gt; @aallaoui ça va sans doute conflicter un peu avec ton issue #8312</p> <p>c'est urgent ? parce que je peux aussi modifier légèrement 8312 pour ne rien casser au monoobs et la valider maintenant<br/> J'allais justement commencer cette partie, @dvibert tu peux vérifier que 8312 en l'état ne conflicte pas trop avec cette issue ? et si on ne merge pas que je travaille sur des éléments qui ne conflictent pas</p> <p>Comment by Didier Vibert on 2023-10-17 13:17:32:<br/> Ali Allaoui wrote in #note-13:<br/> &gt; Didier Vibert wrote in #note-10:<br/> &gt; &gt; @aallaoui ça va sans doute conflicter un peu avec ton issue #8312<br/> &gt; <br/> &gt; c'est urgent ? parce que je peux aussi modifier légèrement 8312 pour ne rien casser au monoobs et la valider maintenant<br/> &gt; J'allais justement commencer cette partie, @dvibert tu peux vérifier que 8312 en l'état ne conflicte pas trop avec cette issue ? et si on ne merge pas que je travaille sur des éléments qui ne conflictent pas</p> <p>rien de très urgent... je la passerai après toi, et donc je gèrerai les conflits, si tu ne tardes pas trop sur #8312. héhé... t'as pas un peu la pression là ? 😀</p> <p>Comment by Pierre-yves Chabaud on 2023-10-27 12:22:33:<br/> Merged into @develop@ (@05b54892@)</p> Development Rank 0|zzszgv: