What's In My Sky

1. The three-panel layout

• Left panel — Location & Time (lat, lon, date, time, timezone, min altitude), Catalog checkboxes, RA/Dec format toggle (decimal vs H:M:S), Local Sidereal Time readout, and a Moon widget with phase %, phase image, rise, transit, and set times.
• Middle panel — Object Type filter: a scrollable checkbox list populated from the catalog's actual Type column. All/None toggle at the top, selection persists across sessions. Useful for narrowing "every PGC galaxy fainter than mag 15" out of the way.
• Right panel — Toolbar (Add Object, Save CSV, Search Object, Horizon, Field Rotation, Settings), sort-mode row (Closest to Transit vs Best Nightly Score), and the results tree with 14 columns including Score and Community.

2. Location & Time inputs

• Latitude — decimal degrees. Accepts suffix N/S (30N, 45.5S) or signed values.
• Longitude — decimal degrees, East positive, West negative. Accepts suffix E/W (87W, 45E) or signed values.
• Date — YYYY-MM-DD. Defaults to today.
• Time — HH:MM local time (observing time, not now).
• Time Zone — all IANA timezones (America/Chicago, Europe/Berlin, Australia/Sydney, etc.).
• Min Altitude — floor cut in degrees; objects below this are dropped from the list. 20° is a reasonable default for imaging, 30° for serious work. Overridden per-azimuth by the custom horizon if one is defined (whichever is higher wins).

3. Catalogs and type filters

Check the catalogs you want to include. SASpro ships with: Messier (110 objects), NGC, IC, Caldwell, Abell (galaxy clusters), Sharpless, LBN (Lynds Bright Nebulae), LDN (Lynds Dark Nebulae), PNG (planetary nebulae including PK cross-reference), Arp (peculiar galaxies), plus User (your own objects).

The middle-panel Object Types filter further narrows by what the catalog's Type column says — Galaxy, Open Cluster, Globular Cluster, Planetary Nebula, Reflection Nebula, Emission Nebula, Supernova Remnant, Dark Nebula, and so on. The filter is additive with catalogs: checking "Messier" and type "Galaxy" gives you just M31, M51, M63, M64, M65, M66, M74, M77, M81, M82, M83, M84, M85, M86, M87, M88, M89, M90, M91, M94, M95, M96, M98, M99, M100, M101, M102, M104, M105, M106, M108, M109, M110.

4. Sort modes

• Closest to Transit (default) — ordered by absolute minutes to transit. Everything the sky is pointing at right now, roughly. Fast to compute.
• Best Nightly Score — ordered by the full observability score for the full night. More expensive (one astropy coordinate transform per candidate across 144 time samples), but gives you the actually-worth-shooting ordering. The tooltip warns "Filter catalogs/types recommended — can be slow" because scoring every PGC galaxy at every timestep adds up.

5. The results tree

14 columns, sortable by any:

1. Name — primary catalog identifier.
2. RA — right ascension, decimal degrees or H:M:S depending on the RA/Dec format toggle.
3. Dec — declination, decimal degrees or D:M:S.
4. Altitude — degrees above horizon at the specified time.
5. Azimuth — compass bearing (0 = N, 90 = E, 180 = S, 270 = W).
6. Min→Transit — minutes until the object transits the meridian.
7. B/A Transit — Before or After. If After, the object is already past meridian for tonight.
8. °from Moon — angular separation from the Moon.
9. Alt Name — secondary catalog name (e.g. "Andromeda Galaxy" for M31).
10. Type — object type (Galaxy, Planetary Nebula, Open Cluster...).
11. Magnitude — visual magnitude where known.
12. Size (arcmin) — angular size, usually major × minor. Abell clusters show galaxy count instead.
13. Score — 0-100 observability score for tonight.
14. Community — ✓ (green) when the object falls inside a published footprint on the Seti Astro Community Atlas (fetched in the background from the atlas CDN; the mark appears a few seconds after Calculate finishes).

Sort by any column (click the header). Size column is smart: 12.0 x 8.5 sorts by the larger dimension, Num Galaxies: 51 sorts by galaxy count, plain numbers sort numerically.

6. The Weekly Score chart (right-click → Weekly Observability Score…)

A ±7-day chart of the object's observability score centered on your target date. Each day gets a blue bar whose height is the score (0-100), overlaid with the score as a yellow line + markers, with the moon-phase % drawn as a semi-transparent grey backdrop behind each day (new moon = transparent, full = opaque). The target date is marked with a red dashed vertical line. The subtitle names the weighting breakdown — 40% altitude quality · 35% moon avoidance · 25% imaging window — so you can see at a glance whether a bad night is bad because the moon is up or because the object is too low.

7. Full Year Analysis (right-click → Full Year Analysis…)

The deep one. A 365-day score sweep starting from your current date, split across up to 12 parallel threads (one per month, roughly). The result opens in a 4-tab dialog:

• Monthly Overview — bar chart of per-month average score, colored by score (red = poor, green = good), with a yellow dashed line marking the best month. A faint daily-score line overlays the whole year to show within-month variation. Best night and best month are called out in the header with badges.
• Best Night (date) — altitude curve for the single best scoring date, with twilight bands, moon trace, horizon limit overlay (if a custom horizon is set), peak-altitude marker, azimuth compass labels along the track, and the imaging-window hours.
• Tonight (date) — the same curve for tonight, for comparison.
• SIMBAD Details — main ID, object type, V/B magnitude, spectral type, angular size, radial velocity, redshift, coordinates.

Bottom buttons give you Full Visibility Dialog, Open in Aladin, Finder Chart, and Field Rotation (all pre-filled from the best night so the rotation night-curve plots immediately).

8. The Visibility dialog (right-click → Altitude / Visibility Plot…)

Full altitude curve for the selected object on the selected date, in local time with the plot running noon → midnight → noon (so a transit at 02:00 shows cleanly). Four tabs:

• Altitude & Visibility — the plot itself. The sky background fades through five brightness bands at the actual sun-altitude crossings: daylight → civil twilight (sun > -6°) → nautical twilight (-6° to -12°) → astronomical twilight (-12° to -18°) → astronomical night (-18°). Linear interpolation between adjacent samples places the band edges exactly on the crossings, so twilight bands line up with the real transition times. Object altitude is yellow, moon altitude dashed grey. If a custom horizon is defined, the blocked zone shows as a red translucent fill overlay. Compass labels (N, NE, ENE, E…) are drawn along the object track at ~2-hour intervals.
• Rise / Transit / Set — rise/transit/set times, peak altitude, imaging window in hours (above 20° during astro night), moon interference hours during the imaging window, and the night's astronomical and nautical twilight boundaries. Circumpolar objects say so; always-below-horizon objects say so.
• SIMBAD Details — background query, cached. Returns main ID, type, V/B magnitude, spectral type, angular size, radial velocity, redshift. Tries multiple name variants (bare, no-space, catalog-prefix-normalized, PK↔PN-G, Abell→ACO expansion) plus a TAP ADQL fallback for anything query_object misses.
• Planet Separations — angular distance from each major planet (Mars, Jupiter, Saturn, Venus, Mercury, Uranus, Neptune) at local midnight. A ⚠ close! flag appears when separation < 5°.

9. The Custom Horizon Editor (🏔 Horizon…)

Where WIMS stops being generic and starts knowing your actual site. Opens an interactive azimuth-vs-altitude plot:

The horizon profile linearly interpolates between your points, with wrap-around from 360° back to 0° handled correctly. Once defined, the horizon:

