How the different (arpege/aladin/alaro/arome) physical packages are co- existing Short introduction to the 3 subsequent presentations Gwenaëlle Hello, Météo-France

Some generalities Main part of the code is common Setup (90%) Dynamics (100 %) Data-flow structures (90-100%) Dyn-phys interface (between 20 to 100 % case dependant) Physic computations (between 0 to 100 % case dependant) The diversity allowed in the setup is active in the gridpoint computations

The setup Level 0 « CNT0 » su0yomA su0yomB On/off Control high-level keys of the different packages SU0PHY Physic detailed set-up SUPHY suphmf suphec suphmnh

The phys-gp computations, the drivers GP-computations driver Gp_model surfext cpg mf_phys cpg_pt cpg_dia Arome Valid for Arome Arpege Aladin Alaro Arpege Aladin Alaro

The current interface routine mf_phys: the different physical packages are called by bloc mf_phys aplpar cptend : Flux  tendencies « n »-call to cputqy : time evolution apl_arome « n »-calls to cputqy_arome Arome Arpege Aladin Alaro AAAAAA AAAAAA AAAAAA A A The diversity is inside

The data-flow: the carriages are the same but the passengers not as well as the road followed gmv/gfl Gmvt1/gflt1, Sl buf aplpar cptend cputqy Apl_arome cputqy_arome Flux tends Arome Arpege Aladin Alaro

Concluding remarks Until now, the co-existence of the different physical packages was with few difficulties to handle From « dynamic side » physics is seen as a package so phys-dyn interaction is limited As a consequence few degrees of freedom are allowed (seq or //, bef or after dyn, gridpoint or origin ?) The physical packages are either quasi the same (arp-ald), either with no intersection (arp-aro) These last 3 points are less and less true 3D & resolved physics will make the phys-dyn interaction more complex Then we will add more degrees of freedom We are also going to add more and more physics that we will also want to possibly mix