Affiliation
American Association of Variable Star Observers (AAVSO)
Tue, 03/21/2023 - 12:28
I have observations of WASP-104b, which I have run through EXOTIC and am attempting to upload. However, when I try to do this, I get an error message that says,
There were errors in your form. Fix these issues to continue:
- Problems with report file AAVSO_WASP-104 b_07032023.txt
- This data does not look to be normalized. This is Rnflux data with a mean of 2.98e-05 and a std dev of 2.03e-07
I'm trying to submit the output file that EXOTIC produced which I would expect to be in the proper format-- it certainly appears to be that way to me. Any ideas? First lines of my data are below-- every line of data has this format.
#TYPE=EXOPLANET
#OBSCODE=RTH
#SECONDARY_OBSCODES=
#SOFTWARE=EXOTIC v2.1.1
#DELIM=,
#DATE_TYPE=BJD_TDB
#OBSTYPE=CCD
#STAR_NAME=WASP-104
#EXOPLANET_NAME=WASP-104 b
#BINNING=1x1
#EXPOSURE_TIME=120.0
#COMP_STAR-XC={"ra": "10:42:19.88", "dec": "07:22:24.1", "x": "632", "y": "442"}
#NOTES=SBIG-ST8xme
#DETREND_PARAMETERS=AIRMASS, AIRMASS CORRECTION FUNCTION
#MEASUREMENT_TYPE=Rnflux
#FILTER=RJ
#FILTER-XC={"name": "RJ", "desc": "Johnson R", "fwhm": [{"value": "590.0", "units": "nm"}, {"value": "810.0", "units": "nm"}]}
#PRIORS=Period=1.75540569 +/- 1.1e-07,Rp/R*=0.12131 +/- 0.00055,a/R*=6.52 +/- 0.13,inc=83.63 +/- 0.25,ecc=0.015,u0=2.182 +/- 0.018,u1=-3.743 +/- 0.073,u2=3.949 +/- 0.095,u3=-1.389 +/- 0.04
#PRIORS-XC={"Period": {"value": "1.75540569", "uncertainty": "1.1e-07", "units": "days"}, "Rp/R*": {"value": "0.12131", "uncertainty": "0.00055"}, "a/R*": {"value": "6.52", "uncertainty": "0.13"}, "inc": {"value": "83.63", "uncertainty": "0.25", "units": "degrees"}, "ecc": {"value": "0.015", "uncertainty": null}, "u0": {"value": "2.182", "uncertainty": "0.018"}, "u1": {"value": "-3.743", "uncertainty": "0.073"}, "u2": {"value": "3.949", "uncertainty": "0.095"}, "u3": {"value": "-1.389", "uncertainty": "0.04"}}
#RESULTS=Tc=2460011.7153 +/- 0.0035,Rp/R*=0.076 +/- 0.044,a/R*=6.45 +/- 1.13,Am1=3.7e-06 +/- 1.7e-08,Am2=0.14 +/- 1.73
#RESULTS-XC={"Tc": {"value": "2460011.7153", "uncertainty": "0.0035", "units": "BJD_TDB"}, "Rp/R*": {"value": "0.076", "uncertainty": "0.044"}, "a/R*": {"value": "6.45", "uncertainty": "1.13"}, "Am1": {"value": "3.7e-06", "uncertainty": "1.7e-08"}, "Am2": {"value": "0.14", "uncertainty": "1.73"}, "Duration": {"value": "0.067", "uncertainty": "0.018", "units": "days"}}
# EXOTIC is developed by Exoplanet Watch (exoplanets.nasa.gov/exoplanet-watch/), a citizen science project managed by NASA's Jet Propulsion Laboratory on behalf of NASA's Universe of Learning. This work is supported by NASA under award number NNX16AC65A to the Space Telescope Science Institute.
# Use of this data is governed by the AAVSO Data Usage Guidelines: aavso.org/data-usage-guidelines
#DATE,DIFF,ERR,DETREND_1,DETREND_2
2460011.67402772,3e-05,0.006817,12.085,2.08e-05
2460011.67556706,3.01e-05,0.0068358,12.089,2.08e-05
Thanks.
Tom (RTH)
Your airmass looks really low.
Tom,
You are getting the error message because the data for the relative normalized flux of the target - the second field in each data row (e.g., 3.01e-05 in your case) is too small. The data is the flux depth of the target star normalized around 1.0. You might check why the data in your observation is so low.
Dennis
EXOTIC also…
Dennis,
EXOTIC also provided me with a graph showing the best-fit for the transit and a couple of other bits of information-- is the proper correction to allow me to calculate the correct value for the relative normalized flux on it? Or is this also a step that I need to do in EXCEL?
I'm trying to figure out how to add an image of the graph, but I'm not being given that option when replying to you.
The only thing on the graph (other than the graph itself) that might be relevant is:
σ =0.52%
If this isn't it, any idea where would I find the information needed to calculate the correct values?
I'm sure I'm missing something obvious-- the best place to hide something is in plain sight so that might apply here as well. :-)
Tom
I took a look at…
Anthony,
I took a look at the FITS header and Airmass does not seem to have been reported by the software (MaximDL) so it looks like EXOTIC inserted a number that it got from somewhere-- not sure where. I would have expected EXOTIC to calculate it from the RA, DEC, TIME, and my location but it apparently doesn't do that. I can fix that easily enough in EXCEL though so not a major issue.
Tom
EXOTIC uses Airmass as the detrend in the AAVSO file it generates. Best of luck!
Right - I'll give the EXOTIC code a look to see how it handles the lack of an AIRMASS FITS header: might be a bug there, since I've otherwise never had problems with submitting EXOTIC generated AAVSO files (but my FITS files always have AIRMASS set).
One concern is your header implies EXOTIC v2.1.1, which is quite obsolete (current release is v2.8.0) - I'll check to see if the lack of AIRMASS header is a concern in current code.
Update: I need to tinker with the code to be 100% sure that the logic is working as it should, but this is how AIRMASS values are derived in EXOTIC:
if (there is an AIRMASS FITS header) {
use it
}
else if (there is a TELALT FITS header) {
assume it is degrees above horizon, and compute simple airmass value as secant from zenith (90 - TELALT)
}
else {
use the target RA, targer DEC, Observatory Lat, Observatory Long, Observatory altitude and timestamp to compute the sky position of the target, and compute secant from zenith of that.
}
I installed it (version 2.1.1) on 11/6/22 which I guess was a long time ago, relatively speaking. My biggest surprise with it was that it actually ran on my Win 10 computer. All of my previous attempts to run EXOTIC on other Windows machines would fail and it would not run. Same for the attempts that I have made in the past couple of weeks-- the newest version will not run on any Windows machine that I have tried it on (I don't want to use the COLAB version since that will require being online-- I prefer local control of everything).
Tom
Right - understood - Rob Zellem and crew are a bit more aggressive on version number bumps than normal (here is release history - https://github.com/rzellem/EXOTIC/releases) - but, more to my point, is if the version isn't 'current', it certainly isn't going get a fix without first being an issue on the current version (there would not be a patch to 2.1.1 - only to the post-2.8.0, if it needed it), so anything older than current is effectively 'unsupported'.
Cannot speak personally to running on Windows - I'm all Mac and Linux, myself, except for the occasional app that forces me to dust off my Windows box :) - but Python on Windows is generally a PITA (in the past, I've favored just firing up a VirtualBox VM or Docker). The default answer from the EXOTIC team is to steer folks towards using the Google Collab version - https://exoplanets.nasa.gov/exoplanet-watch/exotic/welcome/ for details - 'Advanced' case is probably what you want, but I'm not even sure that works if you are feeding EXOTIC already processed photometry data versus images to have both photometry and model fitting (full reduction) applied.
Hi Tom (and Mike):
Relative normalized flux is something that EXOTIC should calculate based on the flux of the target relative to a "baseline" - which is the pre-ingress and post-egress data. I notice that there really is an issue with calculation of your AIRMASS. Mike, you indicated that it is low - I see in the data that it is actually quite high and totally bogus (e.g., 12.085).
Dennis
I didn't indicate that - it was reported in another post, and I was responding to that assertion - but I see what you mean: it's the correction factor (DETREND_2) that is low, not the airmass (DETREND_1), which is very high. 12.085 is mathematically possible (the domain of secant is [1.0, infinity)), but would correspond to around 1 degree above the horizon. If the observatory lat/long were wrong, or the time reference, I could see the generated AIRMASS being similarly incorrect. I've confirmed the AIRMASS calculation in EXOTIC to be arbitrarily close to what is produced by AIJ, at least for non-pathological (close to horizon) sky positions.
I just checked and the Obs latitude, longitude, altitude are all correct, as is the time so I'm not sure what went wrong with the Airmass calculation. Perhaps its because there isn't much pre- and post- transit data-- the data was collected by one of my students and he did not get the hour of out-of-transit data that I recommended he get both before and after the transit-- maybe there aren't enough OOT points for EXOTIC to work with? Pure speculation on my part, though.
I'll start working on getting the COLAB version up and running and see what sort of numbers is gives me when I feed it the raw data. I'll report back here with what happens.
Thanks everyone!
Tom (RTH)
To Dennis' point, the most odd thing is those pathologically low relative flux numbers - it's hard to tell more about what is up there with just the first two data rows. The set as a whole would be normalized around 1.0 representing the average flux levels during the pre and post transit portions of the data set - to the degree that is 'wrong' is only relevant to the data set as a whole, versus specific points in the data set, but an image with a valid target star in field vs a valid comparison star in field should never be THAT much below 1.0, without there being a systematic problem with it (or the comparison star) being obstructed or otherwise wildly off.
Could you post the 'FinalLightCurve_*.png' file from your EXOTIC run? The full copy of the AAVSO report would be nice too, but the light curve might be enough to get a feel for things, since that is ultimately a graph of the same data, with the model fit superimposed.
A copy of the FITS header for one of those first images might also be illuminating :)
I was the one who mentioned the airmass. In the #Results line of the output file, it shows am1=3.7e-06, which definitely not a ground-based telescope!
Anthony
Yep - after some additional poking, I think I know the source of the confusion: the key is 'AIRMASS' (the metric of the relative depth of the slice of air you are looking through) and AIRMASS CORRECTION FACTOR (the modeled effect on observed flux due to AIRMASS).
EXOTIC uses the following model for the detrend relative to AIRMASS - a1 * exp(a2 * airmass), where a1 and a2 are part of the model fit (a1 ranges from 50% of the minimum flux to 200% of the maximum, a2 ranges from -1.0 to 1.0). So, a1 and a2 are 'Airmass coefficient 1' and 'Airmass coefficient 2', when you see the results display at the end of the run, and the calculated AIRMASS CORRECTION FACTOR (aka DETREND2) is the evaluation of a1*exp(a2 * airmass). I do not know the source of this model (paper-wise), but probably could find out, if anyone is interested. I think the effect is to allow for a non-linear effect on airmass (in that AIRMASS and other detrends are considered as linear effects, while these coefficients yield a small but scalable exponential detrend effect for AIRMASS, when appropriate).
On valid outputs, Am1 (aka a1 aka Airmass coefficient 1) tends to be close to 1.0, while Am2 (aka a2 aka Airmass Coefficient 2) tends to be small (close to zero: +- 0.03 or so, at least from what I've seen): example from one of my observations: Am1=1.044 +/- 0.033,Am2=-0.0264 +/- 0.0021
So, net-net, the detrend from EXOTIC is around both AIRMASS and the AIRMASS CORRECTION FACTOR (which is produced from the model fit of Am1 and Am2).
The 'big' vs 'small' is the definition of DETREND1 (AIRMASS, since that is first in the #DETREND_PARAMETERS list, and is huge at 12+) and DETREND2 (AIRMASS CORRECTION FACTOR which is second in the list, and tiny here, but generally about 1.0 for valid results).
Thanks for posting that, Mike. Rob and Kyle could tell us exactly about am1 and am2 and how they are used in the model fit.
But the numbers in the above output file came from somewhere.
Could you post the inits file, Tom?
{
…
This should be it:
{
"inits_guide": {
"Title": "EXOTIC's Initialization File",
"Comment": "Please answer all the following requirements below by following the format of the given",
"Comment1": "sample dataset HAT-P-32 b. Edit this file as needed to match the data wanting to be reduced.",
"Comment2": "Do not delete areas where there are quotation marks, commas, and brackets.",
"Comment3": "The inits_guide dictionary (these lines of text) does not have to be edited",
"Comment4": "and is only here to serve as a guide. Will be updated per user's advice.",
"Image Calibrations Directory Guide": "Enter in the path to image calibrations or enter in null for none.",
"Planetary Parameters Guide": "For planetary parameters that are not filled in, enter in null.",
"Comparison Star(s) Guide": "Up to 10 comparison stars can be added following the format given below.",
"Obs. Latitude Guide": "Indicate the sign (+ North, - South) before the degrees. Needs to be in decimal or HH:MM:SS format.",
"Obs. Longitude Guide": "Indicate the sign (+ East, - West) before the degrees. Needs to be in decimal or HH:MM:SS format.",
"Plate Solution": "For your image to be given a plate solution, type y.",
"Plate Solution Disclaimer": "One of your imaging files will be publicly viewable on nova.astrometry.net.",
"Standard Filter": "To use EXOTIC standard filters, type only the filter name.",
"Custom Filter": "To use a custom filter, enter in the FWHM in optional_info.",
"Target Star RA": "Must be in HH:MM:SS sexagesimal format.",
"Target Star DEC": "Must be in +/-DD:MM:SS sexagesimal format with correct sign at the beginning (+ or -).",
"Formatting of null": "Due to the file being a .json, null is case sensitive and must be spelled as shown.",
"Decimal Format": "Leading zero must be included when appropriate (Ex: 0.32, .32 or 00.32 causes errors.)."
},
"user_info": {
"Directory with FITS files": "H:/King Data/King Astronomy Data 20230307",
"Directory to Save Plots": "H:/King Data/King Astronomy Data 20230307",
"AAVSO Observer Code (blank if none)": "RTH",
"Secondary Observer Codes (blank if none)": "",
"Observation date": "07032023",
"Obs. Latitude": "36.5839",
"Obs. Longitude": "-82.0581",
"Obs. Elevation (meters; Note: leave blank if unknown)": 613.0,
"Camera Type (CCD or DSLR)": "CCD",
"Pixel Binning": "1x1",
"Filter Name (aavso.org/filters)": "RJ",
"Observing Notes": "SBIG-ST8xme",
"Plate Solution? (y/n)": "y",
"Add Comparison Stars from AAVSO? (y/n)": "y",
"Target Star X & Y Pixel": "[954, 334]",
"Comparison Star(s) X & Y Pixel": "[[632, 440], [672, 146]]",
"Directory of Flats": "H:/King Data/King Astronomy Data 20230307",
"Directory of Darks": "H:/King Data/King Astronomy Data 20230307",
"Directory of Biases": null
},
"planetary_parameters": {
"Target Star RA": 160.6023689,
"Target Star Dec": 7.4350768,
"Planet Name": "WASP-104 b",
"Host Star Name": "WASP-104",
"Orbital Period (days)": 1.75540569,
"Orbital Period Uncertainty": 1.1e-07,
"Published Mid-Transit Time (BJD-UTC)": 2457805.170205,
"Mid-Transit Time Uncertainty": 3.7e-05,
"Ratio of Planet to Stellar Radius (Rp/Rs)": 0.1213119532445175,
"Ratio of Planet to Stellar Radius (Rp/Rs) Uncertainty": 0.0005479674362015454,
"Ratio of Distance to Stellar Radius (a/Rs)": 6.52,
"Ratio of Distance to Stellar Radius (a/Rs) Uncertainty": 0.13,
"Orbital Inclination (deg)": 83.63,
"Orbital Inclination (deg) Uncertainty": 0.25,
"Orbital Eccentricity (0 if null)": 0.015,
"Argument of Periastron (deg)": 0.0,
"Star Effective Temperature (K)": 5475.0,
"Star Effective Temperature (+) Uncertainty": 127.0,
"Star Effective Temperature (-) Uncertainty": -127.0,
"Star Metallicity ([FE/H])": 0.32,
"Star Metallicity (+) Uncertainty": 0.09,
"Star Metallicity (-) Uncertainty": -0.09,
"Star Surface Gravity (log(g))": 4.5,
"Star Surface Gravity (+) Uncertainty": 0.02,
"Star Surface Gravity (-) Uncertainty": -0.02
},
"optional_info": {
"Filter Minimum Wavelength (nm)": null,
"Filter Maximum Wavelength (nm)": null,
"Pixel Scale (Ex: 5.21 arcsecs/pixel)": "0.756"
}
}
Thanks, Tom. The inits looks ok to me. Not sure why the output file got the airmass corrections or those detrend numbers. Rob or Kyle Pearson at ExoPlanet Watch could help.
Anthony
It seems that I am no longer given the option to upload new files to this thread-- any idea how to do that? I guess I could put the .png file and the data file in a Google drive and post a link to it.
Tom
…
Here are links to them;
Lightcurve image:
https://www.dropbox.com/s/6br27f2cu6yyq83/FinalLightCurve_WASP-104%20b_07032023.png?dl=0
Data:
https://www.dropbox.com/s/ywc5wx3rzf6uryy/AAVSO_WASP-104%20b_07032023.txt?dl=0
Thanks.
Tom (RTH)
OK, so wow, all kinds of weird here. If you don't mind, I'd love to see your FITS files and inits.json - I'll need some time to debug it, but clearly something 'very bad' is going on here. If you are OK with sharing them with me, kick me an email with a drop box link at mike@primmhome.com - I promise to respect the proprietary data of the observation, but I just want to run things through and see where the 'bad' is happening, so that I can submit a fix to EXOTIC (if that is what is called for).
Will do-- I'm heading out to teach class here in a few minutes so it will most likely be tomorrow before I can get a link to you.
Thanks!
Tom (RTH)
I did find an error in the FITS header-- longitudes were not entered as negative so that probably explains the airmass issue. Going to rerun EXOTIC and see what happens.
Tom
For EXOTIC, the observatory lat/long provided in the inits.json ('Obs. Latitude', 'Obs. Longitude') are the most important to get the signs right on (+=north, +=east) - I'll need to check, but I'm not sure the FITS fields are used for that. Hope it works out!
When I tried rerunning it, the local version would no longer run on my desktop (even though it ran fine the day before). So, while I will probably revisit this and try to find out what the issue is, I ran it using the COLAB version and seemed to run correctly producing the .png file and the .txt file for the AAVSO. The graph looks better to my eyes (the best-fit line is more obvious) and the time of mid-transit has a smaller error.
I think I will use the COLAB version from here out and see where that takes me.
Thanks again for your help!
Tom (RTH)
Really glad you got it worked out, but I'm still trying to post-mortem exactly where that 12 AIRMASS came from :). I wrote up a script to compute your alt-az values, given the BJD_TDB of your observations, and the settings from your inits.json, but those came out shockingly normal:
2023-03-28 13:44:41,730 INFO - alt-az=<SkyCoord (AltAz: obstime=2460011.67403, location=( 708549.92019586, -5078959.08184587, 3780782.9710404) m, pressure=0.0 hPa, temperature=0.0 deg_C, relative_humidity=0.0, obswl=1.0 micron): (az, alt) in deg
( 151.94762831, 70.01120136)>
2023-03-28 13:44:41,731 INFO - airmass=1.0641020751325836
(basically 70 degree altitude, and a 1.064 airmass)
and flipping around the signs and such didn't get me there (mostly I got below the horizon values - negative altitude and meaningless negative airmass values). The colab version is reliably the latest release, so maybe it was a bug that has since been corrected - but I didn't see anything suspicious in the change log since then.