ERA as met input questions

Post questions and find resources to convert meteorological data into a format HYSPLIT can read.
Post Reply
jgrunau
Posts: 1
Joined: May 15th, 2026, 11:51 am
Registered HYSPLIT User: No

ERA as met input questions

Post by jgrunau »

Hi everyone,

I'm new to working with HYSPLIT and would appreciate your input on a few issues I have faced, mostly related to using ERA5 as met data. My goal is to calculate 24-48h daily (potentially sub-daily) backward trajectories across 5-10 years in thousands of locations in Germany to investigate the effect of trees on air pollution. I am using era52arl for the conversion (see attached .cfg file for details how I implemented it). I have checked out the HYSPLIT user guide and several forum posts, but some open questions remain. As I'm an environmental economist by training, I'd appreciate your expertise a lot.

### 1. What is the appropriate model top for Hysplit + ERA5?

Is it possible to provide a general answer to this question? If I remember correctly, the model top in GDAS was 15500 when using it on the web. Are there any disadvantages to using a similar setting or something like 20000 for my European context?

### 2. Drop friction velocity `USTR` and setting `KBLS`

The README shipped with `era52arl` notes that ERA5 `friction_velocity` is biased small, and suggests that users may want to drop `USTR` and run with `KBLS=2` instead of `KBLS=1`. So I suppose I should follow that? Or are there scenarios in which I should not?

### 3. Cloud cover `TCLD` units / scaling

The ARL format guide lists `TCLD` (total cloud cover) in percent, but ERA5 `tcc` is a fraction (0–1). The installed `era52arl` default cfg and mine both use a multiplier of `1.0`, which leaves ARL `TCLD` as a fraction rather than as a percent.

- Should the cfg multiplier be `100.0` to match the ARL %-units spec?
- Or does HYSPLIT consume `TCLD` consistently in whatever units the ARL carries, so `1.0` is fine in practice?

### 4. Heat-flux / DSWF sign

The `era52arl` README states that HYSPLIT expects upward heat flux to be positive while ERA5 uses the opposite convention, so the `sshf`/`slhf` cfg multipliers should be negative. I am using `−0.00028` for `SHTF` and `LTHF` accordingly.

For `DSWF` (downward shortwave) I currently use `+0.00028`, on the assumption that `ssrd` is downward and positive in both ERA5 and HYSPLIT conventions, so no sign flip is needed. However, the `era5utils.py` helper in the `hysplit_metdata` repo appears to apply the same *negative* accumulated-field multiplier to `DSWF` as it does to `SHTF`/`LTHF`, which would contradict my setup. Which is correct — should `DSWF` carry a positive or a negative multiplier?

### 5. Variables I currently omit

I currently do not pull `MSLP` (pressure at mean level), `UMOF` (u-momentum flux), `VMOF` (v-momentum flux), or `RGHS` (surface roughness). Especially for the latter I am not sure whether omission is fine for my case.

### 6. Reduced pressure level set

As downloading ERA5 data takes ages, I am considering downloading only a reduced set of pressure levels (such as only 1000, 925, 850, 700, 600, 500, 400, 300, 250, 200, 150, 100, 70, 50, 30, 20, 10, 5, 1 as these are provided on the Destination Earth platform). I am sure there is no generalisable answer, but can I expect similar trajectories by omitting the rest of the 37 pressure levels?

### 7. Reduced geographical scope

Also related to data download constraints, I am considering subsetting the data such that I have a box that mostly covers Europe's land as I am interested in the forest cover along the backward trajectories. Is it correct to assume that even if a 48h backward trajectory originated outside the box, the path inside the Europe box should still be the same?

Thanks a lot for your help! Even if you can answer only one question, that would be of great help to me.
Attachments
cfg_setup.txt
(929 Bytes) Downloaded 76 times
alicec
Posts: 443
Joined: February 8th, 2016, 11:56 am
Registered HYSPLIT User: Yes

Re: ERA as met input questions

Post by alicec »

### 1. What is the appropriate model top for Hysplit + ERA5? Is it possible to provide a general answer to this question? If I remember correctly, the model top in GDAS was 15500 when using it on the web. Are there any disadvantages to using a similar setting or something like 20000 for my European context?

Set the model top a few vertical levels above your region of interest. HYSPLIT will not use meteorological data above where you set the model top. Trajectories that go above the set model top are not automatically cutoff but will continue, assuming persistence of the highest level. Therefore the accuracy of any trajectories above your model top will be degraded significantly. Changing the model top can result in some differences, usually small, in trajectories as it will change how the model terrain following vertical levels are setup.

### 2. Drop friction velocity USTR and setting KBLS The README shipped with era52arl notes that ERA5 friction_velocity is biased small, and suggests that users may want to drop USTR and run with KBLS=2 instead of KBLS=1. So I suppose I should follow that? Or are there scenarios in which I should not?

This is only relevant for dispersion simulations and will have no effect on trajectories.

### 3. Cloud cover TCLD units / scaling The ARL format guide lists TCLD (total cloud cover) in percent, but ERA5 tcc is a fraction (0–1). The installed era52arl default cfg and mine both use a multiplier of 1.0, which leaves ARL TCLD as a fraction rather than as a percent. - Should the cfg multiplier be 100.0 to match the ARL %-units spec? - Or does HYSPLIT consume TCLD consistently in whatever units the ARL carries, so 1.0 is fine in practice?

TCLD is not relevant for trajectories or most dispersion runs.


### 4. Heat-flux / DSWF sign The era52arl README states that HYSPLIT expects upward heat flux to be positive while ERA5 uses the opposite convention, so the sshf/slhf cfg multipliers should be negative. I am using −0.00028 for SHTF and LTHF accordingly. For DSWF (downward shortwave) I currently use +0.00028, on the assumption that ssrd is downward and positive in both ERA5 and HYSPLIT conventions, so no sign flip is needed. However, the era5utils.py helper in the hysplit_metdata repo appears to apply the same *negative* accumulated-field multiplier to DSWF as it does to SHTF/LTHF, which would contradict my setup. Which is correct — should DSWF carry a positive or a negative multiplier?

This is correct. DWSF should be positive. This is an error in the hysplit_metdata scripts which I just fixed. DSWF will not be relevant for trajectories.


### 5. Variables I currently omit I currently do not pull MSLP (pressure at mean level), UMOF (u-momentum flux), VMOF (v-momentum flux), or RGHS (surface roughness). Especially for the latter I am not sure whether omission is fine for my case.

These will not be relevant for trajectories.

### 6. Reduced pressure level set As downloading ERA5 data takes ages, I am considering downloading only a reduced set of pressure levels (such as only 1000, 925, 850, 700, 600, 500, 400, 300, 250, 200, 150, 100, 70, 50, 30, 20, 10, 5, 1 as these are provided on the Destination Earth platform). I am sure there is no generalisable answer, but can I expect similar trajectories by omitting the rest of the 37 pressure levels?

Omit any pressure levels that are above our model top as they will not be used anyways. Avoid skipping pressure levels within the vertical levels that you are studying.


### 7. Reduced geographical scope Also related to data download constraints, I am considering subsetting the data such that I have a box that mostly covers Europe's land as I am interested in the forest cover along the backward trajectories. Is it correct to assume that even if a 48h backward trajectory originated outside the box, the path inside the Europe box should still be the same? Thanks a lot for your help! Even if you can answer only one question, that would be of great help to me.

Yes, the path from the ‘start’ of the backward trajectory to the time it leaves the model domain will be the same.
Post Reply

Return to “Conversion programs”