I open this topic to highlight a possible bug in the computeElementaryFlux(SpacecraftState state, Vector3D elementCenter, Vector3D sunPosition, double elementArea). In particular, looking at the paper of Knocke reported in the reference of the class, it seems that when computing the variable double cosAlpha = Vector3D.dotProduct(elementCenter, satellitePosition) / (centerNorm * satellitePosition.getNorm()), the relative position between the satellite and the elementary area should be used.
In case my doubt is verified, the bug can be easily solved moving the two lines at 514-515 before the evaluation of the cosAlpha variable (I can open an issue on the forge).
Thanks Luc for the confirmation. I’m not including it in this patch tho as there seems to be non-negligible numerical differences in some tests and I don’t have time to double-check them.
I already opened a merge request just to show the required changes to fix the bug. However, I saw that the change is impacting also the “non-regression” tests relative to the blender algorithms because the reference scenario is using the Earth radiation force model.
I just updated the values with the new ones and replaced also the values in the commented part considering the real epoch together with an angular resolution equal to 1 degree. You can have a look to check if maybe the solution moves towards the correct direction.
In any case the unit test that I added comparing the theoretical value for the flux relative to a uniform sphere and the same value computed using the numerical discretization seems to work. We can continue the discussion in the merge request page.