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.

 

[Carlo]

Incredible work and dedication. Thank you for taking the time to do this.

 

[yoshy]

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.

Doing peer review for no reason other than curiosity is one of the reasons I love this community!

I might have asked you this already, so apologies if I'm repeating myself, but do you have a GitHub you're willing to share?

 

[FatPhil]

I might have asked you this already, so apologies if I'm repeating myself, but do you have a GitHub you're willing to share?

https://github.com/jannefi/vasco/

 

[FatPhil]

Incredible work and dedication. Thank you for taking the time to do this.

Janne exemplifies why I fell in love with Finland and the Finns so many years ago (I've spent 20% of my life there). And, despite the praise and adulation being bestowed upon him for his stick-to-it-iveness, I can assure you (with very high probability, as I don't actually know him personally) he's not doing it for the praise - he's doing it because it's a problem he wants to see cracked, and by heck, he won't stop until he's cracked it, or it's cracked him.

However, he's probably terrible at rock paper scissors (which is an in joke that perhaps only a tiny fraction of the world will get, but almost all of them are Finns, prkl).

 

[HoaxEye]

https://github.com/jannefi/vasco/

https://github.com/jannefi/vasco60 is better starting point, but it is not the one I'm working on now. That's still private for the time being. New version re-uses majority of "vasco60" code, but there are some bigger changes. I'll make it public once I finish the first data release.

@FatPhil nailed it: I'm not doing this for praise. I really must get this done (prkl) Current obstacle: my PC started freezing for no clear reason in the middle of data run. OS is Debian 13 so it should be stable. Hardware is fine. There is still enough disk space. Simple reboot/disk check was not enough.

 

[NorCal Dave]

https://github.com/jannefi/vasco60 is better starting point, but it is not the one I'm working on now. That's still private for the time being. New version re-uses majority of "vasco60" code, but there are some bigger changes. I'll make it public once I finish the first data release.

@FatPhil nailed it: I'm not doing this for praise. I really must get this done (prkl) Current obstacle: my PC started freezing for no clear reason in the middle of data run. OS is Debian 13 so it should be stable. Hardware is fine. There is still enough disk space. Simple reboot/disk check was not enough.

It's been great following along with you, even if I don't understand 75% of what you're talking about, at least with the coding. While I think most of us have a general understanding of what the VASCO project was, I did have a couple of questions.

1. Is there a way to give quick, but dumb down version of what your doing for us non-coders? Don't want to waste your time, but I don't think I'm the only one that has no idea what this means:

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 know it's important to note these things as part of your project, I'd just like to understand a bit of what's going on.

2. Is it possible for any of us to help? As noted, I'm no coder but during the day I have Mac sitting in the office doing nothing. Is there any way I, or others, can run or process batches of data for you on the side?

Again, and I think I speak for many here, this is an incredible effort. Hats off to you. Look forward to your final conclusions.

 

[yoshy]

https://github.com/jannefi/vasco60 is better starting point, but it is not the one I'm working on now. That's still private for the time being. New version re-uses majority of "vasco60" code, but there are some bigger changes. I'll make it public once I finish the first data release.

Thanks for the link! Awesome work!

@FatPhil nailed it: I'm not doing this for praise. I really must get this done (prkl) Current obstacle: my PC started freezing for no clear reason in the middle of data run. OS is Debian 13 so it should be stable. Hardware is fine. There is still enough disk space. Simple reboot/disk check was not enough.

Two things to check off the top of my head:
- are you using multi-threading or multi-core processing? If yes, leave at least one thread/core available for the OS
- RAM: are you maxing that out?

 

[HoaxEye]

It's been great following along with you, even if I don't understand 75% of what you're talking about, at least with the coding. While I think most of us have a general understanding of what the VASCO project was, I did have a couple of questions.

1. Is there a way to give quick, but dumb down version of what your doing for us non-coders? Don't want to waste your time, but I don't think I'm the only one that has no idea what this means:



I know it's important to note these things as part of your project, I'd just like to understand a bit of what's going on.

2. Is it possible for any of us to help? As noted, I'm no coder but during the day I have Mac sitting in the office doing nothing. Is there any way I, or others, can run or process batches of data for you on the side?

Again, and I think I speak for many here, this is an incredible effort. Hats off to you. Look forward to your final conclusions.

Thank you. Bit longer answer, hopefully less-technical/coding:

What "tessellation" means. You can't process the whole sky in one go, so you chop it into small squares and process them one at a time. That chopping-up is the tessellation. Think of it as laying a chessboard grid over the sky and handling one square at a time.

