f8af0ecf6e02804cb354e25613d036fb3af27359
177
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  SenrokaiandClaude Opus 5.5
|
f8af0ecf6e |
List stars in search and routes by the type their colour gives them, and say where archive positions come from
|
||
|
SenrokaiandClaude Opus 5.5
|
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> |
||
|
SenrokaiandClaude Opus 5.5
|
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> |
||
|
SenrokaiandClaude Opus 5.5
|
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> |
||
|
SenrokaiandClaude Opus 5.5
|
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> |
||
|
SenrokaiandClaude Opus 5.5
|
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> |
||
|
SenrokaiandClaude Opus 5.5
|
d097f4b477 |
Correct a giant's light by its type, not by the cooler dwarf its colour reads as
|
||
|
SenrokaiandClaude Opus 5.5
|
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
|
||
|
SenrokaiandClaude Opus 5.5
|
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> |
||
|
SenrokaiandClaude Opus 5.5
|
2242fe0a7f |
Give every star a limb-darkened surface in its own colour, and light its planets with it
Every star but the Sun was a flat disc of one colour, and the Sun wore the texture pack's orange photograph, lit by the same white light as every other star's planets. Every star now shares one TSL material (starSurfaceMaterial in the scene): the Sun's map in grey, times the colour of a blackbody at the star's temperature, times a linear limb-darkening law, 1 - 0.6 (1 - mu), the Sun's coefficient in the visible. The temperature is the one the radius uses: the archive's st_teff for a host, else the dwarf sequence at its colour or type, else the Sun's. The colour comes from blackbodyColor (stellar.ts): Kim et al.'s cubic fit to the Planckian locus, then CIE XYZ to linear sRGB, brightest channel 1. At D65 it gives 2 900 K (255, 180, 103), 5 800 K (255, 241, 235) and 9 600 K (208, 219, 255), against (255, 182, 98), (255, 241, 231) and (211, 221, 255) in Charity's integrated blackbody table. The tint is a uniform, so the shader is built once and not per system. The star's PointLight takes the same colour against the Sun's, since the planets' photographs were taken in sunlight: the Sun's light stays white at pi, TRAPPIST-1's (2 566 K) is (1, 0.44, 0.10) and Proxima's (2 900 K) (1, 0.52, 0.17), Sirius's (0.52, 0.67, 1). The intensity stays pi. No halo comes back. sun.jpg was 2048 by 1024 and 822 427 bytes for a disc that reaches 216 px across at the Sun's closest approach on a 1080-line screen. It is now 1024 by 512 in grey, 31 306 bytes, which covers the disc to a 1440-line screen. Its brightness varied by 56 % rms, which made every star a mottled rock; it is rescaled to 14 % rms about the display's white, of the order of the Sun's granulation contrast, the brighter half clipped as in a photograph exposed for the disc (6 % rms remains). Measured on the dev server (1600 by 1000, the camera at its closest approach): - the disc's brightness against the law, from r/R 0.52 to 0.97: Sun 0.970/0.841/0.763/0.657/0.560 against 0.927/0.829/0.755/0.645/0.554, ups And and Sirius the same to within 0.05; - the disc's centre in sRGB: Sun (245, 233, 226), ups And (F8V, 6 157 K) (249, 239, 239), Sirius (199, 209, 243); - the first system entry of a fresh page, three runs each in alternating blocks against the previous commit: Sol's longest task 90 ms before, 86 ms after, two tasks over 50 ms in every run either way; Proxima Centauri's none over 50 ms after, one run of six with a 53 ms task before. The long tasks on Sol's first entry predate this change. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
7213f987c4 |
Draw every star at its own radius, measured where the archive has one and derived otherwise
The system view drew the Sun at its own radius and every other star at 0.45 of its innermost orbit, capped at 0.2 AU: a size chosen so the star would not swallow its planets, not the star's. Proxima Centauri was drawn at 2.8 solar radii, eighteen times its own, and every star without planets at 43. starSurfaceOf (body-view-model.ts) now gives each star a radius and a temperature. A planet host takes the archive's st_rad and st_teff from its planets' rows: 4 439 hosts are drawn at a measured radius, 22 at a derived one. Every other star's is derived: its temperature off Pecaut & Mamajek's dwarf sequence at its colour (the same table the spectral estimate reads, or at the colour its type implies where it has none), its luminosity from its absolute magnitude and the bolometric correction luminositySolar already applies, and R = sqrt(L) / (T / 5772 K)^2. Against the archive's own st_rad for the 1 447 catalogue hosts that have one, the derived radius is within 0.018 dex at the median, 0.071 dex at the 90th percentile, and within a factor of 1.5 for 97.1 %. Sirius comes out 1.79 solar radii (1.711 published, Liebert et al. 2005), Wolf 359 0.117, Betelgeuse 584, the Sun exactly 1. A star with no band has only the ETL's stand-in magnitude, and gets no derived radius: PSR J1719-1438 came out 2.3 solar radii from it, wider than its planet's orbit. With the stars that have neither a colour nor a type, that leaves 3 077 of 455 608 stars (274 of 4 735 hosts) with no radius; they are drawn at the Sun's, and their card gives none. The card says which it is: "Radius 0.141 solar radii" for a published one, "~0.10 solar radii, from colour and brightness" for a derived one, two figures because colour does not give three. A giant drawn at its size can be wider than its system, so systemFramingDistanceAu also makes room for the star, and the controls' closest approach is now three of the star's radii where that is more than the old 0.05 AU. 23 211 stars are drawn wider than 3.6 solar radii, which put 0.05 AU inside three of their radii, and a zoom would have carried the camera through the surface of the largest. The Sun keeps 0.05 AU. starMarkerRadiusAu and the renderer's innermost axis, which only it read, are gone. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
3392f06c85 |
Read a star's bolometric correction off its colour, and carry Gaia's G to V first
A star's luminosity was its absolute magnitude plus a bolometric correction read off its spectral type, with its magnitude taken as V whatever band it was in. Gaia classifies none of its stars, so all of its 379 000 got the Sun's correction, and their G was read as V: TRAPPIST-1 came out at a seventh of its luminosity. The dwarf sequence spectral.ts already reads types off (Pecaut & Mamajek 2013, table 5, online version 2022.04.16) now carries its effective temperature, bolometric correction to V and Gaia G-V columns, and dwarfSequenceAtColor interpolates them at a colour, in the colour's own system. luminositySolar uses it wherever the star's colour is inside the table: the G magnitude is carried to V, then corrected. Only without such a colour does it fall back to the spectral type, as before. Against the archive's own st_lum for the 1 449 hosts that are catalogue stars, the median error goes from 0.038 to 0.022 dex and the 90th percentile from 0.292 to 0.115 dex; within a factor of 1.5, 84.5 % -> 93.8 %. For the 572 hosts Gaia describes: 90th percentile 0.332 -> 0.073 dex, 81.8 % -> 97.0 % within a factor of 1.5. Barnard's Star with no type now reads 0.0029 L_sun against 0.0035 published, and TRAPPIST-1 7.3e-4 against 5.5e-4 (Agol et al. 2021). Across the catalogue, 311 255 of 455 608 stars move by more than 10 % (median ratio 0.90: a G-type star's G is 0.16 brighter than its V), and so do the hosts of 3 158 planets, whose equilibrium temperatures follow as the fourth root. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
81a4ecfcde |
Name the columns stars-meta.bin gained in the README
The README listed the four columns stars-meta.bin had before
|
||
|
SenrokaiandClaude Opus 5.5
|
b46c840369 |
Warm every body by the microwave background too, so none reads colder than space
The derived equilibrium temperature balanced starlight alone. For the widest orbits that is less than the 2.7 K every body in space is held at by the cosmic microwave background. The planet 7 493 AU from 2MASS J21252752-8138278 read "Equilibrium temp. 1 K", and the one 19 000 AU out from UCAC4 328-061594 would have read 0 K. equilibriumTemperatureK now adds the background as a second source in the same balance, T^4 = T_star^4 + (2.7255 K)^4 (Fixsen 2009). Inside a few hundred AU of any star it changes nothing that shows: Earth, Mars, Jupiter and Neptune reproduce their published values as before. Across the 6 354 exoplanets, the rounded temperature changes for 11, all on orbits of 350 AU or more. Ten go from 0, 1 or 2 K to 3 K, from VHS J125601.92-125723.9 b at 350 AU to UCAC4 328-061594 b at 19 000 AU, and 2MASS J22501512+2325342 b at 518 AU goes from 4 to 5 K. On the dev server, the detail pages of the 7 493 AU planet and of GJ 900 b read "Equilibrium temp. 3 K". Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
1e3ac57229 |
Wrap a body's name on its card instead of cutting off the digits that tell it apart
The detail page and the system view's object card truncated the name and the line under it with an ellipsis. For a designation, the part that went is the part that identifies it: the audit measured "2MASS J21252752-8138278 b" at 288 px in a 256 px heading, shown as "2MASS J21252752-81382…", and the eyebrow at 273 px, shown as "EXOPLANET · 2MASS J21252752-8138…". Both lines now wrap (wrap-break-word) in both places. On the dev server the heading for that planet is two lines, 45 px high, with its scroll width equal to its 256 px box, and the eyebrow fits in 256 px. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
70cbdae306 |
Drop the "..." Hipparcos leaves on a spectral type, which read as the app cutting it short
2 127 stars, Sirius among them, read "Spectral type A0m...", in search rows, route options and the star card. The mark is Hipparcos's own: every one of the 3 803 HYG rows ending in it has a HIP number, and the catalogue ends a classification it does not print in full with it. The app truncated nothing, but the text reads as if it had. fetchStars now trims a trailing "..." from HYG's spectral types. The dictionary in stars-index.json goes from 3 056 distinct types to 2 883, and from 598 dotted ones to none. The names, sources and source indices are unchanged, and so is every other column of stars-meta.bin bar the type indices. gzip -9 of the index goes from 4 015 865 to 4 015 205 bytes. build.ts validateStars now fails a catalogue with any type ending in "...". Run with the trim removed, the ETL failed on 2 127 such types. Two ETL runs from cache wrote identical stars-meta.bin and stars-index.json. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
5333be615e |
Estimate a spectral type from each star's colour where no catalogue gives one, and say so
383 695 of the 455 608 stars read "Spectral type Unknown", every Gaia star among them, although 380 884 of them carry a colour. The card now gives those the type of the dwarf whose colour is nearest, in the colour's own system, marked as an estimate: TRAPPIST-1, BP-RP 4.90, reads "Spectral type ~M8, from colour", which is how it was classified (M8 V). A star with neither a type nor a colour gets no subtitle rather than the literal "Unknown". The colours are Pecaut & Mamajek's mean dwarf sequence (2013, ApJS 208, 9, table 5), as Mamajek maintains it online (version 2022.04.16, which carries Gaia BP-RP), from B0 to M8.5. B-V cannot tell O types apart (the whole sequence spans 0.03 of it), and BP-RP turns back past M8.5 and is tabulated only from B9. A colour outside the table gets no estimate: 186 BP-RP and 41 B-V colours, among them the blue Gaia DR3 5612323414549657984 at BP-RP -0.15. 380 657 stars get an estimate: F 97 840, G 144 327, K 105 984, M 29 142, A 3 272, B 92. Checked against catalogued types: - 19 433 HYG dwarfs with a B-V: 74.3 % within two subclasses, 95.5 % within five. - 146 Gaia exoplanet hosts the archive types as dwarfs, from BP-RP: 88.4 % within two subclasses, 98.6 % within five. The estimate assumes a dwarf, so a giant reads later than it is (Pollux, K0 III at B-V 0.99, reads K3). It also ignores reddening. The comment says both. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
a81dd491ad |
Say which band each star was measured in, whose catalogue it is, and how sure its distance is
The readout named Hipparcos, Yale and Gliese while 378 775 of the 455 608 stars are described by Gaia DR3, printed one "Magnitude" for G and V alike, and gave every distance to the parsec. The band cannot be read off the star's source, which records whose position it has: 62 002 stars Gaia places keep HYG's V and B-V, and the 575 hosts renamed after their planets are Gaia's, in G. stars-meta.bin gains two byte columns, 14 to 16 bytes a star (6 378 512 to 7 289 728 bytes; gzip -9 2 804 049 to 3 110 991). One holds the magnitude's band (V 76 555 stars, G 378 744, none 309, whose magnitude is a stand-in), which colour the colour index is (B-V 75 203, BP-RP 376 703), and whether the distance is Gaia's parallax. The other holds the distance's relative error as its square root in 255ths: a step is 0.08 % of distance at 1 %, 0.35 % at 20 %, and 100 % is the top. encode, decode, BYTES_PER_STAR_META and the build.ts round trip cover both; no workflow reads the format. Where the errors come from: - Gaia rows keep the parallax_error their query already fetched: median 0.3 %, 90th percentile 1.2 %, at most 20 %, the query's own cut. - A HYG star at Gaia's distance takes the cross-match's parallax_over_error, and a star merged into a Gaia entry keeps that entry's error with its position. - The 3 067 Hipparcos stars that keep their Hipparcos distance, Rigel, Deneb and Alnilam among them, take e_plx from van Leeuwen's 2007 reduction: a new cached query of public.hipparcos_newreduction on the ESA archive, whose 117 955 rows HYG's distances invert. - The archive's stars take sy_disterr1/2 from pscomppars, in a query and cache file of their own so the composite rows already cached were not refetched. - 439 distances have no published error: 357 Gliese rows and 82 archive hosts. Of the errors, 392 786 are 1 % or less and are not printed; 61 156 print as "117 ± 12 pc" to the distance's own digits; 1 196 between 20 and 100 %, and 30 past it, print as the range the parallax gives, since a symmetric error in parallax is a lopsided one in distance. The star card (measured on the dev server) now reads, for example: - Rigel: 265 ± 23 pc, V 0.18, B-V -0.03, source HYG. - Deneb: 433 ± 60 pc. - Alnilam: "476 pc to 833 pc" (Hipparcos 1.65 ± 0.45 mas). - Gaia DR3 5612323414549657984: 111 ± 2 pc, G 4.63, BP-RP -0.15, source Gaia DR3. - Proxima Centauri: 1.30 pc, V 11.01, source "HYG, Gaia DR3 distance". - TRAPPIST-1: G 15.62, BP-RP 4.90, source Gaia DR3. - Kepler-186: V 15.14, source NASA Exoplanet Archive. The neighbourhood's subtitle reads "Gaia DR3 378,775 · HYG 73,556 · NASA Exoplanet Archive 3,277", counted by the catalogue describing each star. build.ts validateStars now fails a catalogue with more than 1 000 stars without a band (309 today) or without a distance error (439). Dropping G from the Gaia rows gave 379 040 without a band, and dropping their parallax_error gave 441 216 without an error; both runs failed. Decoding the catalogue in Node took a median 29 ms before and 24 ms after (nine runs each, within noise). In the app, five cold boots gave a 654-786 ms long task after the data landed and the HUD at 1.83-2.07 s. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
4c8e4a02f3 |
Give every planet with a distance a star, from the archive where the catalogue has none
After matching, 4 237 planets still had no star: their hosts are too faint for either Gaia query (fainter than G 12 past 50 pc) or too far (past 250 pc), Kepler-186 at 177.6 pc among them. fetchExoplanets now adds one star per such host from the archive's own figures, 3 277 of them, whenever the archive gives a position and a distance: - position carried back from J2016, where the archive publishes it (741 of the 746 matched hosts moving over 100 mas/yr sit nearer their star carried back, a median 0.11" against 3.47" as published), and placed at sy_dist; - magnitude in V (2 999 hosts), else Gaia G (13), the band the catalogue's Gaia stars are already in; 265 have neither, 128 KMT, 95 OGLE and 32 MOA microlensing hosts at a median 6.2 kpc among them, and take the ETL's faint stand-in of 15; - colour as B-V from the archive's B and V, else from st_teff through a new temperatureToColorIndex (Ballesteros 2012, inverted; the Sun's 5 772 K gives 0.65), else left to st_spectype; - ids from 1 070 000 000, past Gaia's two ranges and under the 2^30 validateStars enforces; source "exoplanet-archive". Hosts past 250 pc are included: 399 of the 3 277 are within 250 pc, 1 962 between 250 pc and 1 kpc, 916 beyond. The drawn budget still chooses what is drawn (70 000 of 455 608). Planets with a star: 2 090 -> 6 327 of 6 354. The other 27 have no distance in either table (Luhman 16 A, mu2 Sco, PSR B1620-26 among them). Systems in the Solar Neighbourhood readout: 1 450 -> 4 736. validateExoplanets now refuses a catalogue where fewer than 99.5 % of planets have a host (measured 99.58 %); dropping the added stars fails it at 2 090, and dropping the composite fill at 6 227. No added star sits within an arcsecond of a catalogue star (validateMerge's twins stay at 23); 5 of the 399 within 250 pc have one within a minute of arc, VHS J125601.92-125723.9 (archive 12.7 pc) 5.8" from a Gaia entry at 21.2 pc the likeliest duplicate. In the app, searching TRAPPIST-1 or Kepler-186 and picking the star enters a system with its seven and five planets drawn. gzip -9: stars.bin 5 030 741 -> 5 067 864 B, stars-meta.bin 2 784 614 -> 2 804 064, stars-index.json 4 003 584 -> 4 015 882, exoplanets.json 342 467 -> 446 532 (host parameters, both commits). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
494fb5616b |
Find the hosts the catalogue already holds, and name them after their planets' star
The archive's default-parameter rows leave sy_dist blank for 100 planets, TRAPPIST-1's seven among them, so the matcher could not place a host the catalogue had drawn since the Gaia nearby query (Gaia DR3 2635476908753563008, 12.47 pc). fetchExoplanets now also reads the Planetary Systems Composite table (pscomppars) and fills a default row's blank host cells from it. Only host columns: a composite row takes each column from its own reference, so orbits still come from the default row alone, one fit per planet. Where both tables give a distance or a position they agree on all 6 225 and 6 352 rows. Three hosts the catalogue holds by name failed the distance ratio test because the archive's sy_dist, from TICv8, contradicts its own parallax: Lalande 21185 (GJ 411) 5.68 pc against 392 mas, Luyten's Star (GJ 273) 5.92 against 263 mas, Struve 2398 B (Gl 725 B) 6.84 against 285 mas. resolveHostStarId now takes the archive's parallax (sy_plx) as a second distance the ratio test accepts. It is a second chance, not a replacement: 47 of 5 959 systems disagree past the tolerance, and for faint far hosts the inverse parallax is the worse figure (K2-238: 538 pc by sy_dist, 6 779 by parallax). Planets on a catalogue star: 2 071 -> 2 090 of 6 354. The 19 gained are TRAPPIST-1 (7), GJ 273 (2), GJ 411 (2), Gl 725 B, HD 62509 (Pollux), K2-65, TOI-2267 A and B, and two brown-dwarf hosts, 2MASS J02192210-3925225 and DENIS-P J082303.1-491201. No planet lost or changed its host. A matched host whose catalogue name is a bare Gaia designation now takes the archive's host name, so search finds TRAPPIST-1, Teegarden's Star, TOI-700, LP 791-18 and K2-18: 575 stars renamed. validateExoplanets refuses a host that is still only a designation, and the star assets are rewritten after the exoplanets for that reason; stars.bin and stars-meta.bin are unchanged. TOI-2267 A and B both land on one Gaia entry, which takes the name TOI-2267 A. Each planet also carries its host's radius, effective temperature and luminosity (10^st_lum), and a mass for 6 344 planets instead of 5 474, from the default row where it gives one and the composite table otherwise, for the star-physics step. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
c01d3ec2bc |
Read OpenNGC's addendum, so the Pleiades and the Large Magellanic Cloud are on the map
OpenNGC keeps the objects no NGC or IC number covers in a second file, addendum.csv, with the same 32 semicolon-separated columns as NGC.csv. The ETL only ever fetched NGC.csv, so the brightest deep-sky object in the sky, the Large Magellanic Cloud (V 0.29), was missing while the Small one was drawn, and so were the Pleiades (M45), the Hyades, the Horsehead and the Coalsack. fetchDeepSky now fetches the addendum beside NGC.csv, caches it as openngc-addendum.csv, and runs its rows through the same loop. Of its 64 rows, 27 pass the existing filters: all 22 named or Messier rows except M40, which OpenNGC types as a double star, and M102, typed as a duplicate of M101; plus seven anonymous open clusters brighter than V 9 (H05, H20, H21, Mel071, Mel101, Mel105, MWSC3171). deepsky.json goes from 463 to 490 objects (galaxies 73 -> 85, clusters 294 -> 306, nebulae 96 -> 99), with no existing record changed. Messier coverage goes from 106 to 107 of 110. 340 of the 490 have a distance: the Pleiades 135.8 pc and the Coma Star Cluster 85.9 pc from their parallaxes; the Hyades and the Local Group dwarfs honestly have none. validateDeepSky now requires the Andromeda Galaxy and the Small Magellanic Cloud from NGC.csv, the Large Magellanic Cloud and the Pleiades from the addendum, and at least 107 Messier objects. Both checks were run against the real catalogue with the addendum removed: the ETL fails on "Deep-sky object ESO056-115 is missing", and with the required list emptied, on "Only 106 Messier objects were produced". In the app, on the dev server: 490 sprites. The Pleiades sprite lies 0.00182 deg from Alcyone (0.00183 deg from the published coordinates); the LMC 18.4209 deg from Canopus and 26.8215 deg from Achernar (18.4209 and 26.8215 published); the Hyades 2.2591 deg from Aldebaran (2.2591). The twelve labelled deep-sky objects now open with the Large Magellanic Cloud and the Pleiades and include Brocchi's Cluster, in place of h Persei, chi Persei and NGC 2516. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
74b93a0428 |
Fill in the Sun's faint neighbours from Gaia, and fold the Gliese entries they repeat
Gaia's G < 12 cut took a quarter of what lies within 10 pc: the red, brown and white dwarfs most of the neighbourhood is made of, which the map only had where Gliese happened to list them. Teegarden's Star was missing, and with it its three planets' host. A second query fetches the complement out to 50 pc: G >= 12 or no G, parallax > 20 mas, with pmra/pmdec so the J2016 -> J2000 propagation applies. The quality filter was chosen by counting. Parallax over error > 5 keeps 39 751 of the 39 764 sources that pass the floor, but the Gaia Catalogue of Nearby Stars (GCNS; Gaia Collaboration, Smart et al. 2021) rejects 11 752 of them as spurious: median G 20.2, astrometric excess noise 5.4 mas against 0.15 for the ones it keeps, 6 933 toward the Galactic centre. So the query joins the GCNS main table (EDR3 astrometry and source ids, which DR3 carries unchanged) and keeps 28 012 rows; the error cut stays and costs no GCNS source, brown dwarfs included. The query has its own row-count floor (28 012) and the row-limit cap, and is ordered by (phot_g_mean_mag, source_id); a second ETL run reproduced stars.bin, stars-meta.bin and stars-index.json byte for byte. Its ids start at 1 050 000 000, clear of the main query's and under 2^30, which V8 keeps unboxed: numbered from 2 000 000 000 they made the app's boot task 230 ms longer (medians of five interleaved runs, 1.41 s against 1.18). validateStars now refuses an id outside 0 to 2^30. The Gliese entries these stars duplicate were not folded: HYG carries them with positions off by up to a minute of arc and photometric distances, so they missed the 15" tolerance or failed the distance test. Their proper motions, which Gliese measured well, give them away: isSameStar now takes two entries moving within 20 % of each other as one star up to 60" apart, whatever their distances, brightness still permitting. Of the 602 Gliese-only rows left without a counterpart, 253 have such a Gaia entry; with every entry shifted a quarter degree, none does. fetchStars passes HYG's motions only for rows without Hipparcos astrometry: given them too, 15 Hipparcos stars took a co-moving companion's Gaia entry and the cross-catalogue pairs under an arcsecond went from 23 to 35. Of HYG's 1 200 stars fainter than V 12 within 25 pc, 1 024 now sit on a Gaia position (325 before); of the 176 left alone, 43 still have a Gaia entry 3-60" away (218 without the motion rule), some of them real companions. Measured on the rebuilt catalogue, against the GCNS (sources with parallax > 100, 40 and 20 mas): within 10 pc 336 -> 372 (GCNS 312; the map adds 60 HYG-only stars) within 25 pc 3 652 -> 5 560 (GCNS 5 111) within 50 pc 13 702 -> 40 916 (GCNS 40 231) 452 331 stars (+27 214). Proxima, Barnard's Star, Wolf 359, Rigel, Deneb and Alnilam are all present by name; Teegarden's Star is Gaia DR3 35227046884571776 at 3.83 pc and hosts its three planets. Luhman 16 is not in Gaia DR3 with a parallax (5353626573555863424 has a two-parameter solution) and stays absent. 94 more exoplanets find a host (2 071), none changes host. TRAPPIST-1 is now drawn (Gaia DR3 2635476908753563008, 12.47 pc) but its planets are not yet matched to it. Merge gate, ceilings unchanged: HYG rows without a Gaia counterpart 12 352 -> 11 554 (ceiling 15 000; 10 886 before the naked-eye stars), cross-catalogue pairs under an arcsecond 23 -> 23 (ceiling 100). The gate's comment now accounts for the survivors by magnitude. gzip -9 sizes against the catalogue before both changes: stars.bin 4 711 922 -> 5 030 741 B, stars-meta.bin 2 576 213 -> 2 784 614 B, stars-index.json 3 724 855 -> 4 003 584 B (+806 KB, 7.3 %). Boot on the dev server, five interleaved cold runs: the task that indexes the catalogue after the data lands, median 1 072 -> 1 182 ms; HUD shown, median 2 622 -> 2 716 ms. This machine measured 0.82-1.30 s for the same baseline task today, above audit #25's 627-843 ms. The drawn-star budget is unchanged. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> |
||
|
SenrokaiandClaude Opus 5.5
|
c64eea0803 |
Keep every star the naked eye sees, Rigel, Deneb and Alnilam among them
The 250 pc cutoff took 1 543 of HYG's 8 920 stars of V 6.5 or brighter:
1 339 that both surveys put past it and 204 HYG has no distance for. Five
of the fifty brightest stars in the sky were gone (Rigel, Deneb, Alnilam,
gamma-2 Vel, Wezen), and Naos, Sadr, Aludra and Arneb with them, while
11th-magnitude Gaia stars at the same distance were drawn. The cutoff
bounds a download, not what the sky shows.
placementDistancePc now keeps a star of V 6.5 or brighter at any distance,
at the better of its two distances as before: Gaia's where the archive's
Hipparcos cross-match has a usable parallax, Hipparcos's otherwise. Gaia
saturates on the brightest, so Rigel (264.6 pc), Deneb (432.9), Alnilam
(606.1), Wezen (492.6), Naos, Sadr, Aludra and Arneb sit at their
Hipparcos distance. 1 502 HYG rows come back, 165 of the 206 without a
Hipparcos distance among them because Gaia measured them; 36 fold into a
Gaia entry. 41 naked-eye stars stay out because neither survey gives them
a distance: beta Phe, Polis, Mu Cep, Rho Cas, Eta Car, Alp Cam, Phi Cas,
Chi Aur, Psi-1 Aur, theta-1 Ori, Omi-1 Cen, 66 Ori, 16 Sgr, 10 Sge and 27
HD stars.
Measured on the rebuilt catalogue: 425 117 stars (+1 466), 8 301 of them
past 250 pc (+1 466), the same 336 within 10 pc and 3 652 within 25 pc.
Merge gate: 12 352 HYG rows without a Gaia counterpart (was 10 886; the
ceiling of 15 000 is unchanged, and its comment now counts the naked-eye
stars among the survivors) and the same 23 cross-catalogue pairs under an
arcsecond. Five more exoplanets find their host: HD 81817 b and c,
HD 158996 b, HD 208527 b, HD 220074 b. gzip -9 sizes: stars.bin
4 711 922 -> 4 728 315 B, stars-meta.bin 2 576 213 -> 2 587 977 B,
stars-index.json 3 724 855 -> 3 731 763 B.
The brief behind this also asked to cut once on the best distance, which
would drop the 6 835 stars Hipparcos puts inside 250 pc and Gaia outside.
Those already sit at Gaia's distance (
|
||
|
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 |
||
|
SenrokaiandClaude Opus 5
|
5dec528cee |
Size the distance rings by what the frame reaches, and keep their labels off the star names
From the review of #19. The rings are distances from the Sun, but their step was taken from `effectiveDistance`, which under the plan view means the extent of the frame rather than how far the camera is from the Sun. Centred on a star 200 pc out and flipped to 2D, the grid became rings of 2 to 20 pc: not one of them on screen. The step now comes from where the view is centred plus how far the camera is orbiting it, which is the same distance under either projection. The set was also rebuilt while the grid was hidden, and every rebuild disposes the rings and builds every vertex again; it now happens only while the grid is drawn. The ring labels went straight to the overlay: never culled to the frame, and free to land on a star's name. They now have to be on screen and clear of the names already placed, by half the separation two names keep — they are a ladder up one ray a twentieth of the screen apart, and holding them apart from each other would take "Survey edge" off the map. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi |
||
|
SenrokaiandClaude Opus 5
|
7971ec4007 |
Simplify: without a give-up the bisection can only have closed on the resolution
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi |
||
|
SenrokaiandClaude Opus 5
|
862fb65ea4 |
Tell a search that gave up from a route that is not there
The route search stops after MAX_VISITED stars and returned null, which everything downstream read as "the catalogue holds no chain". On the real catalogue that was wrong for real questions: Sol to HD 120147 (136 pc) at 5 pc is 50 jumps, and the panel said there was no route. The budget also sat under what the shipped catalogue needs, so it is now 40 000 rather than 20 000: both that route and a star at 170 pc are found, and Sol to HD 2626 at 6 pc, which used to be refused after 4.7 s, plots 56 jumps in about 2 s. A search now reports whether it gave up. The range search no longer counts a give-up as proof that nothing routes below it — that is what reported ranges up to 29% too wide — and it stops after two of them, since those are the probes that cost the most and settle the least: for HD 2626 at 3 pc it offers 5.92 pc in about 4 s, against 6.13 pc in 4.7 s. At the panel's widest range the refused route and the range search are the same question, so it is asked once. Where nothing can be said, the panel says "Too many stars to search at this range." rather than claiming there is no route. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi |
||
|
SenrokaiandClaude Opus 5
|
44f6a8d086 |
Refuse a Gaia answer that came back short, and read the body inside the retry
The merge gate asks whether Gaia contributed any stars, never how many. The TAP service truncates on its own timeout and still serves a well-formed CSV with a 200, ordered by magnitude — so a half answer is the bright half, which is the half HYG overlaps. Every gate passes: Gaia stars are present, HYG survivors go down rather than up, unmerged twins can only fall. The weekly job would publish a catalogue missing two hundred thousand stars and the runner would cache it for the weeks after. `fetchGaiaStars` now refuses fewer than 95% of the 412 765 rows its query holds, as its sibling query already did, and refuses an answer that fills the row limit. `fetchText` retried the request but not the body: a connection reset part-way through the 57 MB CSV rejected out of the loop, with no wait and no second attempt. The read now happens inside it. Also corrected: the merge gate's account of the HYG survivors (two thirds of them are stars Gaia measures but the main query never downloads, since Gaia puts them past the 250 pc cutoff), and the refresh workflow's comment on what happens when the archive is unreachable. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi |
||
|
SenrokaiandClaude Opus 5
|
b4017fcafc |
Merge pull request #28 from avalon-vanguard/perf/link-budget
Budget the jump-link layer in pixels of line, nearest the view's centre first Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi |
||
|
SenrokaiandClaude Opus 5
|
539a0f0a3e |
Answer the review: budget in drawn pixels, re-ask when the budget moves, sort only the band it runs out in
- The budget counted CSS pixels; lines are drawn in device pixels, so a screen scaled to 150% or 200% drew 1.5-2x the calibrated line. It now counts the canvas's drawn pixels. - A graph was re-asked only when the drawn stars changed, so with a star budget covering the whole catalogue, or a resize, its budget and centre stayed wherever the layer was turned on. A view that chose its stars again now asks, and a graph is rebuilt when the stars, the range or the budget changed (the budget by more than half the margin, or its centre by more than 5 pc). - From inside a system the budget was worked out in astronomical units about the system's origin. Graphs are now asked for in parsec space only; the flight back out asks. - Comparing budgets let a request re-asked with a slightly different one supersede its twin, and the twin's rejection cleared the state of the request that replaced it. A rejection now clears it only for the latest request. - The worker sorted every link to keep a few thousand, 2.2x an unbudgeted build. It now bands links by distance, keeps every band before the one the budget runs out in, and sorts only that one: 142-168 ms on the real catalogue against 233-388 ms, 103 ms unbudgeted, returning early when all fit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi |
||
|
SenrokaiandClaude Opus 5
|
bd5e9d4b0d |
Budget the jump-link layer in pixels of line, nearest the view's centre first
With the drawn set following the view, the layer at 8 pc cost the integrated Radeon 503 ms a frame at 30 pc from the Sun. Measured, the cost follows the length of line on screen (about 10 ms per million pixels near the Sun), not the number of links: 100 000 links were 12 ms at the opening view, 25 000 were 61 ms at 30 pc. So the budget is a length: a million pixels, turned into parsecs at the depth the view is centred on, spent on the links nearest that centre by their nearer end. Orbiting with links at 8 pc on the iGPU: 12-18 ms p50 at every pose measured, no long tasks. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi |
||
|
SenrokaiandClaude Opus 5
|
45d5209433 |
Merge pull request #27 from avalon-vanguard/feat/drawn-set-in-view
Draw what the camera shows: the budget goes to the stars in view Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi |