I have encountered transport artifacts near the geographic poles when using meteorological fields on a latlon grid. This could be a bug or a weakness in the transport method. I would appreciate knowing if there is a fix or if this is just a known weakness.
I've attached figures to demonstrate the effects. I started a matrix of trajectories northward of 89.2 °N (spaced every 0.2° latitude and every 30° longitude), then run 3 hour forward trajectories. Some trajectories converge on the pole in order to pass over it then diverge on the other side, which is unrealistic. Trajectories that start further from the pole tend to move tangent to latitude lines, which is suspicious but possibly realistic. The attached figures reproduce these features with 4 different meteorological fields (GFS 1°, GFS 0.5°, GDAS 0.5° NCDC) for selected times in the last 6 months. All figures were generated through the HYSPLIT website. I've reproduced similar patterns with other meteorology on my own computer.
I would appreciate any help understanding and correcting this issue. Thanks.
Transport artifact at poles

 Posts: 660
 Joined: November 7th, 2012, 3:14 pm
 Registered HYSPLIT User: Yes
 Contact:
Re: Transport artifact at poles
Thank you for pointing out this issue. We will look into this and get back to you.
Re: Transport artifact at poles
Hi, has this issue been looked into? Or resolved? Thanks.
Re: Transport artifact at poles
The problem is that velocity is converted to grid points per unit time at each met grid point and
then the velocity at the computational particle position (in grid points per unit time) is calculated. This causes issues at the poles because
(A) the grid spacing at the pole is zero, so velocity in grid cell/ unit time cannot be calculated.
HYSPLIT gets around this problem by simply using a spacing which is a little off of the pole.
(B) This scheme relies on spacing between adjacent grid cells representing about the same number of meters, and near the poles, this assumption doesn't hold.
So the velocity interpolation near the poles is not as good as it could be.
The solution is to compute the velocity at the computational particle position in meters/second and then convert
to grid cell per second. We've done this, and it works, but there is still some work and testing to be done
before it is ready to go out.
We plan to release the next version of HYSPLIT in the spring 2020.
then the velocity at the computational particle position (in grid points per unit time) is calculated. This causes issues at the poles because
(A) the grid spacing at the pole is zero, so velocity in grid cell/ unit time cannot be calculated.
HYSPLIT gets around this problem by simply using a spacing which is a little off of the pole.
(B) This scheme relies on spacing between adjacent grid cells representing about the same number of meters, and near the poles, this assumption doesn't hold.
So the velocity interpolation near the poles is not as good as it could be.
The solution is to compute the velocity at the computational particle position in meters/second and then convert
to grid cell per second. We've done this, and it works, but there is still some work and testing to be done
before it is ready to go out.
We plan to release the next version of HYSPLIT in the spring 2020.