feat/catalogue-completeness
100
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
321540ed91 |
Merge the solar-system branch, so the star catalogue lands on the sky it now shares
Both branches changed the system view's star, the body card's provenance line, the exoplanet fetch and the ETL's validators. Resolved by keeping both sides: - The system view's star is the catalogue's (its own radius and temperature, a limb-darkened surface in its colour) and turns like a planet when it is the Sun (the solar branch's IAU pole and 25.38-day turn), keyed on SUN_STAR_ID, since the catalogue branch dropped the scene's own SOL_STAR_ID. Framing takes the outermost thing drawn (an eccentric orbit's aphelion, from the solar branch) and the star's radius for a giant (from the catalogue). The solar branch's comment about a halo is dropped: there has been none since #33. - The card's no-temperature sentence is the catalogue's (the host's luminosity or the orbit's size, not "not in the catalogue", which holds for 27 planets) and ends with the solar branch's reason why no image is used (a point of light for the 101 imaged planets, none for the rest). - fetchExoplanets reads the composite table and the distance errors (catalogue) and the imaged list (solar); build.ts runs both branches' validators. The data were regenerated by the full ETL on the merged code, from cache (nothing refetched): stars.bin, stars-meta.bin, stars-index.json and deepsky.json come out byte for byte the catalogue branch's, bodies.json the solar branch's, and exoplanets.json the catalogue branch's but for the imaged flag on 101 planets, WASP-108 b not among them. Unit suite 977 passed, the two branches' 870 and 837 over their shared 730, so no test was lost. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
cea4ff799f |
Bring the counts the comments and README quote back to the catalogue
Measured on the published catalogue at this commit, through starSurfaceOf and starReadouts: - star-readouts.ts said 11 546 derived radii read "from its type": 10 702 giants with a colour and 844 stars with none. That left out the 26 dwarfs whose colour is off the table, and the colour Gaia now gives 931 HYG-described stars moved the rest: 10 953 = 10 713 giants with a colour, 214 stars with none (GJ 3655 among them) and those 26. 5 more read "from its temperature". - stellar.ts said 821 dwarfs are placed at their type's row. Counted over every star that is not a giant and whose colour the table does not read: 224 with no colour and 36 with one off the table. - The README still said the card marks every derived radius "from colour and brightness"; it now names the three bases the card gives. - build.ts's survivor breakdown, after θ¹ Ori A left: 11 464 HYG stars without a Gaia counterpart, 8 307 of them past 250 pc, 1 660 of those naked-eye. Comments and documentation only. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
0f659af5b3 |
Pin the M giants' corrections from M4 on, a colour off the table, and a phone held sideways
Three rules the suite passed without, each a test only: - |
||
|
|
74913d844d |
Place a naked-eye star by SIMBAD's name only within a magnitude of its source, and hold HD 45951 to it
|
||
|
|
98082a0460 |
Keep Gaia's colour on a star HYG describes without one
combine took the described entry's colour whole, null included. So a HYG row with no B-V, merged
into its Gaia source, lost the BP-RP Gaia measured for it: HD 45951, HD 45291 and HD 124953, three
naked-eye giants Gaia has at BP-RP 1.25, 1.19 and 0.37, showed no colour on their card. HD 45951's
point had its colour at
|
||
|
|
5620776601 |
Describe a folded Gliese star by its own row where SIMBAD puts the HYG star already there elsewhere
|
||
|
|
e7c420b296 |
Fold a Gliese star into its Gaia source in Gaia's photometry, wherever HYG already put it, and place two naked-eye stars by SIMBAD's name for them
The Gliese fold ( |
||
|
|
c8d1bbb879 |
Hold st_lum's conversion to two hosts' luminosities, and mu2 Sco b to its host
|
||
|
|
ef2099177a |
Give M giants their own bolometric correction, which from M4 on is not a dwarf's at their temperature
|
||
|
|
0a88797ff4 |
Keep the dock's tabs in sight around the date strip, on phones and narrow desktop windows
|
||
|
|
6a45c914ac |
Say a derived radius came from the star's type where no colour went into its temperature
The card said every derived radius came "from colour and brightness". Since
|
||
|
|
c0ed91dcf9 |
Pin three rules the suite passed without: the first planet's temperature, the one-step error floor, and G carried to V by type
publishedTemperaturesK keeps each host's first st_teff so the star field tints it as starSurfaceOf
draws its disc; the only test used Proxima, with one planet, and letting the last row win passed
all 828 tests while 189 hosts in the catalogue would be tinted apart from their disc (193 hosts give
their planets differing st_teff, 30 by more than 200 K). The new test gives one host three rows,
none, 4 094 and 3 640 K, and asks both functions for the same 4 094.
The error column's at-least-one-step floor was tested with an error of 1e-6, which at 255 steps
rounded to none but at f31ffe1's 65 535 rounds to 66, so dropping the floor passed. The fixture is
now 1e-12, 0.07 of a step.
|
||
|
|
ee168996f7 |
Test the disc's limb law by working it out, and the phone framing through the scene
The disc test walked the material's node graph and asserted only that the constant 0.6 was in it,
so any law that kept the literal passed: a limb 1.6 times brighter than the centre, a reversed mu,
mu held at 1, all 828 tests green. It now evaluates the factor the photograph is multiplied by off
the graph itself, at a given cosine between normal and line of sight, knowing only +, -, *, clamp,
dot, oneMinus and negate and failing on anything else, and asks for the Sun's linear law: 1 at the
centre, 0.7 at mu 0.5, 0.4 at the limb and 0.4 past the silhouette. The dot must be of normalView
and positionViewDirection.
The phone framing (
|
||
|
|
4951fd8657 |
Test that a body page opens the next body on its Sun's side and turns an exoplanet for show
Two behaviours of the body page had no test. Showing a body resets the remembered side of the equator (sunSide = 0), so the next body opens on its own Sun's side wherever the reader left the camera; the only test that switched bodies went from Saturn's June Sun (south) to Earth's (north), which moves the camera with or without the reset. And the page turns an exoplanet 0.08 radians a second for show, which no test opened. - 'opens the next body shown on its own Sun's side, wherever the reader left the camera: Earth after Saturn in December': Saturn on 2032-12-01, the camera taken north, then Earth, whose December Sun is south too. Guarded mutant, the reset replaced by void 0: this test fails alone, "expected 0.5999999999999999 to be less than 0". - 'turns an exoplanet slowly for show, clock or no clock': the fake loader now carries one exoplanet round the Sun's record; one second with the clock standing turns it 0.08 radians. Guarded mutant, the turn replaced by void deltaSeconds: this test fails alone. The template comment said no one has measured an exoplanet's day. The app ships two whose spin has been: 2M1207 b turns in 10.7 +1.2/-0.6 hours (Zhou et al. 2016, ApJ 818, 176) and beta Pic b's lines are broadened by 25 +/- 3 km/s (Snellen et al. 2014, Nature 509, 63). It now says the catalogue does not carry the day, which is what ExoplanetRecord holds. Unit suite 869 passed. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
d5a5a0fc3a |
Move a body page's camera across the equator only once the Sun is 3 degrees past it
|
||
|
|
69cada7914 |
Fail the ETL when re-rating a locked moon moves its pole or W off the kernel's at the present
lockedToOrbit re-rates a locked moon's W and node terms and moves their constants so that on 2025-01-01, the date the IAU's elements were fitted near, the pole and W are the kernel's own. Nothing checked it: with the constants left where they were, the solar ETL passed and the suite passed, though every re-rated moon moved (Rhea's pole 0.018 degrees, Triton 0.0054, Miranda 0.0037, Europa 0.0027, Callisto 0.0021, Deimos 0.0016, Ganymede 0.0016, measured on the bodies.json it wrote; before the drawn node rates were corrected, Mimas's W moved 0.21 and Miranda's pole 0.12). lockedToOrbit now compares orientationAt at PRESENT_JD before and after, Iapetus's pole round its orbit included, and throws past 1e-6 degrees. Measured on the shipped catalogue: at most 4.7e-10 (Deimos's W, some 2.6 million degrees round), the pole exactly. Guarded mutants, each through the solar ETL on the real catalogue: - node terms' constants not moved: "Deimos's pole or W on 2460676.5 is 1.60e-3 degrees from the IAU's". - W's constant not moved: Deimos, 9.12e-2. - the check disabled with the first: the ETL passes (control). The unit suite does not see it: the check runs on the kernel, which only the ETL reads. The ETL writes the same bodies.json as before. Unit suite 866 passed. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
24c7be1bae |
Draw four moons' nodes at JPL's current rates, which Horizons and the IAU's poles agree with
The archived satellite table the moons are read from gives older node
periods than JPL's current one for Miranda (17.727 years against URA182's
17.787), Ganymede (132.654 against 137.812), Callisto (338.82 against
577.264) and Titan (704.60 against 687.370), and
|
||
|
|
4c1e19d635 |
Give the disc sizes the framing quotes as radii, and the meta columns in the order they are stored
The framing rule works in radii: at 390x844 a giant's disc may take 0.74 - 90/195 = 0.278 of the 195 px half-side, 54 px from the centre, and before |
||
|
|
280159dcd2 |
Bring the figures the comments quote back to what the catalogue now holds
Later commits on this branch ( |
||
|
|
f31ffe1425 |
Store a star's distance error in two bytes, so the card prints the error its catalogue published
|
||
|
|
ac23496b37 |
Give the old Earth W's error at AD 1 as the reviewers measured it, not truncated
|
||
|
|
67a21b4a10 |
Keep the date on screen on a phone after Go, and hand focus back to the tab that folded
|
||
|
|
4d47896b4a |
Find the naked-eye stars Gaia's HIP cross-match lacks by position, and give two unnamed ones back their names
|
||
|
|
7080a5a817 |
Turn Eris, Haumea, Makemake and Nereid on their pages at their measured days on the map's clock
The body page's comment said the body is drawn at the clock's date and turns at its rate, but a
body with no IAU model turned 0.08 radians a second of wall time whatever the clock said: on
Nereid's, Eris's, Haumea's and Makemake's pages the Clock tab's rates and Backwards changed
nothing (Nereid 4.58 degrees a second at every rate), while the system view turns them at their
measured days on the clock. Hyperion spun the same way on its page and is still in the system
view, where it tumbles and has no day.
A body whose day is measured but whose pole is not now turns pole up at that day, counted from its
orbit's epoch as spinFor counts it; Hyperion is left still; only an exoplanet, whose day no one has
measured, still turns for show. The template comment now says so, and the tick doc names all
five bodies. Live on :4301, degrees a wall second at clock rates 1, 3600 and -3600: Nereid 0.009,
31.05, 31.08 (360/11.594 = 31.05); Eris 0, 0.951, 0.955 (360/378.504 = 0.951); Hyperion 0, 0, 0;
Mars, by its IAU elements, 0.004, 14.67, 14.56.
That makes the sphere reset when a body is shown matter for Hyperion and an exoplanet. The test the
earlier fix added for that reset checked only the light, and deleting the reset passed the suite;
a test now opens Hyperion after Earth and expects the sphere at rest (Earth left it 0.89 radians
turned). Eris's page test checks it stands while the clock stands and turns a sixth of a turn in
a sixth of its 378.504-hour day, pole up.
Guarded mutants (full suite), each failing only its named test: the day ignored and Eris turned
for show ('turns a body whose day is measured'); Hyperion turned for show, and the reset deleted
(both 'puts the sphere back at rest ... Hyperion after Earth').
Unit suite 862/862, tsc -p tsconfig.app.json and etl:typecheck clean.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
||
|
|
a9e910c2ea |
Keep a body page's camera on its Sun's side when the clock takes the Sun across the equator, aimed at the body in that frame
The page put its camera on the side of the equator its Sun lights once, when a body was shown.
The Clock tab the same page gained in
|
||
|
|
2f49002027 |
Check that a redrawn orbit line reaches the GPU, and hold Saturn to the chords' own sag
The redraw test read the reshaped line's points on the CPU, which reshapeOrbitLine rewrites
whether or not it then sets needsUpdate. three uploads a buffer again only when its version
rises, which only that setter does, so a renderer that dropped the line left J2000's ellipse on
screen and passed the whole suite (857/857). The test now takes Saturn's position version after
drawing J2000 and expects it higher once the clock is at AD 1.
Its Saturn bounds, 0.002 AU at AD 1 and 0.0015 at J2000, sat inside the 128 chords' own sag, which
reaches 0.0032 AU near aphelion, where points spaced evenly in true anomaly lie furthest apart:
the test passed only because Saturn falls near a vertex on those two dates, and a line correct by
construction failed it (Saturn without its a, e and i rates: 0.00229 AU). Both are now 0.0035,
which still catches the line left unreshaped (0.054 AU at AD 1). The renderer's comment put the
sag at 0.003 for Saturn and 0.0005 for Mars; it now says 0.0032 and 0.00055, and where.
Guarded mutants (full suite):
- position.needsUpdate dropped: only the redraw test fails ("expected 0 to be greater than 0");
- the reshapeOrbitLine call dropped: only the redraw test fails;
- Saturn's a, e and i rates removed from bodies.json, line and marker on one ellipse: the
distance bound now passes (0.00229 < 0.0035); the redraw test still fails, on the version, as
it should with nothing to redraw, and so does Saturn's AD 3000 Horizons test (0.41 degrees).
Unit suite 858/858, tsc -p tsconfig.app.json and etl:typecheck clean.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
||
|
|
030447b83c |
Fold a Gliese star into the Gaia source SIMBAD names it as, so none is drawn twice or inside 10 pc by mistake
HYG's Gliese-only rows, with no Hipparcos astrometry and no published error on their distance, reach the merge with positions off by up to minutes of arc, photometric distances and sometimes wrong proper motions, and isSameStar's geometry missed 49 of them beside their own Gaia entry. 43 lie within 25 pc and 27 are fainter than V 12, the layer the brief asked to merge without duplicates. GJ 3478 is 16.3" from its Gaia entry, past the 15" tolerance; GJ 2097 moves 39 % differently by HYG's motion; GJ 4285 is co-moving but 1.6 magnitudes brighter in HYG's V than Gaia's G. Two of them were false stars inside 10 pc: GJ 2097 at 6.41 pc and GJ 4285 at 6.80, which Gaia measures at 24.47 and 28.25. HYG also put Gl 94 31.6 degrees from where it is, and HD 23585 and HD 23713, Pleiades members at 135 pc, at 20.6 and 22.2. 0e9ab6f's "no Gliese row within 25 pc has a co-moving bare Gaia entry 3-300" away" held only under its own motion rule. fetchStars now asks SIMBAD once, in one cached TAP query, for the Gaia DR3 designation of every object it knows by a GJ number (4 868), maps HYG's `gl` column onto it, and foldByIdentity folds each Gliese-only row into the bare Gaia entry of that source: HYG's name, type and photometry, Gaia's position and distance, as combine does for any other pair. An ETL run from cache folds 49: 455 571 stars become 455 522, the stars within 10 pc 369 become 367, within 25 pc 5 522 become 5 479, HYG rows without a Gaia counterpart 11 517 become 11 468, distances with no published error 395 become 346. exoplanets.json is unchanged. In the running app GJ 2097 reads "24 pc, HYG, Gaia DR3 distance", GJ 4285 28 pc, Gl 94 17 pc, and 367 stars lie within 10 pc. validateMerge now refuses any Gliese-only row beside the bare Gaia entry SIMBAD names as the same star. Controls: folding with an empty identity map fails the ETL with "49 Gliese stars are drawn beside the Gaia source SIMBAD names them as, starting with GJ 1033" (the baseline passed); in the unit suite, folding a row with a Hipparcos error fails "leaves a star with a Hipparcos error, and a Gaia entry already folded into, alone", and keeping the Gliese position fails "folds a Gliese entry into the Gaia entry SIMBAD names it as, at Gaia's position and distance". HYG's V is kept for a folded star, which for GJ 3207 is the wrong one (11.51 where SIMBAD has 13.75). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
74ea1d655e |
Turn a locked moon's pole round with its drawn node, so its axis stays on its orbit at every date the clock reaches
The IAU carries a locked moon's pole round its orbit normal on a term of the node's angle, as a moon in a Cassini state keeps it, but at the node rate the IAU's source had: Miranda's U11 at -2024.22 degrees a century where the JPL table its orbit is drawn from has -2030.80, Mimas's S3 at -36505.5 against -36511.16. Over AD 1-3000 that parted Miranda's drawn axis from its drawn orbit normal by up to 7.89 degrees (AD 9), so Uranus swung 7.6 degrees north and south on its sky every 1.41 days, and Mimas's by 2.63. Only Iapetus's pole had been put on its orbit. lockedToOrbit now sets every periodic term whose angle turns within 5 per cent of k times the drawn node rate (k from 1 to 9, the most the report takes, Triton's) to exactly that multiple, and moves its constant so the angle, and the pole and W with it, are unchanged on 2025-01-01 (the 2025 pole and W of every changed moon are identical to the 1e-14 degree). Measured: the largest offset taken is Ganymede's J5, 3.4e-2, then Rhea's 1.2e-2; the nearest term that is not a node is 6.0e-2 out (a W-only term of Miranda's), and Umbriel's W has one 1.0e-2 from ten times its node, which the k limit leaves. Ten moons change: Deimos, Io, Europa, Ganymede, Mimas, Tethys, Rhea, Miranda, Triton and Proteus. The Moon and Phobos, whose W carries a quadratic, are left as before, and so is Callisto's J6, 40 per cent from its node rate. Worst angle between the spin axis and the drawn orbit normal over AD 1-3000, every 135 days, before and after: Miranda 7.89 -> 0.42, Mimas 2.63 -> 0.47, Rhea 0.77 -> 0.17, Triton 0.51 -> 0.15, Europa 0.33 -> 0.13, Ganymede 0.50 -> 0.16. Faces: Miranda 2.75 -> 2.39, Mimas 8.94 -> 8.89, Deimos 2.14 -> 2.08, Triton 2.88 -> 2.81; none got worse. build.ts now checks that angle for every locked moon over the same 8114 dates as the face check, at most 1 degree (Tethys 0.97, whose IAU pole sits 0.69 from its orbit today; Titan 0.94, whose IAU pole is still while its node turns in 705 years), with four named ceilings: the Moon 7.1 (its real 6.7-degree tilt, 6.98 at worst), Phobos 2 and Deimos 2 (1.81 and 1.74) and Proteus 1.2 (1.09), whose IAU poles nod with Mars's and Neptune's precessing poles while the Laplace poles their orbits are drawn round are fixed. The obliquity check at Horizons' epoch shares the new axisFromOrbitDeg with it. Nothing checked the axis against the orbit before: an Iapetus pole left on its Laplace pole, 8.30 degrees off at every date, passed the ETL and the suite. Guarded mutants, each through the solar ETL and then the suite on the data it wrote: - node terms left at the IAU rates: the ETL fails with "Moon mimas's spin axis leans up to 2.63 degrees ... (at most 1 expected)", and the suite with only the new test failing; - Iapetus's pole put on its Laplace pole, W re-phased so its face today is unchanged (worst face 16.41, under its 16.5 ceiling): the ETL fails with "Moon iapetus's spin axis leans up to 8.30 degrees", and the suite with only the new test failing. Also: lockedToOrbit called the Iapetus normal's circle "8.3 degrees across"; 8.3 is its radius (the row's i = 8.298 to the Laplace plane) and it is 16.6 across. The README credited every rotation to pck00011 without saying that a locked moon's W and node terms are re-rated to its JPL mean elements and Iapetus's pole carried round its orbit normal; both of its lines now say so, as the body model's doc does. Unit suite 858/858, etl:typecheck and tsc -p tsconfig.app.json clean, solar ETL passes on the real data. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
8d59c720b3 |
Hold the published catalogue to its naked-eye stars, its host luminosities and five other things no check saw
Seven properties of the catalogue could be lost by a one-line slip in the ETL with every validator passing and the weekly job publishing the result. validateStars and validateExoplanets now refuse: - fewer than 8 800 stars of V 6.5 or brighter (8 886 measured), or Rigel, Deneb or Alnilam gone; with no magnitude handed to placementDistancePc, 7 378 are left; - a host luminosity that is not positive, or fewer than 90 % of planets carrying one (6 036 of 6 354): st_lum is published as log10(L/L_sun), and stored unconverted 3 307 read <= 0 and Proxima's -2.82; - fewer than 40 colours marked as read off a temperature (54 measured); - an archive-placed star more than 1 mas from its planets' published position carried from J2015.5 to J2000 (6.6e-8 mas at most measured; not carried, 6 277.9); - fewer than 300 HYG stars folded into Gaia keeping their more precise Hipparcos distance (384), or Tarazed and Eta Leo off theirs; - more than 5 archive stars numbered other than their name hashes to (1 measured). These come from an interrupted earlier attempt left uncommitted in this worktree; its other half, asymmetric archive distance errors that nothing in the ETL wrote, and a placementDistancePc test that failed, was discarded (saved in the scratchpad as uncommitted-at-start.patch). The naked-eye check is new, and runs before the Hipparcos one, which the same slip also trips. Controls, each an ETL run from cache in a throwaway worktree that reached "Validating output..." and failed with the named check's own message: no magnitude to placementDistancePc (naked-eye floor); `10 ** logLuminosity` -> `logLuminosity`; colorFromTemperature never set; the archive epoch offset times 0; combine never taking the other entry's distance; archive ids in arrival order. The unmutated baseline passed. star.model.ts's count of flagged hosts, 57, is now 54. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
5fb0d45623 |
Place an archive host by its parallax where the archive gives no distance, so mu2 Sco b has its star
The archive leaves sy_dist blank for mu2 Sco and publishes sy_plx 6.31 +- 0.86 mas. The matcher only reads the parallax as a second chance beside a finite sy_dist, and the archive-star fallback needs sy_dist too, so mu2 Sco b had no host while Pipirima (HIP 82545, V 3.56, B2 IV) sat on the map 0.4" from the archive's direction at 145.3 pc. The build.ts comment and the step report said the 27 hostless planets had "no distance in either archive table"; mu2 Sco was the one whose row has a parallax. archiveDistancePc takes sy_dist, or 1000 / sy_plx where it is blank (158.5 pc here, within the ratio test of Pipirima's 145.3). An ETL run from cache changes exoplanets.json alone: mu2 Sco b now has host 82294, Pipirima, and 6 328 of 6 354 planets have a host (26 without, none of whose rows has a distance or a parallax). hostDistancePc stays the archive's own blank. Control: ignoring the parallax fails "takes the archive's parallax where it gives no distance, and nothing from a parallax that is none" alone. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
734b048c9e |
Write the star assets once, after the archive's hosts are added, not before them as well
Since |
||
|
|
a15a46c617 |
Correct what the ETL, the code and the textures README said of their own sources and figures
- The IAU day check said it compared W with the period Horizons states. That holds for the eight
planets and Phoebe only. Pluto's and Ceres's periods are the IAU's own rate restated (8.5e-12 and
3.3e-10: Horizons' Pluto period is 360 over its W, and the SBDB notes it derived Ceres's from the
report's 952.1532 degrees a day), and the 22 locked moons' is their orbit's, from JPL's table, not
from their Horizons pages ("Synchronous" on eighteen, nothing on Titan's or Proteus's), and now
their W's own rate. The comment, the log line and the error message say which is which; the log
shows 0.0e+0 for the twenty locked moons turned at their orbit's rate, 1.1e-8 and 3.1e-7 for the
Moon and Phobos. BodyRecord.rotationPeriodHours says that where a source states no period, or
one a later measurement overturns, it is the one the ETL spec carries (Nereid's, Eris's), where
the previous commit had Eris among the bodies whose source states none.
- Phoebe's spec justified its period by a note in the satellite table, which is about another
source (Jacobson 2000, Jupiter's outer moons) and says the table carries corrected values. The
row's n is right as the table defines it, the rate of the mean longitude: n less twice the node's
rate is 0.6541855 degrees a day, against 360 / 550.30391 = 0.6541840. What made Phoebe drift is
that the propagator reads a retrograde moon's n as its sidereal rate, as Triton's row gives it.
The comment now says so; the period, 550.30391 days, is kept.
- body-orientation.ts and its spec said the IAU's W for Earth, "taken at UT", left its face 2.3 and
4.5 degrees off Horizons at AD 1000 and AD 1. The old code took it at UT + 69.184 s; those are
that figure's, and at UT itself they are 2.0 and 4.2, as three reviewers measured through the
code (4.25, 4.25 and 4.28 at AD 1).
- The renderer said the 28 maps entering the Sun's system are about 20 megapixels of JPEG. Read
from their frame headers: 37.75, nine at 2048 by 1024 with the Sun's, Jupiter's at 3840 by 1920
and eighteen smaller.
- The textures README gave Titan 0.02 per cent unmapped, counting only the source's zeros. Its
largest gap is a flat grey of the source's own (147 and 148, its two commonest values), which
NASA's caption for PIA19658 names as the gap in coverage: measured on titan.jpg, one region of
1.09 per cent of the pixels, 0.87 of the sphere, at 48-68 N and 37 W to 25 E. The row says 1.1 per
cent and where, and step 1 says how it is counted; commit 302fa96's "the rest under 0.2%" is
therefore not true of Titan.
No behaviour changes but the ETL's log and error wording; the solar ETL passes with the new text.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
||
|
|
073fb9f718 |
Ring only the planet hosts inside the survey edge, so the Kepler field is not a band over the view
|
||
|
|
dadae7b8ca |
Give Haumea's card its three semi-axes beside its mean radius
Haumea is triaxial, 1161 x 852 x 513 km (Ortiz et al. 2017, Nature 550, 219), and is drawn as the
sphere of its volume, 797.6 km. Its card listed "Radius 798 km" under Measured and said nothing of
its shape, which only a code comment and a commit message gave: its long semi-axis is 1.46 times
that radius and its short one 0.64.
BodyRecord takes semiAxesKm, set by the ETL from Haumea's spec, and the card then reads "Mean
radius 798 km" and "Semi-axes 1,161 x 852 x 513 km". Every other body keeps its one Radius row. The
ETL checks that a body's radius is the mean of its semi-axes, the radius of the sphere of the same
volume, to 0.1 per cent (797.6 against 797.62).
Measured on :4301, Haumea's page: "Mean radius 798 km, Semi-axes 1,161 x 852 x 513 km". Test: the
card of Haumea as shipped in bodies.json. Guarded mutants: the semi-axes dropped from the spec (run
through the solar ETL), the row, or the view model, or the label left as Radius, each fail it and
only it; a radius that is not their mean fails the ETL ("Haumea's radius, 1161 km, is not the mean
of its semi-axes").
Horizons gives triaxial radii for Phobos, Deimos, Miranda and Ariel too, which the page parser
already reads into their mean; they are not carried here.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
||
|
|
e62e2fb03f |
Keep a giant's disc clear of its neighbours' names on a phone, not only on a desktop
|
||
|
|
4e7d4cd1d6 |
Say a type estimated from a colour read off the archive's temperature came from the temperature
|
||
|
|
2dac3767e8 |
List a host's own planets ahead of the systems whose names only run on from its own
Once the archive's 3 277 hosts became stars and 574 Gaia hosts took their names, "K2-18" listed the star K2-18 and then K2-180 to K2-186, and no planet: "k2-18 b" and "k2-180" were both prefix matches, and on a tie the ranking put every star before every exoplanet. Replaying each host's name through the ranking over the published catalogue, 325 hosts had some of their own planets pushed out of the eight rows shown (655 planet rows), against 75 before the archive stars. A prefix match that ends where a word does now scores 3.5, between an exact match and a prefix running on into the same word. The same replay gives 50 hosts and 62 rows. In the running app "K2-18" lists K2-18, K2-18 b, K2-18 c, then K2-180 onward; "Kepler-186" lists the star and Kepler-186 b to f before Kepler-1860; Kepler-22 b and WASP-12 b are back. "Proxima", "Io" and "TRAPPIST-1" list as before. Control: scoring the word-ending prefix level with any prefix fails "lists a host's own planets ahead of the systems whose names run on from its own" alone. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
fc7677e715 |
Turn Nereid in the 11.594 hours Kepler measured, where it was drawn still
Nereid's Horizons page states no spin, and the ETL, finding none, left it still; the validator's
comment read that as "Nereid has no spin". Its rotation is measured: Kepler's K2 light curve gives
11.594 +/- 0.017 hours, confirming earlier ground-based periods (Kiss et al. 2016, MNRAS 457, 2908;
arXiv:1601.02395). Its spec now carries that day, as Eris's carries Bernstein et al.'s, and with no
known pole it turns about its orbit normal, as Eris, Haumea and Makemake do. The free-spinner check
accepts it (11.594 hours against a 360-day orbit).
A new validator: a moon without a lock must have a day unless it tumbles, and only Hyperion
("Rotational period = Chaotic") does. Nereid, left without one, fails it: "Moon nereid is drawn not
turning, and is not known to tumble". The renderer spec's example of a body left still was Titan,
said to have no period on Horizons, though it carries its orbit's; it is Hyperion now, and
BodyRecord.rotationPeriodHours says where each kind of period comes from.
Measured: the solar ETL passes; in bodies.json only Hyperion has no rotationPeriodHours; live on
:4301 Nereid's marker turns 60.000 degrees in a sixth of its day. Test: Nereid, as shipped, turns 60
degrees in 1.93 hours. Guarded mutant, the day removed from its spec and run through the solar
ETL: the validator fails, and the suite on the data it wrote fails that test and only it.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
||
|
|
e8e857ec25 |
Hold Io and Europa to their own track ceilings, and Hyperion's one-date ceiling to just above its offset
Io's and Europa's periapses turn backwards, held by the Laplace resonance (apsidesRegress), which brings them to 0.07 and 0.23 degrees of Horizons from 1950 to 2100. Nothing guarded the flag: with it dropped the ETL still passed, Io at 0.96 and Europa at 2.24 under the general 3-degree track ceiling, their cards quietly rewriting themselves to "within 1.0" and "within 2.3". They now have ceilings of 0.2 and 0.5, as Tethys has for the term it takes from its W. The comment on the one-date check, which said it catches the periapsis run the wrong way, now says it does not (0.904 against 2.5) and which check does. Hyperion's one-date ceiling was 21 degrees, described as just above its offset on that date, where it is 9.413: the 21 was its worst over twelve dates in an earlier check. It is now 10. Measured on the real catalogue with the solar ETL: Io 0.07, Europa 0.23 at worst, Hyperion 9.413, all passing. Guarded mutants, run through the solar ETL: apsidesRegress removed from both specs fails with "Io's mean elements put it up to 0.96 degrees ... (at most 0.2 expected)"; Hyperion's row misread by 6 degrees of node fails the one-date check at 15.41, which 21 let through. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
3b4fd1af6c |
Turn each locked moon at its orbit's rate and Iapetus's pole round its orbit, so they face their planets at every date the clock reaches
The IAU gives a locked moon's W the mean motion of whichever orbit its authors had, and JPL's table has another. Near the present the difference is nothing; over the clock's AD 1 to 3000 it turned Proteus's far side to Neptune at AD 1 (146 degrees), Mimas 52 degrees from Saturn and Miranda 23. Iapetus was worse for another reason: its IAU pole is a straight line, 3.9 degrees a century in right ascension, through its orbit normal's 3 439-year circle round the Laplace pole, which by AD 1 has run past the celestial pole (Dec 97.9), 11 degrees off the orbit, with the face 87 degrees from Saturn. Mimas and Iapetus carry mission maps, so a wrong hemisphere was drawn facing Saturn. The ETL's lock check sampled only 1950-2100, so none of it failed. tools/etl/lib/locked-spin.ts, lockedToOrbit, called for every locked moon: - W's rate becomes the orbit's own mean motion, its constant moved so W is unchanged on 2025-01-01; the pole and every periodic term stay the IAU's. A W with a quadratic is left (Phobos's orbit already takes it; the Moon's is its tidal slowing, 0.75 degrees at AD 1). The kernel's rate must be within 1e-5 of the orbit's first (at most 3.4e-6, Iapetus). - Iapetus (poleFollowsOrbit): the pole follows its orbit normal, as a moon in a Cassini state does, in the IAU's own form: sines of the node's angle and four harmonics on right ascension, cosines on declination, fitted to the normal's circle and pinned to the IAU pole at the present; W takes sines of the same angles, fitted to hold the face where it is today. build.ts samples the lock over AD 1 to 3000 (8 114 dates, every 135 days) instead of 1950-2100, and subPlanetLongitudeDeg moved to the lib, shared by both. Measured on the real catalogue: at most 5.36 degrees (Titan) but the Moon 7.62 (its eccentricity, and W's quadratic at AD 1: a new named ceiling of 8), Mimas 8.94 (ceiling 11 -> 9.5) and Iapetus 15.95 (19 -> 16.5, 9.4 of it its row's lag); Proteus's own ceiling of 9 is gone, at 2.66. Iapetus's axis stays within 0.74 degrees of its orbit normal (11.06 before) and its pole is the IAU's at the present to 1e-4 degrees. Live on :4301, the longitude facing the planet at AD 1 / 1000 / 2025 / 2999: Proteus 2.6 / 2.6 / 2.6 / 2.6 (was -146.5 / -72.9 / 2.6 / 74.5), Iapetus -15.9 / -15.4 / -15.3 / -9.3 (-87.0 / -50.9 / -15.3 / 22.8), Mimas 4.1 / 6.8 / 5.7 / 8.4 (48.6 / 29.3 / 5.7 / -13.0), Miranda -0.1 / 2.2 / 0.0 / 1.4 (-23.4 / -9.6 / 0.0 / 12.6); the present is unchanged. The renderer spec now takes the rotational elements from bodies.json too, so no hand copy is left, and a new test turns Proteus, Miranda, Mimas and Iapetus to their planets at AD 1 and AD 3000. Guarded mutants, each run through the solar ETL and then the full suite on what it wrote: lockedToOrbit bypassed (validator: Mimas 52.30, ceiling 9.5; the new test fails), Iapetus on the IAU's straight pole (98.48), and its pole round the orbit without W's terms (73.13); each fails the new test and only it. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
f8582b78d0 |
Test the star's disc itself: its photograph, its colour and its darkening toward the limb
|
||
|
|
368fcfb6f0 |
Keep each spectral type's giant surface once, rather than reparse it for every star at boot
The star field reads every star's temperature at boot, and each read asked giantSurface, which
splits the type and runs two regular expressions whether or not the star is a giant: 455 571
times for 2 888 distinct type strings. It depends on the type alone, so it is now kept per type.
The tint pass over the published catalogue gives the same colours (checksum 5 830 745.929 before
and after) and in Node takes 167-237 ms against 241-305. In the running app, the star field
rebuilt in the page three times after each of four cold boots: median 65 ms before (60-79), 51
and 53 ms after in two runs (46-67). The longest task after the data lands did not move beyond
the noise (median 851 ms before, 859 and 827 after): most of the boot growth since
|
||
|
|
17cf11b6b1 |
Tint a planet host in the star field at the archive's temperature, which its disc is drawn at
|
||
|
|
09eaf9532f |
Keep the Display panel shorter on a phone, and fold it away once a date is set
The date form made the Display panel 400 px tall at 360x640 (from 257) and 363 at 390x844 (from 220), and the Sun's system sat behind it: every orbit at 360x640, 81 per cent of their points at 390x844. A reader who set a date could not see what it did without closing the panel. The window's description is one line, "AD 1 to AD 3000, where the planets' elements hold." (the sentence on how far each moon's orbit strays is on each card and in the system note), and below sm the field shrinks so Go stays on its line. Measured on :4301 with the panel open: 318 px at 360x640, Go at y 501 beside the field at 500; 318 px at 390x844, where 9 per cent of the orbits' points are behind it and 37 of the 39 lines show. At 360x640 the system is framed behind even the old 257 px sheet, so a date submitted with Go on a narrow viewport now folds the sheet, as choosing a search result already does. Measured: after Go at both sizes the panel is gone and the strip reads "Date 2020-12-21". Wide screens keep it open. Tests: the sheet folds after Go on a narrow viewport, and stays open on a wide one; jsdom has no matchMedia, so the spec gives the dock one it can turn narrow. Guarded mutants: no fold fails the first, a fold on every screen the second (and "jumps the clock to the date submitted", which then cannot find Back to now). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
74535accc5 |
Show the date and the clock on a body's page, and open it on the side of the equator its Sun lights
Since the page turns a body as it stands at the map's date, it has been drawn for a date it never showed, at a rate it gave no way to change: set to 2032 at a day a second in the system view, Saturn's page ran on at that rate with only Search and Bookmarks on its dock, and at a month a second Earth turned about 183 degrees a frame at 60 Hz. The dock now takes `clock`, which offers the clock without the layers, as a tab named Clock, and the page binds it with the date strip the system view already has. Measured on :4301 at 2032-06-01: the strip reads "Date 2032-06-01", the tabs are Search, Bookmarks and Clock, and the Clock panel has the four rates and the date field; Back to now clears the strip. The camera opened 11.3 degrees north of the equator whatever the season, which since 2025 put Saturn's page on the unlit face of its rings, and will until 2039. When a body is shown, the next frame puts the camera on the side of the equator the Sun is on: measured on Saturn's page, the Sun at -26.71 degrees on 2032-06-01 and the camera at -11.31; Earth's in June stays north. Tests, each proved by a guarded mutant that fails it: - the page follows the clock after its first frame (frozen at the first frame: 90 degrees out); - a body with no IAU model shown after Earth gets the page's own light back (left at Earth's Sun); - the page's dock shows the date and a Clock tab, and no date at the present (date never set, or the dock bound without the clock); - the dock offers the clock alone as a Clock tab (no tab, or a tab still named Display); - Saturn's page in 2032 opens with the camera and the Sun both south (camera held north). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
aafc788352 |
Hold van Belle's giant temperatures at 3 134 K from M6, as its table does, and test every piece
giantSurface carried the 64-71.5 fit of van Belle et al. (2021, ApJ 922, 163, table 8) on to index 73.9, where the table's fourth piece, 72-74, is flat at 3 134 K: M6 III (index 72) came out 3 300 K and M7 III 3 214 K. The paper's own M6 and M7 giants average 3 112 and 3 114 K. The temperature and the correction at it both feed the drawn radius, so the 29 catalogue giants from M6 to M7.9 were drawn too small: Rho-2 Ari 57.1 solar radii, now 81.5; 30 Her 88.3, now 126.0; Eps Oct 64.9, now 92.6. The comment said the scale was held "past M7.75"; it now says from M6. The giant test only reached the third piece (Aldebaran K5 III, Antares M1). It now checks each piece against table 8: G8 III 4 797.08 K, K2 III 4 387.58, M5.5 III 3 343.43, and M6 and M7 III at 3 134. Controls, each failing "reads a giant's temperature and correction both off its type" alone: the third piece carried past M6 again; a G giant indexed as K; the first piece's slope 52.74 -> 45; the second's 199.41 -> 180. Before this, the last three left all 817 tests passing. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
206e88ae85 |
Read a dwarf with a type and no colour at its type's row of the dwarf sequence
A non-giant with a spectral type but no colour took its temperature off the textbook colour spectralTypeToColorIndex gives its type, read on Pecaut & Mamajek's table, and its bolometric correction off the old textbook anchors. The table puts those colours elsewhere: M8's B-V 1.88 is M5-M5.5 there, 3 001 K where M8 V is 2 570, and the anchors give M8 -3.92 where the table has -5.65. GJ 3655 (M8, 14.35 pc) was drawn at 0.035 solar radii, a third of Jupiter, where its type's row gives 0.106 (Mamajek's M8 V: 0.114). Every O type came out B0's 31 400 K. Both now read dwarfSequenceAtType, which already existed for the giants, and a G magnitude is carried to V at the type's G-V too. On the published catalogue, of the 835 non-giant stars with a band, a type and no colour, those more than 200 K off their type's row go from 21 to 0, those with a radius more than 1.5 times off it from 7 to 1 and a luminosity from 10 to 1 (the one left, Oph 11, is a G-band star). GJ 3849 (dM9) goes from 0.030 to 0.089 solar radii, GJ 3855 (M6.5) from 0.040 to 0.087. Two tests pinned the textbook path and now read the table: M5Ve with no colour is 3 060 K, not 3 106, and K5 tints as B-V 1.15, its row, not 1.105. An O8 star is 35 100 K, its row, not B0's. Controls: reading the temperature through the textbook colour again fails "is drawn at its type's row of the dwarf sequence" (with the three updated tests); reading the correction off the anchors again fails that test alone. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
28fa79e1e0 |
Check the Horizons vectors against the bodies.json the app ships, and every rate Standish's rows give
The frozen Horizons tests ran on a hand copy of seventeen records, so an ETL that lost Standish's a, e and i rates, or Io's and Europa's backward periapses, wrote a bodies.json that passed both its own validators and the whole unit suite: the data-refresh job's "Unit tests against the new data" read none of it. record() now takes kind, orbit, rates, laplacePole, parentBodyId and massRatio from src/assets/data/bodies.json, read with node:fs as texture-catalog.spec.ts reads its JPEG, and the copy is gone. Today's data passes as the copy did (all seventeen were identical). The parser test checked only the mean motion and the periapsis rate on Earth's row. It now checks the node, a, e and i rates too, against Standish's Table 2a (-0.24123856, -0.00000003, -0.00003661, -0.01337178 a century). Dropped, those rates move Saturn 0.66 degrees at AD 1 (node) and 0.36 at AD 3000 (a, e, i), where no date from 1950 to 2100 shows more than 0.036. Guarded mutants, each run on the full suite: - bodies.json without the a, e and i rates, as that ETL writes it: 'puts saturn within 0.1 degrees of Horizons on JD 2816787.5' and Earth's fail (and the new orbit-line test, on the same data). - bodies.json with Io's and Europa's periapsis rates turned positive: Io's and Europa's 1950 tests fail. - the parser without its a, e and i rates, and with a node rate of 0: 'gives the rates per day' fails, and only it. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
3e1bd33b6c |
Draw every body in a system on one shared sphere, so returning to the Sun's system is no long task
Each marker built its own 64 by 32 SphereGeometry, and the Sun's system now has 38 of them: the
renderer's constructor took 15 ms, 12 of them building spheres, and with their first upload a
return to the system made a long task of 52 to 70 ms that the base's 18 bodies never did.
Every marker is now the one unit sphere, scaled to its radius, which it keeps in
userData.radiusAu. The shared sphere is never disposed; Saturn's ring is built in the sphere's
own units, since it is the marker's child; keepMarkersLegible reads the stored radius and scales
against the sphere's.
Measured on :4301, eight returns to the Sun's system each (select null, then 0, at 1600x1000):
before, a long task on 3 of 8 (52-57 ms), swapToSystemSpace 13-17 ms and the first render 30-40;
after, no long task on 8 of 8, the swap 2.7-4.4 ms and the first render 20-38. Earth is drawn at
the same 0.656 AU at arrival, and every member shares one geometry.
Tests: one sphere for every marker, each at bodyMarkerRadiusAu of its radius, and not disposed
with its system; Earth held to its 3-pixel floor at the arrival framing, which no test covered.
Guarded mutants, each failing only its named test: a sphere per marker, the shared sphere
disposed, the ring built in AU inside the scaled marker ('picks Saturn through its rings'), and
the legibility scale divided by the body's radius.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
||
|
|
c2683da37b |
Redraw a planet's orbit line as its axis and eccentricity drift, so Saturn stays on it at AD 1
The orbit lines kept the shape of the J2000 elements and only turned with the node, while the markers moved on Standish's drifting a and e. Saturn's eccentricity falls 0.00032 a century, so at AD 1 its line passed 0.056 AU (8.4 million km) from Saturn, Jupiter's 0.016 AU from Jupiter, and Pluto's 0.021 AU from Pluto at AD 3000. The comment that said no drawn line shows the drift weighed one century of Pluto's axis, not twenty of Saturn's eccentricity. update() now writes the line's 129 points again once |da| + a |de| since they were drawn passes 1e-4 AU, well under the 128 chords' own sag. Measured in the app on :4301, marker to its own polyline: Saturn 0.0016 AU at AD 1 and 0.0028 at AD 2999, Jupiter 0.0014 at AD 1, Pluto 0.0078 at AD 2999 and 0.0082 today, all the chord sag. The existing Mars test checked only that Mars stays in its line's plane. A new test measures the distance to the drawn chords: Saturn 0.0017 AU and Mars 0.0005 at AD 1 (0.054 and 0.0022 without the redraw). Guarded mutants: the call removed, and the threshold raised to 1 AU, each fail it and only it. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
89c2568018 |
Describe the star at a system's centre as it is drawn now, not by the innermost-orbit rule and its halo
The README still said the star was sized against its innermost orbit and made visible by a halo, two things |
||
|
|
a70a7290f3 |
Test that the host matcher carries an archive row back from J2015.5, where the constant only was
|
||
|
|
69a052730f |
Test that the system view warms a host's planets by the luminosity the archive gives it
|
||
|
|
15b8f2dff3 |
Say which stars sit at the Gliese catalogue's distances, about half of them no parallax at all
|
||
|
|
5ab4c5df89 |
Say a planet has no temperature because its star's luminosity or its orbit is unknown, not its star
The card and the body page said "Its host star is not in the catalogue" for every planet without
an equilibrium temperature. Over the shipped data that is 2 714 planets, and the host really is
missing for 27. 2 420 have no semi-major axis, and since
|
||
|
|
8f99335bae |
Give a luminosity below a hundredth of the Sun's two figures, so Proxima reads 0.0015 L☉ not 0.002
formatLuminosity printed three decimals from a thousandth to 1 L☉, which leaves one figure below
a hundredth.
|
||
|
|
95ffb009a2 |
Tint each star in the field the colour its own disc is drawn in, a blackbody at its temperature
|
||
|
|
a8f394cf57 |
Read a giant's temperature off its type as well as its correction, so a radius has one source
|
||
|
|
06b4ff64b5 |
Read a white dwarf past the table's blue end at the temperature white dwarfs of its colour have
|
||
|
|
18faa6d0b2 |
Classify a star for the rows that list it, not every star each time the index is built
The search index and the route index gave every one of the 455 571 stars a subtitle up front through spectralClassification, which filtered the dwarf table afresh on each call; the star field's tints read the same table once per BP−RP star. Both indices now carry the star itself and classify it only for the rows shown (entrySubtitle): eight search results, a few route options. The two filtered columns of the table are built once. Node, over the shipped catalogue, five runs: classifying every star 121-167 ms before, 56-62 after hoisting the table alone; reading the sequence at every BP−RP colour 187-216 ms, now 111-127. In the app on :4302, two cold loads each, the long task when the Search tab opens was 264-380 ms (median 280) before and 164-276 ms (median 171) after; the longest boot task 863 and 875 ms before, 654 and 741 after. Tests: the search spec checks its index holds no classification and the row still reads "Star · ~M8"; the scene spec now reads the route options, and checks its index holds none either. Controls: classifying every star in the search index, doing so in the route index, and route options printing the index's subtitle each fail the named test. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
d449214309 |
Stop calling WASP-108 b imaged, and stop saying no map exists of an imaged exoplanet
|
||
|
|
936d1c01f8 |
Leave a system outwards from wherever the camera stands, and test that the scene frames the furthest it draws
Leaving a system flew the camera to a fixed 400 AU. Since
|
||
|
|
f6bb2b9584 |
Pin the 1972 hand-over to the leap seconds from the later side too
The test named for the hand-over caught the switch moved earlier and passed with it moved up to six months later: both samples round midnight then fall on the polynomial (a step of about 0), the last day of 1971 still reads 42.2485 s, and the 1972-06-30 = 42.184 check only sees a move past June. Such a switch leaves TT - UT up to 0.59 s high through the first half of 1972. The test now also requires 1 January 1972 itself to read the table's 42.184 s, the 10 s TAI - UTC began with plus 32.184. Control: the switch moved to JD_1972 + 120 now fails "hands over from the polynomial to the leap seconds at the start of 1972" only (1 failed, 843 passed of 844); before, the suite passed 841 of 841. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
83dc46416b |
Test an exoplanet's aphelion in the framing radius and a derived surface's white, and give Earth's old TDB error as 8.6 degrees
Two lines the review found unguarded, each now held by a test that fails without it:
- outermostRadiusAu takes an exoplanet's eccentricity as well as a solar-system body's.
|
||
|
|
acc4b928f2 |
Say that Makemake's day is known only to a factor of two, citing both readings
|
||
|
|
4cd08ee324 |
Credit the IAU W on the three moons whose orbits take terms from it, guard Tethys's, and say what Mimas's lock ceiling is
Since
|
||
|
|
48fd6fd0e5 |
Stop telling the reader that the hundred directly imaged exoplanets were never imaged
Every exoplanet card without a map ended "Not an observation — no image of this world exists.",
and
|
||
|
|
ff744a00de |
Place a naked-eye star HYG gives no distance for by its Hipparcos parallax, where that is 2.5 times its error
|
||
|
|
8c3a86097c |
Place a star at whichever of its two distances is the more precise, not at Gaia's regardless
placementDistancePc took Gaia's distance wherever the cross-match gave a usable one, and its
docstring and
|
||
|
|
23547defe0 |
Read an archive host's colour off the dwarf sequence at its temperature, and say it was not measured
For an archive-placed host with a temperature and no B magnitude, fetchExoplanets took B−V from Ballesteros' blackbody fit, which runs 0.1 to 0.2 redder than Pecaut & Mamajek's dwarf sequence below 3 800 K, and the luminosity then read its correction off that sequence at that colour: 3 500 K came back as 3 102 K with a correction 1.15 magnitudes too large, anything under about 3 170 K was clamped to B−V 2.00, and the card printed it as a measured "Colour B−V 2.00". CFBDSIR J145829+101343, a 580 K brown dwarf, read "Spectral type ~M6, from colour". temperatureToColorIndex now reads the table itself backwards, interpolating B−V between the two types the temperature falls between, so the temperature and correction read back off the colour are the table's at that temperature; it has no answer outside 2 420 to 31 400 K. The colour is flagged colorFromTemperature, a fifth bit in the photometry byte (the format, README and the ETL's round-trip check follow), and the card prints it "B−V 1.66, from its temperature", marked derived. From cache: 57 archive stars change colour; 54 carry the flag and 3, CFBDSIR J145829+101343 among them, now have none. For the 47 of them the archive gives a luminosity, the one derived from magnitude and colour moves from a median 0.228 dex off it to 0.124; Kepler-445 (3 157 K) from 0.0282 L☉ to 0.0080 against the archive's 0.0079. Its colour goes from 2.00 to 1.67. The card shows the archive's luminosity where it has one since earlier on this branch, so this is the figure used for the rest and for their radii. Controls, each failing its named test: the nearest hotter row taken without interpolating (2 of 803 failed), no refusal outside the table, the flag not encoded, and the card calling the colour measured (1 of 803 each). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
c45d9160e3 |
Frame the Sun's system on Eris's aphelion, the furthest it draws, not on the grid ring inside it
The scene framed the grid's outer ring, sized from the largest semi-major axis, and two comments said the ring was "always the wider of the two, by construction". That held until Eris came in: its a = 67.93 AU gives an 80 AU ring, but with e = 0.438 its orbit reaches 97.7 AU, and Eris is 95.5 AU out now. The 12 per cent margin protected the ring, not Eris. The review measured Eris's orbit at 0.982 of the half-width on a 390x844 phone (3.5 px from the edge), 0.987 on 1000x1400, and on a 1000x1000 window Eris's marker at NDC 1.002, off screen on arrival. SystemOrbitsRenderer.gridOuterRadiusAu becomes outermostRadiusAu: the ring, or the largest top-level aphelion a(1 + e) where that runs past it. The scene frames that. Some orbit runs past its ring in 303 of the 1 190 exoplanet systems too (counted on exoplanets.json), and they are framed the same way. The 500 AU ceiling rises to 600: the aphelion needs 508 AU on a 390x844 phone, and 600 holds it with its whole margin down to an aspect of 0.39. The comments are corrected. Measured in the app on :4301 after entering the Sun, Eris's drawn orbit, largest |NDC x| over its 129 vertices (review's figures before): 390x844 camera 507.9 AU 0.804 (0.982) 1000x1400 camera 328.5 AU 0.805 (0.987) 1000x1000 camera 234.7 AU 0.812 (1.004, marker off screen) 950x1000 camera 247.0 AU 0.810 1600x1000 camera 234.7 AU 0.508 (0.627) No orbit vertex of Neptune, Pluto, Eris, Haumea or Makemake is off screen at any of them. The cost: inner bodies arrive smaller, the landscape camera 235 AU out instead of 192. Tests: renderer 'reaches as far as an eccentric orbit goes past the grid: Eris's aphelion, 97.7 AU, not the 80 AU ring' (and the ring where every orbit stays inside it), and framing 'leaves Eris's aphelion its whole margin in every window shape'. Controls, each failing its named test only (1 failed, 839 passed): framing on the ring alone; the ceiling back at 500 AU. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
f82b5e1c74 |
Hold the published catalogue to what its host radii, distance errors and Gaia-distance flags come to
Three things the branch added could vanish from the data with every check passing, as the review
showed with guarded ETL mutants: dropping st_rad or st_teff from each planet left 0 of 6 354
carrying their host's radius or temperature, storing Gaia's parallax_error in milliarcseconds
rather than over the parallax changed 431 464 distance readouts, and dropping the flag fetchStars
sets relabelled 8 129 HYG stars placed at Gaia's distance "HYG". The round trip compares decoded
with encoded, and the counts of missing bands and errors do not look at what the values are.
validateExoplanets now requires 90 % of planets to carry their host's radius and temperature
(measured 6 030 and 6 054 of 6 354). validateStars requires the median relative error of the
distances at Gaia's to be under 1 % (measured 0.33 %), at most 1 % of stars to have a parallax
distance with an error of a fifth or more (measured 1 109, 0.24 %; the archive's, which are on the
distance and never ranged, are left out), and at least 6 000 HYG stars flagged at Gaia's distance
(measured 8 129). Figures from an ETL run from cache on this branch.
Each proved by a guarded mutant in a scratch copy of the ETL, run from the cache, failing with its
own message: host radius dropped ("Only 0 of 6354 exoplanets carry their host's radius and 6054 its
temperature"), host temperature dropped ("6030 ... and 0"), the Gaia error left in mas ("The median
error of Gaia's distances is 1.92 %"), the same with the median check waived ("17689 parallax
distances have an error of a fifth or more"), and the flag dropped ("Only 0 HYG stars are flagged
at Gaia's distance"); a no-op edit completed. No ceiling is loosened.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
||
|
|
6d81c45f45 |
Carry the archive's positions back from Gaia DR2's J2015.5, where it publishes them, not J2016
fetchExoplanets placed each star it adds from the Exoplanet Archive by carrying the archive's
position back sixteen years, and
|
||
|
|
3453cd5d9f |
Say which cards give how far their orbit strays, since Pluto's does not
The date field's description read "Each moon's and dwarf planet's card says how far its orbit strays from 1950 to 2100." Pluto is a dwarf planet on its card, but it moves on Standish's planet elements, and the ETL measures only moons and the SBDB bodies against Horizons: its card ends "Orbit: JPL approximate mean elements (Standish), fit for 3000 BC to AD 3000." and gives no stray figure. In bodies.json, Ceres (7.2), Eris (0.1), Haumea (0.4), Makemake (0.3) and every moon carry one; Pluto does not. The description now reads "AD 1 to AD 3000, where the planets' and Pluto's elements hold. Each moon's card, and Ceres's, Eris's, Haumea's and Makemake's, says how far its orbit strays from 1950 to 2100." The CLOCK_WINDOW comment and the scene's note comment make the same distinction. Test: hud-dock 'opens the date field on the clock's date...' asserts the new sentence. Control: putting the old sentence back fails that test only (1 failed, 836 passed). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
85cb66e63c |
Test that a photograph shows in its own colours once it reaches its body
Since
|
||
|
|
20c34f9662 |
Test the 1972 hand-over to the leap seconds where it happens, and give the ΔT comment its measured joins
The continuity test sampled 1972 at 2451544.5 + (1972 - 2000) x 365.2425 +/- 0.01 d, which is JD
2441317.70 and .72; the switch is at the calendar's 1 January 1972, JD 2441317.5, so both samples
read the leap-second table (42.184 and 42.184) and the join was never compared. Moving the switch
two years early (a 1.99 s step in 1970) passed all 836 tests. The hand-over now has its own test:
the step across midnight must be under 0.1 s (it is 0.067: 42.2514 to 42.184), and the last day of
1971 must still read the polynomial's 42.2485 s. Control: the switch at JD_1972 - 730 fails that
test only (1 failed, 836 passed).
The polynomials' own joins, measured 1e-6 d either side: 0.251 s at 1600, 0.162 at 1700, 0.087 at
500, 0.088 at 1900, and under 0.06 elsewhere.
|
||
|
|
62f81f2c43 |
Number the stars the archive places after their host's name, so a refresh keeps each one's id
|
||
|
|
cbe4908219 |
Turn Earth by the Earth Rotation Angle, so its lit face stays Horizons' at AD 1 as it is today
Earth was turned by its IAU W, taken at the clock's UT plus today's 69.184 s. That W is a straight
line fitted to the present: 360.9856235 degrees a day, which, once its pole's -0.641 degrees a
century in right ascension is counted, runs 6.3e-6 degrees a day slow of Earth's real turning. The
followsUt comment said the clock's date "already says how far it has turned"; it did not. Against
Horizons (observer quantity 14 from the Sun, TIME_TYPE=UT, Earth one light-time back) the drawn
sub-solar point was 2.3 degrees off at AD 1000 and 4.5 at AD 1.
Earth is now turned by the IERS Earth Rotation Angle (IERS Conventions 2010, eq. 5.15) at the
clock's date, counted from the node the IAU's W starts at, 90 degrees past the pole's right
ascension. The pole is unchanged. Drawn minus Horizons, in degrees:
date before after
2025-06-01 12:00 (unit) +0.06 -0.003
AD 1000, JD 2086455 (unit) -2.3 -0.001
AD 1, JD 1721600 (unit) -4.5 +0.051
live app, :4301, same probe as the review's
JD 2460900.25 +0.089 +0.005
JD 2086300.5 -2.281 +0.010
JD 1800000 -4.049 +0.056
JD 1721450.75 -4.530 +0.072
At noon UTC on 1 June 2025 the Sun now stands over 0.52 W on the drawn sphere, where the equation
of time puts it at 0.53 W (0.43 W before).
TT_MINUS_UTC_DAYS had no other use and is removed; its comment also counted 37 leap seconds where
UTC has taken 27 on top of the 10 s it started from in 1972.
Tests: body-orientation.spec 'lights Earth's face where Horizons does at the far end of the clock
too: AD 1000 and AD 1' (within 0.15 degrees), and the renderer's AD 1000 Earth test now checks the
drawn face against Horizons instead of against the IAU W the old code used. Control: turning Earth
by its IAU W at UT + 69.184 s again fails both named tests (2 failed, 834 passed). The README says
which model turns Earth.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
||
|
|
1a8e734651 |
Leave the dark nebulae out of the backdrop, whose sprites can only add light
|
||
|
|
0e9ab6ffb5 |
Fold the Gliese entries that move with a Gaia star up to 160″ away, where a minute left 39 twice
|
||
|
|
150ec76bbd |
Say that a host's radius, temperature and luminosity come from the composite table alone
The comment on hostStarRadiusSolar and its two neighbours said they were read from "the planet's default row first, then the composite table". The default-row query (TAP_COLUMNS in fetchExoplanets.ts) asks for none of st_rad, st_teff or st_lum — the cached answer's columns end at st_mass and disc_year — so host() always reads them from pscomppars, whose columns may each cite a different reference: Proxima's 0.141 R☉ is the composite table's. It also said they were measured where stellar.ts derives a luminosity, which held for the luminosity only once starSurfaceOf began reading st_lum, earlier on this branch; it now points at starSurfaceOf. A comment, so there is no test to fail. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
4ebe663a84 |
Carry the Hipparcos parallax errors between weekly refreshes, as the Gaia answers already are
|
||
|
|
08bf8b18a6 |
Test that a Gaia star with no measured band is still labelled Gaia's
describingCatalogue calls a star Gaia's when its source is gaia and its band is not V. 44 Gaia sources in the shipped catalogue have no G (Gaia DR3 40091256260676736 among them), and nothing tested them: narrowing the rule to band G, which would relabel all 44 "HYG" and count them as HYG in the neighbourhood census, passed the suite. The existing test already builds such a star and now checks its Source row as well. Control: the rule narrowed to band G fails "says a stand-in magnitude was not measured, and leaves out a colour there is none of" (1 of 797). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
f8af0ecf6e |
List stars in search and routes by the type their colour gives them, and say where archive positions come from
|
||
|
|
4191b70e63 |
Tint a star measured in Gaia's BP−RP as the B−V of the dwarf of that colour
colorIndexToRgb maps a B−V onto the star field's tint ramp, and its one caller passed it every star's colour index, whatever colorSystem said. BP−RP is the larger of the two for the same star — 0.823 against 0.65 for a G2 dwarf, 1.84 against 1.42 for an M0 (Pecaut & Mamajek) — so the 376 703 stars measured in it, 83 % of the catalogue, were tinted as later types than they are, and redder than HYG's stars of the same type, and than their own disc in the system view. A BP−RP is now carried to the B−V of the dwarf sequence at that colour (the table's own B−V column, which DwarfSequencePoint now returns, clamped at its ends), then tinted as before. The median Gaia colour, BP−RP 0.883, a G7 dwarf, read as a K2: its tint goes from (1, 0.972, 0.955) to (0.975, 0.982, 1), the same as HYG's G7 stars. Controls, each failing its named test: BP−RP read as B−V (2 of 792 failed), the star field not passing the colour system (1 of 792), and the B−V taken from the wrong column (3 of 792). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
fa52f6a818 |
Give an archive star's distance error as the error on the distance it is, not as a parallax range
formatDistance printed any error of a fifth or more as the range a parallax's error makes, d/(1+e) to d/(1−e). A star the ETL places from the Exoplanet Archive carries the mean of sy_disterr1 and 2 instead, which the archive defines as one-sided errors on sy_dist in parsecs, and many of those distances come from a lensing model with no parallax behind them. 129 of the 3 195 archive stars with an error were printed as ranges the archive does not give: KMT-2016-BLG-1836L as 5.8 to 9.2 kpc, where the archive publishes 7 100 +800 −2 400 pc, and AT2021ueyL as 664 pc to 2.4 kpc against 1 040 +740 −440. The card now tells formatDistance when the error is on the distance (source exoplanet-archive), and it keeps the ± at any size. Measured on the shipped catalogue: KMT-2016-BLG-1836L reads 7.1 ± 1.6 kpc, AT2021ueyL 1.0 ± 0.6 kpc, EPIC 201170410 134 ± 43 pc, KMT-2016-BLG-0212L 6.3 ± 1.3 kpc. The ETL keeps only the mean, so a lopsided interval such as KMT-2016-BLG-1836L's is shown symmetric; carrying both errors would take a second column in stars-meta.bin. The doc comments on formatDistance and on distanceError no longer say an archive distance is an inverted parallax. Controls, each failing its named test: the error on the distance read as a parallax's (2 of 790 failed), and the card not saying it is on the distance (1 of 790). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
d1aa22ed61 |
Frame a giant so its disc sits inside the ring its neighbours are named on
The system view names a star's neighbours on a ring at 0.74 of the view's tighter half-extent, whatever the star. A giant was framed to fill the frame, 2.4 radii out, which the three-radius closest approach then overrode, so it settled at 3 radii with its disc projecting to 0.758 of the half-extent: in the app, Betelgeuse's disc was 379 px on a 1 000 px view against the 370 px ring, and HD 39374 and HD 38118 were printed on it at about 1.3:1 contrast. The star's term in the framing distance now places its silhouette, asin(R / d), at half the tighter half-extent, which puts the camera 4.4 radii out on a 50° view. Measured on :4302 at 1600 by 1000: Betelgeuse settles at 13.9 AU (closest approach 9.5) with a 250 px disc and Antares at 14.1 AU; the nearest corner of any neighbour's name is 292 px from the centre, so none is on either disc (it was two and one of them before). Closing in to the closest approach can still bring the disc over the names; that is the viewer's choice, not the arrival's. This also gives the star's term a job: at 2.4 radii it never exceeded the closest approach, so dropping it changed nothing (the previous commit's one surviving control). Controls, each failing its named test: the star left out of the framing (1 of 788 failed), the star framed to fill the frame (2 of 788), and the disc taken as flat (1 of 788). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
5aac46de08 |
Draw a star nothing gives a size or temperature for as a grey point, not as the Sun
The system view drew every star without a radius at the Sun's radius, and every star without a temperature in the Sun's colour. PSR J1719-1438, a neutron star 10 km across, came out 1 R☉ wide, wider than its planet's 0.0044 AU orbit, and b spent nine tenths of its orbit inside it; Procyon B, a white dwarf of 0.012 R☉ with a type the parser does not read and no colour, was a Sun 81 times too wide in the Sun's colour. Such a star is now drawn at 150 km, under the three-pixel floor from anywhere the camera can go, so the floor's point is what shows, and its disc keeps the photograph's own grey instead of the Sun's tint. Its light stays white, which is the photographs' own light rather than a claim about the star. 2 858 stars take this after the clamping in the previous commit, against 3 077 drawn at the Sun's radius before it. In the app on :4302: PSR J1719-1438's star is drawn at 1.7×10⁻⁴ AU (the floor, 168 times its geometry) with b 0.00417 AU from its centre, outside it; Gl 280B at the floor, tint (1, 1, 1) and no radius on its card; Proxima at 0.141 R☉, tint (1, 0.459, 0.135), light (1, 0.523, 0.165), card "Luminosity 0.002 L☉" unmarked and "Radius 0.141 solar radii". The scene's use of the star's surface had no test: every star in the scene spec was drawn at the Sun's radius, and drawing all of them so, lighting planets white, tinting every disc as the Sun or closing the camera to the Sun's clearance all passed. The spec now gives Proxima its planet's archive row and adds Antares and Procyon B, and three tests enter them. Controls, each failing its named test: every star at the Sun's radius (3 of 787 failed), an unmeasured one at it, the light without the temperature, the closest approach for the Sun, the Sun's tint for a host, the Sun's tint for a star without a temperature, and the card without the surface (1 of 787 each). Dropping the star from the framing distance was not caught: its term, 2.4 radii, never exceeds the three-radius closest approach the camera is clamped to, so it cannot change where the camera settles. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
31e0c04fe1 |
Read a colour past either end of the dwarf table at that end, where the star has no type instead
dwarfSequenceAtColor answers null outside Pecaut & Mamajek's table, B−V −0.301 to 2.16 and BP−RP −0.12 to 5.1, and effectiveTemperatureK then fell back on the type, which Gaia's stars do not have and carbon stars' parser does not read. 219 stars with a measured colour got no temperature and so no radius, and were drawn at the Sun's radius in the Sun's colour: 110 white dwarfs within 50 pc, 38 Gaia stars redder than BP−RP 5.1 (Gaia DR3 6439125097427143808, an ultracool dwarf 4.0 pc away), HD 46687, La Superba and the other carbon stars, and an O8 star. Past the table, the colour is now read at the row it is past (clampToTable), but only for a star with no readable type: beside a type an off-table colour is more often the bad measurement — HD 49748 is G5 V at B−V −0.32 — so the type still wins there, as it did. The luminosity reads the same point, so a star past the red end also gets the M8.5 row's G−V and correction. A type's own colour past the table, which only O types have, is read at B0. Carbon and S stars (C, N, R, S) now count as giants, so their correction stays their type's, not an M8.5 dwarf's −5.78. Measured on the shipped catalogue: stars without a temperature 3 053 -> 2 834, without a radius 3 077 -> 2 858; all 292 stars with an off-table colour now have a temperature, against 73. Gaia DR3 6439125097427143808 is 2 420 K and 0.110 R☉ (M8.5 V: 0.104); the 110 white dwarfs a median 0.018 R☉ at 10 700 K (0.0013 to 0.034); HD 46687 212 R☉ at 2 420 K and La Superba 133; audit #16's Gaia DR3 5612323414549657984, k1 Pup, B6 V at BP−RP −0.15, 203 L☉ and 4.1 R☉ against 143 and none (FLAME gives 336 and 3.49). The 2 851 stars left without a radius have neither a colour nor a readable type, or no band. Controls, each failing its named test: no clamp for an untyped star (2 of 784 failed), the clamp winning over a type, an O type's colour unclamped, the luminosity off the unclamped sequence, and carbon stars not counted as giants (1 of 784 each); clampToTable ignored (3 of 784). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
dc7277f740 |
Say in the textures README that the mission mosaics' brightness is not albedo, as Iapetus shows
Iapetus's leading hemisphere has an albedo of 0.03-0.05 and its trailing one 0.5-0.6, about a tenth. On iapetus.jpg, between 30 S and 30 N, the leading side (30-150 W) averages 83.4 of 255 and the trailing (30-150 E) 108.2, a ratio of 0.77, measured here again; the USGS source gives the same (83.3 and 108.1), so it is the mosaics' frame-by-frame contrast stretch, not the processing. The README's Iapetus row checked only where Cassini Regio lies, and nothing said the brightness is not albedo; it now does, with those figures. The map is not rescaled: no photometric model was applied to any body, and one hemisphere's worth of scaling would be invented for this one. Documentation only; no behaviour changes. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
d93bb1ee2c |
Say that Pluto's tilt is checked against its own IAU pole, not against Horizons
The ETL's obliquity check, its failure message and the renderer spec's test name all compared Pluto's drawn tilt with "the obliquity Horizons gives", as |
||
|
|
98c4eb901f |
Credit the sources the solar system's orbits now come from, in the README and a search comment
Since |
||
|
|
a281f22f34 |
Measure every moon and dwarf planet against Horizons from 1950 to 2100, and say on its card how far it strays
The clock reaches AD 1 to AD 3000, but only the planets' cards named a span their elements hold
over; the 25 moons and the four SBDB dwarf planets gave a source and an epoch, though
BodyRecord.orbitSource is documented as "the span they hold over". And the worst offsets the ETL
stated came from twelve New Year's Days: Nereid's year is 360 days, so all twelve fell far from
its periapsis, where a mean ellipse is furthest out. The one date the ETL checked, 2025-01-01, saw
Nereid at 2.6 degrees; it reaches 11.19.
For each moon and each SBDB dwarf planet the ETL now fetches Horizons' ICRF vectors from 1950 to
2100, every other day (daily for Nereid, at an eccentricity of 0.75, and Hyperion, whose row's
eccentricity is a quarter of its real one: every other day gave it 22.14, daily 22.23), and
measures how far the mean elements stray, at the same TDB dates. The card appends it: "JPL SBDB
osculating elements, epoch 2026 Jun 9, within 7.2 degrees of Horizons from 1950 to 2100". Worst
offsets on the real catalogue: the Moon 2.62 (2010 March 27), Phoebe 2.58 (1969, where a comment
claimed "within 2.0"), Phobos 1.26, Mimas 7.43, Iapetus 10.34, Nereid 11.19 (2039 Nov 1),
Hyperion 22.23 (2055 Feb 26), Ceres 7.12 (1953); Io 0.07, Titan 0.06, Eris 0.06.
build.ts recomputes each from the same Horizons positions and fails if an orbit other than
Standish's names no span, if a card states less than it strays, or if a body passes its ceiling:
3 degrees, and Hyperion 23, Nereid 12, Iapetus 11, Mimas 8 and Ceres 8, each explained. The
2025-01-01 check stays for reading errors, its comment no longer passing one date's offsets off as
worst ones. The Sun's note says the moons' and those four's elements were checked from 1950 to
2100, and the date field's description that each card says how far its orbit strays over that span.
In the running app Ceres's, Phobos's and Nereid's cards end "within 7.2", "1.3" and "11.2 degrees
of Horizons from 1950 to 2100".
The CLOCK_WINDOW comment also had the calendars the wrong way at AD 1: proleptic Gregorian dates
are two days behind the Julian calendar there, level from AD 200 to 300, and ten days ahead by
1582. It now says so, and names Ceres's drift where it named Phobos's, which its orbit now carries.
Controls: the ETL measuring nothing fails ("Ceres's orbit ... names no span it holds over"),
rounding the stated figure down fails on Ceres (7.1 against 7.12), and Nereid held to the general
ceiling fails at 11.19; the note and the date field without the span fail their named tests.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
||
|
|
d097f4b477 |
Correct a giant's light by its type, not by the cooler dwarf its colour reads as
|
||
|
|
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> |
||
|
|
d94451e203 |
Warm a host's planets by the luminosity the archive publishes for it, not one derived beside it
The ETL has carried each host's st_lum since
|
||
|
|
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> |
||
|
|
869635bec1 |
Give a star no survey measured no luminosity, so its planets get no temperature from a stand-in
luminosityOf derived a luminosity from any magnitude, including the stand-in the ETL writes for the 309 stars with neither a V nor a G. starSurfaceOf already refused it for the radius; the card, the system view's planet appearances and the body pages did not. The 265 archive hosts among them came out at a median 33 L☉: KMT-2016-BLG-1107L, a 0.087 M☉ star, at 36.8, and OGLE-2005-BLG-390L b, published at about 50 K, read 388 K and a sub-Neptune. Their cards printed "Magnitude: Not measured" beside a luminosity derived from that magnitude. The guard now sits in luminosityOf, which every caller goes through, so the one in starSurfaceOf is gone. The Sun keeps its 1 whatever band it is filed under. Measured on the shipped catalogue: of the 275 planets on those 265 hosts, 268 had an equilibrium temperature and 0 now do; before the archive stars were added they had no host, and so none either. Controls: without the guard, "has none from a magnitude no survey measured, and gives its planets no temperature from it" fails (with the radius test beside it, 2 of 777); without the Sun's exemption, "is 1 for the Sun, whatever its magnitude is filed under" fails (1 of 777). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
|
8c4f1c11c9 |
Build a body still waiting for its surface with a null map, so three stops warning on each one
Since
|
||
|
|
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> |