getin_p does not work with MESOSCALE GENERIC

[aslmd]

Maxence: "inifis_mod.F est appellé dans phys/iniphysiq_mod.F mais il y a un soucis avec ioipsl, pour que ca marche j'ai remplacé geint_p par getin dans toute la physique et le callphys est lu."

Ehouarn: "getin_p n'est qu'une surcouche qui fait appel à getin et partage le résultat sur tous les procs. Donc c'est probablement que le partage d'information entre procs n'est pas correctement en place dans le couplage avec WRF.
C'est peut-être simplement une initialization des communications MPI qui manque...
Avec DYNAMICO/LMDZ ces initialisations sont faites via l'enchaînement des appels:

dynphy_lonlat/phy***/iniphysiq_mod.F90:  CALL inigeomphy()
=> dynphy_lonlat/inigeomphy_mod.F90: CALL init_physics_distribution()
==> phy_common/physics_distribution_mod.F90: CALL init_phys_lmdz_para()

C'est ce init_phys_lmdz_para() qui met en place l'environnement MPI (et OpenMP) ; peut-être qu'il manque juste cet appel dans l'interface

WRF/phy***

?

En fait des paramètres (tous intent(in) ) de init_phys_lmdz_para(nbp,nbp_lon,nbp_lat,communicator) les trois premiers ne t'intéressent pas particulièrement (vu qu'il n'y a pas de sorties ou besoin de connaitre la structure des tuiles MPI dans la physique), il n'y a que le communicateur qu'il faut correctement initialiser, idéalement en transmettant celui de WRF.
A moins qu'ils aient fait un truc très particulier dans WRF, je parierai que le communicateur est simplement "MPI_COMM_WORLD" (variable de la librairie MPI consacrée).
le getin_p est "bien" écrit. Il repose par contre sur le fait que l'environnement MPI/OpenMP a bien été mis en place. "

[aslmd]

This has been fixed by r2267