Closed dyerlytle closed 5 years ago
@Teznie is there any metadata (name, sky coordinates, etc.) of the star that is being guided upon, or is it really just whatever bright thing looks like it works for the field?
The star is selected using CAT and a Guide Target packet is sent to the TCS. As such RA/Dec/Name/Magnitude etc are available from CAT or the TCS packet. I believe some of this info is already written into the fits headers.
Magic decoder ring for "BOX" lines:
0 0 BOX(0,1)=820.48 [139 134]=27427.00 [146 111]=791.00 570.86 Usage 0.000 (1)
? ? BOX[threadname, usually \0](framenumber, subframenumber)=mean [brightestPixelXCoord brightestPixelYCoord]=brightestPixelValue [faintestPixelXCoord faintestPixelYCoord]=faintestPixelValue stddevPixelValues Usage timeusage (subframesCompleted)",
The first two numbers are sometimes 0s, sometimes real values; I think they're connected to a GUI thing. Same goes for the PHOT lines.
NOTE this style is for what is sent to the loisAnalysis topics; the raw BOX (and PHOT) lines in the actual/direct LOIS logs look a bit different and contain slightly different information, because of course they do.
01:17:02 Level_3:BOX(0,1)=31978.00 [136 118]=1060.00 [151 112] (1782.52, 2959.46) 26x26 77901584
01:17:02 Level_2:SendAnalysis: 138 119 BOX(0,1)=1782.52 [136 118]=31978.00 [151 112]=1060.00 2959.46 Usage 0.000 (1)
...
01:17:02 Level_3:PHOT(0,1):135.90 118.38 4.17 7.58 0.001 1074.88 710.00, 31978.0
01:17:02 Level_2:SendAnalysis: 139 119 PHOT(0,1):135.90 118.38 4.17 7.58 0.001 1074.88 31978.0
ALSO NOTE That the two BOX lines are almost completely backwards. Using the first definition in this comment, I would expect that [136 118] is the location of the brightest pixel value (31978) and [151 112] is the faintest (1060) BUT the raw BOX line says exactly the opposite! Something is jumbled up somewhere, and I can only assume that the SendAnalysis line is the actual correct one since that's getting used elsewhere.
Looking at the code, sure enough that's the case.
lois_log3("BOX%s(%d,%d)=%.2f [%d %d]=%.2f [%d %d] (%.2f, %.2f) %dx%d %d",
threadname, frmno, subno+1,
max,maxx,maxy, min, minx, miny, mean, stddev,
cent->x_size, cent->y_size, boxm_sig);
sprintf(anatxt,
"BOX%s(%d,%d)=%.2f [%d %d]=%.2f [%d %d]=%.2f %.2f Usage %.3f (%d)",
threadname, ( ac->final?frmno:ac->iframe), subno+1,
mean, maxx,maxy, max, minx, miny,min, stddev,
totusage, ++idone);
Magic decoder ring for "PHOT" lines:
139 134 PHOT(0,1):139.02 134.22 1.33 7.61 0.002 801.76 27427.0
? ? PHOT[threadname, usually \0](framenumber, subFrameNumber):centroidColumn centroidRow FWHM instMag instMagErr skyMean maxPixValue
Initial attempt in https://github.com/LowellObservatory/DataServants/commit/a8f0c71a02045691973df74f620ec6376baf11e9; will test tonight. Should probably consider spinning it off into a more dedicated loisAnalysis parser since it's not really necessary to catch everything and it could be put under a different DB name too, but this will work for a first try.
Behold the most boring plot showing success:
Since last night was icky there's not much data in there, but it works and is currently grabbing the analysis values off of RC1, RC2 (and GDR and WFS). It needs to be cleaned up, but the capability is there at least.
One quirk that has come up is that it's possible to toss in another instrument (notably LMI) but I don't have a handle on the binning status yet so it's unclear what plate scale to actually kludge in to put it into arcseconds to all plot together. This is tracked over in https://github.com/LowellObservatory/DataServants/issues/22 but it might be a huge addition for regular LMI users as the following graph shows LMI analyses (in red) flowing regularly while the GDR updates stopped.
Note: the plot above is a little under half of an LMI night on 2018 11 02 UT. I'm assuming that all LMI images are 2x2 binned, which isn't ideal but it's a start.
@LowellObservatory/nightops does this plot seem useful? Useless? I'm not sure if this was the original intent/idea or if I've gone down a side street into something else, but this was the easiest thing to roll into the stuff I'm already pulling out of the logs.
The information from LMI depends entirely on the observer so if the star they're watching goes away then the information gets weird (which I think is what happened at the end of the red points) but it's still pretty neat to see twilight leading into darkness in RC1/GDR.
Not sure what I'm looking at here. It just pops up with a blank page. The only thing that is populated is that there are 7 members.
Andrew Hayslip Telescope Operator, DCT Lowell Observatory
On Fri, Nov 2, 2018 at 12:01 PM Ryan T. Hamilton notifications@github.com wrote:
@LowellObservatory/nightops https://github.com/orgs/LowellObservatory/teams/nightops does this seem useful? Useless? Not sure if this was the original intent/idea or if I've gone down a side street into something else, but this was the easiest thing to roll into the stuff I'm already pulling out of the logs.
The information from LMI depends entirely on the observer so if the star they're watching goes away then the information gets weird (which I think is what happened at the end of the red points) but it's still pretty neat to see twilight leading into darkness in RC1/GDR.
— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/LowellObservatory/NightWatch/issues/6#issuecomment-435458868, or mute the thread https://github.com/notifications/unsubscribe-auth/Aqeu7PFhClanGLnNvyVW4AK34rDN_OgLks5urJaGgaJpZM4X83IG .
He's asking about the LMI plot, I think. I really like it as an idea. I see it having more usefulness than the guider plots tbh.
Qu: Could LMI be used in a series and stars from around the fold mirror shadow be used in the case where another instrument is being used for science?
@astroslip looking at the email notification, the link you followed was to the night operations github group of TOs and a few others. I made that group to tag everyone in one go rather than individually, and I admittedly didn't know how it was going to actually work until I tried it. I wish github put the link to the actual place it is referencing up higher in the email to make it clear.
The actual link to the content is underneath the "—" line in the email, after the line "Reply to this email directly, view it on GitHub". It's a time ordered list of comments/content, with the newest stuff at the bottom.
Still figuring this all out!
@Teznie I'd worry about any stars being vignetted and leading to hard-to-interpret behavior, but if the vignetting is either not too bad or at least stable then it might work.
I think virtual guiding with a probe will work the same without those questions though, at the expense of the extra effort required to keep that going.
I'm not sure it's currently useful to have both RC1 & GDR info on the plot. RC1 is almost always what we use for guiding due to RC2's very limited range of motion.
@hlars-freehub yeah that's a good point, this was really just a "can this be done" sort of exercise; one good thing might be to have it ready to plot (by a button push or something) but have the default just show the usual/expected ones. That would account for the mythical day when RC2 is used as GDR in the easiest/laziest way.
Looking at a few days of these data, the LMI points are great when they're clearly valid, but they can often be a noisy mess for what I'm sure are logistical reasons (analysis box becomes empty when changing fields, or when dithering, etc.). Here's the last few nights, just considering LMI:
And here's RC1+GDR; I left RC1 in for this one since it catches the sunset in the "SkyMean" points on the right Y axis, but I admit that I left it in mostly out of laziness:
Since these are pretty noisy too, I'm starting to think that issue #10 (or some adaptation of those ideas) might be a cleaner/simpler way for a quick look at how the sky is trending. I'll tag folks on that one to start that ball rolling a bit to see if it goes anywhere interesting.
Closing this now because it seems like it's a muddy path that can't really be cleaned up until we reach the rosy LOCUS future; the lack of context on the LOIS points (with respect to binning/plate scale) is a known thing that I'm just not going to deal with. You can look over at another issue ( https://github.com/LowellObservatory/DataServants/issues/22) for my prior notes/thoughts.
The long story short is that while it's theoretically possible to further scrape the LOIS logs as they come in for the needed plate scale/binning info, I don't think it's worth the effort since it can be cleaned up (in LOCUS) at the source via a requirement.
If the crowd/users disagree, it can be revisited sometime "soon."
The most unobtrusive way is to snoop on the broker topics that are basically livestreams of the LOIS logs, and parse the lines accordingly. I'm strongly against other methods such as transferring the log files every X seconds and then parsing them or other such shenanigans.
Ideally this should be an extension of amqparse.py (specifically the parseLOlogs function) and then it could be spun off into a separate function that's called when the right log line is found as part of a greater cleanup of the broker topic parsing I've got going on.
Should keep in mind that we get to specify how things look in a post-LOIS world for Lowell, so it's good to keep in mind how things should change to get this information in a way easier fashion.
@Teznie is there any metadata (name, sky coordinates, etc.) of the star that is being guided upon, or is it really just whatever bright thing looks like it works for the field?
Here's an example of what the relevant log lines lines look like; they'll come thru one at a time on the broker on a .loisLog topic. Some subset of this is probably sent to the other .lois* topics (evident by the "SendAnalysis" lines), but this is a decent first starting point.