Wed, 11/30/2016 - 15:35
I just downloaded the photometry tables for my targets, and see that for V1687 Cyg, no fewer than six of the seven stars I use in my ensemble have changed photometry. It seems obvious that I should go back and re-analyze all my data for that star, but I am wondering if there is any mechanism in place for warning observers that their results have been invalidated by new comparison star photometry. For instance, it would be useful to know whether the sequence changes have been extensive (as in the case of V1687 Cyg, for example) or minor (as in the case of EG And, for example). Obviously we cannot count on HQ to alert us precisely, given that we do not submit the identities of all members of our ensembles.
Comments, anyone?
One of the features of the AID is that if the records are submitted with a single comp a researcher can make the adjustment for changed comp star photometry. That is, there is enough information in the record to redo the analysis.
Using ensembles is enticing because the software packages make it so easy and the result looks more precise. But if it cannot be adjusted for changed comps and because it cannot be transformed to the standard system I think it is less valuable.
I hope a professional astronomer will chime in on this thread and tell us how they view the AID data, ensemble vs single comp.
In answer to your question, I don't believe it's possible or reasonable to setup a changed-comp-warning system. Are you going to reanalyze observations from 5 years ago? IMHO, better to submit observations with single comps and not have to worry about it.
George
Thanks, George for chiming in! Hopefully if someone like yourself expresses a question, the cognoscenti deem it worthy of a response.
As I do DSLR photometry, there really is not much choice other than using an ensemble of comp stars to improve the SNR and thus accuracy. My problem here is that of the seven stars (six comps + the check) five comps and the check star were revised. If my understanding of linear regression is correct, it then becomes impossible to accurately recalibrate my measurements, so I've spent the day reanalyzing my data.
The surprise was that although I expected the results to be more accurate owing to better photometry on the comps, the opposite turned out to be the case! I got significantly larger (i.e., factor of two or worse) errors in all but one of the eleven measurements I redid. That one has me scrtching my head!
What I am about to do is to post the revised measurements, noting that they are revised but leaving the original ones in place. The pros can then work things out for themselves.
Clear skies,
Stephen
There is a thread on this star in the Campaign sub-forum, it's a bit unfortunate that things like this don't get posted there, because I guess the campaign likely was the reason to re-visit the sequence in the first place. So maybe we should take the discussion there.
CS
HBE
You know, I thought about contacting the people for whom the campaign is being conducted to see if it mattered to them. But I didn't. And yes, I agree, I should have posted on the campaign thread to alert others of the issue.
Stephen:
I looked at your data for this star and noticed that your old and new reported magnitudes, which differ by almost 0.2 mags, have the same chart id in the AID. I would have expected that your new magnitudes would have been correlated with a different chart id with the revised comps. How did you get the same chart id for the updated comps?
The chart id is reported as part of the aavso extended format so a researcher could determine what comps you used??
Ken
Ken,
Thanks for pointing out the error; I forgot to take the new chart ID from the revised sequence page. It should be X16992R. I will fix it sofort.
As George has pointed out above, the use of ensembles does not presently allow anyone other than the original observer to reconstruct the estimate given a new sequence. I would vote for having some sort of repository in which observers using the ensemble method could list their comps. Although it would entail some burden to establish, it would not really be burdensome on us observers, at least those of us who use the same comp stars for each target, and who repeatedly observe the same set of stars. That's the vast majority, I suspect, as it is a major exercise to set up the software and train the observer to pick out the comps in the field (speaking for myself, at least. . . )
Stephen
So I did a quick comparison of the tables I get for the charts you mentioned, up to mag 8, Iand I can see only a few differences:
So I wonder if I can get different values in the photometry table of a chart if I query it at different days, if there had been an update in between?? Can you tell us which photometry values have changed for you? Because I don't see any significant differences between the two charts as of today.
CS
HB
I'll reply here. A staff member can move this thread to the campaign page if desired.
The ensemble reporting was designed to roughly handle large sequence changes. The check star is supposed to be measured with the same ensemble as the target, and so if its magnitude is, say, 0.2mags fainter than its value in VSP due to improper comparison star calibrations, then the researcher can adjust the target magnitude by 0.2mags to properly place the target on the proper system. There are more complex ways of reporting how ensemble measures are performed and what stars are part of the ensemble. For the most part, all new fields have been calibrated using APASS or other high-accuracy survey and are on a consistent system.
It is possible for WebObs to inform the observer when observations are submitted using comparison stars whose values have changed. That feature was never implemented for a number of reasons, but you can always post to the software development forum and ask that it be included in the next revision. It can be a quite complex issue, which is one of the reasons we never implemented it, as you have to "filter" the operation - visual observers don't care if a comparison star has changed by 0.02mag, for example.
[my apologies...I was mixing this field up with V1432 Aql, which DID have sequence errors. As far as I know, V1687 Cyg/WR 140 has a good sequence that was only extended for the campaign. If you read my original post, ignore my additional statements.]
Arne
But for that to work observers would have to report the calibrated magnitude for the check star in an ensemble (which many do), not the instrumental magnitude (as instructed by the help text in WebObs). That help text instructs us to put the word "ensemble" into the comp star mag field, and (unconditional if this is for an ensemble or not), the instrumental mag into the check star field. That seems pretty useless then to me. Or am I missing something?
CS
HB
I agree with you; if one uses a single comp star then an adjustment can be made as suggested. But what is being done with an ensemble is to build a linear regression line from which the target and check magnitudes are estimated. Using multiple stars helps reduce the effects of noise and random errors in the comp magnitudes. But changing even one star in the ensemble will alter the slope of the regression line and thus introduce errors in both the target and check stars. It is anything but clear to me that the results can be adjusted without knowledge of the ensemble details, because - at least in my experience - the computed errors for the target and comp are different, i.e. they lie different distances from the regression line.
But, hey, I'm doing a great job of documenting my ignorance! ;-}
Example 3 in The Extended File Format description says for ensemble photometry:
"The check star should not be included in the comparison-star ensemble. This star's calculated magnitude should be put in the KMAG field, so that if the true magnitude of the check star is found to be different at a later date, a simple zeropoint offset can be added to your ensemble value."
It is probably not clear, but the check star is supposed to be measured just like the target star, and the resultant ensemble-derived magnitude is supposed to be placed in the KMAG field.
It is true that if one star in the ensemble has a bad value, that the ensemble slope (if you are doing it that way) is skewed. However, that slope is skewed the same amount for either the target or the check star. So if you know the resulting magnitude offset for the check star, you can then apply that offset to the target star to derive a better estimate of its brightness.
Arne
I see, but this is not what this help text instructs users of the web-form to do:
https://www.aavso.org/sites/all/modules/custom/webobs/help/comp-check.h…
I guess the check star value instructions should be amended with "If doing ensemble photometry, use the calculated magnitude here" , instead of using the instrumental magnitude
CS
HB
"The ensemble reporting was designed to roughly handle large sequence changes. "
Arne: could you elaborate a bit on that? It sounds like a perceived benefit of ensemble photometry is stability of results in the face of sequence changes. If that is the case, it seems one could argue against making sequence changes, since they will not have a large effect?
Tom
Hi Tom,
It is true that ensemble techniques reduce the sensitivity to individual discrepant comparison stars during the analysis. Whether you use least-squares techniques, or even just weighted averages, such single-point errors are avoided. It is the same reason that my ensembles include stars that bracket the variable in magnitude, color and space. Random errors are reduced by such techniques.
However, if there are systematic offsets in all or a large fraction of the sequence, then all techniques, whether ensemble or traditional, will have offsets. For traditional methods, the researcher can see what comp star was used, and what magnitude was used based on the chart, and therefore correct the photometry after the fact. For ensembles, the answer is not so easy. That is why, for simplicity's sake, I asked for the same ensemble to be used on a check star. At least any offset will show up at first order using such a check.
Combining data from multiple observers, and getting a highly accurate light curve, is always a challenge. If one observer uses compA, and another observer uses compB, they will be offset with respect to one another based on the uncertainty of the calibrations of compA and compB, at minimum. As the calibration of comparison stars improves, such errors will reduce, but other errors, such as the accuracy of transformation, inclusion of contaminating stars or emission-line features, poor calibration of images, etc. will still prevent the "perfect" light curve. Such challenges can be fun to certain people! At the same time, I'd like to eliminate as many of the common problems as possible so that the AID light curves look gorgeous and the researcher has less work to do for his/her analysis.
Arne
There must be something else happening on-top of what Arne diagnosed, tho.
If you look at the newly done reductions by Stephen (SFS) in the LCG, they are almost 0.2 mag higher than the previous ones, which is massive. I suspect there is actually something wrong with the later reductions. The initially submitted data points matched up mostly well with other observers' data.
https://www.aavso.org/lcg/plot?auid=000-BCV-759&starname=WR%20140&lastd…
CS
HB
I am pretty sure that what happened was that when I plugged the data back into the spreadsheet, I neglected to account for the switchover to standard time, or put another way, back to DST. I'm redoing it yet again - and redoing the 4 Sep analysis from the start due to the very anomolous result for that date. In any event I apolgize for causing so many people so much trouble.
CS,
Stephen
This is weird indeed. I would volunteer to review your data to figure out what went wrong. I really have doubts about your new, revised reductions because the discrepancy wrt other observers is more than what you would expect from "normal" systematic effects (different sensors, different reduction procedure , ...).
So if you could attach a filled-out spreadsheet and perhaps also an example image, it should be possible to clarify this in a short time.
CS
HB
I redid the foregoing comment, having discovered that I had not been careful with the DST transition. If further analysis doesn't sort it out, I would be happy to post the spreadsheet and a set of images. (But be warned, the files are big - I use an 18 Mpixel camera, 10 images per estimate + 2 ea bias, flat & dark).If it comes to that, I will give you a Dropbox link.
CS,
Stephen
Sure, Dropbox would be fine w/ me.
As for DST: the only difference that a skewed timestamp should have on the photometry would be introduced via the airmass/extinction correction. This is a second order effect nd I doubt it can throw the results off by as much as ca 0.15 mag. There must be something else. E.g. what complicates DSLR photometry is that you want to have only the green color channel(s) contributing to photometry that is to be reported as Tri-color G or transformed to Johnson V. If that goes wrong "somehow", offsets of this magnitude (no pun intended) can easily happen I guess. Saturation is another frequent problem. With the original data at hand, this should be easy to debug.
CS
HB
In the middle of July, per a request, 3 comp stars were added to a C scale chart, 78, 83 & 85 (raising the number of available comps within this fov from 3 to 6. This was the only change for V1687 Cyg specific that I can find any record of or have any knowledge of. Therefore making it a moot point in as far as immediate observer notification for this specific fov.
I have to suspect that the observer may have used a much larger fov and it is possible that some of those values were altered in consideration of a different VS.
If the observer would send me a copy of his original photometry page with his fov scale, I will see if I can track down what may have influenced any subsequent changes, but there again, it is now a moot point, as near as I can tell, of the original complaint. tcarchcape@yahoo.com
Tim Crawford, CTX
Sequence Team
I went through my spreadsheet and data, and found a few data entry errors that degraded the accuracy, but not to a sufficient degree to explain the discrepancies. Then I started experimenting. I found that when I turned extinction OFF in the spreadsheet (on the computation tab, selecting 1: transform vice 2 transform plus extinction), suddenly everything got about 0.1 magnitude brighter. I decided that it is correct to do this, because it substantially reduces the error in the measurement of the check star. Those changes were not enough to resolve the 0.5 magnitude discrepancy in my JD 6457636.6825 measurement, so I redid that one from scratch, deleting BJP-011 as a comp. {It was not used in any of the other measurements; also note that the update to the sequence does not eliminate the ambiguity between BJP-011 and BCL-537; it's the same star, folks and I have verified it with my own eyes.] When I did that, the discrepancy disappeared. Sad to say, though, I hoped I'd seen a flare.
I need to do some more research, but at the moment I suspect that by checking the box in the spreadsheet I was in effect performing an extinction correction twice. I enter star coordinates in AIP4WIN, which presumably uses the information to perform an extinction correction. That's the theory du jour in any case.
Thanks to all for comments. You all motivated me to dig into this problem.
CS,
Stephen
The attached plot shows that my measurements are still setting the lower bound but at this point I am unsure as to how to proceed. I'm now within 20 - 30 mmag of the other observations, which might not be so bad if my tiny aperture and uncooled DSLR is being compared to a proper telescope with a proper CCD and proper observer. Should I declare victory and move on?
That already looks much better.
I'm not sure that AIP really does extinction correction by airmass, I think AIPWIN just computes the airmass to add it in a report file, but doesn't try to correct the photometry. Can anyone confirm this?
My therory is that something went wrong in the spreadsheet when computing the extinction correction, e.g. there are different conventions for choosing the sign in the longitude coordinate value (e.g. minus is either West or East, depending on convention), and if you pick the wrong one you get values that are totally wrong. For realistic ranges of airmass (remember. 1.0 is at zenith, 30 degrees above horizon is ca 2) , the impact of this airmass correction step should be really small unless your field is so wide that different stars that you are using have significantly different airmass values, which means that they will undergo different extinction. If the stars undergo different extinction, the spreadsheets mechanism for transforming the photometry to Johnson V doesn't work so well and the airmass/extinction correction can help. If you are using a narrow field and/or are taking images near the zenith, switching extinction correction off is ok.
CS
HB
Stephen,
I have removed one of the labels for the 69 star (000-BCL-517) and updated the other one (000-BJP-011) with a small revsion.
Tim Crawford, CTX
Sequence Team