I need to provide HIRLAM Met fields to MATCH... I have a few questions:

-Where can I get ECMWF boundary conditions for Jan-Feb-March 2006 to run ?

-I need to provide a good data base for UV albedo, Does anybody know whatdata base can I use with Hirlam? (any suggestions for this information willbe very valuable)

Some data that you'll probably need:

-I'll run Hirlam 7.3bf1. (I mention this, just in case that the ECMWF or albedo data, need to be in a specific format)

-We are currently trying to compile the model in our cluster, but we'd like to have the additional data before, just to have a way to run a testcase. Besides this will give us time, just in case it's hard to obtain this information.

Best regards from the southern Hemisphere!

Felix Carrasco wrote:
Felix, I assume you do not have user access to ECMWF data? In that case I think one way to solve the problem is to ask colleagues in one of the ECMWF member services to fetch the boundary data for you. Let me know if you need help to find such connections.

But prior to this, I think you need to decide on which domain and resolution to run your HIRLAM experiments. In HIRLAM the experiment domain is defined via scripts/Env_domain and then specified in scripts/Env_expdesc by specifying domain name

Specification of a model domain may typically look like
RCR_7.4)
NLON=1162 # number of grid points in x-direction
NLAT=895 # number of grid pts in y-direction
NLEV=65 # number of vertical levels
SOUTH=-32.025 # coodnate of corner points
WEST=-49.875
NORTH=35.025
EAST=37.225
POLAT=-30.0 # coordinate of South pole
POLON=.0
NPBPTS=2 # Number of passive boundary points
NBNDRY=16 # width of boundary relaxation zone
;;
Note that by specifying POLAT/POLON differently from south pole the coordinate is rotated. You may choose to use geographic or rotated lat-lon coordinate for your case. I am not sure if it is necessary to use rotated lat=-on for the Chile area.

Once you have settled the domain size and resolution, you may ask our HIRLAM colleagues to assist with preparing the ECMWF boundary data for you.

Felix Carrasco wrote:
Normally you may take a look at the examples for various computer architectures in the directory src/config/config.$arch

It is likely that you may find from there an approximate match of the existing config file to that of your cluster. But write to forum or This email address is being protected from spambots. You need JavaScript enabled to view it. to ask for assistance.

(forward by xiaohua):

... I have a few questions about the Climatological database. First off all, Do I need all this climate data in HDF4 format? How did you generate that database? Will it depend on the gridsize that I need?
The only data that I can't download was the US-NAVY low resolution global data. the other are from public access.

By now my Hirlam grid is for Central Chile, will be defined for:
Lat:-36 to -32; Lon: -100 to -69. Using a 0.1 dlat and dlon (40x310 grid).
About the vertical levels I'll need to represent as high as possible, as you
mention in the post that representation that 65 levels, what's the maximum high of that?

%%%%%%%%%

Correct me if I'm wrong. But when you read the /src/config and /config/
files, it' possible to deduce, that each time that you run HIRLAM, the
models compile. It isn't like MATCH, that works with compiling an executable and then you run it with the inputs.

(i get this from hirlam.org/trac/wiki/HirlamHowto/Install/General)

Am i wrong?

.... Maybe it's a problem of me that I don't fully understand the contains
of each of the folders in the HIRLAM model tar:
ls 7.3/

config-sh
data
grads_scripts
scripts
src
util

The term Climatological database is probably an unluky description for the data. What the HDF files conatin is a bunch of physiographic data together with some crude climatological means for albedo, surface temperatures etc. -- You may want to read hirlam.org/trac/wiki/HirlamSystemDocumentation/Configure/ClimateGenerationhirlam.org/trac/wiki for more information.

And yes, you need these data in order to initialize Hirlam, at least one of the HDF file sets described in the above mentioned link. The HDF files will be used by the Hirlam system to create what in Hirlam terms is called the climate files

Please note that when you have configured your Hirlam domain, and you launch the model, the climate files for your model domain will be created by Hirlam for the months that cover your date that you run the model on. The input to this climate generation are the HDF files, and the output will be in GRIB format. The climate generation can take quite long - in some recent cases it has been reported that it can take more than 20 hours to run, depending on the configuration. So please be patient in the first time and don't kill the system just because it looks like nothing happens. As long as it does not abort by itself, it is usually running OK.

