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 packagesSU0PHY

Physic detailed set-up

SUPHYsuphmf

suphec

suphmnh

The phys-gp computations, the drivers GP-computations driver Gp_model

surfext

cpgmf_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

AAA

AAA

AAA

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

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