[Therion] Therion uses wrong declination for surveys 'in the future'

[Wookey]

On 2020-10-05 23:54 +0200, Matthias Keller wrote:
>    Exactly this.
> 
>    Unfortunately, even the current Therion 5.5.1 doesn't have a more
>    meaningful (and correct) message than "unable to determine magnetic
>    declination for undated surveys"

I thought this might be a proj confusing error message, but it is therion's.

>    I would propose:
> 
>     1. If a survey is dated but is newer than available correction data,
>        build should fail with a message like:
>        "Error determining magnetic declination for survey <name> with date
>        <date>. Please specify the declination explicitly using for example
>        'declination 3 deg'"
>        instead of the (completely wrong)
>        "unable to determine magnetic declination for undated surveys"
>     2. If at least one of the imported (and thus joined) surveys has magnetic
>        data but at least one does not (or cannot be determined), an error
>        shall be thrown as well, because mixing corrected and uncorrected
>        surveys is just plain wrong and causes a lot of confusion (as it has
>        happened to me). The same error message shall be displayed and the
>        build fails.

This does seem reasonable behaviour. And I agree the error message is wrongly worded or issued here. 

I just had a look at the code that produces this error but it's rather
confusing. A bitmap is used to record what declination data was used
and if bits 1 and 3 are set you get the above error. I think bit 2 is
'used igrf model to get delination' and bit 3 is 'used defined
declination', and bit 3 is 'didn't use any', but I'm not sure and I
don't see why two bits would be set. I'll leave it to Martin/Stacho to
work out how the logic should run here.


>    Is this the right place to request that or shall I open an issue on
>    github?

I think this list is the canonical place to discuss such things.

>    I really find this issue pressing, because I just cannot imagine, that
>    this doesn't happen to everyone here from time to time - keeping therion
>    up to date is not the same cycle as adding new surveys, and suddenly you
>    fall out of the prediction data.

This is really an issue of the geomag model. It does work some way
into the future, but there is a cutoff. Looks like it does 10 years
into the future as the latest data in the therion source (igrf12) ends
in 2015 and the previos igrf11 (used in therion 5.4.4) ended in
2010. igrf13 (with data to 2020) was released in December 2019
https://www.ngdc.noaa.gov/IAGA/vmod/coeffs/igrf13coeffs.txt

So clearly this will arise anytime you have survey data 10 years newer
than the model in the therion you are running, which as they are only
released every 5 years and therion may take a year or two to update
and the installed one may be a few years old, is quite likely to
happen from time to time, especially in years ending with 0 or 5.

>    btw, is there any way to update the data in an existing therion
>    installation? Or is the only way the update to a (hopefully existing) new
>    version?

There could be - the files are available online so therion could use
the currently-installed version of the file. But currently the igrf
coefficients file is compiled-in as thgeomagdata.h This means therion
can always find the data, but it's not updateable without
recompiling. I could fix this for linux relatively easily, but it's
harder on Windows. (and it was making things work on windows that
caused therion to compile-in all the stuff it needed from subsystems,
many years ago). Ideally it would compile one in but have the ability
to read a newer file if provided. But then someone has to write a
parser. We could also try a little harder not to get 10 years behind
again. (5.4.4 was released in May 2019 with a model that expired in
mid 2020, when the 2025 model had been available since 2015 (and was
included with the next therion release in May 2020). Not sure why the
update was not to 2030 as that was available from Dec 2019.)


Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20201006/89c8cd74/attachment.sig>