Once the climate generation files have been created, the model will start much faster, because the
major processings of the climate generation are skipped.

Felix Carrasco wrote:
it is 10 hpa at the top and around 12 m at the bottom,
see details in
hirlam.org/trac/wiki/SixtyfiveLevel

This is indeed not true. Normally there is a check in the script to make sure that IF and ONLY IF sources have been changed there will be recompilation/relink. And in addition, for regular runs in which no compilation is wished, one can also put BUILD=no in Env_expdesc to force over the build process.

config-sh contains the source version and local platform-specific settings;
data contains some constants such as needed in data assimilation and bufr tables;
grads_scripts is obsolete for most users;
scripts contains system scripts;
util contains some utility scripts which are obsolete for most users like yourself.

Felix Carrasco wrote:
Let me comment about your domain specification in this poster,.

I am afraid that the suggested domain has got too few grid points in north-south direction. A LAM model always needs some buffer zone for lateral boundary relaxation and HIRLAM typically defines around 8 points at each horizontal direction for relaxation, in which the weights of host model 'boundary value' drops from 1 at the boundary to 0 toward inner points. Thus with a NBNDRY=8 (as defined in scripts/Env_domain) you'll only have 40-8*2=24 grid points as your inner model domain for serious computation. This is not so ideal to me. Maybe you shall consider something like 100x310 instead of 40x310.

By the way, please choose LHHITER=yes in your Env_expdesc to allow a bit more flexible choice of number of grid points in X-direction (nlon).

Another thing to consider, when you set up your run, is that for a small domain, the impact of lateral boundary is very dominating. Since your targeted experiment period is winter 2006 when the resolution by the ECMWF model was a bit coarser than today T511 (or ca 40 km, Jan 2006) and T799(or ca 25 km, Feb/March 2006) , and in practice it is only possible to get analysis data from then for LBC, (thus with an updating frequency of only every 6 hour), there is a great risk that rapidly developing system that pass through your lateral boundary can not be representated sufficiently well, please be aware of this when you design your domain/experiment.

I guess one way to improve on such situation would be to design your experiments with a double nesting, i.e., one may set up two HIRLAM experiment, one coarser one (e.g. 0.3 degree) covering a bit larger domain and nexted to ECMWF boundary. Another one with 0.1 degree resolution to be nexted to the coarse resolution run, using the coarser resolution forecast run as lateral boundary, the update frequency of the latter can be made hourly, thus overcoming the potnetial risk of losing fast moving system.

Of course a double nesting system maybe more expensive to run, but at least you can avoid some of the deficiencies associated with a very small domain. The cost for a coarse resolution model itslf is limited.

Dear Felix,
I have not been reading all posts too carefully, but concerning the climate generation: please define your domain and we will create the 12 basic climate files for you at ECMWF. No need to obtain the HDF files and stuff to do this locally. This is how most people work here. I have run some test experiments over Southern Andes last year, Climate generation for those experiments was quite automatic as always, as the HDF files are global. The files cl00nn0000 are grib files, independent on any computer architecture and such, transferrable from ECMWF to your local system. I will not be around e-mail for two weeks now, but after that I could run your climate generation.

Thanks for all the answers, Now I think I have a little bit of understanding of how to run a model experiment. According to Xiao Hua it's better to have a big domain, that will avoid any complications of the resolution. So as we have some data from HIRLAM (it's old, from 1999 from a Job of Laura Gallardo and SMHI collaboration), I took it as a reference and I have a proposal, hoping to have feedback:

