[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orekit Developers] cannot estimate angular measurement



Le 15/06/2017 à 14:31, RHONE, Quentin a écrit :
> Hi all,

Hi Quentin,

> I work with Orekit version 9.0-SNAPSHOT updated on a daily basis and
> some of my test failed last week-end following last Thursday’s commits
> on your side (probably Revision 7137ab40).
> The stack trace goes deep in Orekit’s code and I tried to understand but
> it is pretty complex. So I couldn’t determine whether I have misused the
> library or a bug is hidden in Orekit’s code.
> That is why I would like to benefit from your expertise.
> At first some tests fail when run together but all tests are ok when run
> individually. I have checked that I don’t have any static variables
> related to this.
>  
> All the tests that fail try for some reason to estimate angular
> measurements. Here is the typical stack trace :
>  
> Caused by: org.orekit.errors.TimeStampedCacheException: unable to
> generate new data before 2000-08-16T11:00:00.000
>         at
> org.orekit.utils.GenericTimeStampedCache$Slot.insertAtStart(GenericTimeStampedCache.java:738)
>         at
> org.orekit.utils.GenericTimeStampedCache$Slot.getNeighbors(GenericTimeStampedCache.java:603)
>         at
> org.orekit.utils.GenericTimeStampedCache.getNeighbors(GenericTimeStampedCache.java:294)
>         at
> org.orekit.frames.ShiftingTransformProvider.getTransform(ShiftingTransformProvider.java:166)
>         at org.orekit.frames.Frame.getTransformTo(Frame.java:296)
>         at
> org.orekit.estimation.measurements.GroundStation.getOffsetToInertial(GroundStation.java:333)
>         at
> org.orekit.estimation.measurements.Angular.theoreticalEvaluation(Angular.java:100)
>         at
> org.orekit.estimation.measurements.AbstractMeasurement.estimate(AbstractMeasurement.java:178)
>         at
> estimation.measurements.AzelMeasurement.estimate(AzelMeasurement.java:48)
>  
> Before the modification of angular.java, getOffsetToInertial was not
> used and that’s why I had no problem.

In fact, prior to last week change, another method was called instead of
getOffsetToInertial. The problem is not directly related to the new
getOffsetToInertial but seems to be much deeper, as you have already
seen since you were able to reproduce it without any class from the
estimation package.

> We have reproduced the bug in a small test :
> Here is our idea : when getTransformTo() method is used twice with a
> fieldAbsoluteDate it crashes if the second fielAbsoluteDate is prior to
> the first one.
> We don’t manage to go further and that’s why we’re asking for your help.

Your analysis is already pretty deep, thanks for it!
I was able to reproduce the bug and also to simplify further the test
case to reproduce it.

You are right, the scheduling of the dates is the key to trigger the bug
which is really related to the time stamped caches. The behaviour
with a FieldAbsoluteDate is not the same as the behaviour with a
regular AbsoluteDate. The behaviour should be similar. I am looking at
it.

> I address this mail to the developer mailing list because this problem
> seems like a problem of code, not really interesting for other users.
> Tell me if I should have used the user mailing list.

For bug reports, registering a ticket on the forge is the way to go.
However, as you were not sutre it was a bug, asking on the dev list
is a good choice. So I confirm, it is a bug. You can open a new ticket
for it. I will try to solve it as soon as possible.

Thanks for the report!

Luc

> Thank you in advance,
>  
> Quentin Rhoné
>  
>  
> 
> ***************************************************************
> Ce courriel (incluant ses eventuelles pieces jointes) peut contenir des informations confidentielles et/ou protegees ou dont la diffusion est restreinte. Si vous avez recu ce courriel par erreur, vous ne devez ni le copier, ni l'utiliser, ni en divulguer le contenu a quiconque. Merci d'en avertir immediatement l'expediteur et d'effacer ce courriel de votre systeme. Airbus Defence and Space et les sociétés Airbus Group declinent toute responsabilite en cas de corruption par virus, d'alteration ou de falsification de ce courriel lors de sa transmission par voie electronique.
> This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Airbus Defence and Space and Airbus Group companies disclaim any and all liability if this email transmission was virus corrupted, altered or falsified. 
> ---------------------------------------------------------------------
> Airbus Defence and Space SAS (393 341 516 RCS Toulouse) - Capital: 29.821.072 EUR - Siege social: 31 rue des Cosmonautes, ZI du Palays, 31402 Toulouse cedex 4, France
>