Ne pas lancer fuse quand le nombre de samples est trop important ?
Discussion cet après-midi, suite aux problèmes de place sur /mnt/result : Mathieu propose de ne pas lancer fuse lorsque le nombre de samples est supérieur à un nombre (p. ex. 20). Cela permet d'économiser de la place (et du temps CPU : un fuse sur 100 fichiers prend du temps). De plus le fuse est lancé autant de fois qu'il appartient à de sample sets (donc au moins 2, non ?).
753e78ca : On ne garde que les 16 premiers. C'est peut-être un peu brutal de faire cela au niveau de fuse.py, mais bon, cela renvoie tout de même un .vidjil pour une visualisation sur les premiers échantillons.
Ça me paraît un peu rapide. On n'a pas vraiment de solution pour « degrade gracefully ». Garde les 16 premiers : est-ce que ça veut dire qu'on va fusionner toujours les mêmes sur le serveur s'il y a plus de 16 fichiers ? Comment on fait pour avoir les autres ? Le custom fuse ne permet pas de sauvegarder les analyses. Côté serveur il faudrait avertir les utilisateurs qu'ils ne verront que 16 fichiers.
Il y a des utilisateurs avec plus de 16 fichiers, et ça peut faire sens : http://rbx.vidjil.org/browser/index.html?patient=790&config=25 Le problème est surtout avec les runs ou avec Kiel qui met plein d'échantillons différents dans un même patient. Les clones n'ont rien à voir d'un échantillon à l'autre et donc on se retrouve avec des dizaines de milliers de clones dans le fichier. Une autre solution peut être de réduire le top lorsque le nombre de fichier augmente.
D'autant plus que l'utilisateur qui nous pause problème à ce sujet n'utilise pas le fuse automatique mais plutôt le custom_fuse, non ? Ne pourrait-ton pas simplement avoir des configs qui fusent et d'autres non ?
Oui, effectivement ça serait une solution simple de proposer à Kiel une config sans fuse (on sait faire ça ?).
Je pense qu'il y a un bout de code à changer pour que le run accepte de ne pas fuse, mais oui je pense que c'est possible.
Oui, le coup de la config en plus, pourquoi pas !
Ou même... la config par défaut pourrit faire 16 fichiers au plus, et on a une config spéciale si quelques gens veulent avoir beaucoup de points.
« degrade gracefully ». Garde les 16 premiers : est-ce que ça veut dire qu'on va fusionner toujours les mêmes sur le serveur s'il y a plus de 16 fichiers
C'est une bonne question. Mais que cela soit oui ou non, c'est un "degrade gracefully" si on montre 16 points... et si on dit qu'on a une autre config si vraiment on veut avoir d'autre chose.
Enfin, quitte à avoir une autre config, on pourrait aussi régler plus finement les paramètres du fuse (top et autres).
Ça me semble plus simple de demander à Kiel d'utiliser une config sans fuse, plutôt que de mettre en place le nécessaire pour avertir les utilisateurs que quand il y a plus de X fichiers ils ne verront pas tous les résultats et qu'ils doivent lancer avec une autre config (en espérant qu'il y ait une config correspondante avec un fuse infini).
Autre exemple, si j'uploade 20 fichiers dans mon run (ce qui n'est pas délirant), j'ai envie de savoir si j'ai de la conta entre mes 20 fichiers pas entre 16 fichiers plus ou moins choisis aléatoirement (dont l'ordre dépendra de l'upload).
En fait plus j'y réfléchis, plus j'ai l'impression qu'un top qui diminue progressivement avec le nombre de fichiers fournit une solution plus satisfaisante (et même pas besoin de demander à Kiel d'utiliser une autre config, on peut mais ça n'est pas indispensable).
plutôt que de mettre en place le nécessaire pour avertir les utilisateurs
Je ne suis pas d'accord sur ce point, c'est très simple avec les notifications. Cela permet d'avoir, par défaut, un comportement correct pour la majorité des utilisateurs, et de les inciter à utiliser correctement les patients. (Et s'ils leur manquent quelque chose, c'est facile de rajouter une config pour un user, pour des bonnes raisons). Je préfère être sûr, dès maintenant, que tous les utilisateurs font ce qu'il faut (et traiter au cas par cas quelques cas comme Kiel) plutôt que de retomber dans quelques mois sur un autre utilisateur qui fera pareil.
Autre exemple, si j'uploade 20 fichiers dans mon run (ce qui n'est pas délirant)
Oui, tout à fait ! 16 est un exemple, cela peut être 32 ou 42 :-) Dans tous les cas, au-delà de 8-10 simples, on devrait cacher sur le graphe (cf une autre tâche). Et encore plus si on fait des SampleSets : peut-être que quelqu'un aura un SampleSet de 100/200 patients correspondant à un truc particulier... (Mais lance-t-on les mêmes configs dans tous les SampleSet ? Ce n'est pas obligé.)
En fait plus j'y réfléchis, plus j'ai l'impression qu'un top qui diminue progressivement avec le nombre de fichiers fournit une solution plus satisfaisante
Oui, c'est aussi possible, par exemple (1000 / #samples)... mais on a déjà du mal à expliquer ce qu'est notre top, alors là cela va être encore plus dur. Ou alors, 1000 tant que #samples < 8, puis ensuite cela descend.
Par défaut, met-on le -f dans fuse.py à 0 et on fait une config pour Kiel où le -f est à 1 (ou X) ?
Kiel vient d'ajouter une centaine de fichiers → –10 Go