[4 - Future] - Fonctions métier

[PMHLambert]

consider several mortatlity cursors per country (to regionalise a little more the anthropogenic pressure), or even cursors for 2 or 3 periods (to keep track of trends in management). IRisk to lose simplicity in the interactivity and therefore in the effectiveness of the message.

ThinkR:

• Permettre une seconde entrée pour les mortalités (Avant 2050, Après 2050)
• En sortie, on reprend la meme chose que "Changement Climatique"
• Explorer les scripts fournis: diades.atlas.data
• Première version de la fonction qui lance une simulation HyDiaD. Nécessite probablement encore de l'optimisation
  HyDiaDsimulation.zip
• Implémenter la vignette adéquate et les fonctions
• Implémenter les tests unitaires
• Ajouter à l'interface

[statnmap]

• Define all parameters needed => Add info in issue [4 - Future] Meta #23
• Fix list of all parameters that can be tested
• What are the model specifications to be used for predictions ? Can we get scripts ?
• Prepare script to calculate predictions under different parameters choice.
• Create map of predictions

[statnmap]

On pourra voir si on peut faire les prédictions directement dans la base

[ColinFay]

@PMHLambert nous n'avons pas le code permettant de calculer les prédictions, est-ce qu'ils sont disponibles ?

[statnmap]

Les données et scripts sont dans: diades.atlas.data.
A explorer.

[statnmap]

Exploration du jour sur les scripts modèle

Le code est toujours en cours de développement, mais je met mes observations ici au fur et à mesure pour ne pas les perdre

• Reprise du code tel quel, sans essayer d'optimiser ou de vérifier s'il est correct
• Modifications lorsque nécessaire pour que les fonctions marchent avec la base de données le plus loin possible
• Séparation des fonctions dans les fonctions:
  • identification des paramètres non déclarés dans la fonction: cela fonctionne avant séparation car les variables sont utilisées comme variables globales, mais il vaut mieux tout déclarer. En sortant la fonction, on se rend compte plus vite des variables manquantes.
• Pas de moyen de vérifier que les calculs matriciels sont corrects.
  • Le code fait appel a plusieurs calculc matriciels ou entre vecteurs. Ils sont de la même taille et supposés correspondre aux bons bassins versants / années. Pour cela, le code arrange() les variables par ordre alphabétique. Mais cela ne garantit pas une correspondance parfaite. Le mieux est de passer par des data.frame autant que possible de façon à faire des jointures sur la base d'une colonne commune.
  • J'ai réalisé cette opération pour le calcul avec spawnersTo_50 parce qu'ils étaient créés trop loin dans le code pour être sûr qu'ils correspondaient. Ci dessus le code modifié. Ici, on passe de data.frame à matrix et inversement, mais en théorie on devrait pouvoir tout faire en data.frame, à condition de le faire depuis le début.
  • Il y a peu de raison qu'il y ait des erreurs d'appairage, mais ce n'est pas garanti dans le code original

# catchment_spawnersTo_50 est une table créé au départ à la place de `spawnersTo_50` pour conserver le nom des BV
# > catchment_spawnersTo_50
# Source:     lazy query [?? x 3]
# Database:   postgres
#   [diadesatlas_owner@localhost:5432/diades]
# Ordered by: basin_name
   basin_name surface_area
   <chr>             <dbl>
 1 Authie             1305
 2 Orkla              3092
 3 Vefsna             4122
 4 Aulne              1495

  # survival offspring
  if (parameter$withAllee) {
    # => Safe version: Join Spawners to be sure that basins are in the same order
    catchment_spawnersTo_50_collect <- catchment_spawnersTo_50 %>% collect()
    # Keep in order of `spawnersTo`
    survivalOffsprings <- as.data.frame(spawnersTo) %>% 
      # get back rownames as column for the join
      rownames_to_column(var = "basin_name") %>% # count() # 134
      rename(spawnersTo = V1) %>% 
      # Join
      left_join(catchment_spawnersTo_50_collect, by = "basin_name") %>% # %>% count()
      # Calculate survivalOffsprings with correct basin
      mutate(
        survivalOffsprings = parameter$r * 
          (spawnersTo^2 / (spawnersTo_50^2 + spawnersTo^2)) * spawnersTo) %>% 
      # Back to matrix for the calculations
      column_to_rownames(var = "basin_name") %>% 
      select(survivalOffsprings) %>% 
      as.matrix() #%>% 
      # head() %>% is()
    
    # => Original version: calculate the proportion of active spawners
    # survivalOffsprings <- parameter$r * (spawnersTo^2 / (spawnersTo_50^2 + spawnersTo^2)) * spawnersTo
  } else {
    survivalOffsprings <- parameter$r * spawnersTo 
  }

[statnmap]

@PMHLambert
J'ai récupéré tout le code inclus dans le zip pour le mettre les simulations dans des fonctions du package et faire un Rmarkdown d'exploration.
Le code de tes fonctions à changé un peu.
Tu dois quand même pouvoir t'y retrouver si tu veux apporter des modifications.

En effet, le temps de calcul des prédictions est long et je ne suis pas sûr que ça passe dans Shiny car l'application pourrait se fermer avant la fin des résultats. Il y a une limite de temps qu'on peut difficilement changer.
J'ai ajouté dans le README du projet, les instructions pour que tu puisses récupérer le projet en local et explorer le code et les fonctions du package dans la partie "Retrieve package and develop": https://github.com/inrae/diades.atlas

Si tu veux t'aventurer, c'est l'occasion. Par ailleurs, ça te permet d'avoir les fonctions retravaillées pour tout travaux que tu voudrais faire avec ces données.

Tu verras le code dans la page du site web et les résultats pour l'onglet 4 ici: https://inrae.github.io/diades.atlas/articles/be-page4-future.html (dans qq minutes dès qu'il aura fini de construire)

La phase suivante pour moi, c'est de commencer à implémenter tout cela dans l'app Shiny, mais il va falloir trouver une stratégie maline de stockage et affichage des données, pour ne pas attendre trop longtemps les résultats.
Je vais y réfléchir...

[PMHLambert]

j'ai commencé à m'aventurer ... en commençant par me tromper de branche. Il y a deux commit maladroits dans main :-( Je n'ai pas réussi à revenir en arrière. J'avoue ne pas avoir trop cherché de peur de faire plus de bêtises.
J'ai réussi à créer ma banche pour regarder le code. A moi l'aventure

[statnmap]

Ahlala !
Surtout, ne touches plus à rien dans main ! Si c'est envoyé sur le serveur, on ne revient plus en arrière.
Peut-être qu'on peut empêcher l'envoi sur la branche main, mais je ne suis pas administrateur, alors je ne peux pas le faire moi-même.
Et il me faudrait quand même les droits pour que je puisse envoyer dans main directement de mon côté si nécessaire
A voir avec @equinton ?

[equinton]

Bonjour, Je viens de virer le droit d'admin à Patrick, et j'ai créé une protection sur la branche main. Sébastien, peux-tu me confirmer que tu peux toujours faire un commit ? Patrick, peux-tu vérifier que tu ne peux plus faire de bétises dans main ? Merci, Éric

[PMHLambert]

je peux continuer à faire des bêtises sur main . J'en ai profité pour retirer ce que j'avais fait précédemment

[statnmap]

Traité dans #126