Transients in the Palomar Observatory Sky Survey

[HoaxEye]

Interesting, it seems @Brian Dunning is saying the study/paper showing a positive correlation between detected transients and nuclear testing was based on just 9 transients?!:

The Skeptoid episode is not accurate about the publication history and misattributed the origin of the nine transients.

The nine transients were actually introduced in a June 2021 paper, "Exploring nine simultaneously occurring transients on April 12th 1950" (Villarroel et al.). The Hambly and Blair rebuttal paper (2024) was written specifically to analyze and refute the nine transients from that 2021 paper, not the later 2025 ones.

Edit: this nine-transient issue does not invalidate the podcast conclusions. We cannot rule out plate defects without physical microscopic validation of the original glass plates.

Btw, the nine transients were apparently dropped silently from the candidate list. Before 2025 papers, they introduced "triple transients" in MNRAS 2024 (https://doi.org/10.1093/mnras/stad3422) by Solano et al. At this point they used the automated software pipeline (Solano et. al. 2022), and the published list of 5,399 candidates. The current "107K" candidate list originating from the same software pipeline was selected as the primary list in later papers. It's currently the most referenced and discussed candidate list, but it has never been published.

 

[NorCal Dave]

The Skeptoid episode is not accurate about the publication history and misattributed the origin of the nine transients.

Yeah, when I first heard it, it seemed to say the 9 were used to argue the nuclear testing correlations. But in reading the transcript, I think it just gets jumbled up.

As you noted, there's multiple papers, with multiple changing lists and multiple claims, but the most important data, the actual transients date, time and location, are never shared.

The details and intricacies are to complicated for the Skeptoid short form, so the main claims are highlighted as well as the major problems.

 

[HoaxEye]

Update on my "Vasco60" work. I have been working on a slightly different version of the pipeline for some time. Code is not yet public.
Also testing whether a looser, more permissive version can approach the third-party ~107K-scale candidate list.

Checked so far:
- Raw source detection recovers ~99% of the third-party list's rows. Detection sensitivity is not the issue. I've identified a more suitable sextractor parameter set using only one-pass call, without PSFex step. However, this doesn't matter as much as the "naive" tessellation method where plates are downloaded fully, including the edge areas that were excluded earlier
- Most of the gap between "strict pipeline" and "third-party list scale" comes from two places: how much sky area gets covered, and the Gaia/PanSTARRS/USNO-B cross-match veto stage. The veto stage is working correctly
- Testing suggests the strict pipeline, once matched for the same sky coverage, lands roughly in the right ballpark of scale. Early result, not fully validated yet

Unexpected finding (also early result, not fully validated yet):
- The third-party list's plate identifiers appear to have real errors on some plates. A meaningful fraction of rows are tagged with the wrong originating plate. Observation dates could be therefore partly wrong, too

Current status:
- Moved from single-plate pilots to processing plates one at a time across the sky, with checks at every stage
- I'll share more once there's a broader, more solid full-sky picture.

 

[jdog]

Daniel and Kelly's Extraordinary Universe did a July 6, 2026 podcast on the transients: Did aliens put satellites into Earth's orbit pre-Sputnik?

The scientist hosts are Daniel Whiteson, professor of experimental particle physics at the University of California, Irvine, and a fellow of the American Physical Society, and Kelly Weinersmith, who studies parasites that manipulate the behavior of their hosts, and is an adjunct faculty member in the BioSciences Department at Rice University.

I don't know how much new material there is, but there's a lot of discussion of follow-up research on the original claims, such as Watters, et. al. at https://arxiv.org/html/2601.21946v1, with a focus on the fact that the transients team hasn't been particularly forthcoming with their data or their code and that when other people people run the numbers and do rigorous analysis the statistical significance of the apparent non-appearance in earth's shadow and the nuclear test date correlation really diminishes.

From the transcript, Whiteson sums up that the data (and its provenance) wind up being too messy to draw any conclusions: "I haven't given up exactly, but you know, if we don't have solid evidence that we can rely on, then you know, we can't say there aren't aliens, or that there weren't alien satellites observing our nuclear testing or whatever. But we can't say that there were."

 

[JMartJr]

Whiteson sums up that the data (and its provenance) wind up being too messy to draw any conclusions: "I haven't given up exactly, but you know, if we don't have solid evidence that we can rely on, then you know, we can't say there aren't aliens, or that there weren't alien satellites observing our nuclear testing or whatever. But we can't say that there were."

Being unable to prove a negative is not significant, though. Of course you can't do that. The significant bitil is the statement that the data does not prove the hypothesis under discussion...

 

[HoaxEye]

Checked so far:
- Raw source detection recovers ~99% of the third-party list's rows. Detection sensitivity is not the issue. I've identified a more suitable sextractor parameter set using only one-pass call, without PSFex step. However, this doesn't matter as much as the "naive" tessellation method where plates are downloaded fully, including the edge areas that were excluded earlier
- Most of the gap between "strict pipeline" and "third-party list scale" comes from two places: how much sky area gets covered, and the Gaia/PanSTARRS/USNO-B cross-match veto stage. The veto stage is working correctly
- Testing suggests the strict pipeline, once matched for the same sky coverage, lands roughly in the right ballpark of scale. Early result, not fully validated yet

Unexpected finding (also early result, not fully validated yet):
- The third-party list's plate identifiers appear to have real errors on some plates. A meaningful fraction of rows are tagged with the wrong originating plate. Observation dates could be therefore partly wrong, too

Current status:
- Moved from single-plate pilots to processing plates one at a time across the sky, with checks at every stage
- I'll share more once there's a broader, more solid full-sky picture.

Quick update: I have now reached 84% recall rate compared to VASCO. I still have about 17K tiles to download and process, so the recall rate should hit at least 90%. That's a pretty good number.

The unpublished third-party list "V" (107K rows) does not contain coordinate/plate/date errors like the early results indicated. I double-checked everything against two download services: STScI and ESO. All coordinates have correct plate identifier, and the observation date/time.

Naive tessellation plan was not naive enough. It leaves gaps - meaning tiles that should have been downloaded. I added them to the working queue once I realized the gaps. The root-cause was the "smart tessellation" plan of Vasco60. I decided to re-use it, and just try to make it more "naive". Bad decision. I should have rewritten the whole tessellation module from scratch. Because the original code avoids plate edges and tries to avoid overlapping, it's not easy to make it naive by altering the plan only.

I also dropped the 30' circular cut described in MNRAS 2022. If code performs this cut, the pipeline will not reach a good recall rate.

The end result after basic pipeline process is currently 228 628 rows. It will grow after data from 17K additional tiles lands. But this number is not the "final survivor count" - like VASCOs unpublished "V" dataset (107K). Survivor count is subject to number of post-process veto-stages, which will reduce the number dramatically - depending on what kind of veto stages are used. I haven't made final decisions, but many trials. With four heavy veto-stages, the number went down to 11 341 rows.
VASCO's own ML ensemble shows that their V contains only 10-20% valid, star-like objects. I can't implement this kind of ML veto, because it is not public.

I've tested many things to rule out possible problems like tessellation using Aladin app (as mentioned in MNRAS 2022) - this was a disaster. Using ESO or STScI as the source for fits cutouts turned out to be interesting and time-consuming. I was surprised to learn they return different coordinates and slightly different FITS headers. ESO sometimes returns cutouts from different surveys (especially when DEC <=0) without warning. And many ESO tiles contain more garbage than STScI tiles. MNRAS 2022 mentions ESO as source, but later papers also mention STScI. I have no idea where they downloaded the basic data, because Vs coordinates don't match with ESO or STScI.
I also tried using locally mirrored full plate scans, but that's really not feasible.

I tested a large amount of source extractor and psfex configuration values. Even the silly "PHOTO"-mode which will crash the software or just give really bad results. I asked AI to review the full sextractor source code to identify the variables that will cause either more or less detections - this was genuinely interesting, but at the end, my original sextractor/psfex config didn't change that much.

This has been a difficult exercise. VASCO team members often speak about independent replication. Because it is important in science. But because they decided not to publish code, configurations, and not much data either, independent replication becomes a mission impossible. I'm pretty sure that 100% parity cannot be reached with the currently published material. It seems I will reach a good main dataset recall rate, but even that is not going to be enough. Results can be disputed just by saying "you don't have the same configuration or sky coverage" - even without evidence (meaning published sw/configs, and datasets). But I will finish this project and publish the code and results.