As the recent thread on "wrong photometry" of EF Peg pointed out, and this issue also occurs for other variables too, I would like to suggest a new checkbox be added to WebObs, so observers can specifically designate if a contaminating object is included in the photometry of a variable. It should also have a field to allow the observer to specify the magnitude of the contaminating object. Therefore, a new field(s) will also be needed in the AID to account for this.
This improvement would allow LCG to properly and automatically identify observations with contamination from companion objects, by a different symbol icon or color. The problem of mixing pure and contaminated observations in LCG (without any notification), has caused much trouble in the past. One of my own program stars, NSV 1436, had long suffered from this issue of a close 16 mag companion which made it appear the star had two different minima brightness, leading to false conclusions about the nature of the variable, such as an eclipser, which it apparently is not. I believe even some scientific papers have made wrong conclusions based on such contaminated photometry!
While recently, some observers have been leaving comments regarding companions included in CCD apertures, those comments cannot be readily converted into display by the Light Curve Generator, nor do they show up in the list of observations, unless one clicks on the "expand" to show everything. So, without a specific new field and requirement, for all observers to indicate what contamination is in their observations, this serious "misleading" information will continue to exist in our data!
Thank you for listening,
Mike
I'm doing some wide field photometry and would also appreciate a way (other than the comment field) to tag an observation where a sufficiently bright close-by object wasn't resolved.
However, adding fields to a database (and dealing with it in all the software that reads from the DB or exports/imports data) is a very drastic step. Think about all the changes to existing programs that this would entail.
Also note that you would need to specify whether the "contamination" affects the target star or the comparison star (or both with different stars...), as both would degrade the photometry but in different directions (one might object that you should never use a "blended" comp star but a) sometimes you have a very limited choice of comp stars and b) you might use the proposed comment feature when editing observations after you find out that your previously submitted observations have this flaw).
Could there be a less drastic solution, short of adding columns to the DB? One might think about either using an existing comment code like "S" (comparison sequence problem ) or perhaps invent a new comment code for "star blending". More details can then be given in the comment field.
In any case, the observer could (and IMHO should) also try to reflect the added uncertainty about the true magnitude value by increasing the reported magnitiude error value accordingly.
One might object that these simpler ways to deal with this situation do not produce different symbols or colors for data points in the LCG, but then again, nor do things like "poor seeing" (code W) or "Clouds, dust, smoke, haze, etc." (code U) which can just as well ruin your photometry. I think it's impractical to come up with distinct graphical representations of all possible causes for significant systematic errors in photometry, and instead the error bar height should be used to represent your confidence in the measurement.
Last but not least, if the observer already knows about the contamination at the time of submitting the observation, one should ask whether it makes sense to submit this observation at all.
CS
HBE
Maybe the "Uncertain" check box is the right place for this. Such a field already exists in all reporting mechanisms and in the database. You'd select the Uncertain field and then explain why in the Comments field. The only new thing that would be needed is a checkbox to either not show observations marked Uncertain or to show them with a different symbol.
After a year or so of doing this, we could then look at the database and see how often this is occuring. That would provide us with evidence as to whether this is an issue that warrants a database modification or whether an easier solution would suit us.
Aaron (PAH)
Responding to some of these comments:
1. "ALTER TABLE ... ADD COLUMN" in SQL is a quick and simple modification, it will not affect existing programs that do not use the new column. The new column could be used right away in WebObs to allow users ability to designate contaminated obs, and in LCG for displaying them clearly and differently (from that date forward). Other programs can then make use of this new feature at their leisure.
2. Error bars are not the proper place to put systematic errors! AFAIK, bars are always used to represent a random error. Some of the systematic offsets when mistaking a bright companion would be many magnitudes large, which is totally inappropriate in an error bar. By definition, error bars are plus/minus due to the uncertainty introduced by randomness, not to show a known offset in one direction.
3. Also, "Uncertain" checkbox is inappropriate for signifying a systematic error. Such error is in fact "certain" since you know the magnitude of the contaminating object! The real purpose of "uncertain" is just to alert that an observation has a larger than usual random error, for whatever reason, but not to include large systematic offsets.
4. This issue does not involve comp stars. If any comp stars have close companions which may cause problems, they should be corrected using CHET. That is a chart issue, not an observing or DB issue.
5. Waiting a year or more before doing anything ensures this critically important modification will get buried and forgotten!
All that is needed is adding 2 columns to the DB - a flag type field to indicate the obs is contaminated, and a numeric field for the magnitude of the blending object - and a few changes to WebObs and LCG to make them immediately available for use in them. Now is an opportune time to make this simple yet effective improvement, just in time for the new year going forward :)
Mike
Any changes to the AAVSO format also requires changes to vendor supplied photometry software. In at least one case I don't think this is going to happen. In any event, the AAVSO shouldn't use it's silver bullets for changes that will seldom or never be used.
Displaying the data with VStar lets you see the entire input record (including comments) for any observation with a click of the mouse. No change of the data base required.
Jim Jones
[quote=jji]
Any changes to the AAVSO format also requires changes to vendor supplied photometry software. In at least one case I don't think this is going to happen. In any event, the AAVSO shouldn't use it's silver bullets for changes that will seldom or never be used.
Displaying the data with VStar lets you see the entire input record (including comments) for any observation with a click of the mouse. No change of the data base required.
[/quote]
Jim, As far as I can tell, just adding 2 new columns to the database, without changing any existing ones, is a benign modification which should not affect any current 3rd party software. You can choose to incorporate the new information in future releases, anytime.
The problem with "no change of the DB", is that the current situation does not allow separating out contaminated observations from pure ones in any consistent or automatic fashion.
Mike