Module de clés namelists PHYEX Une solution serait de créer un module propre à PHYEX qui contiendrait des clés de contrôle de haut niveau pour la physique. Ce module serait initialisé dans Méso-NH à partir de clés actuellement en dehors de la physique. Dependencies: - définir les interfaces propres - créer des codes pour le driver - liste dans document Interfaces - pour AROME placés, en attendant, dans phyex/externals Clé de compilation REPRO48 + REPRO55 ajoutées pour permettre de reproduire le cycle 48 MNH-5.5.0, elles: - contournent des corrections de bug - modifient l'organisation de calculs - REPRO48 reproduit les résultats obtenus avant l'introduction de la fraction précipitante froide dans l'ajustement Utilisation des clés: | - REPRO48 seule: la version de code qui sera retenue à la fin est celle de Méso-NH 5.5 | Ecrire doc sur marche à suivre pour intégrer un nouveau développement: - REPRO55 seule: la version de code qui sera retenue à la fin est celle du cycle 48 d'AROME | - dev dans MNH à faire en array-syntax - defined(REPRO48) || defined(REPRO55): la version de code qui sera retenue à la fin est nouvelle Ces clés devront être supprimées Ecrire doc sur marche à suivre pour intégrer un nouveau développement: - dev dans MNH à faire en array-syntax - dev dans AROME à faire en boucles do - intégration dans PHYEX: en array-syntax avec directives mnh_expand - les 3 tests suivants doivent donner les mêmes résultats (au bit près) dans chacun des deux modèles: - compilation directe sans activer mnh_expand - compilation en activant mnh_expand - exécution en changeant le nombre de processeurs Merge pb: - rain_ice_red: le cas test MesoNH n'est pas bit repro (diffs > 1% sur rapports de melange) sur la modif src/mesonh/rain_ice_red au commit bdd10dd (First rain_ice new/red merge) - shallow_mf (appels dans aro_shallow et arp_shallow): Dans Méso-NH: shallow_mf doit être appelé avec PDX=XDXHAT(1) et PDY=XDYHAT(1) Dans AROME/ARP: où trouver la taille de maille? Pb identifiés à corriger plus tard: - deposition devrait être déplacée dans ice4_tendencies - avec les optimisations de Ryad, les tableaux 3D de precip passés à ice4_tendencies lorsque HSUBG_RC_RR_ACCR=='PRFR' ne sont pas utilisables puisque les K1, K2 et K3 sont relatifs à la boucle IMICRO et que les calculs faits en debut de routine ne concernent qu'une partie des points => à corriger - seules quelques options sont testées avec les cas test (par exemple, il faudrait tester RMC01 mais l'option n'est pas remontée en namelist) - les options CMF_CLOUD='STAT' et LOSIGAMS=.FALSE. semblent cassées en 48 original - arome/ini_cmfshall devrait s'appeler ini_param_mfshall - th_r_from_thl_rt appelée partout, il faudrait limiter à OTEST - la recompilation complète d'AROME n'est pas testée - il faudrait inclure un cas test plus conséquent en taille au moins sur belenos - doute sur le codage de MODD_PRECISION - appel à abort à travers print_msg non testé - lignes vides ajoutées après les macros mnh_expand - indentation inorrecte dans les blocs mnh_expand - sedimentation momentum non branchée (et à trasformer comme sedim_stat) - si possible, modifier ice4_sedimentation_split* dans le même esprit que stat Répertoire arome/ext et mesonh/ext contiennent les codes non PHYEX qu'il faut modifier dans le pack pour qu'il puisse être compilé. Ce répertoire devra être vidé à la fin du phasage, les modifications nécessaires ayadevront avoir été fournies par ailleurs Budgets/DDH - Le code dans budget_DDH devra être transféré dans mode_budget - les routines arome specifiques aux budgets sont dans mpa/micro, il faudrait les mettre dans aux - Le module modd_dyn n'est utilisé que pour les budgets, voir s'il peut être supprimé - Le code des budgets devrait être revu: pas en phase avec celui de Méso-NH et phasage a priori inutile car très peu de code semble réellement utile pour AROME SPP - modd_spp_type est pour l'instant dans mpa/micro/externals mais n'est pas de la microphysique Nettoyage apl_arome non fait (pb a la compilation) ==> 4 arguments dans aro_turb_mnh supprimés (non utilisés) turb.F90 : il reste un CALL à SOURCES_NEG_CORRECT à ajouter. Regarder s'il ne serait pas possible/souhaitable de supprimer modd_lunit de PHYEX. On pourrait se contenter de recevoir le numero d'unité logique Nettoyage des répertoires aux nécessaire Initialiser dans AROME la variable ldiag_in_run de MODD_DIAG_IN_RUN pour pouvoir phaser le modd