NLAT=260
NLON=130
NLEV=65
SOUTH=-41.
WEST=-76.
NORTH=-15.
EAST=-63
POLON=.0
POLAT=-90.
NPBPTS=2 # Number of passive boundary points
(I don't understand NPBPTS, Any explanation?)

NBNDRY=8 # width of boundary zone
GPHALO=6 # Number of halo-zone points in grid-point model
NDTIME=600 # dynamics time step (s)
HDFSET=regular # old, regular, 9000: climate data set projection
HIRES=0.025 # resolution of climate data sets (as per available)

So maybe this can help to generate the climate database that Laura offer to me (variables HDFSET and HIRES). This variables should include the topography, land cover, Albedo??

Best Regards!

Dear Felix,

there is one small issue related to the number of longitudes, which is because of the Helmholtz solver or something: you need to define nlon so that it is 2**k* 3**m * 5**n + 2*(npbdpts+1) . (k,m,n are any integers). Thus, e.g. 126 (2**3 *3 * 5) and 134 (2**7+6) fulfill this condition, but your 130 does not. If you want a resolution of 0.1 deg (11 km), you need to tune the east/west accordingly, Another thing, you might consider polat something like -120 (hope such negative < -90 definition exists) which would move the Equator closer to the central latitude of 28S of your SH domain. Perhaps this is not that important, after all. If you use no rotation as you suggest, some other things may be easier to handle in the standard lat-lon coordinate. NPBDPTS is the number of passive boundary points, which is usually set to 2. If This is related to the handling of lateral boundaries.

Otherwise, your domain seems O.K.

Forgot about the climate files. They are needed to run the experiment, but in fact during the experiment many of the contents will be replaced. For example, albedo and orographic roughness from the climate files will never be used. This is for historical reasons. There is a piece of code called src/phys/ini_veg.F which contains tables used in the experiment. In general, the ECOCLIMAP data base used by Rossby centre and by the SURFEX in HARMONIE contains more reasonable physiography. We have run experiments in Tanzania, where some of the ECOCLIMAP fields are introduced into normal HIRLAM instead of the ini_veg stuff. For example, the leaf area index from ini_veg is more or less nonsense for you latitudes. The orographic parameters should be O.K., but please bear in mind that the surface elevation field is filtered, smoothed on purpose. The things filtered out will influence via parametrizations (MSO-SSO, radoro).
I am leaving for holidays, but could try to start climate generation for your domain in ECMWF some day next week if needed.

Thanks Laura! I'd rather to have more points, so 134 for NLON is good for me, this means that
WEST=-76.4 in order to set the parameters. Something that I did not have clear enoough is about the proyection that I'll use for my Hirlam fields, basically because I don't knw where to set the parameter related with this. You mention that rotated lat-long, that means that it comes from how I set Polon and Polat?

For me, it's good to start the generation of the climate fields anyday of nextweek, and thanks for the information related with Albedo and orographic data. I'll keep it in mind!

Enjoy the holidays!

Felix,

According to your domain definition and Laura's suggestion of polon -120 your domain would apprx. look like this (Coordinates are in rotated lat - lon grid, nevermind the constant value warning). Is that OK for you, or you'd still like to increase your first experiment coverage a little bit?



I'm editing this now, be right back.

Martynas picture shows how the rotation works. What we mean with POLON and POLAT are the regular geographical coordinates of the South Pole. If we move POLAT, we can create a situation where the Equator is in the middle of our domain, e.g. here at 60N if we would say that POLAT=-30, you might choose this -120 which Martynas has now shown to work.

POLON defines along which longitude your rectangular domain points to the pole. Thus, it defines the direction of your box at the map. Chile is quite N-S directed anyway, not like Norway for example where quite an exotic combination of POLON and POLAT needs to be chosen to define a domain which optimally covers the country. When we are at Equator, deltax and deltay are about of the size, which is not the case in nonrotated lat-lon far from Equator.

Hope this helps. I can start your climate generation as soon as you are happy with your definition.

Seems that I was playing with this domain around your latitudes, only to provide an example of cross-section (attached). This domain is surely too large for you because you need longer run, and only to provide forcing to an air quality model. Seems that I have not changed rotation here, perhaps it is indeed not necessary.

SANDES)
NLON=306
NLAT=296
NLEV=60
SOUTH=-40.06
WEST=-80.00
NORTH=-20.00
EAST=-59.26
POLAT=-90.00
POLON=0.0
NPBPTS=2
NBNDRY=8
GPHALO=8
NDTIME=120
HDFSET=regular
HIRES=0.025
;;