[Therion] Declination handling imprecise?

[Benedikt Hallinger]

If therion calculates the average position of all fixed points this is fine. 
the cave spans about 5km w/e and about 3km n/s.
I strongly dont think this is the error source as it is also visible in the 
test file. Also, calculating the igrf for each station should not be 
neccessary unless there are some strong amd small local anomalys which is not 
the case here.

For the date-observation, indeed my conclusion came from the summary in the 
log. Thank you for claryfying this. Good to hear, therion uses fractions 
here, and 1/12 is perfectly good.

However i have seen that it looks like the calculated declination is maybe 
rounded to full degrees? Or is this just an display thing in aven viewer?


Based on what you have said, i would assume that the problem source lies in 
therion itself summarizing all centreline dates into one survey average date, 
and not just by centerline as i would assume, when each centerline has a date 
specification.

The main issue here is, that we have surveys which were taken in the 1950s 
and extended with an additional centerline in 2000s.


Am 2017-02-17 23:26, schrieb 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