Comment by Ali Allaoui on 2023-11-28 16:45:25:
On peut voir la répartition des temps de calcul en utilisant mon venv de test : /net/CESAM/amazed/aallaoui/venvs/amazed_0.46-RC1

Comment by Didier Vibert on 2023-11-28 17:28:36:
Ali Allaoui wrote in #note-3:
> On peut voir la répartition des temps de calcul en utilisant mon venv de test : /net/CESAM/amazed/aallaoui/venvs/amazed_0.46-RC1

oui joli ! y a plus qu'a aller regarder les spectres lents vs rapide pour voir si on peut expliquer la différence.

Comment by Vincent Le Brun on 2023-11-28 21:59:17:
il faut faire attention aux différences entre machines (qui sont assez énormes), et donc filtrer par nom de node aussi ...

Comment by Ali Allaoui on 2023-12-06 13:12:09:
En rajoutant les noeuds et en virant des noeuds manifestement plus lents, y a clairement moins de spectres problématiques

Comment by Ali Allaoui on 2023-12-06 13:14:13:
du coup je pense qu'il vaut mieux refaire tourner sur la partition cpu_4216 pour regarder de plus près sans le biais des noeuds

Comment by Didier Vibert on 2023-12-06 13:33:36:
en regardant par nœud on voit encore des temps qui vont du simple au triple:

eg node11:

node27:

node45:

node44:

node46:

etc...

Comment by Ali Allaoui on 2023-12-06 13:55:40:
ok donc ce run suffit mais je ne trouve pas de corrélation entre temps de calcul et les paramètres du modèle. Il faudrait avoir le nombre de points par spectre, c'est possible qu'il varie beaucoup sur ces spectres vincent ?

Comment by Didier Vibert on 2023-12-06 13:56:48:
Ali Allaoui wrote in #note-10:
> ok donc ce run suffit mais je ne trouve pas de corrélation entre temps de calcul et les paramètres du modèle. Il faudrait avoir le nombre de points par spectre, c'est possible qu'il varie beaucoup sur ces spectres vincent ?

c'est exactement ce que j'étais entrain de me demander...

Comment by Vincent Le Brun on 2023-12-06 13:59:05:
ce sont les spectres incidents qui sont tous ré-échantillonnés à 1A sur la meme plage de longueur d'onde, donc qui ont tous le meme nombre de pixels.

Comment by Didier Vibert on 2023-12-06 13:59:36:
Vincent Le Brun wrote in #note-12:
> ce sont les spectres incidents qui sont tous ré-échantillonnés à 1A sur la meme plage de longueur d'onde, donc qui ont tous le meme nombre de pixels.

et t'as pas mis de filtrage en entrée ?

Comment by Vincent Le Brun on 2023-12-06 14:02:23:
pourquoi faire ?
non

Comment by Ali Allaoui on 2023-12-06 14:31:33:
en tous cas j'ai vérifié il n'y a aucune corrélation entre le temps de calcul et les attributs présents dans le redshift.csv

Comment by Didier Vibert on 2023-12-06 14:58:30:
une piste possible ?

avec fftprocessing, il faut resampler les templates pour qu'ils soient avec le même pas en log que les spectres (eux même resamplés avec le pas en dz), ce resampling est fait au début de chaque spectre, dans @CProcessFlowContext::Init@ et donc a priori compté dans le usertime du spectre. D'après les logs, seul 4 templates sont resamplés .
Ensuite, dans un bunch, si les spectres ont tous le même sampling, le resampling des templates effectué avec le premier spectre du bunch est conservé et n'est pas refait pour les spectres suivants du bunch. On a donc une diff entre le premier spectre d'un bunch et les autres. Le resampling des templates ne se fait que sur la plage de longueur d'onde restframe qui va être utilisée (fonction de la couverture du spectre et du range z demandé). Avec des spectres incidents avec une grande couverture, les templates sont resamplés eux aussi sur une grande plage. Je ne sais pas si ça suffit à expliquer....