Why test Aladin: it's a Java sky atlas app: https://aladin.cds.unistra.fr/ MNRAS 2022 contains text that they tessellated the sky using Aladin and its scripting capabilities. I don't think they did that at full-sky scale. But Aladin is definitely worth a look.

Why that turned into a disaster. Here's the part that isn't obvious. The sky was photographed as ~600-odd overlapping plates, each covering roughly a 6°×6° patch. When you ask an online archive "give me a picture of this spot", the archive decides which plate to serve it from — and that decision depends on the exact coordinates you asked for. So two neighbouring squares in my grid could come back cut from two different plates: different night, different glass, different exposure, different flaws.

An analogy: imagine mapping a country from old aerial survey photos that overlap. You ask an archive for "the view at this address" and it hands you whichever photo it thinks is best. Fine for looking at one address. But if you're trying to check "what appears on photograph #524", you now have a mixture of photos and no reliable way to know which is which.

That's why finer or cleverer grids don't rescue it. I tested that. It isn't a flaw in my grid - it's a property of how the archive answers requests. No amount of re-tiling gets around it.

The ESO vs STScI part. Those are two separate archives that both serve this same survey. Same sky, same original plates - but they don't always hand you the same image, and the coordinate information attached to those images can differ. Working out where they agree, where they don't, and which to trust ate a lot of time.

Related, and my favourite find: the scanned plate files contain two different sets of coordinate instructions, and different astronomy software silently picks different ones. On about a third of the plates the two disagree by roughly 2.3 arcseconds. That's tiny — about the width of a human hair at arm's length — but it's plenty to make "is this 1950s dot the same object as that modern one?" come out wrong. It had been quietly skewing my results, and nothing errors out; you just get slightly wrong answers.

What I do now. Instead of asking an archive for small cutouts, I download the entire plate scan (they're public, and addressed by plate) and cut the squares myself. Now I know exactly which plate every square came from, because I chose it. That change is the whole reason for the new repository (I'm publishing the code today). Using full plate scans is perhaps the only way to achieve comparable sky coverage.

What this does and doesn't show. It finds dots on old plates with no modern counterpart. That's a statement about two catalogues - not evidence of anything exotic. The interesting question is what the leftovers turn out to be, and that work is ahead of me. Mostly I'm trying to make the method something anyone else can run and check, using only public data, which is not currently true of the original MNRAS/VASCO work.

Appreciate the offer for help. I have all the data I need, and my PC is now re-processing all full plate scans. One problem is the disk space requirement: I have used 8 terabytes in various runs and tests. I bought a separate large HDD for this reason, and use the PCs internal SSD for operations that require disk speed. Many experiments/trials were such that they needed a lot of disk space. Turned out that a single or multiple plate-level tests were not enough: I simply had to do full sky tests/trials. This is because there are plate-level differences that do not show up without full coverage. I ended up doing plate-level corrections and tunings. More about that in the new repository.

 

[HoaxEye]

Thanks for the link! Awesome work!

Two things to check off the top of my head:
- are you using multi-threading or multi-core processing? If yes, leave at least one thread/core available for the OS
- RAM: are you maxing that out?

Thanks! I'm using multi-core processing. And yes, I used too much RAM in this case. It was a weird, almost silent process group OOM crash. This was related to reading local USNO-B mirror, and the code was just trying to keep too much in RAM. Fix was simple as usual

 

[HoaxEye]

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.

Major update: new repository is now public, see: https://github.com/jannefi/poss1-plate-slice/tree/main Results are not in yet - it takes perhaps a week or more to re-process and calculate everything.

I ended up implementing data collection using full plate scans, because the download/cutout services (STScI and ESO) have a ceiling. It's very difficult to go around that. The MNRAS parity using STScI and "dummy tessellation" is max 84.2833%. If you want to get over 95%, you must download tiles around known objects (about 16,942 excess tiles). But the known objects are not public so this is not doable. Independent replication becomes impossible, or at least limited. Full plate scans can achieve good enough coverage without any unpublished object catalogs. Anyone can independently reproduce this because all data is public.

Slicing full plate scans turned out to be challenging. For example, there are plate-specific astrometric differences. I think this version is now correct and contains scripts that measures the per-plate offset between two astrometric solutions and applies it during runtime.

The project documentation contains more details. I had to restart the full-sky campaign again just to be sure that results are not affected by one or more test runs I've been doing recently. This is a slow step. It will take perhaps a week or more before I have reliable/verifiable results. I will publish the results, and the candidate datasets once the fun finishes.