The two code lines you are referencing are trying to find the midnight that occurs before the provided Julian Date.
As written, the first check will be true if the Julian date occurs after midnight and 12+ hours before the time.
As written, the second check will be true if the Julian date occurs after midnight and less than 12 hours before the time.
If both checks are true, the code will use the last midnight that occurred. This is the desired functionality.
Because I am rounding down on the Julian date and subtracting a half day, there is no possible way that jd could be less than jdMin.
In your JD2GMST function, I have a question related to the following two lines:
jd0(jd>jdMin) = jdMin(jd>jdMin);
jd0(jd>jdMax) = jdMax(jd>jdMax);
This appears to be limiting the Julian day between a lower bound and an upper bound. Don't you want the first line to be:
jd0(jd<jdMin) = jdMin(jd<jdMin);
Otherwise, it would appear that no actual lower bounding occurs...
I have been importing some ECI data from the OrbitTools C++ library and have stumbled upon some weird behavior.
In MATLAB I am using your functions to transform ECI to ECEF and then using the MATLAB function, ecef2geodetic to transform into normal azimuth/elevation/height coordinate space.
The weird behavior is that despite having smooth ECI data (smooth as in no jumps in the data) as inputs, I am getting discontinuous ECEF data (graph for r_ECEF(1,:) and r_ECEF(2,:) looks like saw). This is happening for GOES-8 and GOES-15 satellite data.
What is weirder is that on a macro scale (ignoring variations, including the sudden discontinuities), the position of the satellite in the mapa mundi seems to be correct.
J2000 is factored into the ECI to ECEF conversion routine through the call to JD2GAST.m (converts Julian Date to Greenwhich Apparent Sidereal Time). In order to do this, the effects of nutation are considered, and depend on the correct number of Julian centuries since J2000.