Issues with Mapping Functions.

[Lars0001]

Hello!

I am processing GNSS data with goGPS for PWV estimation purposes and I'm having some issues and doubts concerning the Mapping Functions.

My first problem is that each Mapping Function seems to introduce a mm-cm magnitude bias in the altimetric component.
Here one example for ZIM3, only GPS constelation, month of november of 2021. The 0 line correponds to the IGS weekly solution for the 15th of november. Bernese data (in black) was processed using Niell Mapping Function.

I'm aware that small differences can exist between different MF models but I have the impression they should be more subtile. This data was processed with a sin(el) satellite weighting, 7º cutoff angle and stations that count with reasonably dense skyplots. As far as I have read in a quick search (1 and 2), a few mm differences can be expected in low elevations, but not overall.

My second problem concerns the ZWD estimation. On the one hand, the ZTD is biased too depending on the MF (which is logical given that altimetry is biased).

But, most important, on the other hand, ZHD estimates can vary a lot between different models, specially in the case of VMF3 (in this case I used the 1ºx1º grid):


This is an important detail because these differences can modify the fluctuations and peaks observed in the ZWD and PWV and cause problems when trying to correlate them with precipitation events.

VMF3 was my first choice because it is supposed to be more refined, but with these biases I am now doubting on which MF to choose.
I performed a test with 19 IGS stations taking the IGS weekly position as a reference, but I cannot draw any clear conclusion about which MF is the best (it actually seems to depend on the station, here are some of the results: position_MF.pdf, ZHD_MF.pdf).
Any clue of where these biases can be coming from? Any recomendations?

Thank you!

[clicat]

Dear @Lars0001 thank you for your exhaustive report. I run the same test you did with our internal software BREVA (based on goGPS) and the results are quite different. I'm sorry to report that in the current version of goGPS on GitHub there are quite a few bugs but I have tons of modification to push and it might take me a little while to do it.

The two main bugs are related with ZHD extraction from VMF maps, and weighting functions. The first was completely wrong due to some mistakes with handling of the angles (radians/degrees), the second was causing any weighting method not work properly with the exempt of uniform.

I reprocessed one month of ZIM3 with the following commands (they might be incompatible with you the actual goGPS).

I loaded 5 times the ZIM3 station and processed it with the following combination of parameters:

1. GMF - Saastamoinen from GPT => station renamed to GMF1
2. VMF1 - a-priori from VMF1 => station renamed to VMF1
3. Niel - Saastamoinen FROM GPT => station renamed to NIEL
4. VMF3 1x1 grid - a-priori from VMF3 1x1 grids => station renamed to V3_1
5. VMF3 5x5 grid - a-priori from VMF3 5x5 grids => station renamed to V3_5

Let me go through all your findings.

Positions

The positions are stable in the planar component among different tropospheric approaches (as expected).
The up component do not show a clear bias as in your test, but there are differences mostly dependent on the a-priori ZHD used.

I also tried to use for all the solutions the same ZHD as reference (Saastamoinen + GPT1) and in this case the differences became less important but still noticeable. This can be also reflected in closer values of ZTD

ZTD Estimation

ZTD are now less biased (I think) due to less biased coordinates

As before with the same ZHD a-priori all the solutions got closer

ZHD reference

We have seen as the reference ZHD is important for the final estimation of the positions / ZTD.
Here is what it looks like with a non bugged loader:

The differences are important - even among the 3 versions of VMF (the grid size I believe it's the thing that most impact introducing interpolation error). For GMF and Neil I used the same Saastamoinen model.

I will try from the the next week to push back to goGPS most of the bugs solved in our internal version, thank you again for your post here, it really helped and it is remembering me that I need to import the corrections made in our software to the main goGPS repository.

As soon as a new version of goGPS will be available I'll post it here ;-)

P.s. I couldn't make the comparison with the IGS solutions because at the moment the FTP of IGS seems unreachable to me.

[Lars0001]

Hi @clicat .

Thank you very much for taking the time to give such a detailed answer. This really helps me.

So, as far as I have understood, the ZHD extraction from VMF is not working in the current version of goGPS and therefore is very probably introducing a bias/distortion in both altimetry and ZTD/ZWD estimation. I thus conclude that using Saastamoinen-GPT is more cautious by now. In your Breva results I can see that a correct use of VMF ZHD indeed really influences the fluctuations in ZWD estimates (possibly makes them more exact). I will be looking forward for next goGPS updates correcting this bug! :-)

On the other hand, I still have one doubt concerning your plots. When you plot the ENU results, what does the 0 line in each dimension correspond to? I think that goGPS takes the mean value of the time series as the 0 point when plotting the results of a given processing. If it's the case with Breva too, could it be that this fact is hiding the bias existing between the different results? (In my case, I calculated all the ENU coordinates with respect to a fix position (IGS position), so this allows to appreciate the biases).
(IGS weekly solution position ECEF(m) for ZIM3, in IGb14, the 15th of november 2021 (file igs21P21841.snx):
X = 4.33129963975159e+06, Y = 5.67537626458974e+05, Z = 4.63313391194070e+06).

Also, related to the weighting function bug you mentioned: are you refering to the satellite elevation dependent weighting function? sin^2(el) weighting was giving me some problems so I adopted sin(el) as the good one. Let me know if there is any bug with this one too, please!

Thanks again for your answer and the all work you do with goGPS in general.
Best regards,
Leire.

[clicat]

Ooooh you are totally right about the plots, in BREVA I have the option to use the barycentric position of all the coordinates as center of the local coordinates, but usually I don't use the option (rarely I plot multiple coordinates of the same station). I'm going to enable this option to appreciate the biases.

You are totally right about your conclusions: ZHD extraction from VMF is not working in the current version of goGPS and using Saastamoinen-GPT is more cautious by now.

I do not remember exactly how the bug on weighting function affected the results, I know that using anything but uniform was introducing a wrong weighting of the observations.

In the current version of goGPS there is also a bug related with regularisation parameters misinterpreted in the tropospheric parameters, the next update will be a lot more stable, I promise. It fixes numerous errors and stabilise parallel execution.

And now let's have a look at the positions:

Here the old plots:

Using different ZHD - the median point of each solution is the center of each local coordinates

Using same ZHD - the median point of each solution is the center of each local coordinates

Here the new ones:

Using different ZHD - the barycentric point is the center of the local coordinates

Using same ZHD - the barycentric point is the center of the local coordinates

The bias is present among different approaches but as far as VMF are involved now, in Breva, they are pretty consistent each other.

Thanks again for your contribution, it is thanks to people like you that I'm pushed into spend time improving back goGPS!

[Lars0001]

Thank you again @clicat.

Following your observations about the problems with the ZHD extraction, I reprocessed with the same Mapping Functions (Niell, VMF1 and VMF3 1ºx1º) but using Saastamoinen-GPT a-priori model for all of them.

Thanks to the consistency of ZHD model, most of discrepancies in ZWD fluctuations seem to disappear (good!):

However, biases persist in the altimetric component and ZTD estimation and don't seem to improve with respect to the processing using VMF ZHD. And they still are far more noticeable than those you obtained with BREVA:

So: could it be that ZHD extraction is not the only problem with VMF in the current goGPS?

I'm aware that it is a lot of work to analyse all this problem and find an answer to this question. I don't expect so, I just leave it as an open question in case it could be usefull for future improvements of goGPS. For myself, I will stick to the Niell MF until new updates are pushed.

Grazie mille!
Leire.