CDXWRF

De Wikicima
(Diferencias entre revisiones)
Saltar a: navegación, buscar
(→‎Optimization)
 
(No se muestran 17 ediciones intermedias realizadas por un usuario)
Línea 1: Línea 1:
−
CORDEX requirements of data for stake holders and decision making community, push the output of the atmospheric models, which demands that usually require time consuming post-process of the standard model output. In order to avoid this time and effort consuming post-processing task, here is presented the implementation of a new module into the Weather and Forecasting Model ([http://www.mmm.ucar.edu/wrf/users/ WRF], Skamarok et al. 2008) module called <CODE>module_diag_cordex</CODE> with which is expected to substantially limit the need of post-processing.
 +
The `Coordinated Regional Climate Downscaling Experiment' ([http://www.cordex.org/ CORDEX]) is a scientific effort of the World Climate Research Program (WRCP) for the coordination of regional climate initiatives. In order to accept an experiment, CORDEX provides experiment guidelines, specifications of regional domains and data access/archiving. Data requirements are intended to cover all the possible needs of stake holders, and scientists working on climate change mitigation and adaptation policies in various scientific communities. The required data and diagnostics are grouped into different levels of frequency (sub-daily, daily, monthly and seasonal), priority (Core, Tier1, Tier2), and some of them even have to be provided as statistics (minimum, maximum, mean). Here is presented the development of a specialized module called <CODE>module_diag_cordex</CODE> (version 1.3) for the Weather Research and Forecasting (([http://www.mmm.ucar.edu/wrf/users/ WRF], Skamarok et al. 2008)) model, capable of outputting the required CORDEX variables. Additional diagnostic variables not required by CORDEX, but of potential interest to the regional climate modeling community, are also included in the module. `Generic' definitions of variables are adopted in order to overcome model and/or physics parameterization dependence of certain diagnostics and variables, thus facilitating a robust comparison among simulations. The module is computationally optimized, and the output is divided in different priority levels following CORDEX specifications (Core, Tier1, and additional) by selecting pre-compilation flags. This implementation of the module does not add a significant extra cost when running the model, for example the addition of the Core variables slows the model time-step by less than a 5%. The use of the module reduces the requirements of disk storage by about a 50%.
   
−
PDF version of this page here [[Media:module_CORDEX_WRF.pdf]]
 +
An article is available in `Geosciences Model Development' journal:
   
−
In order to get the code send an email to : lluis.fita [a] cima.fcen.uba.ar in order to keep a track and being able to inform of new versions/corrections.
 +
Lluís Fita, Jan Polcher, Theodore M. Giannaros, Torge Lorenz, Josipa Milovac, Giannis Sofiadis, Eleni Katragkou and Sophie Bastin, 2019: <I>CORDEX-WRF v1.3: development of a module for the Weather Research and Forecasting (WRF) model to support the CORDEX community</I>, Geosci. Model Dev., '''12''', 1029-1066, 2019, [https://www.geosci-model-dev.net/12/1029/2019/gmd-12-1029-2019.html https://doi.org/10.5194/gmd-12-1029-2019]
  +
  +
It is recommend to contact Lluís Fita (lluis.fita [a] cima.fcen.uba.ar) in order to keep a track and being able to inform of new versions/corrections.
   
 
'''Disclaimer'''
  
'''Disclaimer'''
Línea 12: Línea 12:
 
</PRE>
  
</PRE>
   
−
There are three working versions of the code for WRFV3.7.1, WRFV3.8.1 and WRFV3.9.1.1. Different tests seem to show that the module slows model performance by a 40% (depending on namelist, compilation, ...)
 +
There are four working versions of the code for WRFV3.7.1, WRFV3.8.1, WRFV3.9.1.1, WRFV4.0. :
  +
* WRF-CORDEX module version 1.3 for WRFV3.7.1, L. Fita, [https://doi.org/10.5281/zenodo.1469639 DOI:zenodo.1469639]
  +
* WRF-CORDEX module version 1.3 for WRFV3.8.1, L. Fita, [https://doi.org/10.5281/zenodo.1469645 DOI:zenodo.1469645]
  +
* WRF-CORDEX module version 1.3 for WRFV3.9.1.1, L. Fita, [https://doi.org/10.5281/zenodo.1469647 DOI:zenodo.1469647]
  +
* WRF-CORDEX module version 1.3 for WRFV4.0, L. Fita, [https://doi.org/10.5281/zenodo.1469651 DOI:zenodo.1469651]
  +
  +
'''GIT repository'''
  +
  +
Recently all the code was uploaded to a GIT server. All new developments / updates / new WRF versions, will carried out only the GIT version of the codes. Please visit:
  +
  +
[https://git.cima.fcen.uba.ar/lluis.fita/cdxwrf/-/wikis/home https://git.cima.fcen.uba.ar/lluis.fita/cdxwrf/-/wikis/home]
  +
  +
  +
Although a pull of the WRF source code has been made and the module is currently being direclty added to the official source of the code of the model, and its final inclusion will be done by decission of the development team of the model.
   
 
Be aware that certain surface variables and their statistics (clWRF, Fita et al 2010) are retrieved from namelist configuration (from [http://www2.mmm.ucar.edu/wrf/users/docs/user_guide_V3/users_guide_chap5.htm#_Description_of_Namelist WRF users web page])
  
Be aware that certain surface variables and their statistics (clWRF, Fita et al 2010) are retrieved from namelist configuration (from [http://www2.mmm.ucar.edu/wrf/users/docs/user_guide_V3/users_guide_chap5.htm#_Description_of_Namelist WRF users web page])
Línea 29: Línea 29:
 
In this page [[CDXWRFevolution]] one founds updates, bug fixes of the module.
  
In this page [[CDXWRFevolution]] one founds updates, bug fixes of the module.
   
−
With this module, now all CORDEX variables are available with the files wrfxtrm, wrfpress and wrfcdx, except for the fied values such as 'areacella'. See [[CDXvariablestable]] for more detail
 +
With this module, now all CORDEX variables (except `snow melt') are available with the files wrfxtrm, wrfpress and wrfcdx, except for the fied values such as 'areacella'. See [[CDXvariablestable]] for more detail
   
 
= CORDEX requirements =
  
= CORDEX requirements =
Línea 37: Línea 37:
 
Some of the variables are not directly computed in the WRF model which require to extend the model output in order to provide enough variables to post-process the variables.
  
Some of the variables are not directly computed in the WRF model which require to extend the model output in order to provide enough variables to post-process the variables.
   
−
The implementation of the module_diag_cordex module should allow to avoid the post-processing by computing
 +
The implementation of the <CODE>module_diag_cordex</CODE> module should allow to avoid the post-processing by computing the CORDEX-required (Core & Tier) variables during model integration. At the same time, some extra variables, which might be of interest to the community but not required by CORDEX, have also been added.
−
the CORDEX-required (Core & Tier) variables during model integration. At the same time, some extra variables, which might be of interest to the community but not required by CORDEX, have also been added.
  
   
 
'''NOTE: '''
  
'''NOTE: '''
Línea 52: Línea 52:
 
* <CODE>phys/module_diagvar_cordex.F</CODE>: Module with the computation of all the variables
  
* <CODE>phys/module_diagvar_cordex.F</CODE>: Module with the computation of all the variables
 
This module is accompanied with a new <CODE>Registry/registry.cordex</CODE> where the variables and a new section
  
This module is accompanied with a new <CODE>Registry/registry.cordex</CODE> where the variables and a new section
−
in the <CODE>namelist.inpt</CODE> labeled cordex are defined. There are other necessary complementary modifications on
 +
in the <CODE>namelist.input</CODE> labeled cordex are defined. There are other necessary complementary modifications on
 
<CODE>phys/module_diagnostics_driver.F</CODE> encompassed by the pre-compilaton flag <CODE>CORDEXDIAG</CODE>, as well some modifications in the <CODE>main/depend.common</CODE> and <CODE>phys/Makefile</CODE>.
  
<CODE>phys/module_diagnostics_driver.F</CODE> encompassed by the pre-compilaton flag <CODE>CORDEXDIAG</CODE>, as well some modifications in the <CODE>main/depend.common</CODE> and <CODE>phys/Makefile</CODE>.
 
Output is provided by the auxiliary history output <CODE>#9</CODE> with a provisional file name: <CODE>wrfcordex_d<domain>_<date></CODE>
  
Output is provided by the auxiliary history output <CODE>#9</CODE> with a provisional file name: <CODE>wrfcordex_d<domain>_<date></CODE>
 
All that variables which are only required at output time step, are computed only at that exact time.
  
All that variables which are only required at output time step, are computed only at that exact time.
   
−
== Additional: pressure levels interpolation ==
 +
Description of the installation process can be found here [[CDXWRFinstall]]
   
−
At the same time, WRF can output on pressure levels while integration. However, initial version of the module does
 +
Description of the usage of the model can be found here [[CDXWRFuse]]
−
not include certain required CORDEX variables. The following ones have also been added to the code of the model and now they are also available:
 
−
* <CODE>wa</CODE> vertical wind speed [ms-1]
  
−
* <CODE>hus</CODE> specific humidity [1]
  
−
* <CODE>uer</CODE> Earth rotated x-compoment [ms-1]
  
−
* <CODE>ver</CODE> Earth rotated y-compoment [ms-1]
  
−
* <CODE>ws</CODE> wind speed [ms-1]
  
   
−
It has been accomplished after modifying the codes: <CODE>Registry/registry.diags</CODE>, <CODE>phys/module_diagnostics_driver.F</CODE>, <CODE>phys/module_diag_pld.F</CODE> and <CODE>dyn_em/start_em.F</CODE>. The three latest modifications are also encapsulated within precompilation flag <CODE>CORDEXDIAG</CODE>.
 +
Description of the additional pressure level interpolation variables can be found here [[CDXWRFpvars]]
   
−
See more details in how to activate this option in [http://www2.mmm.ucar.edu/wrf/users/docs/user_guide_V3/users_guide_chap5.htm#_Description_of_Namelist WRF_users] web-page over the namelist section <CODE>diags&</CODE>.
 +
Description of the `Core' variables can be found here [[CDXWRFcore]]
   
−
== Additional: water budget ==
 +
Description of the `Tier1' variables can be found here [[CDXWRFtier]]
−
It has been added also the components of the atmospheric water budget. They are accumulated internally and vertically
  
−
integrated allover the column. In order to provide this capability, a series of modifications have been introduced in
  
−
<CODE>dyn_em/solve_em.F</CODE>
  
   
−
= Installation =
 +
Description of the `Additional' variables can be found here [[CDXWRFadditional]]
   
−
These steps must be followed prior the re-compilation of the WRF model and assuming that the process is started where the code resides (WRFV3). '''NOTE:''' make sure that the already compiled version of WRF and the version of the module are the same!
 +
Description of the studies about optimization of the module can be found here [[CDXWRFopt]]
−  
−
# Untar the file
  
−
<PRE>
  
−
$ tar xvfz WRFV[VERSION]_CORDEX.tar.gz
  
−
</PRE>
  
−
# It deflates all the required files and the modified orignal WRF files
  
−
<PRE>
  
−
main/depend.common
  
−
dyn_em/solve_em.F
  
−
dyn_em/start_em.F
  
−
phys/module_diagnostics_driver.F
  
−
phys/module_diag_cordex.F
  
−
phys/module_diagvar_cordex.F
  
−
phys/module_diag_pld.F
  
−
phys/Makefile
  
−
README.cordex
  
−
Registry/registry.cordex
  
−
Registry/registry.diags
  
−
</PRE>
  
−
# On the <CODE>Registry/Registry.EM</CODE> add the following line (after the last line with include <CODE>registry.bdy_perturb</CODE> (on WRFV3.7.1, WRFV3.8.1), <CODE>registry.new3d_wif</CODE> (on WRFV3.9.1.1))
  
−
<PRE>
  
−
include registry.cordex
  
−
</PRE>
  
−
# Clean the code (in order to avoid to run again configure one can make a copy of the <CODE>configure.wrf</CODE> and recover it after the clean, otherwise it is erased)
  
−
<PRE>
  
−
$ cp configure.wrf configure.cordex.wrf
  
−
$ ./clean -a
  
−
$ cp configure.cordex.wrf configure.wrf
  
−
</PRE>
  
−
# edit the <CODE>`configure.wrf'</CODE> and add the line (after the line <CODE>-DNETCDF</CODE> and/or <CODE>–DCLWRFGHG</CODE>)
  
−
<PRE>
  
−
-DCORDEXDIAG
  
−
</PRE>
  
−
# Set up (or not) the pre-compilation variable CDXWRF (after the line -DCORDEXDIAG)
  
−
<PRE>
  
−
-DCDXWRF=[value] \
  
−
</PRE>
  
−
** Accordingly to the value given to the pre-compilation variable <code>CDXWRF</code> one obtains:
  
−
*** Without adding the variable: all CORDEX 'Core' variables
  
−
*** CORDEX 'Tier1' variables: clivg, clivh, zmla, [cape/cin/zlfc/plfc/lidx]{min/max/mean}
  
−
<PRE>
  
−
-DCDXWRF=1 \
  
−
</PRE>
  
−
*** The same as with <code>CDXWRF=1</code> and additional variables: ua, va, ws, ta, press, zg, hur, hus, tfog, fogvisbltymin, fogvisbltymax, fogvisbltymean, tdsmin, tdsmax, tdsmean and the Water-Budget relarted ones: wbacdiabh, wbacpw, wbacpw[c/r/s/i/g/h], wbacf, wbacf[c/r/s/i/g/h], wbacz, wbacz[c/r/s/i/g/h], wbacdiabh{l/m/h}, wbacpw{l/m/h}, wbacpw[c/r/s/i/g/h]{l/m/h}, wbacf{l/m/h}, wbacf[c/r/s/i/g/h]{l/m/h}, wbacz{l/m/h}, wbacz[c/r/s/i/g/h]{l/m/h}
  
−
<PRE>
  
−
-DCDXWRF=2 \
  
−
</PRE>
  
−
* Simultanesouly, one needs to modify the <code>Registry/registry.cordex</code> accordingly to the value of <code>CDXWRF</code>:
  
−
*** Without adding <code>CDXWRF</code>, nothing needs to be changed
  
−
*** Adding <code>CDXWRF=1</code>, one needs to remove the comment <code>##CDXWRF1##</code> at the beginning of the line of the definition of certain variables
  
−
*** Adding <code>CDXWRF=2</code>, one needs to remove the comment <code>##CDXWRF1##</code> and <code>##CDXWRF2##</code> at the beginning of the line of the definition of certain variables
  
−  
−
# Additionally, one can also get the instantaneous values for the variables which only certain statistics (accumulation, minimum, mean, ...) are provided. In order to get them, one need to:
  
−
## Search in <code>phys/module_diagnostics_driver.F</code> and <code>phys/module_diag_cordex.F</code> the lines of code marked with <code>'INSTVALS'</code> and change accordingly.
 
−
## Modify <code>Registry/registry.cordex</code> accordingly (removing <code>##INST##</code> at the beginning of the line of the definition of certain variables, and adding <code>'h9'</code> to certain others)
  
−  
−
# compile as always
  
−
<PRE>
  
−
$ ./compile em_real >& compile.log
  
−
</PRE>
  
−  
−
= Usage =
  
−
These are the steps to use the module
  
−
# One need to add to the <CODE>'namelist.input'</CODE> the auxiliar output number 9 (e.g. for output every 3 hours and 1-day files) at the <CODE>`&history'</CODE> section:
  
−
<PRE>
  
−
auxhist9_outname = "wrfcdx_d<domain>_<date>"
  
−
auxhist9_interval = 180, 180,
  
−
frames_per_auxhist9 = 8, 8,
  
−
io_form_auxhist9 = 2
  
−
</PRE>
  
−
# Also a new section should be added (assuming it will get complex and different implementations of the diagnostics might be necessary...) '''NOTE:''' do not copy directly this text. Fortran do not understand ':' as namelist input.
  
−
<PRE>
  
−
&cordex
  
−
output_cordex = 1
  
−
psl_diag = 1: sea-level pressure diagnostic following hydrostatic Shuell correction
  
−
= 2: psl diagnostic following a target pressure
  
−
= 3: psl diagnostic following ECMWF method (default)
  
−
psmooth = 5: passes of neighborgh filtering (3x3-grid point mean) of psfc for psl_diag=2
 
−
(default 5)
  
−
ptarget = 70000.: pressure [Pa] target to be used by psl_diag=2 (default 70000.)
  
−
wsgs_diag = 1: wind-gust diagnostic following Brasseur, 2001, MWR (default)
  
−
= 2: wsgs folllowing heavy precipitation method
  
−
output_wb = 1: whether water-budget variables have to computed (1) or not (0, default)
  
−
wsz100_diag = 1: wind extraoplation at z100m_wind using power-law method (default)
  
−
= 2: wind extraoplation at z100m_wind using logarithmic method
  
−
= 3: wind extraoplation at z100m_wind using Monin-Obukhov theory (NOT activated)
  
−
z100m_wind = 100.: height to extraplate winds (100. default)
  
−
zmlagen_dqv = 0.1: percentage of variation of mixing ratio to determine mixed layer depth used in
 
−
zmla computation (0.1 default)
  
−
zmlagen_dtheta = 1.5: increment in K of potantial temperature from its minimum within the MLD used in
 
−
zmla computation (1.5 default)
  
−
potevp_diag = 1: potential evapotranspiration following Penman-Monteith formulation after ORCHIDEE
 
−
implementation
  
−
convxtrm_diag = 0: diagnostic of extremes from convection indices: 0: No (default); 1: yes
  
−
fogvisibility_diag = 1: diagnostic of visibility inside fog following Kunkel (1984)
  
−
= 2: RUC method (Smirnova et al., 2000)
  
−
= 3: FRAML 50% prob Gultepe and Milbrandt, (2010) (default)
  
−
fogvars = 1: variables to use to diagnose fog using 3D [hur] (default)
  
−
= 2: sfc [hus] (not available for Kunkel, 1984)
  
−
/
  
−
</PRE>
  
−  
−
== Pressure interpolation ==
  
−
Remember to activate section <CODE>&diags</CODE> in order to get pressure-level vertical interpolation of state variables (g.e.: assuming 6 levels only and output every 3 hours)
  
−
<PRE>
  
−
&time_control
  
−
(...)
  
−
auxhist23_outname="wrfpress_d<domain>_<date>"
  
−
io_form_auxhist23 = 2,
  
−
auxhist23_interval = 180, 180,
  
−
frames_per_auxhist23 = 100, 100,
  
−
(...)
  
−
/
  
−  
−
(...)
  
−  
−
&diags
  
−
p_lev_diags = 1,
  
−
num_press_levels = 6,
  
−
press_levels = 100000, 92500, 85000, 70000, 50000, 20000
  
−
use_tot_or_hyd_p = 1
  
−
p_lev_missing = -999.
  
−
/
  
−
</PRE>
  
   
 
= Variables =
  
= Variables =
Línea 151: Línea 151:
 
*:- <CODE>evspsbl:</CODE> mean evaporation [kgm-2s-1]
  
*:- <CODE>evspsbl:</CODE> mean evaporation [kgm-2s-1]
 
*:- <CODE>evspsblpot:</CODE> mean potential evapotranspiration [kgm-2s-1]
  
*:- <CODE>evspsblpot:</CODE> mean potential evapotranspiration [kgm-2s-1]
  +
*:- <CODE>evspsblpotgen:</CODE> mean generic potential evapotranspiration [kgm-2s-1]
 
*:- <CODE>snc:</CODE> mean snow area fraction [%]
  
*:- <CODE>snc:</CODE> mean snow area fraction [%]
 
*:- <CODE>snd:</CODE> mean snow depth [m]
  
*:- <CODE>snd:</CODE> mean snow depth [m]
Línea 195: Línea 196:
 
*** <CODE>wbacz, wbacz[c/r/s/i/g/h]:</CODE> Water-budget vertically integrated accumulated vertical advection for water vapour, cloud, rain, snow, ice, graupel, hail [mm]
  
*** <CODE>wbacz, wbacz[c/r/s/i/g/h]:</CODE> Water-budget vertically integrated accumulated vertical advection for water vapour, cloud, rain, snow, ice, graupel, hail [mm]
 
*** <CODE>wbacdiabh{l/m/h}:</CODE> Water-budget vertically integrated accumulated of diabatic heating from microphysics at low, medium and high levels (same as cloudiness) [K]
  
*** <CODE>wbacdiabh{l/m/h}:</CODE> Water-budget vertically integrated accumulated of diabatic heating from microphysics at low, medium and high levels (same as cloudiness) [K]
−
*** <CODE>wbacpw[v/c/r/s/i/g/h]{l/m/h}:</CODE> Water-budget vertically integrated accumulated total tendency for water vapour, cloud, rain, snow, ice, graupel, hail at low, medium and high levels (same as cloudiness) [mm]
 +
*** <CODE>wbacpw{l/m/h}[v/c/r/s/i/g/h]:</CODE> Water-budget vertically integrated accumulated total tendency for water vapour, cloud, rain, snow, ice, graupel, hail at low, medium and high levels (same as cloudiness) [mm]
−
*** <CODE>wbacf[v/c/r/s/i/g/h]{l/m/h}:</CODE> Water-budget vertically integrated accumulated horizontal advection for water vapour, cloud, rain, snow, ice, graupel, hail at low, medium and high levels (same as cloudiness) [mm]
 +
*** <CODE>wbacf{l/m/h}[v/c/r/s/i/g/h]:</CODE> Water-budget vertically integrated accumulated horizontal advection for water vapour, cloud, rain, snow, ice, graupel, hail at low, medium and high levels (same as cloudiness) [mm]
−
*** <CODE>wbacz[v/c/r/s/i/g/h]{l/m/h}:</CODE> Water-budget vertically integrated accumulated vertical advection for water vapour, cloud, rain, snow, ice, graupel, hail at low, medium and high levels (same as cloudiness) [mm]
 +
*** <CODE>wbacz{l/m/h}[v/c/r/s/i/g/h]:</CODE> Water-budget vertically integrated accumulated vertical advection for water vapour, cloud, rain, snow, ice, graupel, hail at low, medium and high levels (same as cloudiness) [mm]
 
* Pressure interplation (Core)
  
* Pressure interplation (Core)
 
*:- <CODE>hus_pl:</CODE> specific humidity [1]
  
*:- <CODE>hus_pl:</CODE> specific humidity [1]
Línea 205: Línea 206:
 
*:- <CODE>ws_pl:</CODE> wind speed [ms-1]
  
*:- <CODE>ws_pl:</CODE> wind speed [ms-1]
   
−
== clt: total cloudiness ==
  
   
−
This variable computes the total cloudiness above a grid point taking as input the cloud fraction of a given grid cell and level.
 +
= Missing variables =
  +
There are certain variables from CORDEX `Core' and/or `Tier1' which could not yet be introduced
   
−
'''NOTE:'''
 +
== snw: snow melt ==
−
<PRE>
 +
Accumulation of melted snow
−
cloud fraction in WRF is computed by the radiative scheme, which is called at a frequency given by radt.
 
−
It should be taking into account when one gets any accumulation of any value retrieved from it. Otherwise,
 
−
one could compute the cloud fraction at every time-step (using any of the subroutines from
 
−
module_radiation_driver.F: cal_cldfra1, cal_cldfra2, cal_cldfra3), but then it will not be consistent in
 
−
what was already considered whilst model integration
  
−
</PRE>
  
−  
−
The most common implementation of ‘clt’ found in different other models assumes ‘random overlapping’ and its implemented in most of the global climate models. Here the methodology from the GCM ([http://lmdz.lmd.jussieu.fr/?set_language=en{} LMDZ], Hourdin et al., 2006) was implemented. In this GCM, calculation of the total cloudiness is done inside the subroutine <code>newmicro.f90</code>.
  
−  
−
== cllmh: low, medium and high cloudiness ==
  
−
This variable computes the total cloudiness above a grid point at different vertical intervals (low: p ≥ 680hP a, medium: 680 < p ≥ 400 hP a, high: p < 400 HP a) taking as input the cloud fraction of a given grid cell.
  
−  
−
As in the case of the ‘clt’ calculation from LMDZ has already been implemented as an independent subroutine. See in figure 1 the result of the implementation
  
−  
−
[[File:test_cld.png|frame|50px|Figure 1: Vertical distribution of cloud fraction and the different cloud types at a given point (top left): cloud fraction (cldf ra, full circles with line in blue), mean total cloud fraction
 
−
(cltmean, vertical dashed line), mean low-level cloud fraction (cllmean p ≥ 680 hP a, dark green
 
−
hexagon), mean mid-level (clmmean 680 < p ≥ 440 hP a, green hexagon), mean high-level (clhmean
 
−
p < 440 hP a, clear green hexagon). Temporal evolution of cloud types at the given point (top
 
−
right). Map of cltmean with colored topography beneath to show-up cloud extent (middle middle),
 
−
map of clhmean (middle right), map of clmmean (bottom middle) and map of cllmean (bottom right)]]
  
−  
−
== wsgsmax: Maximum Near-Surface Wind Speed of Gust ==
  
−
The wind gust accounts for the wind from upper levels that is projected to the surface due to instability within the boundary layer. It can have different implementations. Winds are Earth-rotated.
  
−
* <CODE>Brasseur01:</CODE> An implementation of a wind gust following Turbuelent Kinetic Energy (TKE) estimates and stability by virtual temperature (θv , see mainly equation 1) reproducing Brasseur (2001) from the clWRF ([http://www.meteo.unican.es/wiki/cordexwrf/SoftwareTools/ClWrf clWRF] Fita et al., 2010) [wsgs_diag = 1]
  
−
[[File:module_CORDEX_WRF0x.png]]
  
−
* <CODE>WRF_afwa_diagnostics:</CODE> Inside the WRF module <CODE>module_diag_afwa.F</CODE> there is an implementation of the calculation of the wind gust which only occurrs as a blending of upper-level winds (around 1km above ground zagl; -1 zagl(k1000 ) ≥ 1000 m, see equation 2) above a given maximum precipitation inrensity of pratemm_hr ≥ 50 mm [wsgs_diag = 2]
  
−
[[File:module_CORDEX_WRF1x.png]]
  
−  
−
These two methodologies have been implemented and can be switched by a new <CODE>namelist.input</CODE> parameter labeled wsgs_diag (in cordex section). Its default value is 1 It comes out, that both methodologies provide wind gust estimation (WGE) from two different perspectives: mechanic and convective. In order to take into account both winds gusts, another variable as the addition of both estimations is provided as <CODE>totwsgsmax</CODE>, <CODE>totugsmax</CODE>, <CODE>totvgsmax</CODE>, <CODE>totwsgspercen</CODE>. On figure 2 is shown the different outcomes applying each approximation
  
−  
−
[[File:test_wsgs.png|frame|50px|Figure 2: near surface wind gust estimates. 3h-maximum total wind gust strength (wsgsmaxtot, top left), percentage of wsgsmaxtot due to Brasseur’s application (wsgsmaxb01, top middle), percentage due to AFWA-heavy precipitation implementation (wsgsmaxhp , top right), percentage of time-steps where grid point got total wind gust (bottom left), percentage of time-steps where grid point got wsgsmaxb01 (bottom middle), percentage due to wsgsmaxhp (bottom right)]]
  
−  
−
== wsgsmax100: Daily Maximum Near-Surface Wind Speed of Gust at 100 m ==
  
−
The wind gust at 100 m is understood that should follow a similar implementation than for the wsgsmax, but at 100 m, an
  
−
extrapolation of such turbulent phenomena it would require a complete new set of equations which have not yet been placed.
  
−  
−
Instead as a way to overcome it, the estimation of maximum wind speed at 100 m is provided. Provided winds are also Earth-rotated. After PhD thesis of Jourdier (2015), two different methodologies are implemented to estimate the wind at 100 m above ground:
  
−
* Following power-law wind vertical distribution, as it is depicted in equation 3 using the upper-level atmospheric wind speed below (k100) and above (k100) the height above ground of 100 m (zagl) [wsz100_diag = 1]
  
−
[[File:module_CORDEX_WRF2x.png]]
  
−
* Following logarithmic-law wind vertical distribution, as it is depicted in equation 4 using upper-level atmospheric wind speed below (k100) and above (k100) the height above ground of 100 m (zagl) [wsz100_diag = 2]
  
−
[[File:module_CORDEX_WRF3x.png]]
  
−
* Following Monin-Obukhov theory is implemented and was tested, but it is not useful for heights larger than few decameters (z > 80. m). However, the necessary code to extrapolate the wind at given height is left commented just in case someone wants to use it.
  
−  
−
These two methodologies have been implemented and can be switched by a new <CODE>namelist.input</CODE> parameter labeled <CODE>wsz100_diag</CODE> (in cordex section). Its default value is 1. Even one can select another height for the estimation by providing the new parameter <CODE>z100m_wind</CODE> with a different value than 100 m (default value)
  
−  
−
On figure 3 is shown the different outcomes applying each approximation. There are some problems on MoninObukhov application under certain stable conditions (too small Obukhov length)
  
−  
−
[[File:test_wsz100.png|frame|50px|Figure 3: 100 m wind estimates. Comparison between upper-level winds and estimation at a given point and moment (upper left): 3h-maximum eastward wind (red) at 100 m by power-law (uzmaxpl, star), Monin-Obukhov theory (uzmaxmo, cross) by logarithmic law (uzmaxll, sum) 10-m wind value (uas, filled triangle) and upper-level winds (ua, filled circles with line), also for the northward component (green). Temporal evolution of wind speed (top right) with all approximations and upper-level winds at the closest vertical level at 100 m (on log-y scale). Maps of both estimations (bottom left and middle) with the blue cross showing the point of previous figures. Wind rose at the given point (bottom right)]]
  
−  
−
== prw: precipitable water or water vapor path ==
  
−
This variable accounts for the column integrated amount of water vapor.
  
−
This one is already implemented in a old WRF tool for vertical interpolation called <CODE>p_interp.F</CODE> related to the clWRF. The general equation following WRF standard variables as:
  
−  
−
[[File:module_CORDEX_WRF4x.png]]
  
−  
−
where <I>mu</I>: perturbation dry air mass in column (Pa), <I>mub</I>: base-state dry air mass in column (Pa), <I>g</I>: gravity (ms<SUP>-2</SUP>), <I>e_vert</I>: total number of vertical levels, <I>qvapor</I>: mixing ratio of water vapour (kgkg<SUP>-1</SUP>), <I>dnw</I>: full-sigma eta-layer height. See an example on figure 4
  
−  
−
[[File:test_prw.png|frame|50px|Figure 4: On a given point (left): water path (prw, vertical straight line), vertical profile of water vapour (qv, line with full circles), water pat at each level (line with crosses). Map of water path (right), red cross shows where the vertical is retrieved]]
  
−  
−
== clwvi: condensed water path ==
  
−
This variable provides similar information, but for the liquid condensed water species. It is the same calculation as in 5, but replacing QVAPOR by QCLOUD + QRAIN
  
−  
−
== clivi: ice water path ==
  
−
This variable provides similar information, but for the liquid condensed water species. It is the same calculation as in 5, but replacing QVAPOR by QICE + QSNOW + QGRAUPEL + QHAIL
  
−  
−
== clgvi: graupel water path ==
  
−
This variable provides similar information, but for the liquid condensed water species. It is the same calculation as in 5, but replacing QVAPOR by QGRAUPEL. This variable is part of the ‘Tier1’ level and it is only accessible if pre-compilation
  
−
variable CDXWRF is set to 1. See section [[http://wiki.cima.fcen.uba.ar/mediawiki/index.php/CDXWRF#Installation 3]] for more detail.
  
−  
−
== clhvi: hail water path ==
  
−
This variable provides similar information, but for the liquid condensed water species. It is the same calculation as in 5, but replacing QVAPOR by QHAIL. This variable is part of the ‘Tier1’ level and it is only accessible if pre-compilation
  
−
variable CDXWRF is set to 1. See section [[http://wiki.cima.fcen.uba.ar/mediawiki/index.php/CDXWRF#Installation 3]] for more detail.
  
−  
−
== psl: sea level pressure ==
  
−
This accounts for the pressure at the sea level (extrapolation of the pressure at the level of the sea). That means the pressure that might be without the presence of orography.
  
−
Three different methodologies have been implemented
  
−
* One using hydrostatic-Shuell method already implemented in the the module <CODE>phys/module_diag_afwa.F</CODE> (assuming a constant lapse-rate of 6.5 K km-1) [psl_diag = 1]
  
−
* Using smoothed surface pressure and a target upper-level pressure, already implemented in <CODE>p_interp.F90</CODE> [psl_diag = 2]
  
−
* ECMWF method taken from LMDZ from the module pppmer.F90, following the methodology by Mats Hamrud and Philippe Courtier from ECMWF [psl_diag = 3]
  
−  
−
These three methodologies have been implemented and can be switched by a new <CODE>namelist.input</CODE> parameter labeled <CODE>psl_diag</CODE> (in cordex section). Its default value is 3. Even, on using the <CODE>'ptarget'</CODE> method (<CODE>psl_diag = 2</CODE>) one can select the degree of smoothing of the surface place by the selecting the number of times that the smoothing (as the mean of the point and its surrounding 8 neighbors) has to be applied (<CODE>psmooth</CODE>, default 5) and the upper pressure to be used as target (<CODE>ptarget</CODE>, default <I>70000 Pa</I>).
  
−
On figure 5 is shown the different outcomes applying each approximation. There are some problems with the ptarget methodology in both psl estimate and borders for each parallel process on applying the smoothing
  
−  
−
[[File:test_psl.png|frame|50px|Figure 5: sea level pressure estimates. Following hydrostatic-Shuell method at a given time-step (pslshuell , upper left), p-target (pslptarget , upper middle) and ECMWF (pslecmwf , upper right). Differences between methods pslshuell-pslptarget (bottom left), pslshuell-pslecmwf (bottom middle) and pslptarget-pslecmwf (bottom right)]]
  
−  
−
== cape: convective available potential energy ==
  
−
This variable accounts for all the energy that convectively might be released.
  
−
From AMS glossary is described as: ([http://glossary.ametsoc.org/wiki/Convective_available_potential_energy CAPE])
  
−  
−
"On a thermodynamic diagram this is called positive area and can be seen as the region between the lifted parcel process curve and the environmental sounding, from the parcel’s level of free convection to its level of neutral buoyancy. CAPE may be expressed as follows:
  
−
[[File:module_CORDEX_WRF5x.png]]
  
−  
−
where <I>Tvp</I> is the virtual temperature of a lifted parcel moving upward moist adiabatically from the level of free convection to the level of neutral buoyancy, <I>Tve</I> is the virtual temperature of the environment, <I>Rd</I> is the specific gas constant for dry air, pf is the pressure at the level of free convection, and <I>pn</I> is the pressure at the level of neutral buoyancy. The value depends on whether the moist-adiabatic process is considered to be reversible or irreversible (conventionally irreversible, or a pseudoadiabatic process in which condensed water immediately falls out of the parcel) and whether the latent heat of freezing is considered (conventionally not). It is assumed that the environment is in hydrostatic balance and that the pressure of the parcel is the same as that of the environment. Virtual temperature is used for the parcel and environment to account for the effect of moisture on air density."
  
−  
−
At this version of the module, only one implementation of the variable has been implemented. WRF model already provides a way of calculation of the variables inside the module <code>phys/module_diag_afwa.F</code> (sinve WRF version V3.6) via the function Buoyancy, which at the same time it provides: Convective inhibition (CIN), Height at the Level of free convection (ZLFC), Pressure at the Level of free convection (PLFC) and Lifted index (LI). Tacking advantage of this, these extra four variables are also provided. This vertical integrated diagnostics have a high computational cost. In order to minimize it, by default, they are only computed at output time-step. However, if user requires Tier1 variables which are related to the statistics of these diagnostics: <I>capemin, capemax, capemean, cinmin, cinmax, cinmean, zlfcmin, zlfcmax, zlfcmean, plfcmin, plfcmax, plfcmean, limin, limax and limean</I>, then these diagnostics are computed at all time-steps. This behavior of the module is regulated via the namelist parameter <code>convxtrm_diag</code> (defaul value is 0, meaning no computation), and setting the pre-compilation flag <code>CDXWRF</code> to 1 and perform some complementary modifications in module's Registry file <code>Registry/registry.cordex</code>. See section [[http://wiki.cima.fcen.uba.ar/mediawiki/index.php/CDXWRF#Installation 3]] for more detail.
  
−  
−
== cin: convective inhibition ==
  
−  
−
This variable accounts for the process which inhibits the convection. Already provided by the implementation of the AFWA’s CAPE calculation
  
−
From AMS glossary is described as: [http://glossary.ametsoc.org/wiki/Convective_inhibition CIN])
  
−
"The energy needed to lift an air parcel upward adiabatically to the lifting condensation level (LCL) and then as a psuedoadiabatic process from the LCL to its level of free convection (LF C). For an air parcel possessing positive CAP E, the CIN represents the negative area on a thermodynamic diagram. The negative area typically arises from the presence of a lid, or the amount of kinetic energy that must be added to a parcel to enable that parcel to reach the LF C. Even though other factors may be favorable for development of convection, if convective inhibition is sufficiently large, deep convection will not form. The convective inhibition is expressed (analogously to CAPE) as follows:
  
−  
−
[[File:module_CORDEX_WRF6x.png]]
  
−  
−
where <I>pi</I> is the pressure at the level at which the parcel originates, <I>pf</I> is the pressure at the LFC, <I>Rd</I> is the specific gas constant for dry air, <I>Tvp</I> is the virtual temperature of the lifted parcel, and <I>Tve</I> is the virtual temperature of the environment. It is assumed that the environment is in hydrostatic balance and that the pressure of the parcel is the same as that of the environment. Virtual temperature is used for the parcel and environment to account for the effect of moisture on air density."
  
−  
−
== sund: duration of sunshine ==
  
−
This variable accounts for the time where short-wave radiation is above 120 Wm<SUP>-2</SUP>
  
−  
−
See results of the variable in figure 6
  
−  
−
[[File:test_sund.png|frame|50px|Figure 6: Temporal evolution (left) of shortwave downward radiation (swdown, red line, left y-axis) and sunshine duration (sund, stars, right y-axis. sund map at a given time (right))]]
  
−  
−
== hur: relative humidity ==
  
−
3D atmospheric relative humidity on standard model η levels can be obtained following the <I>Clausius-Clapeyron</I> formula and its approximation from the well-known <I>August-Roche-Magnus</I> formula of saturated water vapor pressure e<SUB>s</SUB>. This is an 'additional' variable which requires setting the pre-compilation flag <CODE>CDXWRF</CODE> to 2 and perform some complementary modifications in module's Registry file registry.cordex. See section [[http://wiki.cima.fcen.uba.ar/mediawiki/index.php/CDXWRF#Installation 3]] for more detail.
  
−  
−
[[File:module_CORDEX_WRF7x.png]]
  
−  
−
being <I>tempC</I>: temperature (◦C), <I>presshPa</I>: pressure (hPa), <I>e<SUB>s</SUB></I>: saturated water vapor pressure (Pa), <I>ws</I>: saturated mixing ratio (kgkg<SUP>-1</SUP>), <I>q</I>: mixing ratio (kgkg<SUP>-1</SUP>).
  
−  
−
== hus: specific humidity ==
  
−
3D atmospheric specific humidity (From the AMS glossary [http://glossary.ametsoc.org/wiki/Specific_humidity hus]) on standard model η levels is computed according to equation 11. This is an 'additional' variable which requires setting the pre-compilation flag <CODE>CDXWRF</CODE> to 2 and perform some complementary modifications in module's Registry file <CODE>Registry/registry.cordex</CODE>. See section [[http://wiki.cima.fcen.uba.ar/mediawiki/index.php/CDXWRF#Installation 3]] for more detail.
  
−  
−
[[File:module_CORDEX_WRF8x.png]]
  
−  
−
where <I>r<SUB>v</SUB></I>: mixing ratio (kgkg<SUP>-1</SUP>)
  
−  
−
== zg: geopotential height ==
  
−
This variable states for the 3D atmospheric geopotential height on standard model η levels. WRF model integrates the perturbation of the geopotential field from a reference or base one. Thus to obtain the full geopotential height is required to combine two different fields as it is shown in equation 12. This is an 'additional' variable which requires setting the pre-compilation flag <CODE>CDXWRF</CODE> to 2 and perform some complementary modifications in module’s Registry file <CODE>Registry/registry.cordex</CODE>. See section [[http://wiki.cima.fcen.uba.ar/mediawiki/index.php/CDXWRF#Installation 3]] for more detail.
  
−  
−
[[File:module_CORDEX_WRF9x.png]]
  
−  
−
where <I>PHB</I>, WRF base geopotential height (m<SUP>2</SUP>s<SUP>-2</SUP>), <I>PH</I>, WRF perturbation geopotential height (m<SUP>2</SUP>s<SUP>-2</SUP>)
  
−  
−
== press: air-pressure ==
  
−
This variable states for the 3D atmospheric pressure on standard model η levels. WRF model integrates the perturbation of the pressure field from a reference one. thus to obtain the full pressure is required to combine two different fields as it is shown in equation 13. This is an 'additional' variable which requires setting the pre-compilation flag <CODE>CDXWRF</CODE> to 2 and perform some complementary modifications in module's Registry file <CODE>Registry/registry.cordex</CODE>. See section [[http://wiki.cima.fcen.uba.ar/mediawiki/index.php/CDXWRF#Installation 3]] for more detail.
  
−  
−
[[File:module_CORDEX_WRF10x.png]]
  
−  
−
where <I>PB</I>, WRF base pressure (Pa), <I>P</I>, WRF perturbation pressure (Pa)
  
−  
−
== ta: air-temperature ==
  
−
This variable states for the 3D atmospheric temperature on standard model η levels. WRF model equations are based on potential temperature. Thus a conversion to actual temperature is required and it is performed as it is shown in equation 14. This is an 'additional' variable which requires setting the pre-compilation flag <CODE>CDXWRF</CODE> to 2 and perform some complementary modifications in module's Registry file <CODE>Registry/registry.cordex</CODE>. See section [[http://wiki.cima.fcen.uba.ar/mediawiki/index.php/CDXWRF#Installation 3]] for more detail.
  
−  
−
[[File:module_CORDEX_WRF11x.png]]
  
−  
−
where <I>T</I>, WRF temperature (K, which is as potential temperature), <I>PB</I>, WRF base pressure (Pa), <I>P</I>, WRF perturbation pressure (Pa), <I>p0</I>: pressure reference 100000 (Pa)
  
−  
−
== ua/va: air-wind Earth oriented ==
  
−
This variable states for the 3D atmospheric wind speed following Earth coordinates on standard model η-levels. WRF model equations use stagger winds following grid direction. In order to get actual winds following Earth geographical coordinates, a transformation shown in equation 15 is required. This is an ‘additional’ variable which requires setting the pre-compilation flag <CODE>CDXWRF</CODE> to 2 and perform some complementary modifications in module's Registry file <CODE>Registry/registry.cordex</CODE>. See section [[http://wiki.cima.fcen.uba.ar/mediawiki/index.php/CDXWRF#Installation 3]] for more detail.
  
−  
−
[[File:module_CORDEX_WRF12x.png]]
  
−  
−
where U<SUB>stg</SUB>: x-staggered WRF eastward wind (ms<SUP>-1</SUP>), V<SUB>stg</SUB>: y-staggered WRF northward wind (ms <SUP>-1</SUP>), U<SUB>unstg</SUB>: unstaggered WRF eastward wind (m<SUP>s-1</SUP>), V<SUP>unstg</SUP>: unstaggered WRF northward wind (ms<SUP>-1</SUP>), cosa: local cosine of map rotation (1), sina: local sine of map rotation (1).
  
−  
−
== tauuv ==
  
−
Surface Downdward wind stress at 10m. This variable account for the force that winds exercises to the surface. It is implemented following the equation 16, begin CD drag coefficient. Winds are Earth-rotated.
 
−  
−
[[File:module_CORDEX_WRF13x.png]]
  
−  
−
where, C<SUB>D</SUB>: drag coefficient (1) which in WRF is non-zero only for certain options of surface layer physics if <code>sf_sfclay_physics /= 1, 5</CODE> (1: MM5-similarity, 5: MYNN surface layer), uas: eastward 10 m surface wind (ms<SUP>-1<SUP>), vas: northward 10 m surface wind (ms<SUP>-1<SUP>)
  
−  
−
== evspsblpot ==
  
−
This variable accounts for theoretical maximum evaporation that is possible to occur. Potential evapotranspiration is computed following its computation from [[http://orchidee.ipsl.fr/ ORCHIDEE]] model (Organising Carbon and Hydrology In Dynamic Ecosystems. The implementation is retrieved from the module <CODE>src_sechiba/enerbil.f90</CODE> and basically consists on an implementation of the Penman-Monteith formulation (Monteith, 1965). It is a simple formulation (see equation 16)
  
−  
−
[[File:module_CORDEX_WRF14x.png]]
  
−  
−
where <I>qc</I>: surface drag coefficient (ms<SUP>-1</SUP>), <I>q2<SUB>sat</SUB></I>: Saturated air at 2m (kgkg<SUP>-1</SUP>, using <I>August-Roche-Magnus</I> approximation and assuming to be q2 &SIM; q<SUB>sfc</SUB>), <I>uas,vas</I>: 10 m wind components ms<SUP>-1</SUP>), C<SUB>D</SUB>: Drag coefficient (-, only available for surface layer schemes MM5-similarity and MYNN)
  
−  
−
Up to now there is only one implementation and it is selected via namelist parameter potevap_diag, up to now only with value 1 for the ORCHIDEE implementation
  
−  
−
== rsus ==
  
−
Surface Upwelling Shortwave Radiation, is understood as the shortwave radiation from land. It is provided accumulated by radiation schemes CAM and RRTMG (<CODE>sw_ra_scheme = 3,4</CODE>) in variable <CODE>SWUPB</CODE>.
 
−  
−
== rlus ==
  
−
Surface Upwelling Longwave Radiation, is understood as the longwave radiation from land. It is provided accumulated by radiation schemes CAM and RRTMG (<CODE>sw_ra_scheme = 3,4</CODE>) in variable <CODE>SLUPB</CODE>.
 
−  
−
== pr ==
  
−
Total precipitation flux is computed as the sum of all the types of precipitation as it is shown in equation 18
  
−  
−
[[File:module_CORDEX_WRF15x.png]]
  
−  
−
where <I>prc</I>: convective precipitation (kgm<SUP>-2</SUP>), <I>prl</I>: large-scale precipitation (kgm<SUP>-2</SUP>), <I>prsh</I>: shallow-cumulus precipitation (kgm<SUP>-2</SUP>), Nsteps: number of time steps and δt: time-step length (s).
  
−  
−
== prsn ==
  
−
Solid precipitation flux accounts for all the precipitation which is frozen. Depending on the micro-physics scheme it might account for the precipitation of: snow, graupel and hail. It is computed as it is shown in equation 19
  
−  
−
[[File:module_CORDEX_WRF16x.png]]
  
−  
−
where <I>pr</I>: total precipitation (kgm<SUP>-2</SUP>), <I>sr</I>: fraction of solid precipitation (1, variable included in WRF), Nsteps: number of time steps and δt: time-step length (s)
  
−  
−
= Generic variables =
  
−
Some of the diagnostics required by CORDEX depend on the approximations, equations, methodologies and observations used to compute them. This make model intercomparison exercises very difficult because values might differ from one implementation to another one. In a way to overcome this issue, a series of variables are also provided in a 'generic' form (when possible) meaning that they are obtained directly from well established variables. Thus, these generic form of the diagnostics become 'independent' of model's implementation.
  
−  
−
== zmlagen: generic boundary layer height ==
  
−
Boundary layer height is a clear example of model dependence and even scheme dependence of how a diagnostic is computed. Each pbl scheme has its own assumptions and has to be compiled in a specific way. This variable is provided with the 'Tier1' level of variables and requires to set the pre-compilation flag <CODE>CDXWRF</CODE> to 1 and perform some complementary modifications in module's Registry file <code>Registry/registry.cordex</CORDEX>. See section [[http://wiki.cima.fcen.uba.ar/mediawiki/index.php/CDXWRF#Installation 3]] for more details.
 
−  
−
Pursuing this goal, we implemented a general definition for the boundary layer height as it was done in (García-Díez et al., 2013) after (Nielsen-Gammon et al., 2008). The method consists in defining the height of the boundary layer as the first level where potential temperature exceeds the minimum potential temperature reached in the mixed layer (ML) by more than 1.5 K. It has been implemented as it is shown below:
  
−  
−
# Mixed layer depth (kMLD) first layer at which the variation of mixing ratio upwards from first layer value achieves a given percentage:[[File:module_CORDEX_WRF24x.png]] > δqv (here applied a δqv = 0.1)
 
−
# Minimum potential temperature within the MLD: θminM LD = min(θ(1), ..., θ(kM LD ))
  
−
# Boundary layer level (kzmla ) first level where: θ(kzmla ) + δθ > θminM LD (here δθ = 1.5 K)
  
−
# Boundary layer height (zmla) height above ground (zagl): zmla = zagl(kzmla )
  
−  
−
Comparison of this implementation with the zmla directly provided by WRF’s pbl scheme is shown in figure 14.
  
−
No general rule has been applied to determine the correct value of δqv used to determine depth of mixed layer. They can be determined by the <CODE>namelist.input</CODE> parameters <CODE>zmlagen_dqv</CODE> for δqv (default value 0.1) and <CODE>zmlagen_dtheta</CODE> for δθ (default value 1.5 K)
  
−  
−
[[File:test_zmla.png|frame|50px|Figure 14: Vertical characteristics of the atmosphere at a given point (top left): potential temperature vertical profile (θ K, red line), vertical profile of mixing ratio (qv kgkg-1 , blue line), mixed layer depth (M LD, dashed horizontal line at 323.522 m), derived boundary layer height (zmla, horizontal dashed line at 107.122 m and WRF derived pbl scheme value (W RF zmla at 903.017 m). Comparison of temporal evolutions (top right) between derived zmla (yellow stars) and WRF’s pbl scheme (blue line). Map of differences between derived and WRF simulated (zmla-zmlaWRF ,bottom left), zmla map (bottom middle) and zmlaW RF (bottom right)]]
  
−  
−
== cdgen ==
  
−
Drag coefficient at surface. Computation of drag coefficient depends on selected surface scheme. In order to avoid this scheme dependency, a general calculation of the coefficient has been introduced as it is shown in equation 20, after Garratt (1992).
  
−  
−
[[File:module_CORDEX_WRF18x.png]]
  
−  
−
Being, <I>u<SUP>∗</SUP></I>: from similarity theory (ms<SUP>-1</SUP>), <I>wss</I>: 10 m wind speed (ms<SUP>-1</SUP>)
  
−  
−
== tauuvgen: generic surface downdward wind stress ==
  
−
Generic surface downdward wind stress at 10m. It is implemented following the equation 21. Winds are Earth-rotated.
  
−  
−
[[File:module_CORDEX_WRF19x.png]]
  
−  
−
where <I>C<SUB>D</SUB><SUP>gen</SUP></I> generic drag coefficient (-, see equation 20), uas: eastward 10 m wind (ms<SUP>-1</SUP>), vas: northward 10 m wind (ms<SUP>-1</SUP>)
  
−  
−
== rsusgen ==
  
−
Surface Upwelling Shortwave Radiation, is understood as the shortwave radiation from land. It is calculated in a generic way as the reflected shortwave radiation due to albedo as it is shown in equation 22
  
−  
−
[[File:module_CORDEX_WRF20x.png]]
  
−  
−
where <I>albedo</I>: albedo (1), <I>sdown</I>: downward at surface shortwave radiation (Wm<SUP>-2</SUP>)
  
−  
−
== rlusgen ==
  
−
Surface Upwelling Longwave Radiation, is understood as the longwave radiation from land. It is calculated in a generic way as the longwave radiation due to surface temperature following black body formulation as it is shown in equation 23. '''NOTE:''' This equation was wrong on version v1.0 [[CDXWRFevolution]]
  
−  
−
[[File:module_CORDEX_WRF21x.png]]
  
−  
−
where <I>CtBoltzman</I>: Boltzman constant (5.67051E<SUP>-8</SUP> W m<SUP>-2</SUP> K<SUP>-4</SUP> ), <I>emiss</I>: emissivity (1), <I>skt</I>: skin temperature (K)
  
−  
−
= Adittional variables =
  
−
Some other variables not required by CORDEX, but might be interesting for other purposes will be also added because it was thought that they might be useful to the community and to take advantage of all the work done for the 'Core' and 'Tier1' variables. These variables are obtained if the pre-compilation flag <CODE>CDXWRF</CODE> is set to 2 and some additional modifications are made in module's registry file <CODE>Registry/registry.cordex</CODE>. See section [[http://wiki.cima.fcen.uba.ar/mediawiki/index.php/CDXWRF#Installation 3]] for more details.
  
−  
−
== tds ==
  
−
Dew point temperature following August-Roche-Magnus approximation as it is shown in equation 24
  
−  
−
[[File:module_CORDEX_WRF22x.png]]
  
−  
−
where <I>tas</I>: 2m temperature (K), <I>hurs</I>: 2m relative humidity (%), b = 17.625, c = 243.04
  
−  
−
Statistical values are provided in the output: minimum, maximum and mean within output time-steps as part of the 'additional' level of variables.
  
−  
−
== Water vapor balance terms ==
  
−
These covers the different column integrated terms of the water balance equation. The equation of the water vapour budget:
  
−
[[File:module_CORDEX_WRF23x.png]]
  
−  
−
Where <I>q</I> stands for either of the five water species concentration (vapor, snow, ice, rain and liquid), <I>Vh</I> stands for horizontal wind speed, <I>w</I> stands for the vertical wind speed and <I>MP</I> for the loss or gain of water due to cloud microphysical processes. The term in the left-hand side of the equation represents the water species tendency (<I>TEN</I> or <I>PW</I>), referring to the difference between q at the model previous time step and at the end of the actual time step, divided by the time step. <I>TEN</I> equals to the horizontal advection (<I>HOR</I> or '<I>F</I>', first term in right-hand side of the equation), the vertical advection (<I>VER</I> or <I>'Z'</I>, second term in right-hand side) and the sources (<I>SO</I>) or sink (<I>SI</I>) of atmospheric water due to microphysical processes (<I>MP</I>). All terms are expressed in kgkg-1s-1. However, <I>SO</I>, and <I>SI</I> ca not be provided because they are micro-physics dependent an make difficult to provide a general formula for them.
  
−  
−
In order to obtain the total column mass of water due to each term (in units of mm), it is applied to each term of eq. 26 (similarly as in 5):
  
−  
−
[[File:module_CORDEX_WRF24x.png]]
  
−  
−
Following the methodology of Huang et al. (2014) and Yang et al. (2011), Fita and Flaounas (2018) implemented the water budget terms in a new module in WRF in order to allow the computation of the terms during model integration. For the CORDEX module, only the vertically integrated variables will be implemented. Microphysics processes depends on the micro-physics scheme used during model run. It is know the the budget is closed, thus, residual of the terms must be the micor-phsyics term. Due to the complexity of each micro-physics scheme and the impossibility to generalize the calculation, the accumulation of diabatic heating from the micro-physics scheme is provided as a proxy.
  
−
All water species decomposition is shown in figures 7 and 8
  
−
It has also been grouped by vertical levels as it is done with the clouds: p ≥ 68000 P a, 40000 ≤ p < 68000 P a, p < 40000 P a. Decomposition of each term is shown for water vapour qv and snow in figures from 9 to 12.
  
−  
−
[[File:test_acpw.png|frame|50px|Figure 7: Normalized Water budget 3h-accumulated vertically integrated total tendency 'PW' at a given time, for water vapour (qv, top left), cloud (qc, top middle), rain (qr, top right), water condensed species (qc + qr, middle left), snow (qs, middle middle), ice (qi, middle right), water solid species (qs + qi + qg, bottom left), graupel (qg, bottom middle), hail (qh, bottom right). Number on low left corner of the figure correspond to the standard deviation (σ in mm) value used for the normalization]]
  
−  
−
[[File:test_acf.png|frame|50px|Figure 8: As in 7, but for Water budget 3h-accumulated vertically integrated horizontal advection 'F' at a given time]]
  
−  
−
[[File:test_wb_qV.png|frame|50px|Figure 9: Water budget evolution at a given point for water vapour of vertically integrated water-budget terms: total tendency ‘PW’ (∂t qv, red), horizontal advection ‘F’ (advh qv, green), vertical advection ‘Z’ (advz qv, green), residual PW-F-Z (res(∂t qv), gray dashed) and diabatic heating from micro-physics (Qd , pink) (top left), only high-level vertically integrated values (p < 440 hP a, top right), high/mid/low-level (degree of color intensity) decomposition of partialt qv (red) and Qd (pink) and their respective residuals as dashed lines (middle left), only mid-level vertically integrated values (680 > p ≤ 440 hP a, middle right), high/mid/low-level (degree of color intensity) decomposition of advh qv (green) and advz qv (blue) and their respective residuals as dashed lines (bottom left) and only low-level vertically integrated values (p ≥ 680 hP a, bottom right)]]
  
−  
−
[[File:test_wb_map_qV.png|frame|50px|Figure 10: water vapour water budget maps of each component and diabtic heating from micro-physics at a given time and the percentual contribution at each different vertically integrated layer respective the total. total tendency ‘PW’ (∂t qv, first column), horizontal advection ‘F’ (advh qv, second col), vertical advection ‘Z’ (advz qv, third col.) and diabatic heating from micro-physics (Qd , 4th col). Percentage contribution of high level (p < 440 hP a) integration to the total (second row), percentage for mid level (680 > p ≥ 440 hP a) integration to the total (third row) and percentage of low-level (p ≥ 680 hP a) integration (bottom row)]]
  
−  
−
[[File:test_wb_qS.png|frame|50px|Figure 11: The same as in figure 9, but for snow]]
  
−  
−
[[File:test_wb_map_qS.png|frame|50px|Figure 12: The same as in 10, bur for snow]]
  
−  
−
== tfog: time of presence of fog ==
  
−
A diagnostic of visibility has been introduced. From it, one can define fog as that moment where the visibility is lower than 1 km (WMO, 2010).
  
−
<code>tfog</code> accounts for the time in which the grid point has visibility lower than 1 km (see equation 27)
  
−  
−
[[File:module_CORDEX_WRF25x.png]]
  
−  
−
where <I>N<SUB>fog</SUB></I>: number of time steps where visibility was below 1 km. δt: model time step (<I>s</I>)
  
−  
−
== fogvisblty: visibility inside fog ==
  
−
A diagnostic of visibility is introduced in order to provide a diagnostic for fog. Three different methods have been introduced:
  
−  
−
* '''K84:''' Visibility is computed by means of liquid water (<code>QCLOUD</code>) and ice (<code>QICE</code>) concentrations. Following (Bergot et al., 2007) fog appears when there are liquid and/or ice water species at the lowest level. Visibility using (see equation 28, Kunkel 1984) formula is computed on that grid points where fog appeared. Method selected with <code>visibility_diag = 1</code>
  
−  
−
[[File:module_CORDEX_WRF26x.png]]
  
−  
−
where <I>qc</I>: liquid water (cloud) mixing ratio (<I>kgkg-1</I>), <I>qi</I>: ice mixing ratio (<I>kgkg-1</I>). Visibility values are in <I>km</I>
  
−
* '''RUC:''' Visibility is computed using relative humidity (<I>hur</I>) as it is implemented in the RUC model (see equation 29, Smirnova et al. 2000). Method selected with <code>visibility_diag = 2</code>
  
−  
−
[[File:module_CORDEX_WRF27x.png]]
  
−  
−
where <I>rh</I>: relative humidity (<I>1</I>) and can be from surface or first model layer. Visibility values are in <I>km</I>
  
−  
−
* '''FRAM-L:''' Visibility is computed using relative humidity (<I>hur</I>) after (see equation 30, Gultepe and Milbrandt, 2010). In this work, it is proposed a probabilistic approach to the computation of the visibility in three different bins: 95% , 50% and 5% of probability to get certain visibility (for <I>rh > 30%</I>). As a matter of compromise, the calculation for the 50% of probability has been chosen as the preferred one. Thus, this method provides the visibility that might be with a 50% of probability. Method selected with <code>visibility_diag = 3</code> (default)
  
−  
−
[[File:module_CORDEX_WRF28x.png]]
  
−  
−
where <I>rh</I>: relative humidity (<I>1</I>) and can be from surface or first model layer. Visibility values are in <I>km</I>
  
−  
−
Provided values in the output are the minimum, maximum and mean values within output time-steps
  
−  
−
Different choices are controlled throughout <code>namelist.input</code> variables: <code>visibility_diag</code> method of visibility computation, <code>fogvars</code> source of the relative humidity. From first model layer (''hur'') <code>fogvars=1</code> (default), surface (''hurs) <code>fogvars=2</code>. See some preliminary results in figure 13
  
−  
−
[[File:fogvismean.png|frame|50px|Figure 13: Comparison of the different configurations of the diagnostics of the mean fog visibility (in 1 hour) to the satellite image from GOES-12 at the same time in the visible channel (courtesy of NOAA-CLASS), default (fogvisibility=3, fogvars=1; top middle), vis3vars2 (top right), vis1vars1 (bottom left), vis2vars1 (bottom middle) and vis2vars2 (bottom right)]]
  
−  
−
It is known that certain methods of visibility relay on numerical adjustments on certain observational data taken under certain circumstances and places (e.g.: for FRAM-L adjusted values come from observations from a Canadian airport). It would be desirable to provide a more generic all places/purposes (if possible) approach. Take this value with certain care
  
−  
−
= Missing variables =
  
−
There are certain variables from CORDEX ‘Tier1’ which could not yet be introduced
  
   
 
== wsgsmax100: Daily Maximum Near-Surface Wind Speed of Gust at 100 m ==
  
== wsgsmax100: Daily Maximum Near-Surface Wind Speed of Gust at 100 m ==
Línea 216: Línea 216:
   
 
== ic_lightning, cg_lightning, tot_lightning: intra-cloud, ground and total lightning flashes ==
  
== ic_lightning, cg_lightning, tot_lightning: intra-cloud, ground and total lightning flashes ==
−
There is lightning scheme implementation in WRF. (lightning_option among other from namelist.input). It might require some adjustment prior it’s use.
 +
There is lightning scheme implementation in WRF. (lightning_option among other from namelist.input). It might require some adjustment prior it's use.
 
It does not sees to provide a wolrdwide cloud/ground discrimination
  
It does not sees to provide a wolrdwide cloud/ground discrimination
−  
−
= Optimization =
  
−
Regional climate dynamical downscaling experiments require long continuous simulations. Thus, model performance in terms of speed of integration are crucial. First version of the module (v1.0) was known to introduce a lose in time-step speed of integration of about 40\% slower (highly dependent on HPC, model configuration and domain). In order to improve model performance when the module is activated, an enhanced version of the module (v1.1) was prepared. In this new version, a series of pre-compilation flags were activated, with which, user can choose the level of complexity and amount of variables to obtain. Doing it in this way instead via regular namelist options, two main goals are obtained: (1) reduce the amount of variables to be kept in memory during model execution and (2) reduce the amount of conditions (mainly avoiding IF statements) to be check at each execution step.
  
−  
−
A domain (see figure 15 and table for details) has been set-up to perform short runs (5 days) to check the optimization of the WRF module with the pre-compilation flags for the compilation of the model. Simulations are run in a single node (to avoid non-homogeneous communications among nodes of the cluster) and with the model compiled (intel compiler v16.0.4.258) only in distributed memory mode on CRAY XE6/XC40 machine under SUSE Linux Enterprise Server 12 (x86_64) version 12 patchlevel = 3.
 
−  
−
[[Archivo:CDXWRF_domain_test.png|frame|50px|Figure 15: Domain WRF3.8.1 configuration where different performance tests where carried out]]
  
−  
−  
−
{|-
  
−
! Domain characteristic
  
−
! value
  
−
|-
  
−
| projection
  
−
| lat-lon
  
−
|-
  
−
| central point
 
−
| N 48.0522<SUP>&deg;</SUP>, 23.07623<SUP>&deg;</SUP> E
  
−
|-
  
−
| ref<SUB>x,y</SUB>
  
−
| 118, 99
  
−
|-
  
−
| pole<SUB>lat,lon</SUB>
  
−
| N 39.25000<SUP>&deg;</SUP>, 18.00000<SUP>&deg;</SUP> E
  
−
|-
  
−
| standard longitude
  
−
| 18.00000<SUP>&deg;</SUP> W
  
−
|-
  
−
| grid-points
  
−
| 100x100
  
−
|-
  
−
| resolution
  
−
| 0.13750x0.13750<SUP>&deg;</SUP>
  
−
|-
  
−
| vertical levels
  
−
| 50
  
−
|-
  
−
| time-step
  
−
| 15 s
  
−
|-
  
−
|}
  
−  
−
Time measurements are done with the elapsed time-step of each model integration obtained from the standard output of the model run (<CODE>rsl.error.0000</CODE> WRF ASCII file, see in figure 16). In this file, WRF users can get the elapsed time for all the time-steps of the model. Different peaks of slower time-steps are seen with coincidence to Input/Output file operations and when different physical schemes (mainly the radiative scheme) are activated on a given frequency. With 5-days simulations and time-steps of 50 seconds, one obtain more than 10,0000 time-steps. Thus, the mean time step is computed as the average of all the 23,221 time-steps of the simulation.
 
−  
−
[[Archivo:CDXWRF_Josipa-short.png|frame|50px|Figure 16: Elapsed times for each individual time-step integration (time steps from number 3800 [simulating date 2014-01-01 15:35:00 UTC] to 4050 [2014-01-01 16:37:30 UTC]). Model was ran with different module configurations. See text for more details. Larger time-steps are related to activation of the short/long-wave radiative scheme (every 5 minutes)]]
  
−  
−
In order to know sensitivity of the model performance to the different configurations and options of the module, a series of simulations are performed (see table below). The first simulation (labeled v381orig) and used as reference, is the simulation with the original version of the model (here version 3.8.1) without the module. The first version of the module (v1.0, labelled v10) with all the extra calculations (water budget components, namelist option <CODE>wb_diag=1</CODE> and extremes of convective parameters, namelist option <CODE>convxtrm_diag=1</CODE>). A simulation with version 1.0 but without extra computations (v10_NOwbconvxtrn). Another with the new version (v1.1) without the setting of pre-compilation parameter <CODE>CDXWRF</CODE> (labelled v11_NOCDXWRF). Another with version 1.1 with pre-compilation parameter <CODE>CXWRF=1</CODE> (v11_CDXWRF1). Another with pre-compilation parameter <CODE>CDXWRF=2</CODE> and computing all extra calculations (v11_CDXWRF2). Finally three additional more without any extra calculation (v11_CDXWRF2_00), without calculation of extra water-budget terms (v11_CDXWRF2_01) and only without extremes from convection indices (V11_CDXWRF2_10).
  
−  
−
{|
 
−
! label
  
−
! module version
  
−
! description
  
−
! mean time (second)
 
−
! % increment
  
−
|-
  
−
| v381orig
 
−
| -
  
−
| original WRF 3.8.1 version of the code
 
−
| 0.163376306424
 
−
| 1
  
−
|-
  
−
| v10
  
−
| 1.0
 
−
| <code>wb_diag=1</code> & <code>convxtrm_diag=1</code>
  
−
| 0.26841433724
  
−
| 64.3
  
−
|-
  
−
| v10_NOwbconvxtrm
  
−
| 1.0
 
−
| <code>wb_diag=0</code> & <code>convxtrm_diag=0</code>
  
−
| 0.223246675347
 
−
| 36.6
  
−
|-
  
−
| v11_NOCDXWRF
  
−
| 1.1
  
−
| without <code>CDXWRF</code>
  
−
| 0.167709105469
  
−
| 2.7
  
−
|-
  
−
| v11_CDXWRF1
  
−
| 1.1
  
−
| <code>CDXWRF=1</code>
  
−
| 0.167785992187
  
−
| 2.7
  
−
|-
  
−
| v11_CDXWRF2
  
−
| 1.1
  
−
| <code>CDXWRF=2</code>
  
−
| 0.267609857639
  
−
| 63.8
  
−
|-
  
−
| v11_CDXWRF2_00
  
−
| 1.1
  
−
| <code>CDXWRF=2</code> <code>wb_diag=0</code> & <code>convxtrm_diag=0</code>
  
−
| 0.22327053342
  
−
| 36.7
  
−
|-
  
−
| v11_CDXWRF2_01
  
−
| 1.1
  
−
| <code>CDXWRF=2</code> <code>wb_diag=0</code> & <code>convxtrm_diag=1</code>
  
−
| 0.233002554688
  
−
| 42.6
  
−
|-
  
−
| v11_CDXWRF2_10
 
−
| 1.1
  
−
| <code>CDXWRF=2</code> <code>wb_diag=1</code> & <code>convxtrm_diag=0</code>
  
−
| 0.26442043099
 
−
| 61.8
  
−
|-
  
−
|}
  
−  
−
Results show that all the simulations where the module has been added are slower than the simulation with the original version of the code (v381orig, <t>= 0.1634 s). Simulation with version 1.1 of the module without pre-compilation flag <CODE>CDXWRF</CODE> (v11_NOCDXWRF, <t>= 0.1677 s) is the second more fast begin faster than the similar configuration with the original version of the module without the extra calculation (v10_NOwbconvxtrm, <t>= 0.2232 s). In both versions the simulation is similarly slow when all the extra calculations are performed (v10 <t>= 0.26841433724 s, v11_CDXWRF2 <t>= 0.2676 s). The heaviest part of the module is related to the water budget computation since with respect the simulation without extra calculations (v11_CDXWRF2_00, <t>= 0.2233 s) there is an increase of only about 4% of mean time step when only statistics of extreme convective indices is activated (v11_CDXWRF2_01, <t>= 0.2330 s) with respect an increase of 18% when only water-budget terms are included (v11_CDXWRF2_10, <t>= 0.2644 s).
  
−  
−
These results show the important effect on model performance of the number of variables included during the integration (included in the derived type <CODE>grid</CODE>) which will reduce the required amount of memory.
  
   
 
Accordingly to the value given to the pre-compilation variable CDXWRF one obtains:
  
Accordingly to the value given to the pre-compilation variable CDXWRF one obtains:
 
* Without adding the variable: all CORDEX 'Core' variables
  
* Without adding the variable: all CORDEX 'Core' variables
 
* <code>CDXWRF=1</code> CORDEX 'Tier' variables: clgvi, clhvi, zmla, [cape/cin/zlfc/plfc/lidx]{min/max/mean}
  
* <code>CDXWRF=1</code> CORDEX 'Tier' variables: clgvi, clhvi, zmla, [cape/cin/zlfc/plfc/lidx]{min/max/mean}
−
* <code>CDXWRF=2</code> The same as with CDXWRF=1 and additional variables: ua, va, ws, ta, press, zg, hur, hus, tfog, fogvisblty{min/max/mean}, tds{min/max/mean} and the Water-Budget relarted ones: wbacdiabh, wbacpw, wbacpw[c/r/s/i/g/h], wbacf, wbacf[c/r/s/i/g/h], wbacz, wbacz[c/r/s/i/g/h], wbacdiabh{l/m/h}, wbacpw{l/m/h}, wbacpw[c/r/s/i/g/h]{l/m/h}, wbacf{l/m/h}, wbacf[c/r/s/i/g/h]{l/m/h}, wbacz{l/m/h}, wbacz[c/r/s/i/g/h]{l/m/h}
 +
* <code>CDXWRF=2</code> The same as with CDXWRF=1 and additional variables: ua, va, ws, ta, press, zg, hur, hus, tfog, fogvisblty{min/max/mean}, tds{min/max/mean} and the Water-Budget relarted ones: wbacdiabh, wbacpw, wbacpw[c/r/s/i/g/h], wbacf, wbacf[c/r/s/i/g/h], wbacz, wbacz[c/r/s/i/g/h], wbacdiabh{l/m/h}, wbacpw{l/m/h}, wbacpw{l/m/h}[c/r/s/i/g/h], wbacf{l/m/h}, wbacf{l/m/h}[c/r/s/i/g/h], wbacz{l/m/h}, wbacz{l/m/h}[c/r/s/i/g/h]
   
 
Simultanesouly, one needs to modify the <code>Registry/registry.cordex</code> accordingly to the value of <code>CDXWRF</code>:
  
Simultanesouly, one needs to modify the <code>Registry/registry.cordex</code> accordingly to the value of <code>CDXWRF</code>:
Línea 352: Línea 238:
   
 
== CF-compilant file ==
  
== CF-compilant file ==
−
WRF does not provide a real CF-compilant file format. It would be necessary to add at least at the output (at least on the wrfcdx_d<domain>_<date> file):
 +
The module provides almost all the required all the CORDEX variables. However, user still needs to perform some postprocessing of the output data in order to meet CORDEX standards. Mainly:
−
* time variable: CF-version of variable with times in the file
 +
* Computation of the required different statistical values as daily, monthly and seasonal extremes (minimum, maximum, accumulations, means)
−
* atrtributes: WRF does not provide variables with standard attributes like: standar_name, long_name, ...
 +
* Cmorization of the output understood as: 1 file per variable, right metadata and attributes and general CF-compilant standard specifications
   
−
== Instantaneous valuess ==
 +
WRF output does not fully follows CF-conventions. Thus a huge coding effort needs to be done in order to provide a full CF-compliant output directly from it. User still needs to process the output of the model in order to provide data following all the CORDEX guidelines. Due to uncovered steps of the CF-standard, a user of the WRF model still needs to: concatenate files, change names and attributes of variables, calculate temporal statistics over different periods (daily, monthly, seasonal) and provide the right time-variables in order to fully reach the CF-standard which followed by CORDEX. However, these steps are computationally lighter and easier to perform in comparison to the computation of the different diagnostics and the vertical pressure interpolation already introduced in the module.
  +
  +
The incompatibility between WRF output and CF-convention can be overcame with the use of a complementary dedicated I/O library. This has been done for example in the [[https://sourcesup.renater.fr/wiki/morcemed/Home RegIPSL]] platform (which uses WRF as atmospheric model) which uses [[http://forge.ipsl.jussieu.fr/ioserver XIOS]] libraries to manage the I/O.
  +
  +
== Instantaneous values ==
 
As an additional work, all the instantaneous variables used for the different accumuluations and extremes, can also be retrieved. It is only necessary to:
  
As an additional work, all the instantaneous variables used for the different accumuluations and extremes, can also be retrieved. It is only necessary to:
 
# Give an output unit on the <CODE>registry.cordex</CODE> (see instructions at the end of the file)
  
# Give an output unit on the <CODE>registry.cordex</CODE> (see instructions at the end of the file)
Línea 366: Línea 252:
   
 
= Acknowledgements =
  
= Acknowledgements =
−
All the coders of WRF, LMDZ, ORCHIDEE are acknowledged for their work on the developing and maintaining of the models. M. A. Jiménez from Universitat de les Illes Balears (UIB) is acknowledged by her explanations on certain PBL calculations. J. Milovac from U. Hohenheim for her comments is also acknowledged. D. Argüeso from UIB. E. Katragkou and G. Sofiadis from U. Thesaloniki, T. Μ. Giannaros from National Observatory of Athens, T. Lorenz from Uni Research, the Bjerknes Centre and J. Milovac from U. Hohenheim for their assistance in the additional tests. V. Galligani, J. Ruiz and M. Sebastián from CIMA. All the development of the module has been carried out in the CIMA `hydra' cluster, L. Fita thanks the IT support for their work.
 +
All the coders of WRF, LMDZ and ORCHIDEE models are acknowledged for their hard work on the developing and maintaining of the models. M. A. Jiménez from Universitat de les Illes Balears is acknowledged by her explanations on certain PBL calculations. D. Argüeso from UIB. V. Galligani, J. Ruiz and M. Sebastián from CIMA are also acknowldeged by their commentaries. A. Sörensson and E. Borrell are also acknowledged by their assistance. Implementation tests where performed in CIMA HPC resources ‘hydra’ cluster supported by the High Performance Computing National System (SNCAD) of Argentina L. Fita thanks the CIMA-IT support for their work. E. Katragkou and I. Sofiadis acknowledge the technical support and provision of resources from the Scientific Computing Center of [[https://it.auth.gr/el AUTH]] and the [[https://hpc.grnet.gr/ GRNET]] National HPC infrastucture. J.Milovac gratefully acknowledge the support by the German Science Foundation (DFG) through project FOR 1695 and the supercomputing center HLRS in Stuttgart Germany for granting the computing time necessary for the test simulations. T. Lorenz acknowledges the support from the Research Council of Norway and its basic institute support of their strategic project on Climate Services. The simulations were performed on resources provided by UNINETT Sigma2 - the National Infrastructure for High Performance Computing and Data Storage in Norway. Figures were produced with python (except performarnce tests drawn with GNUplot) and L. Fita thanks the development of matplotlib above which he developed and make available a suite in python for netCDF management and plotting purposes called [[http://www.xn--llusfb-5va.cat/python/PyNCplot PyNCplot]]. Authors thank the commentaries of the topical editor (J. Kala) which remarkably improve the manuscript.
−  
−
= References =
  
−
* Bergot, T., Terradellas, E., Cuxart, J., Mira, A., Liechti, O., Mueller, M., and Nielsen, N. W. (2007). Intercomparison of single-column numerical models for the prediction of radiation fog. Journal of Applied Meteorology and Climatology, 46(4):504–521.
  
−
* Brasseur, O. (2001). Development and application of a physical approach to estimating wind gusts. Monthly Weather Review, 129(1):5–25.
  
−
* Fita, L., Fernández, J., and García-Díez, M. (2010). Clwrf: Wrf modifications for regional climate simulation under future scenarios. Proceedings of 11th WRF Users’ Workshop.
  
−
* Fita, L. and Flaounas, E. (2018). Medicanes as subtropical cyclones: the december 2005 case from the perspective of surface pressure tendency diagnostics and atmospheric water budget. Q. J. Royal Met. Soc., doi: 10.1002/qj.3273
  
−
* García-Díez, M., Fernández, J., Fita, L., and Yagüe, C. (2013). Seasonal dependence of wrf model biases and sensitivity to pbl schemes over europe. Q. J. of Roy. Met. Soc., 139:501–514.
  
−
* Garratt, J. (1992). The Atmospheric Boundary Layer. Cambridge Univ. Press, Cambridge, U.K.
  
−
* Hourdin, F., Musat, I., Bony, S., Braconnot, P., Codron, F., Dufresne, J.-L., Fairhead, L., Filiberti, M.-A., Friedlingstein, P., Grandpeix, J.-Y., Krinner, G., LeVan, P., Li, Z.-X., and Lott, F. (2006). The LMDZ4 general circulation model: climate performance and sensitivity to parametrized physics with emphasis on tropical convection. Clim. Dyn., 27(7-8):787–813.
  
−
* Huang, H.-L., Yang, M.-J., and Sui, C.-H. (2014). Water budget and precipitation efficiency of typhoon Morakot (2009). J. Atmos. Sci., 71:112–129.
  
−
* Jourdier, B. (2015). Ressource éolienne en france métropolitaine : méthodes dâĂŹévaluation du potentiel, variabilité et tendances. Climatologie: École Doctorale Polytechnique, 2015. Français. ph:+33 01238226, pages 1–229.
  
−
* Kunkel, B. A. (1984). Parameterization of droplet terminal velocity and extinction coefficient in fog models. Journal of Climate and Applied Meteorology, 23(1):34–41.
  
−
* Monteith, J. L. (1965). Evaporation and environment. the state and movement of water in living organisms. 19th Symp. Soc. Exp. Biol, pages 205–234.
  
−
* Nielsen-Gammon, J. W., Powell, C. L., Mahoney, M. J., Angevine, W. M., Senff, C., White, A., Berkowitz, C., Doran, C., and Knupp, K. (2008). Multisensor estimation of mixing heights over a coastal city. Journal of Applied Meteorology and Climatology, 47(1):27–43.
  
−
* Skamarock, W. C., Klemp, J. B., Dudhia, J., Gill, D. O., Duda, D. M. B. M. G., Huang, X.-Y., Wang, W., and Powers, J. G. (2008). A description of the advanced research wrf version 3. NCAR TECHNICAL NOTE, 475:NCAR/TNÂŋ475+STR.
  
−
* Smirnova, T. G., Benjamin, S. G., and Brown, J. M. (2000). Case study verification of ruc/maps fog and visibility forecasts. Preprints, 9 th Conference on Aviation, Range, and Aerospace Meteorlogy, AMS, Orlando, FL, Sep. 2000, 2.3:6.
  
−
* WMO (2010). Guide to meteorological instruments and methods of observation. Weather - Climate - Weather, pages
  
−
1–176.
  
−
* Yang, M. J., Braun, S. A., and Chen, D.-S. (2011). Water budget of typhoon nari (2001). Mon. Wather Rev., 139:3809–3828.
  

Última revisión de 05:00 1 jul 2022

The `Coordinated Regional Climate Downscaling Experiment' (CORDEX) is a scientific effort of the World Climate Research Program (WRCP) for the coordination of regional climate initiatives. In order to accept an experiment, CORDEX provides experiment guidelines, specifications of regional domains and data access/archiving. Data requirements are intended to cover all the possible needs of stake holders, and scientists working on climate change mitigation and adaptation policies in various scientific communities. The required data and diagnostics are grouped into different levels of frequency (sub-daily, daily, monthly and seasonal), priority (Core, Tier1, Tier2), and some of them even have to be provided as statistics (minimum, maximum, mean). Here is presented the development of a specialized module called module_diag_cordex (version 1.3) for the Weather Research and Forecasting ((WRF, Skamarok et al. 2008)) model, capable of outputting the required CORDEX variables. Additional diagnostic variables not required by CORDEX, but of potential interest to the regional climate modeling community, are also included in the module. `Generic' definitions of variables are adopted in order to overcome model and/or physics parameterization dependence of certain diagnostics and variables, thus facilitating a robust comparison among simulations. The module is computationally optimized, and the output is divided in different priority levels following CORDEX specifications (Core, Tier1, and additional) by selecting pre-compilation flags. This implementation of the module does not add a significant extra cost when running the model, for example the addition of the Core variables slows the model time-step by less than a 5%. The use of the module reduces the requirements of disk storage by about a 50%.

An article is available in `Geosciences Model Development' journal:

Lluís Fita, Jan Polcher, Theodore M. Giannaros, Torge Lorenz, Josipa Milovac, Giannis Sofiadis, Eleni Katragkou and Sophie Bastin, 2019: CORDEX-WRF v1.3: development of a module for the Weather Research and Forecasting (WRF) model to support the CORDEX community, Geosci. Model Dev., 12, 1029-1066, 2019, https://doi.org/10.5194/gmd-12-1029-2019

It is recommend to contact Lluís Fita (lluis.fita [a] cima.fcen.uba.ar) in order to keep a track and being able to inform of new versions/corrections.

Disclaimer 

Authors decline any responsibility of the possible unexpected consequence of the use of this software. This piece 
of code is provided following the scientific spirit of sharing knowledge and technical advances. Please, use it 
with the same intention and willingness.

There are four working versions of the code for WRFV3.7.1, WRFV3.8.1, WRFV3.9.1.1, WRFV4.0. :

GIT repository

Recently all the code was uploaded to a GIT server. All new developments / updates / new WRF versions, will carried out only the GIT version of the codes. Please visit:

https://git.cima.fcen.uba.ar/lluis.fita/cdxwrf/-/wikis/home


Although a pull of the WRF source code has been made and the module is currently being direclty added to the official source of the code of the model, and its final inclusion will be done by decission of the development team of the model.

Be aware that certain surface variables and their statistics (clWRF, Fita et al 2010) are retrieved from namelist configuration (from WRF users web page) 

4. output_diagnostics = 1 in &time_control. Climate diagnostics. This option outputs 36 surface diagnostic variables:
maximum and minimum, times when max and min occur, mean value, standard deviation of the mean for T2, Q2, TSK, U10, 
V10, 10 m wind speed, RAINCV, RAINNCV (the last two are time-step rain). The output goes to auxiliary output stream 3, 
and hence it needs the following:

auxhist3_outname = “wrfxtrm_d<domain>_<date>”
auxhist3_interval = 1440, 1440,
frames_per_auxhist3 = 100, 100,
io_form_auxhist3 = 2

In this page CDXWRFevolution one founds updates, bug fixes of the module.

With this module, now all CORDEX variables (except `snow melt') are available with the files wrfxtrm, wrfpress and wrfcdx, except for the fied values such as 'areacella'. See CDXvariablestable for more detail

Contenido

[editar] CORDEX requirements

CORDEX requirements of data must cover all the possible needs of stake holders, and scientists working on the adaptation and mitigation strategies. They are grouped in different levels of frequency and priority. A working copy of this list is available here from the CORDEX convection permitting Flag Ship Pilot study.

Some of the variables are not directly computed in the WRF model which require to extend the model output in order to provide enough variables to post-process the variables.

The implementation of the module_diag_cordex module should allow to avoid the post-processing by computing the CORDEX-required (Core & Tier) variables during model integration. At the same time, some extra variables, which might be of interest to the community but not required by CORDEX, have also been added.

NOTE: 

Be aware that any systematic checking process has been applied to this module. Use it and the
variables therein at your own risk !! It has been tested on a 2-nested domain configuration with the 
inner domain at cloud resolving resolution (< 5 km, without cumulus scheme), making use of restarts 
and on serial, pure distributed memory and hybrid distributed/shared parallel environment

[editar] module_diag_cordex

The module is basically based on two modules:

  • phys/module_diag_cordex.F: Main module which manages the calls to the variables and the accumulations for the means, ...
  • phys/module_diagvar_cordex.F: Module with the computation of all the variables

This module is accompanied with a new Registry/registry.cordex where the variables and a new section in the namelist.input labeled cordex are defined. There are other necessary complementary modifications on phys/module_diagnostics_driver.F encompassed by the pre-compilaton flag CORDEXDIAG, as well some modifications in the main/depend.common and phys/Makefile. Output is provided by the auxiliary history output #9 with a provisional file name: wrfcordex_d<domain>_<date> All that variables which are only required at output time step, are computed only at that exact time.

Description of the installation process can be found here CDXWRFinstall

Description of the usage of the model can be found here CDXWRFuse

Description of the additional pressure level interpolation variables can be found here CDXWRFpvars

Description of the `Core' variables can be found here CDXWRFcore

Description of the `Tier1' variables can be found here CDXWRFtier

Description of the `Additional' variables can be found here CDXWRFadditional

Description of the studies about optimization of the module can be found here CDXWRFopt

[editar] Variables

These are the different variables added and their implementations from the WRF point of view. There might be necessary to revise some of them, or even decide which version to use In case of accumulation/mean they are also be included

These variables are:

  • Instantaneous diagnostics (only computed on output times)
    • Core
    - prw: Total water path
    - clwvi: Total liquid water path (QCLOUD + QRAIN)
    - clivi: Total ice water path (QSNOW+QICE+GRAUPEL+QHAIL)
    - uas: 10m earth-rotated eastward wind [ms-1]
    - vas: 10m earth-rotated northward wind [ms-1]
    - wss: 10m wind speed [ms-1]
    - hurs: 2m relative humidty [1]
    - huss: 2m specific humidty [1]
    - mrso: total soil moisture content [kgm-2]
    - slw: total liquid water content [kgm-2]
    - ws100: 100m wind speed [ms-1]
    - uz100: 100m wind x-direction [ms-1]
    - vz100: 100m wind y-direction [ms-1]
    - tauu, tauuv: components of the downward wind stress at 10 m [m2s-2] (might be zero if sf_sfclay_physics /= 1, 5)
    - tauugen, tauuvgen: generic components of the downward wind stress at 10 m [m2s-2]
    - cdcdx: drag coefficient [-] (might be zero if sf_sfclay_physics /= 1, 5)
    - cdgen: generic drag coefficient [-]
    - ps: surface pressure [Pa]
    - ts: skin temperature [K]
    • Tier1
    - zmla: pbl height following a generic method [m]
    - clgvi: Total graupel path (QGRAUPEL)
    - clhvi: Total hail path (QHAIL)
    • Additional
    - ua: 3D earth-rotated eastward wind [ms-1]
    - va: 3D earth-rotated northward wind [ms-1]
    - ws: 3D wind speed [ms-1]
    - ta: 3D air-temperature [K]
    - press: 3D air pressure [Pa]
    - zg: 3D geopotential height [m]
    - hur: 3D relative humidty [1]
    - hus: 3D specific humidty [1]
    - psl: sea level pressure [Pa] (three different ways)
    • Only via changes in the registry
    - clt: total cloud cover [1]
    - cll: low-level cloud cover [1]
    - clm: mid-level cloud cover [1]
    - clh: high-level cloud cover [1]
    - cape: Convective Available Potential Energy [Jkg-1]
    - cin: Convective inhibition [Jkg-1]
    - zlfc: Height at the Level of free convection [m]
    - plfc: Pressure at the Level of free convection [Pa]
    - li: Lifted index [1]
    - tds: 2m dew point temperature [K]
  • Accumulated or similar time dependency (computed at every time-step). They are initialized after each output time-step. Thus, they represent statistics (mean, accumulation) only from between output time-steps.
    • Core
    - cltmean: mean clt
    - cllmean: mean cll
    - clmmean: mean clm
    - clhmean: mean clh
    - wsgsmax: maximum surface wind gust [ms-1] (two different methods)
    - ugsmax: eastward maximum surface gust wind direction [ms-1]
    - vgsmax: northward maximum surface gust wind direction [ms-1]
    - wsgspercen: percentage of times when grid point got gust wind [%]
    - totwsgsmax: maximum surface wind gust [ms-1] (addition of different methods)
    - totugsmax: eastward maximum surface gust wind direction [ms-1]
    - totvgsmax: northward maximum surface gust wind direction [ms-1]
    - totwsgspercen: percentage of times when grid point got total gust wind [%]
    - wsz100max: maximum 100m wind [ms-1] (two different methods)
    - uz100max: eastward maximum 100m wind direction [ms-1]
    - vz100max: northward maximum 100m wind direction [ms-1]
    - sund: sunshine length [s]
    - rsds: mean surface Downwelling Shortwave Radiation [Wm-2]
    - rlds: mean surface Downwelling Longwave Radiation [Wm-2]
    - hfls: mean surface Upward Latent Heat Flux [Wm-2]
    - hfss: mean surface Upward Sensible Heat Flux [Wm-2]
    - rsus: mean surface Upwelling Shortwave Radiation [Wm-2]
    - rlus: mean surface Upwelling Longwave Radiation [Wm-2]
    - rsusgen: mean generic surface Upwelling Shortwave Radiation [Wm-2]
    - rlusgen: mean generic surface Upwelling Longwave Radiation [Wm-2]
    - evspsbl: mean evaporation [kgm-2s-1]
    - evspsblpot: mean potential evapotranspiration [kgm-2s-1]
    - evspsblpotgen: mean generic potential evapotranspiration [kgm-2s-1]
    - snc: mean snow area fraction [%]
    - snd: mean snow depth [m]
    - mrros: mean surface Runoff [kgm-2s-1]
    - mrro: mean total Runoff [kgm-2s-1]
    - mrsol: mean total water content of soil layer [kgm-2]
    - pr: precipitation flux [kgm-2s-1]
    - prl: large scale precipitation flux [kgm-2s-1]
    - prc: convective precipitation flux [kgm-2s-1]
    - prsh: shallow-cumulus precipitation flux [kgm-2s-1]
    - prsn: solid precipitation flux [kgm-2s-1]
    - snw: accumulated snow [ksm-2]
    - rsdt: Top Of the Atmosphere incident shortwave radiation [kgm-2]
    - rsut: TOA outgoing shortwave radiation [kgm-2]
    - rlut: TOA outgoing Longwave radiation [kgm-2]
    • Tier1
    - capemin: minimum CAPE [Jkg-1] (activated if convxtrm_diag =1)
    - cinmin: minimum CIN [Jkg-1] (activated if convxtrm_diag =1)
    - zlfcmin: minimum height at LFC [m] (activated if convxtrm_diag =1)
    - plfcmin: minimum Pressure at LFC [Pa] (activated if convxtrm_diag =1)
    - lidxmin: minimum Lifted index [1] (activated if convxtrm_diag =1)
    - capemax: maximum CAPE [Jkg-1] (activated if convxtrm_diag =1)
    - cinmax: maximum CIN [Jkg-1] (activated if convxtrm_diag =1)
    - zlfcmax: maximum height at LFC [m] (activated if convxtrm_diag =1)
    - plfcmax: maximum Pressure at LFC [Pa] (activated if convxtrm_diag =1)
    - lidxmax: maximum Lifted index [1] (activated if convxtrm_diag =1)
    - capemean: mean CAPE [Jkg-1] (activated if convxtrm_diag =1)
    - cinmean: mean CIN [Jkg-1] (activated if convxtrm_diag =1)
    - zlfcmean: mean height at LFC [m] (activated if convxtrm_diag =1)
    - plfcmean: mean Pressure at LFC [Pa] (activated if convxtrm_diag =1)
    - lidxmean: mean Lifted index [1] (activated if convxtrm_diag =1)
    • Additional (not required by CORDEX)
    - tfog: time of presence of fog [s]
    - fogvisbltymin: minimun visibility inside fog [km]
    - fogvisbltymax: maximun visibility inside fog [km]
    - fogvisbltymean: mean visibility inside fog [km]
    - tdsmin: minimum 2m dew point temperature [K]
    - tdsmax: maximum 2m dew point temperature [K]
    - tdsmean: mean 2m dew point temperature [K]
    • Additionally added referred to the water budget in the atmosphere:
      • wbacdiabh: Water-budget vertically integrated accumulated of diabatic heating from microphysics [K]
      • wbacpw, wbacpw[c/r/s/i/g/h]: Water-budget vertically integrated accumulated total tendency for water vapour, cloud, rain, snow, ice, graupel, hail [mm]
      • wbacf, wbacf[c/r/s/i/g/h]: Water-budget vertically integrated accumulated horizontal advection for water vapour, cloud, rain, snow, ice, graupel, hail [mm]
      • wbacz, wbacz[c/r/s/i/g/h]: Water-budget vertically integrated accumulated vertical advection for water vapour, cloud, rain, snow, ice, graupel, hail [mm]
      • wbacdiabh{l/m/h}: Water-budget vertically integrated accumulated of diabatic heating from microphysics at low, medium and high levels (same as cloudiness) [K]
      • wbacpw{l/m/h}[v/c/r/s/i/g/h]: Water-budget vertically integrated accumulated total tendency for water vapour, cloud, rain, snow, ice, graupel, hail at low, medium and high levels (same as cloudiness) [mm]
      • wbacf{l/m/h}[v/c/r/s/i/g/h]: Water-budget vertically integrated accumulated horizontal advection for water vapour, cloud, rain, snow, ice, graupel, hail at low, medium and high levels (same as cloudiness) [mm]
      • wbacz{l/m/h}[v/c/r/s/i/g/h]: Water-budget vertically integrated accumulated vertical advection for water vapour, cloud, rain, snow, ice, graupel, hail at low, medium and high levels (same as cloudiness) [mm]
  • Pressure interplation (Core)
    - hus_pl: specific humidity [1]
    - w_pl: vertical wind speed [ms-1]
    - uer_pl: Earth-rotated wind x-component [ms-1]
    - ver_pl: Earth-rotated wind y-component [ms-1]
    - ws_pl: wind speed [ms-1]


[editar] Missing variables

There are certain variables from CORDEX `Core' and/or `Tier1' which could not yet be introduced

[editar] snw: snow melt

Accumulation of melted snow

[editar] wsgsmax100: Daily Maximum Near-Surface Wind Speed of Gust at 100 m

The wind gust at 100 m is understood that should follow similar processes that the wind gust at the surface (like in wsgsmax). At this version of the module there has not been considered to be included in the search for the right equations and approximations.

[editar] ic_lightning, cg_lightning, tot_lightning: intra-cloud, ground and total lightning flashes

There is lightning scheme implementation in WRF. (lightning_option among other from namelist.input). It might require some adjustment prior it's use. It does not sees to provide a wolrdwide cloud/ground discrimination

Accordingly to the value given to the pre-compilation variable CDXWRF one obtains:

  • Without adding the variable: all CORDEX 'Core' variables
  • CDXWRF=1 CORDEX 'Tier' variables: clgvi, clhvi, zmla, [cape/cin/zlfc/plfc/lidx]{min/max/mean}
  • CDXWRF=2 The same as with CDXWRF=1 and additional variables: ua, va, ws, ta, press, zg, hur, hus, tfog, fogvisblty{min/max/mean}, tds{min/max/mean} and the Water-Budget relarted ones: wbacdiabh, wbacpw, wbacpw[c/r/s/i/g/h], wbacf, wbacf[c/r/s/i/g/h], wbacz, wbacz[c/r/s/i/g/h], wbacdiabh{l/m/h}, wbacpw{l/m/h}, wbacpw{l/m/h}[c/r/s/i/g/h], wbacf{l/m/h}, wbacf{l/m/h}[c/r/s/i/g/h], wbacz{l/m/h}, wbacz{l/m/h}[c/r/s/i/g/h]

Simultanesouly, one needs to modify the Registry/registry.cordex accordingly to the value of CDXWRF:

  • Without adding CDXWRF, nothing needs to be changed
  • Adding CDXWRF=1, one needs to remove the comment ##CDXWRF1## at the beginning of the line of the definition of certain variables
  • Adding CDXWRF=2, one needs to remove the comment ##CDXWRF1## and ##CDXWRF2## at the beginning of the line of the definition of certain variables

Additionally, now interpolation of 3D fields to pressure levels is only done at the same frequency as the output of the wrfpress file.

[editar] Others

It will be some other hard work to do related to it.

[editar] New variables

Pretty sure that as we get closer to stake-holders, decision makers, impact and mitigation communities more variables will arise... keep in touch !?

[editar] CF-compilant file

The module provides almost all the required all the CORDEX variables. However, user still needs to perform some postprocessing of the output data in order to meet CORDEX standards. Mainly:

  • Computation of the required different statistical values as daily, monthly and seasonal extremes (minimum, maximum, accumulations, means)
  • Cmorization of the output understood as: 1 file per variable, right metadata and attributes and general CF-compilant standard specifications

WRF output does not fully follows CF-conventions. Thus a huge coding effort needs to be done in order to provide a full CF-compliant output directly from it. User still needs to process the output of the model in order to provide data following all the CORDEX guidelines. Due to uncovered steps of the CF-standard, a user of the WRF model still needs to: concatenate files, change names and attributes of variables, calculate temporal statistics over different periods (daily, monthly, seasonal) and provide the right time-variables in order to fully reach the CF-standard which followed by CORDEX. However, these steps are computationally lighter and easier to perform in comparison to the computation of the different diagnostics and the vertical pressure interpolation already introduced in the module.

The incompatibility between WRF output and CF-convention can be overcame with the use of a complementary dedicated I/O library. This has been done for example in the [RegIPSL] platform (which uses WRF as atmospheric model) which uses [XIOS] libraries to manage the I/O.

[editar] Instantaneous values

As an additional work, all the instantaneous variables used for the different accumuluations and extremes, can also be retrieved. It is only necessary to:

  1. Give an output unit on the registry.cordex (see instructions at the end of the file)
  2. Uncomment in the code (phys/module_diagnostics_dirver.F and module_diag_cordex.F), the commented lines with the key word: INSTVALS
  3. re-compile WRF after cleaning all the code (due to the modification in the Registry)

[editar] WRF output names

Open page for the list of variables added with the module CDXWRFout

[editar] Acknowledgements

All the coders of WRF, LMDZ and ORCHIDEE models are acknowledged for their hard work on the developing and maintaining of the models. M. A. Jiménez from Universitat de les Illes Balears is acknowledged by her explanations on certain PBL calculations. D. Argüeso from UIB. V. Galligani, J. Ruiz and M. Sebastián from CIMA are also acknowldeged by their commentaries. A. Sörensson and E. Borrell are also acknowledged by their assistance. Implementation tests where performed in CIMA HPC resources ‘hydra’ cluster supported by the High Performance Computing National System (SNCAD) of Argentina L. Fita thanks the CIMA-IT support for their work. E. Katragkou and I. Sofiadis acknowledge the technical support and provision of resources from the Scientific Computing Center of [AUTH] and the [GRNET] National HPC infrastucture. J.Milovac gratefully acknowledge the support by the German Science Foundation (DFG) through project FOR 1695 and the supercomputing center HLRS in Stuttgart Germany for granting the computing time necessary for the test simulations. T. Lorenz acknowledges the support from the Research Council of Norway and its basic institute support of their strategic project on Climate Services. The simulations were performed on resources provided by UNINETT Sigma2 - the National Infrastructure for High Performance Computing and Data Storage in Norway. Figures were produced with python (except performarnce tests drawn with GNUplot) and L. Fita thanks the development of matplotlib above which he developed and make available a suite in python for netCDF management and plotting purposes called [PyNCplot]. Authors thank the commentaries of the topical editor (J. Kala) which remarkably improve the manuscript.

Obtenido de «https://wiki.cima.fcen.uba.ar/mediawiki/index.php?title=CDXWRF&oldid=1916»
Herramientas personales