Hi all! Currently I am trying to model the non-gravitational perturbations acting on a satellite using the BoxAndSolarArraySpacecraft class. I am providing the list of all the Panels that form the box and the solar array. I have a macro-model with all the optical and infrared properties of the different surfaces including the solar panels. For the solar panels I am using the PointingPanel class targeting the Sun and I am providing the coefficients of the side of the panel facing the Sun. I would like to know if it is possible to provide also the coefficients of the back side of the solar panel, given that they are different from those of the front. Is there any way to do that? I was thinking to create another PointingPanel which somehow points towards the anti-Sun direction, but I am afraid that then it is considering again the front and the back with the same coefficients. Many thanks for you help!
Hello @fpan, and welcome to the Orekit forum!
I am not an expert in this type of modelling, but I can do some low-lift to guide you through the docs.
From the documentation of 12.0, the BoxAndSolarArraySpacecraft consumes a list of objects that inherit the Panel interface. There are three implementation classes of this Panel interface.
PointingPanel: Double sided panel that can rotate its surface wrt the satellite body. Provided coefficients seem to apply to both sides. It seems the intent is to model solar panels, which many times populate both sides of a panel (to avoid death modes, but not always)SlewingPanel: Double sided panel, similar toPointingPanelFixedPanel: Single sided panel, without the ability to rotate (no degree of freedom), fixed wrt to the satellite.
If your spacecraft is using a rotating panel with one side populated with solar cells, I don’t know how that would be implemented (this in fact may not be uncommon, e.g. Starlink’s huge solar array). But if your panels have fixed orientation wrt satellite body frame, and you control the Sun pointing at the level of the satellite body attitude, have you considered using FixedPanel pairs with opposite orientations and different material properties?
This recently resolved issue shows that the support for “Facet dependent coefficients” was recently added for the FixedPanel, but I would love to be corrected and know if this applies for PointingPanel as well!
Welcome once again! Manny
Hi Manny,
thanks a lot for your reply. From your inputs I thought about possible solutions. The solar panel does not have fixed orientation with respect to the satellite body frame. So then I decided to create a “modified” PointingPanel class in my source code, with “doubleSided” parameter set to “false” (differently from what the orekit PointingPanel class is doing) and adding another input parameter to define if the considered solar panel plate is “frontside” or “backside” (the frontside is towards the Sun of course). So if I provide two modified “PointingPanel” objects (one for the frontside and one for the backside) I will be able to compute the normal to the panel rotation axis that best points towards the Sun with a set of coefficients and the anti-normal opposite of Sun with a different set of coefficients. Then everything should be handled correctly by the class BoxAndSolarArraySpacecraft which computes
the direction of the incoming flux with respect to the frontside solar plate normal (towards the Sun) and the backside solar plate normal (anti-Sun direction).
Thanks again!
Hello,
first of all sorry for taking back this discussion after a long time.
I am actually working on a same topic as @fpan and, since I cannot see any further reply (ideally from people that developed the logic behind BoxAndSolarArraySpacecraft), I was wondering whether the approach described by @fpan is fully valid, in order to handle different sets of coefficients on opposite sides of a same panel. To me it looks totally correct as approach, but not really sure whether there are some particular “caveats“ that should also be taken into account to make it fully working.
The second (and last) point, that I’m going to ask you, is instead related to the possibility to adopt, still for each side of a panel, a set of optical coefficients (albedo) and a set of infrared coefficients, useful when using the BoxAndSolarArraySpacecraft model to compute the Earth Radiation Pressure (via the KnockeRediffusedForceModel).
I did some scouting in the Orekit source code and below are my findings (but I might have misunderstood or missed something, so please let me know in case I’m stating something wrong below).
The computation of the radiation pressure acceleration (via the “radiationPressureAcceleration“ method in BoxAndSolarArraySpacecraft class) is based, among other parameters, on an input “flux“ vector. For the case of KnockeRediffusedForceModel, I can see that the flux is computed by means of the logic in the method “computeElementaryFlux“ that, to my understanding, it produces a flux being already the sum of the albedo and infrared component.
When using back the computed flux in the “radiationPressureAcceleration“ method, this is used in combination with the radiation coefficients of the panel to eventually produce a resulting acceleration.
Here is my doubt: is this fully correct?
I’m asking this because to me it seems that a single set of radiation coefficients (can be albedo, infrared, …) is used in a formulation that takes into account a flux consisting already of an albedo and infrared component. Shouldn’t we rather consider first an albedo flux used in combination with albedo radiation coefficients to produce an acceleration due only to albedo radiation, and then similarly using the infrared flux in combination with infrared coefficients to produce an acceleration due only to infrared radiation? Then the overall ERP acceleration would be the sum of these two latter accelerations.
What do you think? Am I missing something or saying something wrong in the above reasoning, or do you agree with it?
Lastly, according to current Orekit implementation, would it be eventually possible to address my original problem, i.e. use a set of optical and infrared coefficients for each side of a panel?
Thanks in advance for you time!
I think providing two panels with opposite normals and doubleSided set to false would work. A panel contribution is applied if the panel is in the incoming flux. This is computed by looking at the sign of the dot product of flux and normal, so with two opposite normals, at any time this would always select only one of the sides, changing the selection when flux crosses the panel plane itself.
Yes, the Knocke model always computes both effects and adds them together
I have never seen a satellite using different coefficients for infrared and visible light. See for example Galileo satellite metadata, which are used for very precise (centimeters level) orbit determination. Only one set of coefficients is used for direct solar radiation pressure, albedo and infrared reflection. One thing you could do is to use a different set of panels when configuring direct solar radiation pressure and Knocke model (they are different force models, and you provide the configuration). It would still not separate albedo from infrared. In order to achieve that, we could add flag to Knocke model to switch albedo and infrared independently on or off. With that modification, users could set up three different force models (direct SRP, Knocke with albedo on and infrared off, Knocke with albedo off and infrared on), each one with its own set of panels. Users would still have to find the coefficients for their satellite, though.
In the Galileo link above, you are right, there are coefficients for the rear side of the solar array panel, so we should probably provide an API for this. The rear side is never used for direct solar radiation pressure, but it sure can be in the Earth radiation flux. Could you open an issue for this on the forge for this?
Hello @luc, thanks a lot for your reply and suggestions!
Sure, I will open an issue for this!
Thanks again,
nick.