[Therion] Declination handling imprecise?

[Olly Betts]

On Fri, Feb 17, 2017 at 07:08:48PM +0200, Benedikt Hallinger via Therion wrote:
> i found out that the declination handling seems to be somewhat inaccurate.
> The produced error is marginal and negligible with small caves, however i am
> currently working on a system with >100km and this produces errors of >10m
> there.

Therion calculates all declination values at the same location (the average
location of all the fixed points), which is potentially problematic if your
survey spans that sort of distance.  I wonder if this might actually be the
source of your problems.

Survex requires specifying the location to calculate declination values at,
and you can use different locations for different parts of the survey
hierarchy.  So keeping your centreline data in Survex format and feeding
therion a 3d file would be one solution if this is the issue you're hitting.

(Using the actual location of the station the reading was taken at is hard
as you need the declination value to calculate that location.  It would also be
fairly slow to evaluate the IGRF model at every station where a compass was
read.)

> What i observe is the following:
> - Therion seems to use the first day of any given year referenced by "date"
> command.

If that's from looking at therion's log file, the "geomag declinations (deg)"
table there is just a summary.  It indeed shows the values on January 1st of
each "interesting" year, but doesn't reflect the dates actually being used to
calculate declinations for surveys.

Or was that from looking at the source code?  The get_start_year() and
get_end_year() methods actually return a fractional year value, not just the
year of the survey.  The fraction is calculated assuming each month is 1/12 of
the year - not quite right, but probably not a significant error in practice.

> - If a survey was taken at the end of a year it seems that the 1.1 of the
> following year will be used (i assume this happens at mid-year).
> - This approach looses at most half a years magnetic drift.
> This alone is acceptable as the data by itself is already not that accurate.
> 
> However if you have several centerlines in the survey, each with different
> date-commands, therion seems to calculate the average of all dates and then
> uses the calculated declination for that date (applying the rule above, so
> taking the "closest 1.1.").
> This is then applied to all shots of the whole survey.

Not sure - I don't know therion's code that well.

> A possible solution to this seems, to get the correct declination for each
> date and explicitely write suitable "declination" commands that override the
> "date"-calculated values. This then gives the proper results.

This approach is less than ideal, and not just because it's a significant
effort.

Each generation of the IGRF model is necessarily predictive for dates after it
was issued and only declared to be definitive for dates more than 5 years
before it was issued.  So each new generation of the model can change the
declination figures reported for the last 10 years compared to the previous
generation.

In simple terms, when IGRF-13 comes out in late 2019 it'll potentially give
different answers for all dates in 2010 and later (not hugely different one
would hope, but your motivation here is to avoid introducing unnecessary
errors).

See table 1 here for the date information for each IGRF model generation:

http://earth-planets-space.springeropen.com/articles/10.1186/s40623-015-0228-9

So unless you're dealing with historic data, you really want your software
to calculate the declination automatically so that you get the benefit of
improvements when the IGRF model is updated.

Cheers,
    Olly