• Replaces the single Min Altitude threshold in Calculate — each object is only kept if its altitude at its azimuth exceeds max(horizon(az), min_alt).
• Draws as a red filled overlay in every visibility and best-night altitude plot.
• Changes the scoring: the "above 30°" quality bar becomes "above max(horizon(az), 30°)" at each timestep, and the "above 20°" imaging window becomes "above max(horizon(az), 20°)". A trailhead you can only see while it clears your east-facing treeline gets a lower score than a northern-circumpolar one you can see all night.
• Shows an "Effective above horizon" hours figure alongside the "Imaging window" figure in the Full Year altitude plots.

10. The Object Search dialog (toolbar → Search Object…)

Full-catalog search by name, with smart matching:

• Catalog prefix normalization — M42, M 42, m42 all match the Orion Nebula. Same for NGC, IC, UGC, PGC, ACO, LBN, LDN, SH2, PNG/PN-G, PK, Abell, Arp.
• Alt-name search — matches on both the primary name and the alt-name column, so Andromeda Galaxy finds M31, Pleiades finds M45, Squid Nebula finds OU4 (if in your catalog).
• Partial match — abell 1242 matches the full "Abell 1242" entry even if the catalog spells it "ACO 1242".
• Manual RA/Dec… button for objects not in any catalog. Accepts decimal degrees, 5h26m31.2s / 60d03m00s, or 5:26:31.2 / 60:03:00 colon-separated; Dec prefix − for south.

Double-click a search result (or hit Analyse Selected Object…) to run the full-year sweep on it. This is the backdoor to full-year analysis for objects that aren't in your tree — you don't need to Calculate first, just search and go.

11. Workflow recipes

12. Credits

Technical details

13.1. The observability score

Three weighted components, each clamped to [0, 1], combined and scaled to [0, 100]:

Each component is computed from a 144-sample grid spanning noon to the following noon (10-minute resolution). The altitude quality and imaging window components are both fractions of astronomical night where the object clears a given altitude:

If no astronomical night exists at the given latitude on the given date (polar summer), both components are 0 and the score is 0.

13.2. The moon component

Combines angular separation and lunar phase so a full moon 30° away is worse than a crescent 30° away, and a new moon anywhere is near-perfect:

