|
|
Discussion avec Christine
|
|
|
|
|
|
Les 15 et 20 et 28 mai 2020
|
|
|
|
|
|
Points techniques :
|
|
|
1) comprendre comment fonctionne une branche dans un projet git
|
|
|
|
|
|
https://gitlab.in2p3.fr/grasland/formation-git
|
|
|
|
|
|
2) quelles différences entre un objet R, .Rdata et un .rda ou .rds : un .Rda est une abbréviation d’un .Rdata. Dans un .Rda sont sauvés un ensemble d’objets R. Dans un .rds, un seul objet est sauvegardé.
|
|
|
|
|
|
3) comprendre le wiki dans projet git : un wiki interne au projet, ce n’est pas visible aux autres personnes que les développeurs
|
|
|
|
|
|
4) comprendre la logique du versionning
|
|
|
|
|
|
http://r-pkgs.had.co.nz/release.html
|
|
|
If you’ve been following the advice in versioning, the version number of your in-development package will have four components, major.minor.patch.dev, where dev is at least 9000. The number 9000 is arbitrary, but provides a strong visual signal there’s something different about this version number. Released packages don’t have a dev component, so now you need to drop that and pick a version number based on the changes you’ve made. For example, if the current version is 0.8.1.9000 will the next CRAN version be 0.8.2, 0.9.0 or 1.0.0? Use this advice to decide:
|
|
|
Increment patch, e.g. 0.8.2 for a patch: you’ve fixed bugs without adding any significant new features. I’ll often do a patch release if, after release, I discover a show-stopping bug that needs to be fixed ASAP. Most releases will have a patch number of 0.
|
|
|
Increment minor, e.g. 0.9.0, for a minor release. A minor release can include bug fixes, new features and changes in backward compatibility. This is the most common type of release. It’s perfectly fine to have so many minor releases that you need to use two (or even three!) digits, e.g. 1.17.0.
|
|
|
Increment major, e.g. 1.0.0, for a major release. This is best reserved for changes that are not backward compatible and that are likely to affect many users. Going from 0.b.c to 1.0.0 typically indicates that your package is feature complete with a stable API.
|
|
|
In practice, backward compatibility is not an all-or-nothing threshold. For example, if you make an API-incompatible change to a rarely-used part of your code, it may not deserve a major number change. But if you fix a bug that many people depend on, it will feel like an API breaking change. Use your best judgement.
|
|
|
|
|
|
|
|
|
Idée :
|
|
|
créer une mailing liste DiCoExpress pour annoncer les changements
|
|
|
|
|
|
|
|
|
Changement de point de vue sur l'analyse d'expression différentielle pour la plateforme.
|
|
|
Atouts et difficultés liés à ce changement de modélisation.
|
|
|
|
|
|
→ identification d’un besoin de communication sur les analyses statistiques
|
|
|
|
|
|
Comment le personnel humide plateforme intervient dans ces nouvelles analyses ?
|
|
|
|
|
|
→ par des discussions en fonction du ressenti et des compétences de chacun
|
|
|
→ à réfléchir aussi avec la création du pôle Intégration de SPOmics
|
|
|
|
|
|
Deux pipelines d'analyse d'expression différentielle coexistent : DiCoExpress et un pipeline plateforme.
|
|
|
|
|
|
Différences :
|
|
|
Pipeline POPS prend en charge des plans avec plus de 2 facteurs bio mais le plan doit être complet et équilibré
|
|
|
Pipeline POPS crée un Rmarkdown, crée le Target par le fichier de la table de comptage
|
|
|
Pipeline POPS permet de donner la modalité de référence
|
|
|
DiCoExpress : plan déséquilibré, fait la coexpression et les enrichissements
|
|
|
|
|
|
→ travail à faire [Christine]
|
|
|
1) combiner la fonction Load_Data_File et la fonction POPS pour charger les données même quand le fichier Target n’est pas donné
|
|
|
2) La fonction Quality_Control : faire les ACP sur les 3 premiers axes au lieu de 2
|
|
|
3) Vérifier l’arborescence des résultats de l’analyse différentielle est compatible avec l’organisation POPS.
|
|
|
|
|
|
→ Filtration des faibles comptage
|
|
|
Filtration par edgeR : FilterByExpr
|
|
|
La fonction filtre sur les cpm pour ne pas favoriser les grandes tailles de librairie.
|
|
|
Le cutoff est moins choisi arbitrairement, il s’adapte aux tailles de librairies en regardant la mediane des tailles de librarie.
|
|
|
1) envoi d’un Rmarkdown [Christine]
|
|
|
2) corriger le bug dans DiCoExpress [Marie-Laure]
|
|
|
|
|
|
→ a réfléchir et faire évoluer [Christine]
|
|
|
1) le modèle quand il y a 3 facteurs
|
|
|
2) l’écriture des contraste : la solution du package contraste de Christine
|
|
|
3) générer un objet R qui permettrait de reproduire des graphiques facilement parce que la résolution graphique n’est pas bonne dans DiCoExpress
|
|
|
http://larmarange.github.io/analyse-R/export-de-graphiques.html : R peut exporter un graphique dans une grande variété de formats. Il permet d'exporter des images matricielles et des images images vectorielles qui ont l’avantage de pouvoir être redimensionnées à volonté sans perte de qualité et produisent des fichiers en général de plus petite taille.
|
|
|
|
|
|
→ enrichissement : encore du travail de code et de perfectionnement [Marie-Laure]
|
|
|
→ coexpression : il faut la mettre en place à partir de DiCoExpress
|
|
|
|
|
|
Les interfaces graphiques des pipelines d'analyse d'expression différentielle qui existent par ailleurs
|
|
|
avec Rshiny [Christine]
|
|
|
→ intérêt de rendre un objet R qui permet de laisser le collaborateur refaire des graphiques
|
|
|
→ proposer une interface graphique
|
|
|
|
|
|
Ce serait quoi le pipeline d'analyse (d'expression différentielle) idéal pour la plateforme ?
|
|
|
→ garder DiCoExpress pour la production des résultats en veillant que chaque fonction rende un objet R ou un .Rdata ou un .rds afin de les utiliser dans un autre script pour faire un compte-rendu aux collaborateurs en Rmarkdown.
|
|
|
→ avoir un package R pour la plateforme est difficile à maintenir car il doit etre installé par les informaticiens.
|
|
|
|
|
|
|
|
|
Quels résultats et sous quel forme fournir aux collaborateurs ? Comment "convaincre" le collaborateur de cette nouvelle façon de faire par rapport à l’existant de la plateforme ?
|
|
|
|
|
|
Comment fournir les résultats aux collaborateurs, qui fournit les résultats aux collaborateurs, comment et où stocker les données générées, les analyses intermédiaires ?
|
|
|
|
|
|
garder DiCoExpress pour la production des résultats en veillant que chaque fonction rende un objet R ou un .Rdata ou un .rds afin de les utiliser dans un autre script pour faire un compte-rendu aux collaborateurs en Rmarkdown.
|
|
|
Dans ce cas, possibilite aussi de donner l’objet R aux collaborateurs
|
|
|
|
|
|
Un FAQ (frequently asked questions) pour les analyses d'expression différentielles ? Si oui quel contenu et où ?
|
|
|
|
|
|
→ un wiki sur le git de DiCoExpress
|
|
|
→ une mailing liste
|
|
|
→ une FAQ
|
|
|
A voir comment organiser cela
|
|
|
|
|
|
Gestion des projets de la plateforme quand il y a d'autres personnes que toi qui interviennent sur les analyses .... |
|
|
\ No newline at end of file |