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
Top Related