SuperDARNCanada / fitacf.3.0

The repo for the new and improved fitacf routine
GNU General Public License v3.0
0 stars 1 forks source link

Xphi0 change #6

Closed kkotyk closed 7 years ago

kkotyk commented 7 years ago

I broke git and this needs to be remerged. I added the fix that caused this change to segfault in the first place

egthomas commented 7 years ago

I no longer get the segmentation fault when processing the handful of rawacf files I've tried today. Should I go ahead and merge this?

kkotyk commented 7 years ago

I would say yes. It was a trivial fix.

kkotyk commented 7 years ago

As long as the data product seems reasonable and not totally out to lunch of course.

egthomas commented 7 years ago

Maybe this is more of a question for Pasha (and unrelated to this particular pull request), but are the velocity errors supposed to still be so small with fitacf.3.0?

As an example, here's a comparison of CVE data on beam 10 for 20160101 generated using fitacf.2.4 (from rst.3.2), fitacf.2.5 (from the new rst repository), and fitacf.3.0:

fitacf_test_velocity

fitacf_test_error

The velocity errors for the fitacf.3.0 data are pretty much all less than 50 m/s, even for the >300 m/s ionospheric scatter.

pasha-ponomarenko commented 7 years ago

This might sound counterintuitive, but velocity errors are not related directly to velocity magntude. Instead, they are proportional to spectral width. It is because velocity values are derived from phase, which is a peculiar parameter, i.e. a subject to 2Pi uncertainty etc. Below are some simulation results for a 1-min itegration time, so one can see that the error is independent of the velocity itself: for a given spectal width of 100 m/s, the error stays the same between +- 2000 m/s at aseveral m/s. Velocity_err_velocity_simulated.pdf velocity_err_velocity_simulated

In contrast, if you increase spectral width, the errors will grow linearly: Velocity_err_width_simulated.pdf velocity_err_width_simulated

pasha-ponomarenko commented 7 years ago

So, several m/s for velocity errors is reasonable. A couple more things. (1) I have changed the minimum number of lags from 3 to 5 in order to be compatible with FITACF2.5. (2) I am also concerned a bit about the amount of "salt-and-pepper" velocity values at the edges and wonder if this has any detrimental effect on mapping and how much this would cancel the advantage of getting more points (e.g. like filling the gap in on the lesft side of your example). Interestingly, these "fringe" point still show "good" elevaiton values, so we might need to think about different "good data" flags for different parameters.

egthomas commented 7 years ago

Thanks for the explanation Pasha - I didn't appreciate the greater dependence of velocity error on spectral width compared to velocity magnitude. I'll go ahead and merge this pull request so we can move forward with processing and analyzing more data.

pasha-ponomarenko commented 7 years ago

In fact, the only dependence on velocity is a casual one owing to the fact that the faster ionospheric scatter echoes usually have larger spectral width. Otherwise, there is no connection whatsoever.