You have to check now and then to see if the sequences have changed. Changes are rare most likely, someone found an error, or a comp was dropped for some reason, or a comp was found to be variable. The T CrB sequence underwent some changes a few years ago for example and if I remember there was some discussion here on the forum about it–T CrB WAS a “popular girl” (an olde song by the band Survivor btw)!
If you find a sequence changed you’ll have to decide if the change would require you to reprocess your photometry, delete the old data from the db, and upload the new.
p.s. This is also a reason why one should compute and routinely check your check stars, check star against another check star, etc. It is always good to look at your photometry in a plot to see if everything makes sense.
AAVSO apparently has no protocol for addressing the consequences when comp star magnitudes are changed - the revisions happen silently. I discovered a serious error in the I magnitude of 000-BQL-490 (a comp used for ASASSN-17cf). The bug was fixed but no effort was made to alert the community to the problem, which amounted to over a magnitude. The bad value is still being used by those who got charts before the change. In the case of T CrB, the B magnitude of 000-BJS-901 was changed by over 0.1; observers are unaware of the change.
These examples were not mere tweaks - they called for revisions to submitted photometry. The observers who reported their comparisons in the 000-XYZ-123 format are discoverable in the AID and could be directly contacted. This is a reason not to use the old-style identifiers (eg: “98”, “106”). It is also a reason not to use ensembles, the makeup of which cannot be determined from the AID records.
The T CrB sequence was updated and improved in early July, 2024. The original sequence was very poor and the decision was made to revise it to improve the photometry. For example, two observers might have used two different comp stars, and one might think an outburst had started when it was just poor comp star photometry. There were posts to the forums that announced this change.
As far as I know, it would be very difficult to implement version control, because the comp star database is based on position in the sky and not association with some target. The sequence team may get a request for a sequence around some object, but the name of that object is NOT included in the database, because the intent was for good comp stars to be used for other nearby objects. Since the AAVSO does not require all comp stars in an ensemble to be listed in the report, it would be nearly impossible to notify all observers of changes in individual stars. As James comments, it is wise to update your charts on a regular basis.
Lately, I’ve been having fun creating programs using AI tools like Claude. I’m not volunteering (yet), but it seems it would straight forward to create a tool that a user could specify a target star, and/or which comparison stars he uses, and re-query VSP for the latest values, and flag when something has changed. If I wrote this, it would be a Python program (probably targeting Windows) that a user would download and run locally. Maybe a setting to automatically periodically look for differences and notify the user when something he cares about changes.
As some of you may know, I attended the Accurate Flux Calibration in the Era of Space Astronomy and All Sky Survey workshop in October 2024. As part of that program, I gave a talk describing AAVSO’s photometric reference frame and the multitude of issues that we encounter getting good photometry in our system-of-systems approach to data collection.
An interesting take away from that workshop is that some scientific use cases now require better than 1% absolute flux calibration for spectroscopy. While none of these use cases are in our traditional wheelhouse, the broader desire for more accurately calibrated photometry is clearly coming down the pipe.
Unfortunately, this is a very complicated problem that is not easy to solve. At present, we’ve put it on the back burner while we address other challenges.
@tcalderw You’ll be happy to know that the database backing VSP keeps track of revision information. Until this forum thread, there hasn’t been much of a desire for access to this data. Rather than issue a continual stream of changes, we’d prefer for people to check their charts annually and denote the chart revisions at submission time.
@Joseph_H_Ulowetz please don’t implement software to query VSP for potential chart changes. The software isn’t designed for this use case and it would likely negatively impact the performance of VSP for other users.
(an olde song by the band Survivor btw)!