-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sites output suggestion #74
Comments
I thing Dave and Alvaro have been developing the sites. The height are for now hardcoded for 20 levels, yes. |
In addition, the levels are probably defined for the old vertical levels, which are no more in use! |
Yes, this is strange now. Ideally I would prefer to change to an altitude-based system, or relative altitude system. I won't manage to do this any time soon though, since I find the coding in that module to be extremely difficult to follow. (The move to netcdf made everything too obscure in my view.) The idea of using -999 seems much easier though, although sites with high altitude would still need some hard-coded iz values in sites.dat. |
I am not sure what is meant here. Doesn't the code just use the iz index, and make use of KMID_MAX? Nothing about sigma, eta, or specific pressure levels? |
The surface is "easy", (one could simply replace 20 with kmax, as is done for columns). However the other levels depend on the vertical distribution of levels. We shifted from sigma to EC/IFS levels a few years ago, but I do not think the levels in sites has been updated. |
In the f90 code KMAX_MID is used, but think the "20" and other iz values only apply to the sites.dat file, and yes, those were calculated for earlier vertical levels. Specifying altitude would be a very good alternative, but it is so easily mis-used and mis-understood too. A site at 500m might need vertical profile and/or deposition correction if sitting on a 500m high plateau (hence it has a relative altitude of 0m, and should use iz=KMAX_MID), but if sitting on an isolated mountain in terrain of height 0m, the relative altitude would indeed to 500m and we should pick from some model level which represents that. Tricky! (Best might be to give station altitude and relative altitude in separate columns, so it is explicit at least.) |
For now I have implemented Massimos proposition (but not altitude in meters):
|
Hi Peter, |
I did not know that. Now I removed the "=", so at least we have the option for the future. |
HI @mvieno |
Hi Massimo,
I actually prefer (3) now, since relative altitudes as usually calculated compared to local topography (e.g. < 5km), and so best calculated using an off-line digital elevation model. Option (3) also allows the same Hrel to be used regardless of the underlying meteo resolution. One can also get Hrel from the TOAR database for some sites. However, I find that nothing is perfect, so it is good to have the chance to tweak the Hrel so that e.g. the diurnal variations come out best. (Sites with little day-night variation in O3 are probably on hills or similar, and might need higher Hrel to capture that. Beware coastal sites though which can also have no day-night changes despite being at sea-level.) |
Hi,
the sites.dat file assume that the EMEP model vertical layers are 20 (KMAX_MID=20).
for example for Auchencorth Moss:
Auchencorth_Moss 55.79323 -3.244781 20
This may create an issue as it is only OK if the model vertical layers are 20,
One option could be to add a "-999" and then assign the KMAX_MID:
Auchencorth_Moss 55.79323 -3.244781 -999! Default surface
I added this as a test near line 338 in Sites_mod.f90
s_gx(n) = ix
s_gy(n) = iy
if(lev==-999) lev=KMAX_MID
s_gz(n) = lev
A better solution may be to add -999 for the surface and the actual altitude w
Auchencorth_Moss 55.79323 -3.244781 -999 ! Default surface
Other_site 55.79323 -3.244781 200 ! Find the nearest layer at that altitude in m
The text was updated successfully, but these errors were encountered: