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

*To*: orekit-users@orekit.org*Subject*: Re: [Orekit Users] Fwd: Problem with additional equations*From*: MAISONOBE Luc <luc.maisonobe@c-s.fr>*Date*: Mon, 04 Dec 2017 21:02:33 +0100*In-reply-to*: <20171204201426.Horde.DyzqhzUiV9W2AHmfUeopWQ1@messagerie.c-s.fr>*References*: <CAAv=LsNmxH=D=FiEki3sceNBzvYt6MDB7qUXxGwJECcz+ttD=Q@mail.gmail.com> <CAAv=LsOxHZd8dtVchcxKGFA6ESnkbZXL7qa0dnMxPKbkeyrsAA@mail.gmail.com> <20171204182938.Horde.zsvdd0yyzVcKh6zJz0QRwQ1@messagerie.c-s.fr> <CAAv=LsN674eS8sMA5Lmsm=wsHTL_zwe5=YMPZcQOv4O3=rJQOw@mail.gmail.com> <20171204201426.Horde.DyzqhzUiV9W2AHmfUeopWQ1@messagerie.c-s.fr>*User-agent*: Internet Messaging Program (IMP) H5 (6.2.3)

MAISONOBE Luc <luc.maisonobe@c-s.fr> a écrit :

Christophe Le Bris <chris.lebris@gmail.com> a écrit :Hello Luc,Hi Christophe,thanks for the detailed reply. You propose to split the computation in 2 parts but I don't know how to solve my problem with this approach as one of my force model depends on the additional states. And the additional states are not available in the force models (as far as I understand). In fact, I try to test if we could use Orekit to solve an optimal control problem with the integration of the co-states as the additional equations. My co-states are used to compute the optimal thrust direction but they are not available when I need to compute the acceleration in my "optimal thrust" force model. Only the "primaryState" is available in the SpacecraftState for the computation of the primary equations. ie: in the force models, I do not have access to the additional states. That's the reason why I tried another approach and tried to compute the optimal command (and its effect on the primary states) in the additional equations.OK, now I understand better the use case.Do you have any tips to find a way to solve my dependency problem between the states, the co-states and the thrust force model?No, there is no way right now. At the boundary between Orekit and Hipparchus, arrays are now quite separated and you don't even see the full state whenthe computeDerivative from the primary equation is called. So yourapproach touse the secondary equation is the way to go, as at least thesecondary equationsees the primary state and its derivative (which is normal). Then I will change Hipparchus so your use case is supported. I will move the offending line (in both ExpandableODE and in FieldExpandableODE which has a similar feature) and make clear in the javadoc that updating the primaryStateDot array *is* supported.

This is now fixed in Hipparchus git repository. See <>https://github.com/Hipparchus-Math/hipparchus/issues/31. You will have to generate the library by yourself and have Orekit use it. One way to do this is run "mvn install" on the top of the Hipparchus tree so it installs version 1.3-SNAPSHOT in your local .m2 repository and than change in Orekit pom.xml file the line <orekit.hipparchus.version>1.2</orekit.hipparchus.version> into <orekit.hipparchus.version>1.3-SNAPSHOT</orekit.hipparchus.version> Tell me if anythig goes wrong. Thanks for the report Luc

best regards, LucThanks! Christophe 2017-12-04 18:29 GMT+01:00 MAISONOBE Luc <luc.maisonobe@c-s.fr>:Christophe Le Bris <chris.lebris@gmail.com> a écrit : Hello,Hi Christophe,I tried to reproduce the behavior exposed in my previous email with a minimal test. I integrate numerically a trajectory with only central force and an additional equation that increases the value of an additional state of 1/sec. The "Additional equation" should also increase the SMA of 2m/sec but, after integration for the duration of one keplerian orbit, my additional state changed to the value of the initial orbital period but the orbit did not changed => the increase of 2m/sec has not been taken into account.I confirm the behaviour you get, and also confirm your thorough analysis. The latest version on Hipparchus indeed does not allow the secondary equation to modify the main equation. However, I am on the fence with it. Should we really allow an additional equation to modify the main equation? If I remember well, the fact that the derivatives of the main state are provided as an argument is mainly because they may be needed to compute the secondary derivatives, it was not because users could modify the primary derivatives. This was however not obvious in the Apache Commons Math era because the signature of the method was anyway to provide arrays and have the user fill them. So the interdace SecondaryEquations did specify the computeDerivatives method as: /** Compute the derivatives related to the secondary state parameters. * @param t current value of the independent <I>time</I> variable * @param primary array containing the current value of the primary state vector * @param primaryDot array containing the derivative of the primary state vector * @param secondary array containing the current value of the secondary state vector * @param secondaryDot placeholder array where to put the derivative of the secondary state vector * @exception MaxCountExceededException if the number of functions evaluations is exceeded * @exception DimensionMismatchException if arrays dimensions do not match equations settings */ void computeDerivatives(double t, double[] primary, double[] primaryDot, double[] secondary, double[] secondaryDot) throws MaxCountExceededException, DimensionMismatchException; As you see, primaryDot and secondaryDot are passed the same way, despite only the secondaryDot is really intended to be filled by user. Since Hipparchus, the design is that arrays the user should fill must be return values (i.e. allocated within the method), so the equivalent interface, which is now called SecondaryODE defines: /** Compute the derivatives related to the secondary state parameters. * @param t current value of the independent <I>time</I> variable * @param primary array containing the current value of the primary state vector * @param primaryDot array containing the derivative of the primary state vector * @param secondary array containing the current value of the secondary state vector * @return derivative of the secondary state vector * @exception MathIllegalStateException if the number of functions evaluations is exceeded * @exception MathIllegalArgumentException if arrays dimensions do not match equations settings */ double[] computeDerivatives(double t, double[] primary, double[] primaryDot, double[] secondary) throws MathIllegalArgumentException, MathIllegalStateException; It makes more clear than only the derivatives of the secondary state vector are expected from this method. The primaryDot array is still passed because it may be needed in to compute the other derivatives, but is was not intended that users change it. For the sake of separation of concerns, I would prefer to have realy the primary equations completely computed by one part of the code, and secondary equations by another part and not messing with the primary. So if you remove the secondary equations, you only don't get the secondary state they compute, but you do not change at all the premary equations. When the secondary equations do change the primary derivatives, they are not secondary anymore: they are needed to compute the primary state. I understand that moving the mapper.insertEquationData call corresponding to the main state from before the computation of the secondary equations to after the computation allows as a side effect changes made by the secondary equations to be taken into account, but it is not really clean. It implies that the primary equations were indeed incomplete, and it implies the secondary equation returns two different results, on in its regular return value, and one by changing a value in an array passed by the caller, and expected this array to be used only after the call, not before. In your use case, would it be possible to split your computation in two parts, one in the secondary equation (to compute the return value as in your return new double[] { 2, 0, 0, 0, 0, 0, 0 } example) and another one as a force model (to compute the main state derivative as in your pDot[0] = 1 example)? best regards, Luc*Initial orbit = Keplerian parameters: {a: 7800000.0; e: 0.001; i: 28.0; pa: 0.0; raan: 0.0; v: 0.0;}Initial keplerian period = 6855.717044697212 secFinal value of added state = 6855.717044697215Final orbit = Keplerian parameters: {a: 7800000.000000003; e: 0.001000000000000334; i: 28.000000000000007; pa: -1.1173044601630712E-25; raan: 2.925205344836198E-29; v: -5.234453515214931E-13;}* I expect the problem to be in Hipparchus 1.2 (at least) and not Orekit. In *org.hipparchus.ode.ExpandableODE*, I think the line 137 "mapper.insertEquationData(index, primaryStateDot, yDot);" should be placed just before the "return". If I execute the same program with Orekit 7.0/Commons Math 3.4.1, the behavior is different and is ok: *Initial orbit = keplerian parameters: {a: 7800000.0; e: 0.001; i: 28.0; pa: 0.0; raan: 0.0; v: 0.0;}Initial keplerian period = 6855.717044697212 secFinal value of added state = 6855.717044697215Final orbit = keplerian parameters: {a: 7813711.434089395; e: 0.0010000000000002728; i: 27.999999999999993; pa: -1.3080031127518713E-13; raan: 3.7263393091775305E-17; v: -0.4748813935419053;}* Thank you! Christophe ---------- Forwarded message ---------- From: Christophe Le Bris <chris.lebris@gmail.com> Date: 2017-11-30 18:21 GMT+01:00 Subject: Problem with additional equations To: "orekit-users@orekit.org" <orekit-users@orekit.org> Hello, I have a problem when integrating "additional equations" that impact the derivatives of the primary state (ie: value returned by "computeDerivative" method is not null). I have the feeling that these values are not taken into account during the integration. I use Orekit 9.1 with Hipparchus 1.2. It seems that the origin of my problem is located in Hipparchus library (in the "computeDerivative" method of the class "ExpandableODE") and not in Orekit but I would like to know if someone already used this functionality with the last versions of Orekit/Hipparchus ? Thank you. Christophe

**References**:**[Orekit Users] Problem with additional equations***From:*Christophe Le Bris <chris.lebris@gmail.com>

**[Orekit Users] Fwd: Problem with additional equations***From:*Christophe Le Bris <chris.lebris@gmail.com>

**Re: [Orekit Users] Fwd: Problem with additional equations***From:*MAISONOBE Luc <luc.maisonobe@c-s.fr>

**Re: [Orekit Users] Fwd: Problem with additional equations***From:*Christophe Le Bris <chris.lebris@gmail.com>

**Re: [Orekit Users] Fwd: Problem with additional equations***From:*MAISONOBE Luc <luc.maisonobe@c-s.fr>

- Prev by Date:
**Re: [Orekit Users] Fwd: Problem with additional equations** - Next by Date:
**[Orekit Users] Orekit day presentations available** - Previous by thread:
**Re: [Orekit Users] Fwd: Problem with additional equations** - Next by thread:
**[Orekit Users] Orekit day presentations available** - Index(es):