Fix for a gfortran specific byg. In the following expression:
nam = [(TRIM(name(i))//TRIM(int2str(nsrf,2)), i=1, SIZE(name))]
where nam(:) is an ALLOCATABLE string, the gfortran compiled executable crashes, but should not:
"Fortran runtime error: Index '0' of dimension 1 of array 'name' below lower bound of 1"
4 lines of code changed in 2 files:
* remove "config_inca" variable from "control_mod" and "infotrac_phy" (read in infotrac)
* only kept version of "type_trac" is in tracinca ; few tests are moved from infotrac to this module.
* simplify and generalize a bit the routines "phyetat0_get" and "phyetat0_srf" from phyetat0, converted to a module.
* fix the isotopic version: few "USE … » were misplaced between ISOVERIF CPP keys
* fix the old water and derived isotopes names in the ISOTRAC case
1712 lines of code changed in 17 files:
Tidying code & grilles_gcm.nc.
In grilles_gcm.nc :
- some variable arguments are corrected/clarified ;
- grille_u and grille_v are filled (instead of "NaN") with "checkerboard" values, same as grille_s.
122 lines of code changed in 1 file:
Bug fix: out_dim(2) instead of out_dim(3).
And a nice story:
The bug was there from "immemorial" times, older than the "Initial revision" on svn, 19 mai 2004 : LMDZ4/trunk/libf/dyn3d/grilles_gcm_netcdf.F@524).
It only started to act in rev4253, when replacing nf_def_var by nf90_def_var:
with the original "out_dim(3)", the 2D variables got a supplementary dimension "lonu" with NaN values, making grilles_gcm.nc impossible to open with cdo and ferret. But some regridding scripts using NCO and lat*&lon* variables could probably still work.
So the bug remained undetected until trying to use grille_s to regrid ERA 10m-winds for SPLA ("dust" module).
L. Fairhead (lfairhead) helped with the "bug hunt" and L. Guez (lguez) independently got the same solution.
1 lines of code changed in 1 file:
Hexadecimal constant Z"3FFFFFFF" can appear in a "data" statement but not in a "parameter" statement
0 lines of code changed in 2 files:
Hexadecimal constant Z"3FFFFFFF" can appear in a "data" statement but not in a "parameter" statement
3 lines of code changed in 1 file:
option pour conditionner l'activation des params SSO a un critere
sur la "planitude" de la maille afin de ne pas freiner de facon irrealiste
les vents sur les calottes
Travail de Valentin Wiener
27 lines of code changed in 3 files:
legeres modifis suite a l'atelier sur les downdrafts
6 lines of code changed in 2 files:
Details pour la fonctionalie Replay
41 lines of code changed in 3 files:
Fix in strinngs_mod + few more comments in this module.
88 lines of code changed in 1 file:
Fix for the backward compatibility with "traceur.def" description files (former format).
91 lines of code changed in 2 files:
Fix the traceur.def backward compatibility issue.
2 lines of code changed in 1 file:
Bug correction for generation computation.
1 lines of code changed in 1 file:
Remove "-qopenmp-threadprivate=compat" which causes crashes in OpenMP on Spirit (the MESOIPSL cluster).
EM
1 lines of code changed in 1 file:
* rewrite few routines from "readTracFiles_mod" to avoid crashes with gfortran, in particular "setGeneration" and "addKey".
* make "addKey" routine public and replace "addKey_m" and "addKey_mm" with callings to "addKey_1" in loops to avoid a gfortran-specific crash
* rewrite the "getKey" functions family so that when "tname" is not specified, result is as expected, even for tracers lists with repeated tracers (use index instead of name search).
240 lines of code changed in 2 files:
Missing modifications in the previous commit.
4 lines of code changed in 1 file:
Modification to solve a gfortran specific bug ; this compiler wrongly claims:
Error: Ambiguous interfaces in generic interface 'fgetkey' for ‘fgetkeynam_s1’ at (1) and ‘fgetkey_sm’ at (2)
But they are not:
* FUNCTION fgetKeyNam_s1(tname, keyn, ky[, def_val, lerr]) RESULT(val) with val being a scalar string
* FUNCTION fgetKeym ( keyn, ky[, def_val, lerr]) RESULT(val) with val being a vector string
So no way to have a single generic interface => gGetKey_sm is renamed fGetKeys.
4 lines of code changed in 1 file:
* simplify the parser usage:
- the getKey_init routine is now embedded in the readTracersFile routine.
- the initIsotopes routine is now embedded in the readIsotopesFile routine.
- the database is now unique, but can be changed using the get/setKeysDBase.
- the derived types descriptions, originally located in trac_types_mod, are moved to readTracFiles_mod.
- few checkings moved from infotrac to the routine testIsotopes, contained in the readIsotopesFile function from readTracFiles_mod.
- the readTracersFiles and readIsotopesFile routines no longer use a tracers/isotopes argument.
* remove tnat and alpha_ideal from infotrac ; use instead getKey to get them where they are used (check_isotopes, dynetat0, iniacademic)
* the trac_type field %Childs is renamed %Children
* move the isoSelect routine and the corresponding variables routine from infotrac and infotrac_phy to readTracFiles_mod
* infotrac_phy routine is now fully independant of the (very similar) routine infotrac (init_infotrac_phy has no arguments left).
* all the explicit keys of the trac_type are now included in the embedded keys database, accessible using the getKey function.
* the getKey/addKey routines are expanded to handle vectors of integers, reals, logicals or strings.
* few subroutines converted into functions with error return value.
* corrections for isotopic tagging tracers mode (to be continued).
1721 lines of code changed in 27 files:
corrected call to bcast in get_in from isotopes_mod.F90
24 lines of code changed in 1 file: