2d4b8a98d549dd9a3e1a3d61e9c08476ef295f43
185
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  SenrokaiandClaude Opus 5.5
|
2d4b8a98d5 |
Put each body's photograph on it one frame at a time, so entering the Sun's system no longer stalls
buildMarker gave every photographed body its map at once. A texture is copied to the GPU in the first frame that draws it, and the 28 maps arrive within about 40 ms of each other, so that frame copied some 20 megapixels of JPEG (seven maps at 2048x1024) through copyExternalImageToTexture: a second long task of 135-162 ms about 1.25 s after entering, measured here four times on the committed renderer (reviewers measured 160-210 against 85-100 without the 18 new maps). de34fff's "adds no long task" was measured before those maps landed. A photographed body now starts in its kind's flat colour, as a derived one does, and its texture waits in a queue; each update() puts the first one that has loaded on its body. The copies are spread one a frame, and all 38 bodies have their maps within half a second of the first. In the running app, five fresh entries into the Sun's system at 1600x1000 left one long task of 52-66 ms or none at all ([66], [52], [62], [], [56] ms, where the committed renderer gave [62, 149], [56, 135], [74, 162], [78, 162]). Control: putting every loaded photograph on in one frame fails "puts them on their bodies once loaded, one a frame". Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
6c0626ca38 |
Frame the Sun's system out to Eris on a portrait window, where Eris and Makemake arrived off screen
The arrival framing fits the grid's outer ring, which Eris (a = 67.93 AU) took from 40 AU to 80, but its 200 AU ceiling was sized for Pluto's ring. At 390 by 844 the ring needs 416 AU and at 1000 by 1400 269, so both were clamped to 200: Eris arrived at NDC (2.08, 0.48) on the phone, with Makemake at (-1.14, -0.25), and at (1.34, 0.48) on the tall window. The spec never saw it, its solar system ending at Neptune. The ceiling is now 500 AU, which frames the 80 AU ring at any aspect down to 0.385; the landscape fit is unchanged. The window-shape test now includes the solar system out to Eris and a 390 by 844 phone. In the running app every top-level body is on screen on arrival: the camera at 415.8 AU on 390x844, 269.0 on 1000x1400 and 192.1 on 1600x1000. Control: the ceiling back at 200 fails "leaves the outermost ring clear of the frame edge at every scale and window shape". Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
8c4f1c11c9 |
Build a body still waiting for its surface with a null map, so three stops warning on each one
Since
|
||
|
SenrokaiandClaude Opus 5.5
|
036af5f02d |
Test what the drawn solar system claims at far dates and on Saturn's ring
Three claims had no test that fails without them: - Standish's rates for a, e and i. The frozen Horizons vectors run from 1950 to 2100, where dropping them moves a planet at most 0.036 degrees (Saturn in 2100), inside every ceiling; the clock runs to AD 3000, and the long span is what those rates are for. Two vectors from Horizons (DE441) for 3000-01-01 now join the table: the Earth-Moon barycentre, 0.005 degrees out (0.129 without the rates), and Saturn's, 0.065 (0.412). - A planet's orbit line turned each tick with its node and periapsis: only the Moon's and Pluto's were tested. Mars must stay on its own line 730 000 days before J2000; on a line left at J2000 it is 3.3 million km from it at AD 1. - Saturn's ring lit and drawn from both faces, which dc20acc's title claims and the tests, reading only its geometry and picking through its front face, never checked. Controls: the three rates dropped fails "puts earth within 0.02 degrees of Horizons on JD 2816787.5" (and Saturn's); the top-level line left unturned fails "turns a planet's drawn orbit with its node"; an unlit front-face-only material fails "is lit, and seen from either face". Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
56af5e3553 |
Test the clock where CI could not see it: the date field's time zone, a backwards date, a reopened panel
Three behaviours of the clock had no test that would fail without them: - "jumps the clock to the date submitted, read as UTC" only told UTC from local time on a machine outside UTC. CI runs on ubuntu-latest, in UTC, where both readings are the same instant, so a field read as local time passed all 805 tests there. The test now sets TZ to Asia/Kolkata (UTC +5:30) itself, and afterEach unstubs it. - Nothing checked that a negative rate moves the date backwards; the dock's test read only the rate's sign. The store now checks that at -86 400 s/s a second of wall clock is a day earlier. - Nothing checked that reopening the Display panel fills the date field with the clock's date, rather than the one it held when the dock was built. Controls, the suite run under TZ=UTC: the field read as local time fails "jumps the clock to the date submitted, read as UTC"; the rate's size taken without its sign fails "runs the date backwards at a negative rate"; toggleTab not refilling the field fails "fills the date field again with the clock's date when the panel is opened again". Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
34084c0eec |
Test the body page itself: its ring in Saturn's equator, and each body turned for the map's date
No spec mounted BodyDetailSceneComponent, so the two things the page was changed for could be undone with all 805 tests passing: putting audit #47's 17-degree lean back on the page's ring, and sending every body back to the slow turn for show instead of bodyPageView. saturnRing's geometry and bodyPageView were each tested alone; how the page wires them was not. body-detail-scene.component.spec.ts mounts the page on a stand-in engine and data loader, the pattern galaxy-system-scene's spec uses, with the page's template cut to its canvas. It opens Saturn and checks that the ring's face normal, read off its geometry through its world matrix, lies on the planet's pole within 1e-6 rad; and it opens Earth with the clock pinned to 2025-06-01 12:00 UTC and checks that the sphere and the light are what bodyPageView gives for that date. Controls: the ring leant 17 degrees fails "lays Saturn's rings in its equator on the page"; the page falling back to its show spin fails "turns Earth on its page as it stands at the map's date". Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
ff7525d3b5 |
Stop a running clock at the ends of its window, where setDate already refused to go
Only setDate held the clock to AD 1 - AD 3000; julianDate did not, so a month a second carried it past either end with nothing to stop it. Past AD 3000 it drew the planets on elements Standish never fitted there, under a note naming "AD 3000"; before AD 1, toISOString writes the six-digit years ECMA-262 uses outside 0000-9999, and the note, the date strip and the date field, which cut it at fixed places, read "... to -000001-10-05 20 UTC.", "-000001-10" and an empty field. julianDate now stops the clock at the end it ran into: re-anchored there, at real time turned back into the window (forwards at AD 1, backwards at AD 3000), as if the reader had set that date. In the running app, run backwards from 0001-01-10 at a month a second for 20 s, the note reads "to 0001-01-01 00:00 UTC." and the strip "0001-01-01", the clock 19.7 s into AD 1 at real time; run on from 2999-12-01 for 8 s, "to 2999-12-31 23:59 UTC." at real time backwards. Control: julianDate unheld fails "stops a running clock at either end of the window". Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
97b8dd9dc8 |
Turn the Sun about its IAU pole, once in 25.38 days, as every planet already is
Every body with IAU elements was turned by its pole and W, but the Sun, which is the system's star marker and no BodyRecord, was built with an identity rotation and never touched: its pole pointed at RA 90, Dec 0, 115.03 degrees from the WGCCRE 2015 solar pole (RA 286.13, Dec 63.87), and it stood still where its W turns 14.1844 degrees a day. SUN_ROTATIONAL_ELEMENTS carries NAIF body 10 from pck00011.tpc, and the ETL fails if they are not the kernel's. The scene turns the star marker by bodyOrientation each tick when the star is the Sun, as the renderer turns the planets. In the running app the Sun's drawn pole lies on the IAU's (0.00 degrees) and its map turns 14.1844 degrees between 2026-01-01 and 01-02. The map's longitudes are Solar System Scope's, not Carrington's, so the phase of W is not the Sun's own; the pole and the rate are. Controls: leaving the marker unturned fails "turns the Sun about its IAU pole, once in 25.38 days"; the app's elements off the kernel's (W rate 14.18) fails the ETL. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
8e3a494fe9 |
Print Hyperion's eccentricity as JPL measures it now, 0.105, not the archived row's 0.023
The card listed Hyperion's eccentricity under "Measured" as 0.023: the archived JPL satellite row
the orbit is drawn from gives 0.0232. JPL's current table (SAT441) gives 0.105, and Horizons'
osculating orbit ranges 0.074 to 0.132 from 1980 to 2100 (0.1099 on 2025-01-01). The row stays
the orbit: with 0.105 put into it, Hyperion is further from Horizons, not nearer (median 9.6
degrees against 7.8 over 1980-2100, as a reviewer measured), so only the card changes.
BodyRecord.measuredEccentricity carries the figure the card prints where it is not the orbit's
own; the ETL sets it for Hyperion, and buildBodyViewModel prints it. build.ts now checks every
card's eccentricity against Horizons' osculating one on 2025-01-01, within 0.03: measured at most
0.0151 (Phoebe, and the Moon, whose eccentricity swings) once Hyperion prints 0.105, where the
row put it 0.0867 out. The live Hyperion page reads "ECCENTRICITY 0.105".
Controls: the ETL with Hyperion on its row's figure fails ("Hyperion's card gives an eccentricity of
0.0232, where Horizons' osculating orbit has 0.1099"); the view model ignoring the field fails
"prints the eccentricity measured for a moon whose orbit keeps an older one".
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
||
|
SenrokaiandClaude Opus 5.5
|
f655a4c0f7 |
Turn Eris once in 15.77 days, locked to Dysnomia, not in the 25.9 hours the SBDB flags as unreliable
Eris took its day from the SBDB's rot_per, 25.9 hours, whose own note reads "Result based on less than full coverage, so that the period may be wrong by 30 percent or so" (Roe et al. 2008). Eris is locked to Dysnomia: its light curve repeats every 15.771 +/- 0.008 days (Bernstein et al. 2023, PSJ 4, 115), Dysnomia's 15.78590-day orbit (Holler et al. 2021; Szakáts et al. 2023, A&A 669, L3). It was drawn turning 14.6 times too fast. Eris's BodySpec now carries that day, 378.504 hours, cited as its radius already cites Sicardy et al., and a spec's measured day comes before its source's. build.ts checks that Eris's day is Dysnomia's orbit within 0.2 per cent. In the running app Eris turns 5.707 degrees in six hours, as 15.771 days gives; on 25.9 hours it turned 83.4. Makemake's SBDB period, 22.83 hours, carries the same flag; it is Hromakina et al. 2019's own result and nothing later overturns it, so it is kept. Control: Eris on the SBDB's period fails the ETL: "Eris turns once in 1.079 days". Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
86d97b903e |
Print Earth's inclination as 0.00 degrees, not -0.00
Standish's Table 2a fits the Earth-Moon barycentre's inclination as -0.00054346 degrees, and the card printed toFixed(2) of it: "Inclination -0.00°", where the branch's base read 0.00. A negative inclination is the same orbit as its size with the node turned half round, so the card prints the size. The elements the map propagates are left as Standish gives them. The live Earth page now reads "INCLINATION 0.00°". Control: printing the fitted sign again fails "prints the size of an inclination fitted below zero". Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
395b613f82 |
Stop telling the reader that the moons drawn without a map were never imaged
provenanceFor ended every derived surface with "Not an observation — no image of this world exists", a sentence written for exoplanets. The branch added eleven solar-system bodies with no map in the catalogue, and eight of them are moons spacecraft photographed: Voyager 2 imaged Miranda, Ariel, Umbriel, Titania, Oberon, Proteus and Nereid, Cassini Hyperion (26 Sep 2005, from about 500 km). The textures README says so itself. Hubble sees Eris, Haumea and Makemake too, as points. Only an exoplanet now gets that sentence. A moon or dwarf planet drawn from its measurements says "no global map of this world is used here", which is true of all eleven. Read off the live pages: Titania, Hyperion and Eris end with it, and an exoplanet keeps the old wording. Controls: giving every derived surface the exoplanets' sentence fails "says a moon without a map is illustrated, without saying it was never imaged"; giving it to none fails "says an exoplanet has never been imaged". Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
87e9ec274b |
Turn Venus's map north up, so Maxwell Montes is drawn in the north where the IAU puts it
venus.jpg, from the Solar System Scope pack, is the Magellan radar map turned half round: south up and east to the left. Its brightest feature north or south of 50 degrees, Maxwell Montes, sat at 63.4 S, 8.9 W (blurred at sigma 3), with Lakshmi Planum east of it; the IAU Gazetteer puts Maxwell at 65.2 N, 3.3 E, at Lakshmi's eastern end. The IAU pole and W are right (Venus's sub-Earth longitude matched Horizons to the thousandth), and so is MAP_TO_BODY, which Earth, Mars, the Moon and Mercury were checked against; the file was not, and its surface was drawn turned 180 degrees about the prime meridian's axis. Turned back with PIL's ROTATE_180 and re-saved on the file's own quantisation tables (0.03 grey levels from the exact turn, 240 079 bytes), its brightest point is 63.7 N, 8.3 E with Lakshmi to the west, and the dev server serves that file. The textures README records the check, the MAP_TO_BODY comment adds Venus to the maps it names, and texture-catalog.spec.ts pins the checked file's SHA-256, since no image decoder runs in the unit suite (a triple-slash reference gives that one spec Node's types). Control: the pack's file put back fails "wraps Venus in the map turned north up". Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
34ae803c06 |
Take TT - UT from the historical record before 1972, so the far dates the clock reaches turn every body by the right amount
The clock reaches AD 1, but TT - UT was held at today's 69.184 s. At AD 1000 it was 1 574 s and at AD 1 about 10 570 (Espenak and Meeus, NASA's Five Millennium Canon; Horizons' TDB - UT gives 1 658 and 10 466 on JD 2086455 and 1721600). So every spin but Earth's was (ΔT - 69 s) times its rate out, Jupiter 15.2 degrees at AD 1000 and 106 at AD 1, Mars 6 and 43, and every orbit that much behind: the Moon about 0.2 and 1.4 degrees. ttMinusUtSeconds gives TT - UT for a date on the clock: the Espenak-Meeus polynomials before 1972, 32.184 s plus UTC's leap seconds from 1972 to the last one, at the start of 2017, and 69.184 s held after it, as Horizons holds it. Its pieces join within 0.1 s. tdbFromUtc, which positions and spins already share, now adds it. Within 0.2 s of Horizons in 1950, 105 s at AD 1 and 86 s at AD 1000, where the historical record itself is that uncertain. Earth is the exception: its turning is what UT counts, so the clock's date already says how far it has turned, and ΔT would turn it again, 44 degrees at AD 1. Its W, fitted to today, keeps today's 69.184 s (bodyOrientation's followsUt, set for Earth in the system view and on its page). In the running app at 1000-01-01 00:00 UT, Jupiter's drawn prime meridian sits 0.000 degrees from its IAU W at TT and 15.164 from where the held offset put it; Earth's sits on its W at UT + 69.184 s, 6.288 degrees short of what TT would have turned it to. The renderer spec now hands its frozen Horizons vectors over as the UT dates that name them through the same TT - UT, and checks Jupiter's and Earth's prime meridians at AD 1000. Controls: the leap-second rule used before 1972 fails "follows the historical record before 1972"; TT - UT held at 69 s fails "turns Jupiter at AD 1000 by its W"; Earth turned at TDB, or the renderer or the page not keeping it on UT, fails the Earth tests. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
d4808788ec |
Take the orbits at TDB as the spins already were, so a locked moon faces the planet it is drawn round
Every element set here runs on TDB: Standish's T_eph, the SSD satellite and SBDB epochs, the IAU's d and T. bodyOrientation already took the clock's UTC to TDB, but SystemOrbitsRenderer.update and the body page's heliocentricPosition fed the UTC date straight to meanElementsAt, so in one frame each body's place was 69.184 s behind its spin. That is n x 69 s of orbit: Phobos 0.90 degrees, Mimas 0.31, Deimos 0.23, Enceladus 0.21, Miranda 0.20, Io 0.16, Tethys 0.15, Europa 0.08, the Moon 0.011. 48319c3's table measured the app at a UTC date against Horizons at the same number read as TDB, which hid it, and its "nothing for anything else" was wrong: Io's 0.16 is four to five times Io's worst model error there (0.035). tdbFromUtc, in constants.ts, is now the one conversion, and positions and spins both go through it. In the running app, clock pinned to 2025-06-01 12:00 UTC, Io's face towards Jupiter is at 0.024 E, latitude -0.009, where Horizons (observer quantity 14 from Jupiter's centre) has 0.036 E and -0.003: 0.012 degrees apart, where it was 0.175. The renderer spec checks that point, and now hands its frozen Horizons vectors, which are TDB, to update() as the UTC dates that name them, 69.184 s earlier; the same frozen rows fed at the UTC date fail for Io and Europa. A body-page test checks that the Sun lights the point it stands over at the same TDB instant the body is turned for. Controls: taking the renderer's orbits at the clock's UTC fails "faces jupiter and the Sun with the points Horizons gives on io"; taking the page's Sun there fails "takes the Sun where it stands at the same TDB instant". Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
f8ee3ac3ab |
Move Mimas, Tethys and Phobos along their orbits by the terms their IAU W already carried
The IAU W of a locked moon follows its mean longitude, so a term of W that is the moon running
ahead of and behind its mean motion is its orbit's too. Two were in bodies.json's W and in no
orbit: the 71-year libration of the Mimas-Tethys 4:2 resonance, -44.85 degrees on Mimas and
+2.23 on Tethys on the angle S5 = 316.45 + 506.2 T of pck00011.tpc, and Phobos's tidal
quadratic, 9.536e-9 degrees a day squared about J2000. JPL's satellite table has a column for
neither. orbitalTermsOfPrimeMeridian now turns each into the row's meanAnomalyTerms about the
row's own epoch (Phobos's 1950 row gets the quadratic re-centred, which adds to its mean motion
and mean anomaly at the epoch), and the ETL takes them for the three moons named in their specs.
Against Horizons: Mimas on 2026 May 27, near the libration's extreme, 2.24 degrees instead of
43.3; Tethys the same day 0.18 instead of 2.05; Phobos in 2100 1.25 instead of 11.1. On the
ETL's 2025-01-01 check Mimas is 1.56 degrees, so its named 46-degree ceiling is gone. The renderer
spec freezes the Mimas and Phobos vectors.
The day-equals-orbit check checked a number that turns no locked moon: since
|
||
|
SenrokaiandClaude Opus 5.5
|
db3af1a820 |
Wrap Deimos in Stooke's Viking map, once its longitudes were settled on the body
Audit #40. deimos.jpg was a 592x592 disc photograph, 32.6% black sky, left in the folder
unlisted by
|
||
|
SenrokaiandClaude Opus 5.5
|
ac6a3bb1ea |
Let the reader set the clock to a date, and run it backwards
The clock from #33 could only run forwards from now. The Display panel's clock now has a Date (UTC) field, a native datetime-local in a form, so Enter submits it and the browser holds it to its min and max. It jumps the clock to that date, and the clock carries on from there at the rate it was running at. A Backwards toggle (aria-pressed) runs the same four rates the other way. The radios still pick the rate's size and keep the direction when it changes. The window is AD 1 to AD 3000. The end is where Standish's Table 2 stops being fitted (3000 BC to AD 3000; every planet within 0.29 degrees of Horizons at each date measured out to 3000). The start is the date input's own floor. TimeStore.setDate refuses anything outside it, and NaN, and leaves the clock where it was. The field is read as UTC. Its dates are proleptic Gregorian, as a Date is, so before 1582 they run up to ten days ahead of the Julian-calendar dates history gives. The window is written beside CLOCK_WINDOW, with the moons' shorter reach (Phobos 11 degrees out by 2100). The system note now names the date it is drawn for, to the minute: "... to 2020-12-21 18:00 UTC.", or "to now, <date> UTC." at the present. Measured in the app (port 4311, keyboard only: fill, Enter): - Set to 2020-12-21 18:00 UTC, Jupiter and Saturn seen from Earth's drawn position are 0.113 degrees apart. Horizons gives 0.102 geocentric (geometric 0.1017, astrometric 0.1018). Distances: 5.9267 and 10.8296 AU against Horizons' 5.9258 and 10.8270. - 3001-06-01 is refused by the form (validity false) and the clock does not move. - Backwards at 1 d/s: -2.011 days in about 2 s. - The field's accessible name is "Date (UTC)" and its description is the window. Its colour-scheme is dark, so the picker icon shows on the HUD. - Back to now puts the field back on the present too. Unit suite 799 -> 805: two tests for the store, three for the dock, one for the scene note. Eleven guarded mutants; each changed its file and made its named test fail. Among them: the window check dropped, the wall clock not re-anchored on a jump, the radio dropping the direction, the field read as local time, and the note not naming the date. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
dc20accfdf |
Draw Saturn's rings in the system view, lit, at the radii their texture draws
Audit #47. The body page's rings already lie in Saturn's equator (
|
||
|
SenrokaiandClaude Opus 5.5
|
302fa963ad |
Wrap seventeen moons and dwarf planets in the missions' own maps, grey where no probe looked
Audit #40. Io, Titan and Pluto had square disc photographs (40.5, 42.6 and 42.9% black sky) that PR #33 unlisted, and every other moon or dwarf planet fell through to the derived surface. Seventeen of them are now wrapped in public-domain global mosaics from USGS Astrogeology and the NASA PDS: Phobos (Viking), Io, Europa, Ganymede, Callisto (Galileo and Voyager), Mimas, Enceladus, Tethys, Dione, Rhea, Titan, Iapetus, Phoebe (Cassini), Triton (Voyager 2), Ceres (Dawn), Pluto and Charon (New Horizons). io.jpg, titan.jpg and pluto.jpg are replaced by maps under the same names. Every file is simple cylindrical over 360 by 180 degrees, with longitude 0 in the middle and east to the right, the frame MAP_TO_BODY puts on the IAU body frame. Processing: the source's no-data pixels (0 in every band) become one flat grey, the mean of the mapped surface, never invented terrain; area downsampling to 2048x1024 for bodies over 1 000 km in radius and 1024x512 for the rest; half a turn where the source is centred on 180; JPEG q85 (Europa q82). Largest file 386 KB (Europa); 3.5 MB for all seventeen. The centre was read from each GeoTIFF's central meridian and left-edge tie point, not from its label: Rhea's and Enceladus's labels say CENTER_LONGITUDE = 180 over images centred on 0. Taken from the label, Rhea came out half a turn round, which the seam it left down the middle of the map gave away. Each map was then checked by eye against the IAU Gazetteer: Pele and Loki on Io, Pwyll on Europa, Osiris and Tros on Ganymede, Valhalla and Asgard on Callisto, Herschel on Mimas, Ali Baba and Aladdin on Enceladus, Odysseus on Tethys, Creusa on Dione, Inktomi on Rhea, Xanadu, Shangri-La and Belet on Titan, Cassini Regio on Iapetus, Jason on Phoebe, Occator and Haulani on Ceres, Stickney on Phobos, Sputnik Planitia and Cthulhu on Pluto, Mordor Macula on Charon, Leviathan Patera on Triton. Unmapped share, now grey: Triton 38.6%, Charon 34.0%, Pluto 31.9%, Phoebe 20.4%, the Galilean polar gaps 3.6-4.3%, Ceres's south pole 3.6%, the rest under 0.2%. Pixels darker than 8 of 255: at most 0.55% (Charon's Mordor Macula, Pluto's Cthulhu), against the 20-43% black sky of the photographs PR #33 dropped. Left out, and said so in src/assets/textures/README.md: Deimos, whose only cylindrical map (Stooke, Viking) has no label for its longitude direction and on which neither Voltaire nor Swift could be found to settle it; the five Uranian moons, whose only maps (Schenk 2020, USRA) carry no licence; Hyperion, Nereid, Proteus, Eris, Haumea and Makemake, which have no photographic simple-cylindrical map. Source URLs, credits, licences, processing and each measurement are in the new src/assets/textures/README.md; the root README now points there and counts twenty-seven bodies in real photography. texture-catalog.spec.ts checks that the seventeen are registered and that Deimos, the Uranian moons, Hyperion and Eris are not. Unit suite 790 -> 792 tests. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
76fb38665f |
Show each body on its page turned as it is at the map's date, under its real Sun
The body page used to spin every body about its pole at 0.08 radians a second, under a light at (4, 3, 5) whatever the date. A body with IAU elements is now drawn as it is at the map's clock, using the same pole, prime meridian and map convention as the system view. It is shown pole up under a Sun held at the light's old azimuth, so the camera still opens on the day side. The Sun's height above the equator is the real one, and so is the face it lights. The clock's rate now turns the page too: at 1 h/s Earth's sub-solar point moved 15.17 degrees in the 1.012 h of sky one wall second carried. What the page gives up is the stars, which do not turn with the body. bodyPageView in src/app/shared/rendering/body-orientation.ts takes the Sun's direction from where the body is: a planet's own mean elements, a moon's planet's place plus its own offset. It sets the sphere's rotation and the light's direction. Exoplanets, Eris, Haumea and Makemake keep the old slow turn and light. Saturn's rings now lie flat in its equator, the page's horizontal. They used to lean 17 degrees, which put them out of the plane they orbit in. Measured: - Live app, clock pinned to 2025-06-01 12:00 UTC: the Sun stands over 0.433 W, 22.125 N on Earth's page, the same point as on its sphere in the system view. - Unit test, raycast on the page's own sphere: Earth one light-time earlier is 0.09 degrees from Horizons' sub-solar longitude. Its latitude, put on the flattened Earth, is within 0.03. - The Moon's sub-solar point is within 0.004 of Horizons'. Three mutants each fail their named test: a moon lit as if it had no planet; the Sun not held at the page's azimuth; the body left in the ICRF instead of the page's frame. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
cdf474bcd5 |
Turn every body in the system view by its IAU pole and prime meridian, so the lit face is the real one
Until now each body's axis was its orbit normal, tipped by the obliquity about the orbit's node, an azimuth the data never gave. Its phase started at an arbitrary point at the elements' epoch. The rate and the sense were real; the face towards the Sun was not. Now each of the 33 bodies with IAU elements is set, every tick, from its pole and its W at the clock's date. Eris, Haumea and Makemake keep the old fallback: their published period, about their orbit normal. None of them has an obliquity, so the tilt code that only served bodies now turned by the IAU is gone. Exoplanets have no rotation published and stay still, as before. The texture convention is settled once, in src/app/shared/rendering/body-orientation.ts (MAP_TO_BODY): - SphereGeometry runs u eastward about +Y from a seam on -X, so u = 0.5 faces +X. - Every photograph in the catalogue is centred on longitude 0 with east to the right. Checked on the maps: Greenwich; Olympus Mons 134 degrees left of centre; Mare Crisium right and Mare Orientale left; Kuiper just left. - A map labelled in west longitude is still drawn east-right, so where longitude 0 sits is the only question, and for all of them it is the centre. - So a quarter turn about X puts the map on the IAU body frame: pole +Z, prime meridian +X. The scene is already ICRF equatorial (the ecliptic is turned into it by the J2000 obliquity), so the pole goes in as it is. The equator frame is built through laplacePlaneToEquatorial, the same conversion the moons' Laplace planes use; moonFrame now calls it too. The clock is UTC and the elements TDB, so TT - UTC (69.184 s) is added: Earth turns 0.29 degrees in that time, Jupiter 0.70 and Phobos 0.90. Measured on the live app (port 4311), clock pinned to 2025-06-01 12:00 UTC: - The Sun stands over 0.433 W, 22.125 N on Earth's drawn sphere. The equation of time puts it at 0.53 W. - Each body was drawn one light-time earlier and compared with Horizons' observer quantities 14 and 15: - Earth (from the Sun): longitude 0.095 off. - Mars: sub-Earth 0.001, sub-solar 0.004. - Jupiter: sub-Earth 0.005, sub-solar 0.002. - The Moon: sub-solar 0.004; sub-Earth 0.699, which is the error of its mean orbit. - Horizons' latitudes are planetodetic. Raw, they differ by the flattening: Earth 0.14, Mars 0.23-0.27, Jupiter 0.33, the Moon (a sphere) 0.000. The unit tests put the same comparison through real raycasts on the drawn spheres' texture coordinates, with the latitudes put on each body's flattened figure. Every residual is within 0.09 degrees, but for the Moon's sub-Earth point (0.70 and 0.09). The retrograde tests of #33 are rewritten for the IAU's convention: a planet's named pole is the one on the north side, so W runs backwards for Venus and Uranus, while Pluto follows the right-hand rule. The spin read off the drawn sphere, against the drawn orbit's normal, is 177.36 for Venus, 97.77 for Uranus and 119.61 for Pluto, all past 90, and 23.44 for Earth. Each is within 0.5 of Horizons. Six mutants, each failing its named test: the map upside down; UTC taken for TDB (Jupiter's test); W turned the wrong way (the retrograde test, and again Earth's noon test); moons, or planets, not turned by the IAU; and the fallback ignoring a negative period. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
1c86584642 |
Carry every body's IAU rotational elements, read from NAIF's kernel of the 2015 report
bodies.json now holds, for 33 of the 38 bodies, the pole right ascension and declination and the prime meridian W of the IAU WGCCRE 2015 report (Archinal et al. 2018), with their rates and the periodic terms. They are read from NAIF's pck00011.tpc, which carries the report in a form a program can read, periodic terms and their angles included. Hyperion (chaotic), Nereid, Eris, Haumea and Makemake have no model in the report. The parser, src/app/shared/astro/rotational-elements.ts, sits beside the other source readers so the unit suite covers it. It reads data blocks only where \begindata stands alone on a line, as the kernel's own prose mentions the token mid-sentence. It reads the Fortran exponent (the Moon's -1.4D-12 d² term) and the degree-2 angles of the Mars system, where Phobos's tidal acceleration lives. NAIF numbers a small body 2 000 000 past its catalogue number, so Ceres is 2000001. Periodic terms under 0.01 degrees are left out. 0.01 degrees moves a point by 0.11 px on the largest body ever drawn (Jupiter at 641 px of radius). That drops 32 terms: - Mercury: 4 (0.0011 degrees and less) - the Moon: 8 of 13 (0.0072 and less) - Mars: 13 (0.00024 and less); its three 0.42-1.59 degree long-period terms stay - Phobos: 1 (0.0063) - Jupiter: 5 (0.0022 and less) - Europa: 1 (0.009) Kept, among others: Mimas's 44.85-degree libration, Triton's 32-degree precession, Miranda's 4.4 and Phobos's 1.14-degree libration. build.ts now checks the elements against Horizons on the real catalogue: - Every body but those five carries elements, and they do not. - The IAU day, 360 over W's rate, is within 1e-4 of Horizons' period. Measured: at most 1.8e-5 (Jupiter). Neptune gets a 0.01 ceiling: 0.89 per cent, because the report takes Karkoschka's 15.9663 h where Horizons keeps Voyager's 16.11. - The spin axis, the pole turned end for end where W runs backwards, is within 0.1 degrees of Horizons' obliquity. Measured: at most 0.058 (Venus, 177.358 against 177.3); Uranus 97.771, Pluto 119.610, Earth 23.435. Full npm run etl passes. Three mutants each fail it on the named check: - W's sign dropped: "Venus's IAU spin axis is 2.642 degrees". - Ceres looked up by catalogue number: "Body ceres has no IAU rotational elements". - W's rate read per century: "Mercury's IAU day ... 3.65e+4". Nothing is drawn from these yet. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
ab7d454db1 |
Read Mercury's obliquity in the arcminutes its Horizons page gives it in
Mercury's page states "Obliquity to orbit[1] = 2.11' +/- 0.1'", in arcminutes, where every other page writes degrees. The pattern took the number alone, so bodies.json had Mercury tilted 2.11 degrees, sixty times too far, and the system view drew it that way. It now reads the arcminute mark and divides by 60: 0.0352 degrees, against the 0.034 the IAU's pole for Mercury makes with its orbit. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
1d42be2ad5 |
Add Charon, the moons of Uranus, Saturn's other large moons and the four dwarf planets past Pluto's table
The solar system stopped at 18 bodies: Pluto without Charon, Uranus without a moon, Saturn with Titan alone, no dwarf planet but Pluto (audit #22). bodies.json now holds 38: the eight planets, the five IAU dwarf planets, and every moon in JPL's mean-element table more than 100 km in mean radius. New: Ceres, Eris, Haumea, Makemake; Mimas, Enceladus, Tethys, Dione, Rhea, Hyperion, Iapetus, Phoebe; Miranda, Ariel, Umbriel, Titania, Oberon; Nereid, Proteus; Charon. Search finds each by name (it indexes bodies.json), each has a body page, and the Sun's system draws them. Where they come from - Moons: the same archived JPL satellite table as the others. Uranus's and Pluto's are given against the planet's equator, with the IAU WGCCRE 2015 poles: Pluto's as the IAU gives it (132.993, -6.163), Uranus's at the end the table measures inclinations from (77.311, 15.175) with its nodes counted 180 degrees on, from the IAU pole's crossing; read without that offset every Uranian moon was 180 degrees from Horizons at every date from 1980 to 2100. - Two rows are corrected where they disagree with JPL's own ephemeris and the reason is known. Pluto's section prints epoch 2000 Jan 1.0; JPL's current table gives Charon's as 2000-01-01.5, and at 1.0 Charon was 27.8-28.2 degrees from Horizons at every date, half a day of its motion. Phoebe's mean motion gives 548.02 days where its Horizons page and the current table give 550.30 (the table's own note says its source misstated retrograde moons' mean motions); on the row's figure Phoebe was 24.6 degrees out by 2025 and 100 by 2075. - Dwarf planets: JPL SBDB osculating heliocentric elements with their epoch (2026 Jun 9), carried at their own n. Against Horizons (heliocentric, 1950-2300; the clock only runs forward from now): Ceres 0.02 degrees in 2025, 1.9 in 2050, 4.0 in 2075, 5.3 in 2100, 11.6 in 2200 (Jupiter pulls on it and nothing here carries that); Eris within 0.06 to 2100 and 0.5 to 2300; Haumea within 0.35 to 2100; Makemake within 0.25 to 2100 and 1.7 by 2200. - Size and spin: Horizons pages for the moons (Charon 606 km, Miranda 235.7 as the mean of its three axes). The SBDB for Ceres (469.7 km, 9.074 h) and for the other three's spins (Eris 25.9 h, Haumea 3.915 h, Makemake 22.83 h). Neither source nor the WGCCRE 2015 report has a radius for Eris, Haumea or Makemake, so each carries its stellar-occultation measurement: Eris 1163 km (Sicardy et al. 2011), Makemake 715 (Brown 2013, the mean of 1434 x 1434 x 1422 km), and Haumea 797.6, the radius of a sphere of its volume: it is triaxial, 1161 x 852 x 513 km (Ortiz et al. 2017), and is drawn as that sphere. - Rotation uses the branch's model. Every moon is locked except three: Hyperion's page says "Chaotic" and Nereid's gives no spin, so both are left still; Phoebe turns in 9.274 h. - Charon carries massRatio 0.12205, the GM ratio of the two Horizons pages (106.10 / 869.326), so it and Pluto are drawn round their barycentre 2 131 km from Pluto's centre. Validators (tools/etl/build.ts, on the real catalogue; full npm run etl passes) - Offsets from Horizons on 2025-01-01, new bodies: dwarf planets at most 0.016 degrees (Ceres), under the 0.25 ceiling; moons Dione 0.009, Ariel 0.058, Rhea 0.070, Charon 0.111, Oberon 0.142, Titania 0.185, Umbriel 0.219, Proteus 0.245, Enceladus 0.309, Phoebe 0.984, Miranda 1.162, Tethys 2.042, under the 2.5 ceiling, which is unchanged. - Four moons get their own ceiling, each just above its worst offset at twelve dates from 1980 to 2100 and each named with its reason: Mimas 46 (measured up to 44.7: its resonance with Tethys swings its longitude 44 degrees either way over 70.8 years, which the table has no column for), Hyperion 21 (20.2; held in resonance by Titan, and the row's eccentricity 0.0232 is under a quarter of the current table's 0.105), Iapetus 11 (10.1; the row sits 9.4 degrees behind Horizons at its own epoch and keeps that, with its plane within 0.07 degrees and its period within 0.001 per cent), Nereid 3 (2.6 in 2025; eccentricity 0.75). - New checks: every body has a radius over 0 (Charon's would have been 0 before the page parser learnt its form); a freely spinning moon is not locked; a moon with a mass ratio puts the barycentre outside its planet; there are 5 dwarf planets. - Negative controls, each a full npm run etl on the real catalogue refused with the named message: Uranus's node offset removed (Miranda 172.50 degrees), Charon at the printed epoch (28.08), Phoebe on the row's mean motion (24.61), Charon's radius unread (no radius), free spinners locked (Hyperion), mass ratio inverted (barycentre 17 460 km out). Measured in the running app (port 4311): the Sun's system has 38 members ("13 + 25 moons"); Charon comes back to within 0.0004 degrees of where it started after 6.38723 days and is 179.98 degrees round after half that; Pluto is 2 130.6 km from the barycentre and Charon 17 456.8, exactly opposite; Saturn's moons in order of distance now: Mimas 185 617 km, Enceladus 238 042, Tethys 294 648, Dione 376 805, Rhea 526 964, Titan 1 231 389, Hyperion 1 470 453, Iapetus 3 637 059, Phoebe 11 740 900. At the arrival framing the dwarf planets are held at the 3 px floor and the moons at 1.5 px, half their planet's drawn radius, the scene's existing rule. Searching Charon, Enceladus, Ceres, Titania, Makemake and Phoebe each finds the body; the body pages show Charon 6.39 d and 606 km, Titania 8.71 d, Ceres 4.6 yr and 470 km, Haumea 283 yr and 798 km, Hyperion 21.3 d, each with its orbit source. Long tasks on entering: see the previous commit. The Sun's note now says the four dwarf planets are on the SBDB's osculating elements. Holding Eris's orbit, the arrival framing widens: 192 AU of range on a 1600 x 1000 window, under the 200 AU ceiling. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
de34ffff43 |
Paint a system's derived surfaces after entering it, not while building it
Every body with no photograph gets a surface derived from its measurements, a 128 by 64 texture painted on the main thread as its marker was built, inside the task that enters the system. At about 4.4 ms each (measured in node for the twenty the next commit adds, 88 ms together), that is the cost that grows with the number of bodies: with the solar system at 38 bodies, the long tasks after selectStar(0) were [219, 72], [228, 79] and [177, 72] ms over three runs, against [85, 72], [94, 75] and [78, 67] at 18. buildMarker now gives such a body its kind's flat colour and hands the painting to the renderer, which paints one surface per task (setTimeout 0) once the constructor has returned, and drops the rest if the system is left first. Measured in the running app (port 4311, three runs each, long tasks over 50 ms in the 9 s after entering the Sun's system): - 18 bodies: [79], [73], [77] ms. The task that entered the system is under 50 ms. - 38 bodies: [55, 72], [69, 78], [60, 83], and [52, 78] on a fourth run. The entering task is 52-69 ms, down from 78-94 before this change with 18 bodies, so the twenty new bodies add no long task over what the branch had. What they still add to it is not measured apart. The flat colour shows for a moment: the Sun's 29 derived surfaces were all painted 436, 689 and 399 ms after its renderer was built (three runs), and a surface once painted is cached, so a return visit paints them at once. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
7b65ab4812 |
Draw a planet and a heavy moon going round their barycentre, as Pluto and Charon do
Standish's "Pluto" is the Pluto-Charon barycentre, and Charon is an eighth of Pluto's mass, so that point lies 2 131 km from Pluto's centre, 943 km above its surface. Drawn the usual way, with Pluto at its row's position and Charon going round it, Pluto sits where nothing is and Charon's orbit is 2 131 km too wide on one side. A moon record can now carry massRatio, its mass over its planet's. For such a moon the renderer keeps the pivot at the planet's elements, which is the barycentre, and each tick puts the planet massRatio / (1 + massRatio) of the relative separation back from it and the moon the rest out. Both orbits are the relative ellipse scaled, the moon's by 1 / (1 + q) and the planet's by -q / (1 + q), turned with the moon's node every tick: Charon's spans 17 460 km of radius and Pluto's 2 131, round the same point, and neither passes through Pluto. Only Charon will carry it; every other moon's barycentre is inside its planet. Checked against Horizons in the unit suite, on JPL's records for the two: Pluto (999) from the Pluto-system barycentre (9) in 2100 is 2 131.24 km out, and the renderer puts it within 5 km of that length and 0.5 degrees of that direction, exactly opposite Charon at the inverse of their mass ratio; Charon from Pluto is within 0.5 degrees of Horizons in 2100 (measured 0.37). The same table adds Titania, against Uranus's equator 120 years from its 1980 epoch, within 0.75 (measured 0.62). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
b0d7989c6f |
Read moons given against their planet's equator, and dwarf planets from the Small-Body Database
Two sources the missing bodies need, read and tested before any body uses them.
JPL's satellite table gives Uranus's and Pluto's moons against the planet's equator ("Mean
equatorial orbital elements") rather than a Laplace plane, and does not print that equator's
pole. parseSatelliteMeanElements now takes the pole from its caller for such a section and reads
the row against it exactly as against a Laplace plane's; it throws if a section is equatorial and
no pole was given, or a pole was given for a section that is not. Read as ecliptic elements, which
is what the old code would have done, Titania is 88 degrees from Horizons on 2025-01-01. The
section's plane is now the nearest heading above the row, with the ecliptic as before where there
is none.
Ceres, Eris, Haumea and Makemake are in none of Standish's tables. parseSmallBodyElements reads a
JPL SBDB answer (sbdb.api?sstr=...&phys-par=1&full-prec=1): the osculating heliocentric elements
against the J2000 ecliptic, carried round at their own n with nothing turning, and half the
published diameter and the rotation period where the answer has them. full-prec matters: without
it SBDB rounds to three figures, Ceres's n to 0.214 degrees a day for 0.2143045, 1.1 degrees out
within a decade. The fetcher, tools/etl/lib/mean-elements.ts, caches the answer like the others.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
||
|
SenrokaiandClaude Opus 5.5
|
cdc0cf4678 |
Read the Horizons pages the missing moons are written in, and give triaxial bodies their mean radius
The pages of the moons this branch is about to add state their size and spin in forms the ETL
did not read. Charon's gives "Radius (km, IAU2015) = 606", which none of the radius patterns
matched, so it would have come out at radius 0. Phoebe's gives "Rotational period = 9h 16.438 m",
which the hours-or-days pattern read as 9 hours flat instead of 9.274. Pluto's and the moons' GMs
are now read too ("GM (planet) km^3/s^2 = 869.326" on Pluto's page, "GM (km^3/s^2) = 106.10" on
Charon's), for placing a pair's barycentre.
Miranda and Ariel, like Phobos and Deimos already, give three semi-axes, "240x234.2x232.9". The
first figure was taken as the radius, which is the longest axis. A triaxial body now gets the
radius of the sphere of its volume, the cube root of the product, which is how the IAU states a
mean radius. That changes two bodies already shipped: Phobos 13.1 -> 11.06 km (IAU 11.08) and
Deimos 7.8 -> 6.20 km (IAU 6.2). Nothing else in bodies.json moves.
The page parsers move from tools/etl/lib/horizons.ts to src/app/shared/astro/horizons-page.ts,
as the mean-element parsers did, so the unit suite runs their tests; the ETL imports them. A
small body's command ("1;" for Ceres) is now URL-encoded: sent raw, the semicolon made Horizons
refuse the request ("one or more query parameter was not recognized").
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
||
|
SenrokaiandClaude Opus 5.5
|
2e5daa0f97 |
Give every body the period it is drawn going round in, and say where its orbit comes from
Audit #38: Europa's card listed its axis, eccentricity and inclination but no period, while the scene turned it round Jupiter all the same: heliocentricPeriodDays refused every moon, since the catalogue carried no planet masses. Every solar-system body's period is now 360 over the JPL mean motion that carries it round the scene, filed under Measured since that is JPL's published figure: Europa 3.55 d, the Moon 27.3 d, Saturn 29.5 yr on the live cards, Earth 365.2564 d. heliocentricPeriodDays is gone. Exoplanets keep the archive's period, or none. The card's provenance line now ends with where the orbit comes from, "Orbit: JPL SSD satellite mean elements, epoch 1997 Jan 16." for Europa, "Orbit: JPL approximate mean elements (Standish), fit for 3000 BC to AD 3000." for a planet, and the Sun's system note says so too: "Orbits propagated from JPL mean elements, the planets' fit for 3000 BC to AD 3000, to the current date." Other systems keep "published elements". All three read in the running app. Each has a test that fails without it (moons refused a period, provenance without the orbit, a note without the source). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
48319c3fe2 |
Move the solar system on JPL's mean elements, so it stays right as the clock runs
Every body carried one set of osculating elements from Horizons at 2025-01-01, run forward by
Kepler with a GM from a table of mass ratios. That set is exact at its instant and drifts from
then on, and the clock now runs a month a second: the Moon, with Earth's mass ratio lacking its
own and the osculating axis, went round in 27.70 days instead of 27.32, 66 degrees out after a
year, and its locked face was spun at the same wrong rate.
Planets and Pluto now take Standish's Table 2a/2b ("Keplerian Elements for Approximate
Positions of the Major Planets"): elements against the J2000 ecliptic, their rates per century,
and the b, c, s, f terms of Jupiter to Pluto, fit for 3000 BC to AD 3000. Table 1 is closer near
the present (Saturn 0.23 degrees at worst 1950-2100, against 0.32 here) but is only fit for
1800-2050, and by AD 3000 has Saturn 4.3 degrees out where Table 2 holds every planet within 0.3.
The moons take JPL SSD's satellite mean elements: sidereal mean motion n to ten figures, the
periods of their node and periapsis, and each one's local Laplace plane by its pole. They
propagate with n itself, never a GM: gmForParent and its mass table are gone. Horizons still
gives size, spin and obliquity.
Both tables are read from the Internet Archive's copy of JPL's pages, pinned to one capture: the
live approx_pos page has dropped Pluto, and the live sats/elem page has dropped n and rounds the
period to four or five figures (Phobos 0.3187 d, a revolution out within a decade).
What the tables leave implicit, measured against Horizons before it was accepted:
- The precession periods are magnitudes. A node regresses on a prograde orbit and advances on a
retrograde one; a periapsis advances except where a resonance forces the eccentricity. Io's
and Europa's follow their conjunction line backwards at 2 n(Europa) - n(Io) = 0.74 degrees a
day, which is exactly the 1.625- and 1.394-year periods in the table. Read as advancing, Io
was 0.9 degrees out and Europa 2.1.
- On a retrograde orbit the node's turning is added back to the mean anomaly. Taken off, Triton
drifted a degree a year, 105 degrees by 2100.
- The Laplace frame's x axis is where the plane rises through the ICRF equator, RA of the pole
plus 90. Read against the ecliptic, Io was 2.8 degrees out, Phobos 54 and Titan 127.
Orbit lines are now drawn in their own plane and turned by a quaternion each tick, so a turning
node carries the line with the body: fixed at one date, the Moon's line would be up to 69 000 km
off it nine years on. The Earth row is the Earth-Moon barycentre, 4 700 km from Earth, 0.002
degrees from the Sun. A tidally locked moon's day is now 360 / n, its sidereal period (the Moon
27.321662 d), so it stays locked to the orbit it is drawn on.
Angular error against Horizons VECTORS (ICRF, TDB; heliocentric for planets, planet-centred for
moons), degrees, read from the live renderer's markers in the running app:
body 1950-01-01 1975-01-01 1987-07-23 2000-01-01 2025-01-01 2037-03-06 2050-01-01 2075-01-01 2100-01-01 max
mercury 0.004 0.002 0.003 0.002 0.002 0.001 0.000 0.002 0.000 0.004
venus 0.003 0.007 0.003 0.004 0.004 0.004 0.003 0.004 0.004 0.007
earth 0.003 0.008 0.002 0.005 0.004 0.009 0.003 0.002 0.003 0.009
mars 0.009 0.010 0.008 0.024 0.009 0.012 0.009 0.011 0.028 0.028
jupiter 0.063 0.030 0.171 0.135 0.013 0.020 0.056 0.041 0.075 0.171
saturn 0.080 0.064 0.018 0.320 0.066 0.114 0.044 0.164 0.177 0.320
uranus 0.018 0.169 0.068 0.050 0.101 0.015 0.141 0.017 0.114 0.169
neptune 0.070 0.028 0.004 0.021 0.036 0.037 0.013 0.029 0.072 0.072
pluto 0.045 0.054 0.041 0.033 0.019 0.020 0.023 0.027 0.026 0.054
moon 0.486 1.928 0.127 0.631 1.407 1.086 0.720 0.339 1.180 1.928
phobos 2.068 0.294 0.881 1.113 0.313 0.636 2.089 5.862 11.099 11.099
deimos 0.077 0.043 0.310 0.066 0.164 0.068 0.034 0.468 0.044 0.468
io 0.021 0.015 0.010 0.019 0.009 0.035 0.006 0.011 0.022 0.035
europa 0.036 0.039 0.053 0.064 0.078 0.032 0.006 0.034 0.044 0.078
ganymede 0.132 0.103 0.018 0.007 0.023 0.054 0.091 0.118 0.044 0.132
callisto 0.040 0.019 0.023 0.019 0.038 0.008 0.060 0.119 0.056 0.119
titan 0.003 0.019 0.023 0.023 0.027 0.028 0.048 0.008 0.014 0.048
triton 0.051 0.029 0.009 0.021 0.052 0.048 0.063 0.089 0.137 0.137
Three miss what was hoped for, and why:
- Jupiter 0.17, Saturn 0.32, Uranus 0.17 against the 0.1 hoped for: short-period perturbations
of the giants by one another, which no Keplerian fit carries. Standish states his own Table 2
errors as 600, 1 000 and 2 000 arcseconds (0.17, 0.28, 0.56 degrees). Out to AD 3000, measured
at 1800, 2200, 2400, 2600 and 3000, every planet stays within 0.3.
- The Moon, 1.9: evection (1.27) and variation (0.66), which a mean ellipse leaves out.
- Phobos, 2.1 until 2050, then 5.9 in 2075 and 11.1 in 2100, growing as the square of the time:
its tidal acceleration, which the table has no column for. Its elements are MAR080's, epoch
1950. The map's dates are also UTC where the elements are TDB, 69 s today,
which is 0.9 degrees of Phobos and nothing for anything else.
Held in place by:
- build.ts: each body's mean elements against Horizons' own osculating elements on the ETL's
2025-01-01, at most 0.25 degrees for a planet and 2.5 for a moon (measured: Uranus 0.101, the
Moon 1.407; a regressing Triton node reads 10.24 and fails), and every moon's day equal to its
sidereal period (a 1% error fails).
- Unit tests freezing nine Horizons vectors (Earth 2100, Jupiter 1950, Saturn 2075, Pluto 1975,
the Moon 2050, Io and Europa 1950, Titan and Triton 2100) through SystemOrbitsRenderer, the
Moon kept on its own turning line, the retrograde rule, the Standish terms, the Laplace frame,
and both table parsers. Nine mutants each fail the test named for them, and the two
validators each refuse a mutated build of the real catalogue.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
||
|
SenrokaiandClaude Opus 5.5
|
c38a42cbcb |
Fix what the review of this branch found, starting with the pick rule it only claimed
The off-screen rule for clicks was described in
|
||
|
SenrokaiandClaude Opus 5
|
468c98b14a |
Surface the system view with the photographs it already had, lit by its star
Every body in the system view was an unlit sphere wearing a 32 by 16 pixel procedural texture — the size chosen when a marker was a few pixels across and what survived was its average colour. The thirteen real photographs in `src/assets/textures/bodies/` were used only by the detail page. So Mars was a pale grey ball with invented polar caps while its own NASA mosaic sat unread in the repository, and nothing had a day side or a night side. Each marker now takes its own photograph where one exists, at the size the detail page uses, and the derived texture only where none does — the five moons no probe mapped, and every exoplanet, none of which has ever been imaged. The material is lit, and the light is a point at the star, so each world shows the terminator where it really falls. The light does not fall off with distance. Under the inverse square that real light obeys, Neptune receives a thousandth of what Mercury does and reads as black; the map is a set of worlds to look at rather than a light meter, so each is lit as a photograph of it would be. That is the same concession the pixel floor makes for size, and it is only about brightness: the *direction* is real. Spheres are 32 by 24 rather than 16 by 12, since at true scale a body is drawn anywhere from a pixel to the whole frame and the old silhouette was visibly faceted at the near end. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5
|
4b276e44a5 |
Give the map a clock, so the sky it computes can be watched
The orbits and the rotations are both functions of a date, and the only date the map ever asked for was this instant. So a view built on propagated ephemerides showed a still picture: Earth turns 15 degrees an hour and takes a year to go round, and a reader watching for a minute saw nothing move at all. `TimeStore` is that date, at a rate the reader sets: real time, an hour a second, a day a second, a month a second. It is read once a frame rather than held in a signal — it changes continuously, and a signal changing sixty times a second would ask the whole HUD to re-render for a number nothing is watching. Changing the rate re-anchors rather than rewinding, so speeding up and slowing down never jumps the sky, and "Back to now" returns to the world's own time. Measured in the app, three seconds of watching in the Sun's system: | rate | sky elapsed | Earth turned | Jupiter moved | |---|---|---|---| | real time | 0 | 0 | 0 | | 1 h/s | 3.0 h | 45.12 deg | 0.0009 AU | | 1 d/s | 3.0 d | (three full turns) | 0.0222 AU | 45.12 degrees in three hours is 15.04 an hour, which is Earth's own sidereal rate, and Jupiter's 0.0222 AU in three days is its own orbital speed. The rates are radio buttons, not toggles: they are one of four, and the native control carries that to a screen reader and to the arrow keys with no script. The date joins the strip only while the clock is running faster than the world, since at real time it is today's, which the reader's machine already says. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5
|
225d676ab0 |
Turn each body at its own rate, from Horizons' own figures
The view had one rotation in it — the planet on the detail page, at 0.08 rad/s, a number with no source. Nothing in the system view turned at all. The data was already on disk: every cached Horizons page carries how its body spins, in one of five forms. The rate in radians per second is preferred where it appears, because it is signed — that is how Venus and Uranus are known to turn backwards — then a period in hours or days, then the `9h 55m 29.711 s` the giant planets use, and finally the word every major moon here carries instead of a number: Synchronous. A tidally locked moon's day is its orbit, so Kepler supplies it from the elements already parsed and the parent it goes round. Seventeen of the eighteen bodies come out within 1% of their published period — Earth 23.934 h, Jupiter 9.925 h, Venus -5832.5 h, Io 42.5 h, Callisto 400.5 h. Titan is the exception: its page states no period at all, so it is left still rather than turned at an invented rate. The axis is the orbit normal tilted by the obliquity about the orbit's ascending node, which is where an obliquity is measured from and the only line in the orbit the elements name. The phase at the epoch is published for none of these bodies, so the face turned toward the camera is not a claim; the rate and the direction are. At true rates nothing is visible moving — Earth turns 15 degrees an hour. A clock the reader can run faster is the next piece, and the audit asks for it anyway. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi |
||
|
SenrokaiandClaude Opus 5
|
3f0abf8717 |
Draw the system at true scale, drop the halo, and refuse to enter what is off screen
Three changes to what the system view claims, all of them the same claim: that the sizes on screen mean something. **The halo is gone.** It was a sprite sized against the arrival frame — 1.12 AU for the Sun — so it stayed that wide as the camera closed in and ended up a flat gradient filling the screen, over the photograph it was meant to dress. It existed to keep the star visible at a framing that holds the whole system, which is now handled in pixels instead. **Bodies are drawn at their own radius.** The old marker size was exaggerated and scaled to the system span, and clamped: Jupiter and Ganymede both ran past the ceiling and were drawn at one radius, so every moon orbited inside its planet, and Phobos and Triton sat entirely within Mars and Neptune. True scale needs no rule against that — physics already puts a moon outside the planet it orbits. What it costs is visibility at the arrival framing, where every body is sub-pixel, so the scene floors each marker at 3 px on screen and holds a moon to half its planet's drawn size. Measured in the Sun's system: at arrival, planets 3 px and moons 1.5 px, against 3 px for everything before; at Jupiter, the planet 10.8 px at scale 1 with the Galilean moons on their orbits outside it. The Sun is drawn at its own radius too. Every other star keeps a size derived from its innermost orbit, because no stellar radius reaches the app — Gaia's `radius_gspphot` is the obvious next fetch. **A click cannot enter a system that is not on screen.** The picker tested depth but not the frame, and a star's hit area is its drawn size plus a slop, so a click in the last pixels of the view could fly into a system outside it, with nothing on screen to explain where it had gone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi |
||
|
Senrokai
|
e45c3b6287 |
Merge pull request #32 from avalon-vanguard/fix/routes-panel-honesty
Let the Routes panel be clicked as soon as it is back, and stop it departing from elsewhere |
||
|
SenrokaiandClaude Opus 5
|
2d06408c3f |
Merge main into fix/routes-panel-honesty
Both sides added a test beside the other in the dock's spec: the panel's own departure guard here, the give-up wording on main. Both kept, and the offer test carries the `least` the route answer now has. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi |
||
|
Senrokai
|
56870fd9fe |
Merge pull request #31 from avalon-vanguard/fix/grid-rings
Size the distance rings by what the frame reaches, and keep their labels off the star names |
||
|
Senrokai
|
cea39c7186 |
Merge pull request #30 from avalon-vanguard/fix/route-search-budget
Tell a search that gave up from a route that is not there |
||
|
Senrokai
|
03b3d3b2d6 |
Merge pull request #29 from avalon-vanguard/fix/etl-gaia-floor
Refuse a Gaia answer that came back short, and read the body inside the retry |
||
|
SenrokaiandClaude Opus 5
|
0c5efec505 |
Measure the ring span along the plane the rings lie in
The span went to `distanceRings` as the target's straight-line distance from the Sun, but a ring of radius r passes within |r - p| of the view's centre, where p is how far out that centre is *along* the galactic plane. For a target above the plane the two differ by its height, so the band was centred on a radius no ring has — and `ringLabels` picks its bearing by comparing its own in-plane distance against the innermost ring, a comparison the new first ring quietly broke. Two comments and a constant, from the same review. A frame short of the survey edge gets its callout only when its last ring overshoots it: 245 pc does, 235 pc does not, which is now a test rather than a sentence. The ring count can reach 16, not 14, now that the span need not start at the Sun. And a ring label was measured as 135 px of star name when "50 pc" is a third of that, which rejected rungs a hand's breadth clear of the name: RING_LABEL_REACH_NDC, 0.23, is the widest of them — "1.5 kpc" with "Survey edge" under it. Three mutants, three caught. Measured again in the app: unchanged for a star in the plane (4 labels at 20 pc above it, 7 at 2 pc), and the rings now follow the plane for one 195 pc above it rather than ringing a place the grid does not reach. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi |
||
|
SenrokaiandClaude Opus 5
|
337602f606 |
Make the budget test spend the budget, and bound the probes that earn nothing
The fixture built for "exactly MAX_VISITED stars reachable" was 338 short: its random cloud leaves clumps the departure never reaches (the LCG gives 12 212 distinct positions for 39 999 stars), so the search settled 39 662 and the pre-fix code answered `gaveUp: false` too. The test could not fail on the code it was written to pin — and the mutant that seemed to prove otherwise was failing to compile, not failing the test. It is now a line of 40 000 a parsec apart with the island off the line: settled 40 000 exactly, 115 ms, and the pre-fix code does report a give-up. Both mutants now compile and are caught. The give-up cap also has to hold while the bisection has earned nothing: the exception added for that case had no bound at all, so a search could spend the resolution's own eight full-budget probes — about 17 s of "Plotting…" — where two used to cost 4 s. Bounded at five. On the repo's crowded-knot fixture: 1.9 s for the unearned ceiling figure with the old cap, 7.2 s for a range the bisection earned, and five probes is where that lands. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi |
||
|
SenrokaiandClaude Opus 5
|
1a5785fb63 |
Keep the row cap live for the queries that can reach it
Gating it on `jobsQuery` switched it off for every override that *widens* the query — which is the only way to fill `select top N` at all. `ETL_GAIA_MAGNITUDE_LIMIT=14` asks for 500 000 rows, the sky holds more, and the answer is the limit rather than the filters: exactly what the tripwire is for, and it no longer fired. It now reads the row limit itself, so only a deliberately smaller slice is silent. Measured with a synthetic answer of exactly 500 000 rows in the cache, under the key the widened query hashes to: refused. With the `jobsQuery` gate back, the same run keeps 500 000 Gaia stars and goes on to publish them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi |
||
|
SenrokaiandClaude Opus 5
|
dd56eafba4 |
Answer the review: hold the offer to the same test as the button
`canPlot()` guarded the Plot button and not `raiseTo`, which is the other way into `plot()`. So with a departure typed but never chosen, clicking "1.8 pc would reach." moved the range control and plotted nothing: the panel then read "No route at this range. 1.8 pc would reach." beside a control already set to 1.8. The offer carries the same `disabled` as the button, since it is the same request by another route. And the departure guard is trimmed, as the scene trims the same text before offering matches for it: one space in the field left it looking empty, with no suggestions to pick from, and Plot dead for no reason on screen. Measured in the app, from inside Barnard's Star with Sirius as the destination: offer enabled with the field empty, disabled once "Sol" is typed and never chosen — a forced click then moves nothing — and enabled again when the field is cleared, where it raises the range to 2.40 pc and plots 7 jumps. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi |
||
|
SenrokaiandClaude Opus 5
|
7fba48c808 |
Answer the review: size the rings to the band the frame covers, and clear the text
The rings are centred on the Sun and the frame need not be. Sizing their step from how far the frame reaches — 210 pc for a star at 190 with the camera 20 pc back — gives 20 pc rings at 180 and 200, both outside a frame 19 pc deep, so a view away from the Sun still had no ring on it and no ladder of labels either. `distanceRings` now takes the span the frame covers rather than its far edge, and the step is a fifth of that: 5 pc rings from 165 to 210 for the same view. Measured in the app, centred on a star 187 pc out in the galactic plane: 4 ring labels drawn 20 pc above the plane and 7 from 2 pc, against 1 and none before. The clearance was a radius around the anchor, and a label is a line of text hanging 135 px to one side of its anchor: at 0.065 NDC apart, past the radius, "50 pc" printed inside "Alpha Centauri". It is now tested against the span the name occupies, on the side it hangs, with the radius kept for the pair whose text runs the other way. Also from the review: the ladder in the clearance test was built at exactly the constant it tests, so 1057 of 2000 camera poses would have decided it by float round-trip error — the rungs now sit 0.02 either side of the rule. And two comments that were wrong: a frame one step short of the survey edge does get its callout, and CSS2DRenderer hides a label behind the camera rather than drawing it at the page edge. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi |
||
|
SenrokaiandClaude Opus 5
|
1a53f26474 |
Answer the review: say which search gave up, and let the bisection earn its offer
The panel printed "No route at this range." beside the range it was offering — which is the sentence this branch exists to stop it printing. It was gated on there being no offer, and a search that gives up usually has one: Sol to HD 120147 at 4.5 pc spends the budget, offers 4.83 pc, and says there is no route where a 71-jump route exists. The wording now follows the search at the range that was asked for, and nothing else. That needs the two give-ups kept apart, so `least` travels beside `gaveUp` to the panel: one says the asked range was not searched out, the other that the search for a range that would work was. HIP 69445 at 3 pc — asked-range search exhaustive in 44 ms, ceiling probe out of budget — used to read "Too many stars to search at this range." and now reads "No route at this range.", with nothing claimed after it. Two more from the same review. The budget flag was read off the settled count, so a search that proved a dead end with the last star it was allowed reported a give-up; it now records why the loop stopped. And the bisection's cap could fire before a single probe had narrowed anything, leaving the ceiling route's own longest hop as the answer: star 1000115173 at 3 pc was told to go to 8.00 pc, the control's maximum, for a crossing that works at 6. It now offers 6.93. Measured in the app, all three: "Too many stars to search at this range. 4.90 pc would reach.", "No route at this range." alone, and 7.00 pc in place of 8.00. The duplicated dead-end test now asks the question it was named for — exactly the budget's worth of stars reaching each other and none of them the destination — and each fix kills its own mutant. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi |
||
|
SenrokaiandClaude Opus 5
|
b7f277ea04 |
Answer the review: a short answer makes more survivors, and must not be skipped
Three things this got wrong. The direction: truncating Gaia leaves the HYG rows whose counterpart it dropped without one, so survivors rise — 10 886 today, 12 711 at half the rows, 16 258 at a third — which the comment claimed was the other way, and which decides whether the 15 000 ceiling can be leaned on at all (it catches a truncation past about two thirds, and nothing shallower). The throw: `fetchStars` catches everything a source throws and skips it, so a truncated CSV was reported as "the archive was unreachable" one step after `writeStarAssets` had already overwritten the published catalogue. Marked with `GaiaAnswerError` and rethrown there, so an answer that cannot be worked with fails the run where it happened. Measured end to end in a throwaway working directory, 300 000 rows in the cache: fails, names the cache file to delete, assets untouched. With the rethrow taken back out again: assets written, then "the archive was unreachable". The row limit: `rows.length >= ROW_LIMIT` is true for every reduced ETL_GAIA_ROW_LIMIT, so the tripwire fired on exactly the deliberate slice the override exists for — and told the operator to raise it. Gated on the same flag as its neighbour. `ETL_GAIA_ROW_LIMIT=20000` now runs through; without the gate it dies on the limit it was given. Also: the row floor names the one cache file it is about rather than a glob that takes the Hipparcos cross-match with it, and says an edited query is a third reason it can fire — DEFAULT_QUERY_ROWS now sits under the query it counts. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi |
||
|
SenrokaiandClaude Opus 5
|
7ab92e61a1 |
Give the budget tests room and cells to run in
Both make a search spend its whole 40 000-star budget, twice over in the bisection, and the CI runner timed out at the default five seconds. The crowds are now indexed in cells sized for the ranges asked of them, as the real catalogue is, and the two tests carry their own 30 s timeout. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi |
||
|
SenrokaiandClaude Opus 5
|
365252f534 |
Let the Routes panel be clicked as soon as it is back, and stop it departing from elsewhere
From the review of #24. Two defects, both in a real browser. The panel keeps its entries across a trip to another tab, but still replayed the acquire wipe on the way back, and for the 380 ms that runs, its clip path swallows clicks: type "Siri", leave for Readout, come back and click the Sirius suggestion, and the click lands on the star field behind it — measured, the element under the pointer is the canvas, and the field stays "Siri". The wipe is gone from this one panel: it is not acquiring anything it did not already have. The departure field fell back to the star the view is in whenever nothing had been chosen, text in the field or not. So a field reading "Sol" that was never resolved plotted from Barnard's Star: "1 Barnard's Star, 2 Sol, 3 Sirius", the panel naming one departure and the route leaving from another. Text nobody chose is no longer a departure, and the button waits until it is one or the field is empty again. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi |