A short survey of the T2m in the different GLAMEPS members shows that there are significant problems with the SST's in the HIRLAM and ALADIN members.

One can see the problems very clearly in the following link:
www.knmi.nl/~tijm/HIRLAM_MONITOR.html
and the animation under "SST-problems HIR & ALADIN members GLAMEPS"

The EC SST looks OK, the ALADIN SST is a bit cold close to the coast, and for the Netherlands a significant portion of land East of Amsterdam seems missing. This land was already reclaimed from the sea in 1968, so why it is still missing in the ALADIN surface description puzzles me.

Especially the HIRLAM SST looks bad. All along the coastline you can see very low T2m caused by the low SST. It is the same problem that we have seen in the run in the Caribean Sea with HIRLAM 7.3 (HIRLAM 7.4 has the same problem) and caused by the 0 degree C values in the ECMWF SST's over land in the forecast boundaries. The easiest solution is not using the forecasted SST's in the boundary files but the analysed SST's.

This issue should be fixed as soon as possible in the GLAMEPS runs, because it has a big impact on the behaviour of the model close to the coast. About one week ago we had a case with significant precipitation (up to 100 mm in 24 hours) in the northwestern part of the Netherlands, which was forced for a significant part by the warm sea water, and GLAMEPS only gave 10-20% chance of more than 10 mm of precipitation.

Sander,
Is it also possible for you to plot the SST or T2m from the CONTROL members of both HIRLAM_KF, HIRLAM_ST and ALADIN?
I think all ensemble members of the HIRLAM components in GLAMEPS now have its own surface purturbation, but as least for control members the script seems to point to that of ANALYSIS of the ECEPS. Since the ECEPS member in your plot shows normal SST pattern while the displayed HIRLAM and ALADIN members suffer obvious problem, it is worth digging into and understand why.

Xiaohua,

I have looked at a number of members of the HIRLAM part of the ensemble (e.g. STRACO control and members 1,2,3, KF-RK control and members 13, 14, 15) and all HIRLAM members show the same problem with the SST as shown in the plots in the animation from the link in my first post.

The same is true for the ALADIN members, they all show the same problem with much less variability in the SST than in the surface temperature over land.

The HIRLAM problem is clearly the same problem as we have seen with HIRLAM 7.3 for the Caribean Sea, zero degrees C temperature for the SST in the ECMWF land points, which translates to a steep gradient in SST close to the coast in the HIRLAM grid (interpolation between valid points in the ECMWF SST and the zero degrees C points over land).

Our solution for that problem is to put the analysed SST with missing values for the land points in all the forecast files. If you put that in a cycled run, then the SST problem will probably be away after 1-2 weeks. For our Caribean run we have now implemented this for a week and the problem has been diminished by 50%, so we probably need another 1-2 weeks before the whole problem is away. A cold start may therefore be better to quickly solve the problem.

Where the ALADIN problem comes from I do not know, there the ALADIN experts may have the answer.

Jeanette mentioned that there seem to be more general problems in the temperature forecast than only the SST:
"I also do not believe that the behaviour that can be seen in your plots is due to SST alone. The same kind of high bias of the HIRLAM EPS controls consistently occurs throughout Europe. I was wondering whether this is due to an error with a “yearly cycle” nature (as Sander suggests) or one which has simply been introduced into GLAMEPS-v1 at some time. Looking at your graphs, it seems to me that up until April, the HIRLAM control run error behaviour for T2m is fairly comparable to ECMWF (similar bias, somewhat worse sd), but from May onwards it starts to go wrong (increasingly). The “increasing” part is consistent with Sander’s conjecture of an error with a yearly cycle nature, but I am wondering if it worth while to look more closely at any changes made in the HIRLAM part of the GLAMEPS system during late April and/or May, and check whether those are “suspicious” or not? "

Looking a little bit further in the error of the temperature, it is clear that the problem is largest in the coastal area (around 3K in the Summer) but there also is a problem with the temperature in more inland areas. It is clear that this problem is not caused by the SST, but it seems to point more in the direction of a problem with the data-assimilation. If you look at the development of the error in T2m during the forecast for the control members, then the error at t=0 is almost the same as the error at other time steps in the forecast. It therefore seems that the T2m analysis does not work or does not work properly, as other HIRLAM versions have a much better T2m at t=0 than later in the forecast. Even a model version that has significant problems during the forecast shows a much better T2m at t=0.

See the plot below.

This is a bug in the Climate script:
hirlam.org/trac/browser/trunk/harmonie/scr/Climate

in the namelist nam923_smoothing_description, line 140:
LNLSM=$NLSM,
has to be:
LNLSM=$LNLSM,

ie. the correct land sea mask form the surface should also be used for the atmosphere

Jisk Attema wrote:
Jisk,

I saw that Ulf committed your suggested change in July,
hirlam.org/trac/changeset/10875/trunk/harmonie/scr/Climate
Of course that correciton was too late to be included in 37h1.1. I htink it is worth a warming here to all that climate generation for all existing tagged version may have suffered same bug, thus it preferably shall be redone even for daily runs based on earlier releases.

When committing the above suggested changeset in July, Ulf forwarded en email from Jan from Bert, a KNMI coleague working on RACMO, about the detection of this particular bug. I take liberty to quote the excertp below.

I am uncertain if the ALADIN component in GLAMEPS also suffer similar problem in climate generation. If so, it indeed could explain part of the odd features as reported in the recent discussion about coastal SST issue. I'll report in separate recent findings and remedy in GLAMEPS about the latter.

Greetings, Xiaohua

Following is quote from dr. L.H. van Ulft's email to Ulf in Jan. 2012.

Hi Xiaohua Yang,

yes, the bug with the land sea masks being different between atmosphere and surfex is already fixed in some new version.

The mail you quote is talking about a different problem: points with a land-sea-fraction of exactly 0.5 were treated inconsistently: sometimes land, sometimes sea. As i understand it, Ulf had a look a it, and it should be better now. I am not sure if they are exactly the same at the moment; the atmospheric land-sea mask is spectrally filtered, i'am not sure the filtered mask is then used in surfex..

Another issue with the land-sea masks, is that gl_grib_api creates a single surface temperature field from the boundaries (that is a combination of the SST and surface-skin-temperature over land, depending on lsm). For points that are partly sea, partly land (ie. 0 < lsm < 1) this one temperature is used to initialize the whole tile: both the land and sea part. However, there can be quite a difference (several degrees) between SST and Tskin, especially at mid-day. So the coastal area can end up with a large bias. The SST is not updated during a run, so the bias wont disappear during spin-up.
You can easily see this when comparing a run starting at noon with a run starting at midgnight.

Xiaohua Yang wrote:
The above was written quite some days ago, I update now part of the findings about SST and ice in the GLAMEPS.

In both HIRLAM and ALARO members as used in GLAMEPS, ECMWF SST and ice cover are used either as pseudo observation or background in surface analysis. In the deterministic HIRLAM, it had been reaslised that the SST and ice information in the ECMWF data at ANALYSIS time does not assign value on land point, i.e., UNDEFINED. For some reason, from the forecast data stream, land points are given a somewhat artificial value. In view of these difference, HIRLAM since 7.2 release specified in the scripts to acquire ECMWF SST and ice data from ANALYSIS, instead of FORECAST data stream. The interpolation and surface analysis scheme will then take it into account when encountering undefined SST value over land points. The HARMONIE GL interpolation procedure, which ALARO model component in GLAMEPS uses, have also taken this into account.

However, in GLAMEPS, the implementation so far failed to take the subtle difference in ECMWF sst and ice data stream between analysis and forecast into account. When interpolation procedure see the 'continuous' data from forecast file of ECMWF/ENFO, a normal interpolation is done, which results in often an unrealistic gradient at coastal area. The erroroneous sst gradient at European coastal area appears to have caused severe consequence on resulting T2m forecast, with the negative impact sprending over not only coastal area but whole model domain. The SST problem here is assumed to be one of the main cause for the abnormally larger T2m bias in GLAMEPS members.

Last week, a solution has been implemented in the daily GLAMEPS suite in which data stream for ECMWF SST and Sea Ice was changed from ENFO data stream to that of the deterministic ANALYSIS data. The positive impact of such change is immediately visible from the monitoring of the T2m behavior in the GLAMEPS controle run. see e.g. the wiki interface

hirlam.org/portal/glameps/WebgraF/ObsVer...l?choice_ind=Surface

The attached plot shows the time series of the T2mstd and bias for GLAMEPS domain, comparing control suites of HIRLAM-KF (blue), HIRLAM-ST (magenda) , ALARO (green) and ECEPS (red) models, as well as the ensemble mean (cyan) for the current month.