umr-cnrm / phyex Goto Github PK
View Code? Open in Web Editor NEWPHYsique EXternalisée
License: Other
PHYsique EXternalisée
License: Other
Is there a reason to not include the KSPLIT argument of the turbulence scheme inside the modd_turbn module? If not we must do it.
This issue lists the modifications to introduce before issuing the version 1.0 of PHYEX:
ELEP and ELECD structures from modd_elec_* have been introduced into PHYEX (in rain_ice and lima) to apply sedimentation of electric charges with respect to the microphysics scheme.
In mode_elec_tendencies, there is still some USE MODD of variables from LIMA and ELEC routines to be included in a structure.
For ELECP and ELECD, there are a lot of missing variables included in the structure already created...to be continued.
The full electricity scheme could be included further in PHYEX.
For now, it must be excluded from the GPU transformations applied for IAL.
On a small 3D case with AROME (small_2D_alt9), the results given by rain_ice_old are different between commits 37885e5 and 6e28495.
It could be due to the merging of branch 'rain_ice_old' of https://github.com/rolfhm/PHYEX or due to the branch itself.
Investigation and/or bug correction needed.
The deposition process must be moved in ice4_tendencies
On branch demo-dwarf, commits :
6f801ec
ef6b29a
c6e9033
transforms by hand COUNT() and ANY() in the case of the argument is a scalar.
(on master branch, CPU, arguments are arrays)
For a better way of handling both cases (array or scalar), one must code a version of ANY() and COUNT() that
By extending the intrinsic functions (possible ? which version of FORTRAN ?) or re-write new home-made function
Include performance metrics (DrHook, total execution time, analyse of the compilation logs for checking vectorisation).
Test on other architectures (NEC?)
With the inclusion of LIMA in PHYEX, minpack.f90 is introduced (726e04c). This routine is attached with a LICENCE in MesoNH pack
LICENCE.txt
. Is this LICENCE compatible with PHYEX's and how to distribute minpack within PHYEX folder ? (in micro ?)
The option LPACK_MICRO=FALSE doesn't work in Meso-NH
At the integration of changes from mesonh 5.6->5.7 a new process changes the some mixing ratio in turb.F90, so budgets are added around turb_ver such as :
IF( BUCONF%LBUDGET_RR ) CALL BUDGET_STORE_INIT_PHY(D, TBUDGETS(NBUDGET_RR), 'VTURB', PRRS (:,:, 3) )
IF( BUCONF%LBUDGET_RS ) CALL BUDGET_STORE_INIT_PHY(D, TBUDGETS(NBUDGET_RS), 'VTURB', PRRS (:,:, 5) )
IF( BUCONF%LBUDGET_RG ) CALL BUDGET_STORE_INIT_PHY(D, TBUDGETS(NBUDGET_RG), 'VTURB', PRRS (:,:, 6) )
IF( BUCONF%LBUDGET_RH .AND. KRR==7 ) CALL BUDGET_STORE_INIT_PHY(D, TBUDGETS(NBUDGET_RH), 'VTURB', PRRS (:,:, 7) )
and call budget_store_end_phy.
(Budgets on ri, PRRS(:,:,4) was already present).
At the call of BUDGET_STORE_INIT_PHY, the default test case of arome raise at first timestep the error on call of budget of RS
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
[EC_DRHOOK:sxphynh:4:1:26619:26619] [20231222:115855:2.594] [LinuxTraceBack] [03]: MASTER() [0x136de72] : __mode_budget_phy_MOD_budget_ddh() at mode_budget_phy.F90:173
[EC_DRHOOK:sxphynh:4:1:26619:26619] [20231222:115855:2.594] [LinuxTraceBack] [04]: MASTER() [0x136ee10] : __mode_budget_phy_MOD_budget_store_end() at mode_budget_phy.F90:30 (discriminator 4)
[EC_DRHOOK:sxphynh:4:1:26619:26619] [20231222:115855:2.594] [LinuxTraceBack] [05]: MASTER() [0x136eef6] : mode_budget_phy_MOD_budget_store_end_phy() at mode_budget_phy.F90:39
[EC_DRHOOK:sxphynh:4:1:26619:26619] [20231222:115855:2.594] [LinuxTraceBack] [06]: MASTER() [0x150cac7] : turb() at turb.F90:1131 (discriminator 1)
[EC_DRHOOK:sxphynh:4:1:26619:26619] [20231222:115855:2.594] [LinuxTraceBack] [07]: MASTER() [0x121f49e] : aro_turb_mnh() at aro_turb_mnh.F90:389
In mesonh and testprogs, there is no problem.
If the new budgets of RS is commented, the error triggs on the call of budget or RG.
The call budget on RR is fine.
The problem does not come from the changes in mesonh 5.6 : I tried in the master branch of PHYEX at commit 7c3b2cb (20/12, before merging changes from mesonh) to add the call of BUDGET_STORE_INIT_PHY in turb : the error is the same.
On 7c3b2cb, I tried :
It looks like a problem of the shape of PRRS at entering of turb. I checked apl_arome and aro_turb_mnh without sucess.
Workaround : in commit 32e554f , I controled the call BUDGET_STORE_INIT/END_PHY on r_s and the others impacted new mxing ratios by the namelist key LTURB_PRECIP (False by default in AROME) that` is responsible of the changes (and the budget term).
But using LTURB_PRECIP in AROME would then not work for now
Results are different for test case small_3D_alt10
Issue found by Ph. Marguinaud in mode_mf_turb (line 198):
CALL TRIDIAG_MASSFLUX(D,PTHLM,PFLXZTHMF,-PEMF,PTSTEP,PIMPL,...
The "-PEMF" part should be replaced by a temporary variable.
The same kind of array syntax in call statements exist in other places. They must be suppressed.
The EDKF shallow convection scheme already computes a thermal production term of TKE but no dynamical one. This term must be added.
These modifications have not been introduced in the AROME version as they break the bit-reproducibility and, thus, need a more complex validation.
There are two solutions:
Control to implement: when lred=F, lsnow must be F
Be careful, in arome, to keep consistency with ini_snow (easier if code is rewritten to enable bit-reproducibility)
At the beginning, it wasn't possible to use the official versions of AROME and Meso-NH to plug PHYEX because of the too many differences in the source code and in particular the changes in the source directory organisation.
Starting from cy49t1 for arome and v5.7 for Meso-NH, we could:
This evolution needs some modifications in the check_commit_ial.sh and check_commit_mesonh.sh scripts and allows the suppression of the 'pack' subdirectory in the PHYEX repository. Documentation must also be updated.
Moreover, a limited set of testprogs data could be made available on a web page to ease the use of these test programs.
A small install script could be written to install filepp, mnh_expand and the testprogs data.
Is it possible to merge the arome and mesonh versions of rain_ice_old?
This key must be replaced by some namelist individual keys
It seems that ini_snow code is very similar to in_rain_ice and could be replaced by a control switch in in_rain_ice to limit code duplication.
Running the testprogs, the results for turb are different depending on the --noexpand option
In mode_ice4_pack, we can compute the microphysics on a selection of points by packing them in new arrays before calling ice4_stepping (LPACK_MICRO=T) or call directly ice4_stepping on all the points (LPACK_MICRO=F).
With the packing, we can activate the NPROMICRO mechanism; but this mechanism is not available without the packing.
This issue describes how to implement NPROMICRO without packing:
The code should give the same results whether the zeros are signed or not. Is it the case?
In mode_ice4_pack, we can compute the microphysics on a selection of points by packing them in new arrays before calling ice4_stepping (LPACK_MICRO=T) or call directly ice4_stepping on all the points (LPACK_MICRO=F).
On NEC, it could be more efficient to use indirection.
This issue describes how to implement an indirection mechanism in the LPACK_MICRO=.F. case. But this way of implementing it was not fully validated by Ryad.
Would it be possible to move the modd_turb_cloud keys into modd_turbn?
This would allow a better flexibility (activation of cloud mixing length modification in several models) and the suppression of the KMI argument of turb.
In Meso-NH, arrays are overdimensioned along the vertical axis.
In AROME, we can use "normal" arrays for all parametrisation except the turbulence one.
This issue list the steps to realise in order to suppress the unphysical points for AROME:
Energy is not conserved in:
The rain fraction diagnostic must be computed before calling ice4_tendencies in order to suppress all the 3D arrays in ice4_tendencies.
This modification will induce an approximation that should be acceptable.
XTKEMIN seems to be incremented at each time step (tested in LMDZ)
Several cleanings are needed:
Replace the do concurrent in rain_ice by a do with the "$DIR$ IVDEP" directive
Since the introduction of the rain_ice_old testprog, the initialisation of the PHYEX parametrisations has evolved.
The rain_ice_old testprog should be modified to use the new setup mechanism
When vertical resolution increases near the surface, the scheme closure happens too near the surface and can lead to an overestimated transport.
The idea of Valery is to modify the closure mechanism to take into account the environment variables values higher and start the updraft at a given height above ground (maybe around 20m). The difficulty is to impose updraft characteristics under this point to allow the mixing on the whole column and not only starting from the 20m level.
A tesprog (and code to generate data) must be written for the LIMA scheme.
The third moments in turb is not used in Méso-NH, AROME-FR, HARMONIE-AROME, AROME and ALARO from Austria, Hungary and Poland (mail from [email protected]).
ALARO-CMC use their own TOM options called under the key LCOEFK_TOMS=.T. (NAMPHY) and fully coded in acdifv3.F90
Cleaning of this option will help a lot for GPU porting
Is it possible to merge the mesonh and arome version of the shallow part of KFB
Fleur C. :
Durant son stage, Aude avait soulevé un bug dans la limitation de l'updraft dans EDKF qui dès que l'updraft dépasse une certaine hauteur tout l'updraft est coupé alors que l'idée initiale (cf les commentaires) était plutot de faire progressivement diminuer le flux de masse.
Actuellement si le nuage dépasse la hauteur max des nuages bas, alors le flux de masse est nul pour toute la colonne.
Work as done in MesoNH 5.5.1. Must :
MODD_CONF might be suppressed from PHYEX:
At line 559 of file /home/riette/TESTPROGS/COMMITe070d16/build/with_fcm/arch_mesonh-LXgfortran/src/rain_ice_old/getdata_rain_ice_old_mod.F90
Fortran runtime error: Index '16' of dimension 2 of array 'p_in' above upper bound of 15
Error termination. Backtrace:
#0 0x7fca6753bad0 in ???
#1 0x7fca6753c649 in ???
#2 0x7fca6753cc46 in ???
#3 0x55af1011a112 in __getdata_rain_ice_old_mod_MOD_npromize3
at /home/riette/TESTPROGS/COMMITe070d16/build/with_fcm/arch_mesonh-LXgfortran/src/rain_ice_old/getdata_rain_ice_old_mod.F90:559
#4 0x55af1012e656 in __getdata_rain_ice_old_mod_MOD_getdata_rain_ice_old
at /home/riette/TESTPROGS/COMMITe070d16/build/with_fcm/arch_mesonh-LXgfortran/src/rain_ice_old/getdata_rain_ice_old_mod.F90:415
#5 0x55af0fe4cef2 in main_rain_ice_old
at /home/riette/TESTPROGS/COMMITe070d16/build/with_fcm/arch_mesonh-LXgfortran/src/rain_ice_old/main_rain_ice_old.F90:357
#6 0x55af0fe5e515 in main
at /home/riette/TESTPROGS/COMMITe070d16/build/with_fcm/arch_mesonh-LXgfortran/src/rain_ice_old/main_rain_ice_old.F90:3
Rewrite/reorganise the present tools to have:
The small scripts needed to control the results (comp_DDH.py, compare.py, diffNODE.001_01) may be, or not, in-lined in the different check_commit_* scripts
Presently the testing.sh script uses commit comments to store and display the result of the integration tests.
Statuses are a a better feature to display the result of the integration tests but cannot be used to display result details. Details must be stored elsewhere and a web link can be added to the statuses.
We must found a public place to store these details and modify the testing.sh script to use statuses.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.