Fix computation of signed phase angle to determine apparent magnitude #3306
Conversation
|
Great PR! Please pay attention to the following items before merging: Files matching
This is an automatically generated QA checklist based on modified files. |
10110111
force-pushed
the
signed-phase-angle
branch
3 times, most recently
from
a0f65e3 to
934f403
Compare
| @@ -305,6 +305,9 @@ class StelCore : public QObject | |||
|
|
|||
| //! Return the observer heliocentric ecliptic position (GZ: presumably J2000) | |||
| Vec3d getObserverHeliocentricEclipticPos() const; | |||
| //! Return the observer heliocentric ecliptic velocity. This includes orbital and diurnal motion; | |||
There was a problem hiding this comment.
If you include diurnal changes in velocity, this should be added to the aberration correction of the observer in SolarSystem::computePositions().
There was a problem hiding this comment.
I suppose then observerPlanet->getHeliocentricEclipticPos() should also be replaced with core->getObserverHeliocentricEclipticPos(), right? Because currently that computation takes "observer" to be in the center of the planet.
There was a problem hiding this comment.
Yes, I also think that's all that has to be changed. When I did aberration correction, I said we won't include the diurnal aberration, but when you are doing this computation now, it's even one more step. Not sure about the magnitude, though, it may introduce an observable milliarcsecond wobble. Of course, switching off topographic correction will also disable that.
There was a problem hiding this comment.
Do you think it should go right into this PR? This seems quite unrelated.
There was a problem hiding this comment.
It will be an obvious next change then. Probably we can even make a switch aberration: none/annual/diurnal (for didactic purposes).
There was a problem hiding this comment.
Why do you only say that it should be applied in SolarSystem? Shouldn't it equally affect everything?
|
@gzotti What is your verdict on this PR? |
|
Just having a look into its differences, but answering other duties at the same time. Why is the Moon about 0.1-0.2mag less bright? It may not matter a lot in reality, but still it's a notable difference between my model and your change in computing one of the required angles. |
|
The change in magnitude reflects the change in the phase angle that's fed into the algorithm that computes the magnitude. A totally expected result. |
It proved to be quite challenging to properly determine whether phase angle is increasing or decreasing. So it's worth providing a flag for this in the scripting API.
10110111
force-pushed
the
signed-phase-angle
branch
from
934f403 to
9e8316c
Compare
|
The difference between the old angle and the new one is that the old angle was computed between projected positions of the observer and the Moon, while the new one is between the actual 3D positions. As we take into account different z components of the positions, we should expect the angle between the objects to increase, which will reduce the visible lit part. |
alex-w
added
the
state: published
|
Hello @10110111! Please check the fresh version (development snapshot) of Stellarium: |
alex-w
removed
the
state: published
|
Hello @10110111! Please check the latest stable version of Stellarium: |
Description
Current computation of apparent magnitude uses two similar quantities: phase angle and something that approximates it, adding a sign to indicate whether the it's a waxing or waning phase.
As I understand, the only reason of determining the sign is to make magnitude depend on what half of the Moon is illuminated, due to asymmetry in the albedo of the visible side of the Moon. So the quantity should actually be equal to the phase angle, up to a sign.
The unsigned phase angle is computed correctly, taking into account positions of the observer and the Moon. But the way the signed quantity is currently computed has some problems:
This PR implements the correct computation of whether the phase angle is increasing or decreasing (this is done in
Planet::isWaning()). This computation uses heliocentric position and velocity of the observer (the velocity is computed inStelCore::getObserverHeliocentricEclipticVelocity()).I spent some time time trying to reverse-engineer orientation of the axes of the AltAz frame, so the first commit here documents my findings. Please check that it's actually correct.Also, it appeared that the computation to determine the phase angle tendency is quite nontrivial (the simple elongation-based trick mentioned in #2916 won't yield precise results), so the third commit here exports a flag to the scripting API that indicates whether the planet is in the waning phase, i.e. whether its phase angle is increasing.
Type of change
How Has This Been Tested?
Test Configuration:
Checklist: