RAiDER
RAiDER copied to clipboard
dbekaert
Differences between slant and ray-tracing
Slant computed through projection from Zenith and that of ray-tracing on slant direction should be the same.
They can only be the same for a constant ideal weather model. This should be a unit test.
There are a few things to check:
- [x] Are both workflows using the same DEM in the code?
- [ ] Are we making same assumptions on Geoid and ellipsoid?
- [x] Are you intersecting the cube afterwards with the same DEM?
Above is ZTD projected to LOS? RAY is the ray tracing output or the difference?
Above is ZTD projected to LOS? RAY is the ray tracing output or the difference?
Sorry I had the titles mislabeled. From left to right: ZTD projected to LOS (using orbit files) output, RAY tracing output, and the difference between the two outputs (middle column - left column)
Ray tracing systematically being lower than LOS projection at west end of the image might also suggest that there is not enough support in the weather model cube for ray interpolation. I would check that as well.
I think that may be the issue. In the former figure, I computed height levels from -500 to 9500 m in 500 m intervals. Here, I computed them in 100 m intervals. Also notice the difference in lower bound of colorbar
The data is right looking ascending? The rays at west (near range) are shorter because of lack of support in that case. If you end up increasing the top of the atmosphere, for ray tracing you will need to increase the padding as well as the rays would need support.
But if user specifies the height levels they are interpolated from the 3D cube of the model, where they are hard-coded at fixed steps. So are we missing something in the model or what is the cause for seeing water?
I mean the height levels available as part of the weather model that get used. Each ray is intersected with the model heights. If you truncate at 30km vs 80km or use all levels provided by the model. You will need greater support for 80km than 30km.
yes i understand that part. We should add a larger spatial buffer (long lat bufer). Depending on left or right looking, one side would need more.
I was more puzzled why the increase in number of steps in vertical would impact it. Internally we use the maximum available height in the model; when a user specifies height intervals the final cube is just re-interpolated to match the user requested heights.
Do we have a good idea of what zenith delay vs hgt profiles look like? Can we generate some of these 1D plots at 10m steps. Maybe that will inform how to space the layers - uniformly or non-uniformly etc. 10m 3D cubes might be too expensive - I feel like 100m also might be too expensive. Being smart and using a non-uniform grid in height might help possibly.
Hopefully these are helpful. The two curves per panel are different locations, about 5 km apart and 275 m elevation difference.
Thank you. These look great. My gut feeling is that for dry delay, 500m should be more than enough. For wet, there seems to be 2 regimes. One up to 3-4K or so and another higher than that. There may be some room for optimization here without having to use a dense set of heights all the way to 10K. It will be a tradeoff between little bit of complexity vs additional storage
@bbuzz31 @jlmaurer have we close the loop on the buffering to remove the tilt like residual?
This is being fixed in #506. The tilt is removed when buffering is increased.