Hello,
I'm new here and I am greatly enjoying variable star observing. I have been pleased that all of my visual estimates so far have been very close to what other observers have posted; however, the other night I made three estimates which differed quite a bit from what others reported. In one case the difference was lower by over one magnitude. What was a bit disconcerting is that I remember feeling particularly confident about these observations when I made them. Granted, I am inexperienced and despite being very careful, I may have just made some erroneous estimates, but after thinking about this for a few days, I am not so sure if I did. It is also possible that I witnessed transient events like a brief flare up or an occultation...I just don't know. In any case, should I post my data even if it may be wrong, or should I withold it to avoid submitting bad data? I would greatly appreciate any advice in this regard.
It has been cloudy, so I have not yet been able to recheck these stars.
Thank you,
Harry
Hello Harry,
Thank you for writing. The AAVSO fundamentally depends upon the observer community accurately reporting their data, and that includes cases where your observations differ from those of others. If you are certain you had the correct field, the correct star, and a current(!) comparison star chart, and you were able to make an unambiguous estimate of the variable, then please report it. If you are uncertain, you can flag it yourself as uncertain, but in this case it sounds like you were not uncertain at the time. Not reporting your observation because of what you saw in the Light Curve Generator may in fact bias the light curve, and that does more harm than good.
The only things I'll recommend are (a) make sure you correctly identified the variable in the field; (b) make sure you have good comparison stars; and (c) make sure you got the time correct (month, day, year, and UT time) and that you're using Universal Time, not local time.
Matthew
Matthew,
Thank you for taking the time to answer my question, your answer was very helpful. Yes, I do know about universal time, and even though I am getting on a bit in years, I am still aware of the current month and year...lol.
Thanks again,
Harry
Hi Harry,
Happy to help, and please do submit your observations if you haven't already.
To be clear, I didn't make note of time to single you out for suspicion, but because typographical errors on submitted times are one of the more common issues that come up during data validation, and they happen most often by accident. Transposed digits or being off by one key on a keypad or number row happen often enough to be notable. The issue with UT versus local is also common, as is daylight savings time (which UT does not follow).
It's especially important if you're using LCG as a check -- you may have a perfectly good estimate, but if the time is recorded off by an hour or a day or a year (which we encountered with another observer recently) it will be wrong.
Clear skies,
Matthew
One big help with getting the time of observations entered correctly, would be to add the phrase with real time displayed just under the time entry field, such as: "The current time is xx:xx:xx UT on day-month-year". Another help would be to ask the user to enter the night of the observation as the two sequential dates around midnite separated by a slash like "Mon dd1/dd2". These would make it substantially less likely to inadvertently enter the wrong times.
I also submit observation data to the IMO (Int'l Meteor Organization) via their web based interface, and they use the above described method which greatly reduces time related errors! You can see an example of their interface at this link - http://imo.net/visual/report/electronic
I had made this request to the WebObs support some time ago, without any result :( Hopefully, the necessity for this improvement is now becoming more apparent.
Mike LMK
Another idea regarding cross-checking date/time entry - have the Webform calculate the time difference between the entered observation and the current time, and display that difference, as it is being entered. Anything less than 24 hours ago can be highlighted in green, over 24 hours ago highlighted in RED.
This would have the additional benefit of encouraging people to enter their observations in a timely manner ;)
Mike LMK
Harry:
If in doubt-submit.
The key to making that decision is to perform your own qual checks. Most of these are just a natter of proper observing technique-i.e.don't check the latest obs before observing, keep your charts up to date , take a measurement several times, using a stop down aperture or defocusing to eliminate as nuch color as possible-etc, etc.
As a final check I will usually look at the latest data before submitting for any obvious discrepent observations. When I find one I try to identify why- I once measured SS Cyg at 8.6. On looking at the latest data and my chart it was clear that I had recorded the magnitude of the bright comparison star instead of the variable itself-- real "Birch Streeet Irregulars " territory.
But- if you can't clearly identify your error you should always submit it. Ignoring data points just to make your data look cleaner is bad science. In every Science Lab I ever took that practice would have earned an instant fail. Besides- it may turn out not to be an error at all.
An example from late last year: At one of my club's public star parties I had a student from an astronomy class try her hand at estimating R CrB. A few weeks before I had seen it at about mag 12. When she told me her easurement it was below mag 13. When I looked it was immediately clear she had made a reasonably close estimate- in fact I had made the classic . When I got home and chcked the LCG I found R CrB had gone into another decline. At the time we observed it there were only 3 visual observations and 1 V measurement since the decline had begun. She was one of the first in the world to see the decline visually.
David,
Thank you for your response, that was very good advice. Your comments illustrate why I do not think that this is a trivial question. In other words, as observers for the AAVSO, should we just blindly submit our data, or should we engage in some form of error checking? While I would never alter my data just to make it look cleaner, I am very concerned with submitting the most accurate and reliable data that I am capable of. Clearly, a largely discrepant data point is evidence of a possible error. In my case, I was able to reobserve my stars in question, and in two cases it was clear that I simply made some very poor estimates, but in the other I just could not tell. Judging from the replies though, I think the answer to this question is to engage in error checking by being very careful when making observations, but after that, just report the results and move on. Doing what I did is probably a bit too much. In essence, we are all just photon detectors with an inherent amount of noise, and it is up to us to report our results noise and all.
Thank you again David for replying to my question, you and everyone else have been very helpful.
Harry
I don't want to contradict anything that anyone has posted on this topic, simply to add a couple of points. One of the worst observing techniques one could have is that of prior expectation. For example, if just prior to going out to observe, I ran through the most recent CCD observations for the stars in my program, I would uncounsciously bias myself toward repeating those values, even though what I was actually seeing was different. This would produce bias in the estimates, and thereby diminish their value. For that reason, I personally never refer to prior data before a session - even my own observations from the previous night.
From the point of view of statistical analysis, it is better to have independent observations, even if they are all disparate, than to have observations that are causally connected. So do your best, by all means compare your results to those of others so that you might improve, but report what you see!
On a different but related topic, I long ago developed a little spreadsheet that computes Julian date and time. It is valid anywhere in the US but can be adapted for any location east of the international date line. Currently it is in Open Office (.odt) format, but I can convert it back to Lotus 123 (.123) or even Excel (.xls) format if anyone wants it. Let me know by replying to this post, and I can put it on dropbox.
Hi Harry. If you wondering if you did a "bad" estimate on RV Bootis, I did an magnitude estimate in the same star last night on the 5th June. And I am in complete agreement with you estimate. Check it out. It is geeting a bit brighter!
Aubrey.
Thanks for your reply. I was thinking of writing a julian date converter on my TI programmable. Actually it would be nice if there was a julian clock app for a smart phone. I would be interested to see your spreadsheet.
Thanks,
Harry
Here's the link: https://www.dropbox.com/s/9v7lvjn2h1g6nbi/GMAT.ods
It will be active for about a month.