where Δ_moon is the angular separation of the target from the moon (clamped at 90°; farther doesn't help) and P is lunar phase as a percentage of illumination. The (0.5 + 0.5·φ) term floors the moon contribution at half-value even for a full moon — because angular separation alone still buys you something — and ramps linearly to full value at new moon.

13.3. Lunar phase from solar elongation

Phase percentage is derived from the Moon-Sun elongation using the standard illumination formula:

where E is the angular separation of the Moon and Sun as seen from Earth. Waxing vs waning is determined by whether the elongation is increasing or decreasing six hours later; this picks the correct phase image from the 23-image set (new, waxing/waning crescent 1-5, first/last quarter, waxing/waning gibbous 1-4, full).

13.4. Local sidereal time and minutes to transit

LST is computed from astropy's Time.sidereal_time("apparent", lon), which accounts for nutation and precession:

An object transits (crosses the meridian) when its RA equals the LST. The time to transit, in hours, is:

WIMS converts to minutes and splits "Before/After": if Δt > 12 h, the object transited earlier and the displayed value becomes 24 − Δt (as a positive "minutes since transit"), with the B/A column marked "After":

13.5. The custom horizon

Internally stored as a sorted list of (azimuth, altitude) control points. The horizon altitude at an arbitrary azimuth is linear interpolation between the two adjacent points, with wrap-around from 360° back to 0° handled by injecting an implicit point at (360°, h(0°)) if the user's rightmost point sits below 360°, and (0°, h(360°)) if the leftmost sits above 0°:

The effective minimum altitude at each azimuth is the elementwise max of the horizon and the configured min_alt floor:

When scoring with a custom horizon, the quality and window masks become per-timestep horizon-aware:

so a target that peaks at 45° altitude but spends most of its time behind an eastern treeline gets a lower score than its naive altitude curve would suggest.

13.6. Twilight thresholds

Standard astronomical definitions, used throughout the plot bands and the scoring night mask:

Visibility plots show four distinct bands (daylight, civil, nautical, astro night) with their edges placed at the exact linear-interpolated crossing times — not sample-grid-rounded — so the bands align with the real transition moments.

13.7. Azimuth-to-compass labeling

Compass labels along the altitude plot's object track use 16-point rose spacing:

with the +11.25° shift centering each 22.5° arc on its label (so az = 0° reads "N", not "NNE"). Labels are placed every ~2 hours along the track, with a 1.5-hour minimum horizontal spacing to prevent crowding, and skipped when altitude is below −5° (object below horizon).

13.8. Timezone vs longitude consistency

WIMS compares your timezone's UTC offset Δt_UTC against your longitude λ. The timezone's "central meridian" is:

A warning fires if the signs disagree or if |λ − λ_c| > 45°. For bare-sign-mismatch cases (user entered a bare "87" longitude without E/W suffix and the sign is wrong for their timezone), WIMS auto-flips the sign — this handles the common US-user "I put in positive 87 but I'm in Chicago" case. For other inconsistencies the warning is informational and the calculation proceeds with the entered values.

13.9. SIMBAD name resolution

The SIMBAD lookup tries each of these name forms until one hits:

1. Primary name as-is.
2. Primary name with whitespace removed.
3. Primary name with catalog-prefix space-normalized (NGC891 → NGC 891).
4. Alt name variants (same three transforms).
5. PK ↔ PN-G cross-references: PN-G 064.6+48.2 is tried as PK 064.6+48.2 and PK064.6+48.2, and vice versa.
6. Abell → ACO expansion for Abell cluster names.
7. If all query_object attempts fail, a direct TAP ADQL query against SIMBAD's basic table joined on ident catches identifiers query_object doesn't surface.

Returns main_id, otype, V/B magnitude, radial velocity, redshift, spectral type, and major/minor galdim axes where available. Missing fields render as — rather than failing the whole lookup.

13.10. Chunked parallel scoring

For both the tonight-ranking (Best Nightly Score sort) and the full-year analysis, scoring is split across a thread pool. Chunk sizes are computed as:

• Workers: max(4, min(cpu_count // 2, N)) — half the CPUs by default, floored at 4, capped at the candidate count.
• Chunk size: max(10, ⌈N / workers⌉) — big enough that per-chunk setup cost (astropy state construction) is amortized.
• For the 365-day sweep, chunks are per-month (31-day slices), run in up to 12 parallel threads.

Each worker constructs its own pytz, Time, EarthLocation, and AltAz frame locally — no sharing of astropy objects between threads, which would be undefined behavior under the GIL for the C-extension bits. Results are stitched back together in deterministic order.

13.11. Catalog loading

Two independent sources:

• Bundled catalog at data/catalogs/celestial_catalog.csv, loaded read-only. ISO-8859-1 encoding (handles accented author names in alt-name fields).
• User catalog at ~/saspro_user_objects.csv, UTF-8, created on first Add Object…. A one-time migration from an older in-home-dir celestial_catalog.csv (where user objects used to be appended into the bundled catalog) extracts rows with Catalog == USER and seeds this file.

The two frames are concatenated at load time with user rows always marked Catalog = "User", so the User checkbox in the UI exclusively shows your own objects regardless of what the row data said.

13.12. The Community Atlas footprint test

The atlas catalog.json is fetched in a background thread with a 3-attempt retry (1.5 s between tries, 8 s per-request timeout). Each entry carries either four corner RA/Dec points or a center + FOV width/height. For the corner form, a point (RA, Dec) is "inside" when:

• min(dec_corners) ≤ dec ≤ max(dec_corners), and
• the RA bracket contains the point, with wraparound at 0°/360° handled by checking whether the corner-span exceeds 180° (which signals a wrap-crossing footprint, where "inside" means ra ≥ ra_min OR ra ≤ ra_max).

Fast enough to test thousands of catalog rows against a small atlas index per Calculate. The tick appears in the Community column a few seconds after Calculate finishes.