[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Orekit Developers] Fixed Tropospheric Correction Accuracy
- To: orekit-developers@orekit.org
- Subject: Re: [Orekit Developers] Fixed Tropospheric Correction Accuracy
- From: Luc Maisonobe <Luc.Maisonobe@c-s.fr>
- Date: Fri, 19 Sep 2014 13:04:05 +0200
- In-reply-to: <CAP2my4Zo_JUGdE=X+0k0N2+uPB7Wzga0f4MCtk-n6PtQZHcA6Q@mail.gmail.com>
- References: <CAP2my4Zo_JUGdE=X+0k0N2+uPB7Wzga0f4MCtk-n6PtQZHcA6Q@mail.gmail.com>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.0
Le 18/09/2014 22:49, Hank Grabowski a écrit :
> Hello all,
Hi Hank,
>
> We were looking at using Apache Math Commons 3.3 with the 6.1 release of
> Orekit. When we re-ran the unit tests we realized that the
> FixedTroposphericModel tests were mostly failing due to the function
> lookup returning different numbers. I noticed that the tests in Orekit
> 7.0 have been changed to reflect the new numbers coming back from the
> interpolation functions.
There are other changes that were related to Apache Commons Math 3.3
too. See for example commits 771ea84, 026b2f1, 1b92bd6 or f219c48.
>
> The reason for the new numbers is that between 3.2 and 3.3 they changed
> the way the coefficients in the BicubicSplineFunction were being
> calculated. I believe that this was to try to address some accuracy
> problems in there. I have been studying that exact area of code for a
> week or so due to a problem we was with it on another project.
>
> The current implementation of their BicubicSplineFunction is suspect.
> It cannot even calculate the correct interpolation values for a
> regularly spaced grid of a 2D linear function. That isn't something new
> to 3.3 either.
>
> I'm going to be attempting to implement a new version of that method,
> and if they allow will also be doing some additional 2D interpolation
> methods besides a cubic spline. I just wanted to call that problem to
> everyone's attention.
Thanks for the heads up. I did not look at this area directly, and
trusted the change between 3.2 and 3.3 done to fix issue
<https://issues.apache.org/jira/browse/MATH-985>.
>
> We may want to use another 2D interpolation method for this until a
> validated one makes it into Apache Math. We may also want to check the
> values we are using in this test to make sure that they are numerically
> accurate versus having drifted as the various implementations of the
> underlying interpolators were being manipulated.
Well, the best thing would be to fix it at Apache Commons Math level
(several Orekit committers are also Apache Commons Math committers ...).
If you can come up with a fix, we will include it.
I fully agree with the facts the numbers should be better validated. I
was obviously too lazy here, sorry for that.
best regards,
Luc
>
> Hank
>