Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
fluxcal_notes [2012/06/13 17:13] amberbfluxcal_notes [2019/09/06 22:52] (current) – removed casey
Line 1: Line 1:
-====== CARMA FluxCal Notes ====== 
  
-===== To Do ===== 
-  * Figure out algorithm for error estimation (currently 15%, or RMS of values) 
-  * check that planet brightness temp is different for different windows 
- 
-===== Telecon, Jun 13 ===== 
-  * online: Amber, Statia, Woojin, Manuel, Doug, Peter 
-  * data transfer issue at Illinois: 
-    * issue with script  
-  * Peter - testing new code with Woojin 
-    * 3 mars tables:  
-      * 1 is marstb original increments of 25 days 
-      * 2 is marstb2 stops at 115 GHz, increments of 6 hours 
-      * 3 is marstb3 1cm to 260 GHz, increments of 1 hours 
-        * this table is ~5 K cooler than old curves at 115 GHz - see Woojin's plots 
-        * need to check at other freq and if spec index is the same, then ask Brian Butler 
-    * can play with these in new miriad - marstb with table= (need to grab tar files for the tables first) 
-    * will build new binaries for school students tomorrow but it is in CVS now 
-    * fluxtest script is in Miriad now 
-    *  
- 
-===== Telecon, Jun 6 ===== 
-  * online: Amber, Statia, Chat, Nikolaus, Andreea, Woojin, Manuel, Peter, Doug  
-  * Woojin: more 1cm data points and 'new' models from Peter 
-    * still trying to sort out what these new models are: 'most recent models of Glenn Orton and Rafael Moreno' from Brian Butler 
-  * Peter:  
-    * new model from Brian Butler on Mars - Jan 2010 - Dec 2020 in 1 hour intervals at 30-1000 GHz (this is becoming the standard model in CASA) - 11 MB 
-    * miriad program marstb will be able to read this soon - use table= to read 1hr cadence 
-    * Uranus and Neptune models - European + North American collaboration. Hofstader model is more appropriate at 1cm, but this model is better at 3mm and 1mm.  
-  * fluxcal on science: 
-    * copy could take a minute or two but it does happen all in one go - check size of visdata  
-    * multiple corr configs - Doug: sci1 track doppler tracking wasn't set up in first NOISE integration - this is nothing to worry about. sci2...?? wideband channels have a bandwidth of 0...maybe first antenna is being flagged by the system. maybe try re-running uvwide to recalculate the wideband channels from the spectral line channels. uvcat just spectral channels out options=nowide. 
-  * Andreea - looking for comments on everything (incorporated my comments) 
- 
-===== Telecon, May 30 ===== 
-  * online: Amber, Statia, Chat, John, Andreea, Doug, Peter, Woojin, Manuel, Tom 
-  * Woojin: added new data points as well as JPL models (from Andreea) to plots 
-    * new data point: Mars track not good (3C84 low elevation, pointing didn't converge) 
-    * 1cm points: 5 or 6 tracks have been tried - planning to add these points soon 
-  * Andreea: looking at 1cm data 2 tracks from May 18 
-    * estimate the flux of 3C454.3 using Uranus and Neptune separately with different fluxes 
-      * JPL Nep 5.2 
-      * JPL Ura 5.3 
-      * CARMA Nep 6.7 (bootflux with nothing specified) 
-      * CARMA Ura 6.6 (bootflux with nothing specified) 
-    * looking now at dataset to figure out which of these fluxes is more appropriate using Mars 
-  * Doug getting Illinois set up 
-    * Peter uses Python package NTHOUGHT? 
-  * fluxcal on science running automated on the high site now, will be running at Illinois soon  
-    * pass on to Manuel once we have fully documented (coming soon) 
-  * Peter contacted Mark Gurwell about Mars models 
-    * passed on to Brian Butler - haven't heard back yet (but Brian Butler is slow to respond) 
-    * been working on table reader in Miriad 
-    * can't officially distribute marstb2.tab (only to 105) until we get okay from Brian Butler 
-===== Telecon, May 23 ===== 
-  * online: Amber, Statia, John, Andreea, Doug, Peter, Nikolaus, Woojin, Manuel, Tom 
-  * Andreea: working on 1cm abstest data 
-    * comparision of Uranus and Neptune models from Mark Holfstader show these models agree with eachother within 2% 
-  * Woojin: still needs more abstest data at 1mm 
-    * John points out that models are very similar at 1mm - 1mm data may not tell us much 
-    * perhaps 1mm Uranus/Neptune data could constrain Mars model at 1mm? 
-  * Mars model: 
-    * best bet seems to be szaCalcMars at 1cm, 3mm (diurnal + seasonal var) and marstb at 1mm (seasonal var only) for now 
-      * szaCalcMars uses a table that is almost identical to marstb2.tab, but has additional diameter columns (both of these tables only cover 26-115 GHz) 
-      * marstb uses marstb.tab - this is what is written into datasets by the online system (this table only covers 43 - 345 GHz) 
-      * Peter is working on a miriad program to read marstb2.tab, therefore making the diurnal variation mars model available in miriad 
-      * Peter will contact Mark Gurwell about getting diurnal variation Mars model good out to 1mm 
-    * fluxcal on science: 
-      * Doug got permissions worked out - we should be getting new datasets today 
-      * python install needed: Doug will check, but the best bet may be to put our own local install of python in our area 
-      * getting julian dates on the high site: high site date calculations are done in C, so we should just use a local copy of a python package to do it. 
- 
-===== Telecon, May 16 ===== 
-  * online: Amber, Statia, Chat, Woojin, Manuel, Doug, John, Andreea, Tom 
-  * fluxcal on science: 
-    * Doug gave us a username at Illinois and a directory to work in 
-      * where should we put our scripts and other files? /home/fluxcal/ ? 
-      * where do the miriad files live? (so i can grab one for testing)  
-      * would you like to copy files to our directory as they come in? script currently just makes a copy of the full path file to local directory, so this is not totally necessary.  
-      * what is the best way to automate this?  
-        * cron job, python script just always running in a screen, sleep for 30 min  
-  * Woojin: 
-    * more datasets - 3mm regime data looks good, large scatter in 1mm regime 
-    * weather in 1mm data not terrible...why so much scatter? Woojin is doing a phase-only selfcal using the planet... 
-    * Mars model: cross points cannot be explained by Mars diurnal variation - what is going on? lots of scatter in daytime pointing - could this be the issue? 
-  * Tom:  
-    * fluxcal_sci2 now gets abstest sources when they're up. Needs an endtrack though. 
-    * eventually want to get just one script for all of this 
-  * Peter: ? 
-  * email obs and Nikolaus about how to run abstest 
- 
-===== Telecon, May 9 ===== 
-  * online: Woojin, Manuel, Amber, Statia, Doug, John, Andreea, Peter 
-  * Woojin - new plots of brightness temp versus freq 
-    * want to sample higher frequencies in the 3mm band - change track for today to 105-110 GHz 
-  * Nikolaus try to get abstest going in sci2 - will contact Tom offline 
-    * actually - possible to make 1 fluxcal script work for sci1 and sci2? Nikolaus will take a look 
-  * Peter - hasn't gotten to the online system model stuff 
-  * Doug - has the go ahead from Leslie, tracking down the IT guy 
- 
-===== Telecon, May 2 ===== 
-  * online: Woojin, Manuel, Amber, Statia, Chat, Doug, Tom, Andreea 
-  * Woojin: plots from abstest last week 
-  * how can we get brightness temperature from planet flux? 
-    * Statia 
-    * Woojin 
-  * Andreea doing same as Woojin but using JPL models 
-  * MARS pipeline model is identical to marstb != SZA model w/ diurnal variation 
-    * TODO get good MARS model in online system (but Erik's szacalcmars only good at 3mm and 1cm) 
-  * Doug will let us know about getting set up at Illinois this week - maybe we can bother Lisa 
- 
-===== Telecon, Apr 25 ===== 
-  * Woojin - abstest: still needs 1mm 
-    * U+N still give consistent values for other cals, but M gives slightly smaller value by 5% (but much closer than two weeks ago - 15%) 
-    * reduction script applies different brightness temperatures in different windows 
-  * Jupiter model - constant brightness temp (also too big to be used) - actually may be okay for sci2...? Might be worth taking a look at... 
-  * Andreea - also working on abstest data from March 
-    * smaflux - links don't work, Tom contacted guy (Eric Weistein) but hasn't gotten answers...odds of making sense of smaflux data are low 
-  * Peter - nothing yet 
-===== Telecon, Apr 18 ===== 
-  * Woojin: abstest tracks from last week (3mm - 93.5 GHz) -  
-    * Mars and Jup gave same values for 3C84, but 20% lower than values from U+N 
-    * we should get brightness temp of U+N based on Mars calib 
-  * Peter - same as last week, check against what Woojin has (he will email around) 
-  * us: 
-    * add a check of flux versus last entry and flag to check it if  
-===== Telecon, Apr 11 ===== 
-  * waiting to hear from Doug about getting set up at Illinois (emailed Apr 5) 
-  * DRIP comp stalled b/c webpage hasn't been updated since Mar 16 - emailed Doug Apr 5 
-  * sent notes on webpage to Ted Yu (got short response) 
-  * TO DO: 
-    * Peter: sort out what planet models the online system is using: let us know the models used, the code that does this, any tables referenced, and where the code and tables live on the high-site. 
-    * Andreea: re-work primay fluxcal document, send a summary of relevant information out to everyone for discussion at the next telecon 
-    * Nikolaus/observers: run fluxcal list=abstest (with NO endtrack specified) at 23 and 7.5 LST (about an hour each) 
-    * Woojin: analyze fluxcal abstest data when they are taken 
-    * Amber,Statia,Chat: continue testing the new fluxcal on science script; get set up at Illinois when Doug is able to help us with that 
- 
-===== Notes on Webpage (Telecon, Apr 4) ===== 
-  * http://carma.astro.umd.edu/cgi-bin/calfind.cgi 
-  * source selection: 
-    * ra dec input - text input should be the default 
-    * searching by cal name 
-    * extended sources? script writer knows! Depends on array. 
-  * show all 3 wavelength band plots at once? 
-  * SolSys date? what is this? 
-  * error bars - how to handle points that don't have an error? very large error bar? a different color point? 
-  * identify change over when we switch to new error reporting 
-  * should print FluxSource.cat entries below the plot 
-  * plot fluxes versus freq as well? calc rough spectral index? 
-  * changing plot limits: 
-    * okay to just enter min, not max 
-  * flux val reporting:  
-    * report avg and scatter for fluxes within plotting window instead of current value 
- 
- 
-===== Telecon Jan 31 ===== 
-  * set up telecon w/ DRIP people (Doug Freidel) to compare flux results there!!! 
-  * SMA, PdBI values for polarization comparisons? 
-    * 3C286 paper on archiv  
- 
-===== Day of Action: occupy the lounge to fight the 20% - Dec 16, 2011 ===== 
-Looking over compare3 results (Nov 25 - Dec 9): 
-  * empty datasets: 
-    * Why so few? Grading! quality script says a B grade but our script does not do a PACS reduction, so the straight grade was a D and failed the first check. (For 1mm and 3mm tracks this will be most relevant) 
-    * mostly seems to be bootflux crashing (due to resolution issues) -> change new script to catch this bootflux failure and stop the reduction? 
-  * just old datasets: 
-    * sci2 tracks (PACS) weren't getting run Nov 25-29 due to run_gainCheck issue (resolved by AB, 11/29) -> this explains all but one of the just old tracks 
-    * cx332 track has an F grade so didn't run through new 
-  * datasets with fractional diff > 0.5 seem to mostly be due to bad data in pacs datasets because of bad baselines. We still don't know why the old script was able to handle this though... 
-  * analysis of the 5-40% dataset - what have we learned? 
-    * at 1cm, using all widebands is going to be an issue w/spectral index of the source - discuss this on the telecon perhaps.  This can cause a ~10% change in flux over 8 GHz. 
-    * we need to update amp flagging in the new script - amp(500) insufficient - need to track down which bands it is happening in and flag those bands in all ants 
-    * DATASET DETAILS: 
-      * 1224+213  c0791B.3D_88NGC471.7 -- brought within 5% after adjusting for old script's rounding error (it rounds 1.11 to 1.2, which is weird) 
-      * 1224+213  c0791B.3D_88NGC471.9 -- rounding error 
-      * 0108+015  c0852.1D_230NGC062.5 -- within 7% after rounding error; nothing obviously wrong with plots in old script 
-      * 0108+015  c0852.1D_230NGC062.3 -- there were high amplitudes on C7 ONLY during the planet observation.  This showed up in the amp vs. uvdist plot at the end of the old script.  Flagging C7 made a HUGE difference: 
-        * NOTE: the MFCAL failed when solving for the passband, though plotting the passband in calibrators.mir with smagpplt looked fine afterward... 
-        * Before flagging: 3C84 2.500 / 2.280 (old/new)  
-        * After flagging: 3C84 5.977 / 5.816 (within 3%) 
-        * Before flagging: 0108+015 0.500 / 0.440 
-        * After flagging: 0108+015 1.167 / 1.105 (within 6%) 
-          * These numbers are much closer to the c0852.1D_230NGC062.3 numbers 
-        * MORAL OF THE STORY: Flagging C7 was hugely important... 
-      * 3C84  cx327.1SH_31DQFlex.15 -- no phase coherence on C21 for 1st 1.5 hours (inc. planet observation). Flagging C21 brought flux of 3C84 from old script within 2% of new script value. Note: For whatever reason, flagging C21 did not help the script's other calibrator 0530+135, which disagreed by 10%. I ran the new script on window 1 only, and got agreement of better than 1% between the two versions. There was nothing clearly different about window 1.  
-      * 3C84 c0782.7D_230L1551I.1 The amplitude vs. time plots vary for several antennas. The output of bootflux varies from 6.3-8.1. Not sure how to fix this without an amplitude selfcal. Tried flagging the worst offender (C12) but this did not improve matters. What to do? 
-===== Telecon Dec 2, 2011 ===== 
-  * Mark H on the line to discuss models 
- 
-===== Telecon Nov 18, 2011 ===== 
- 
-  * Planet models -  
-    * Orton models may not be an option b/c may not be done soon and they want recognition in some way? 
- 
-===== Working-Time October 20, 2011 ===== 
-Sorting through the results from the new/old fluxcal comparison: 
-  * 248 datasets total 
-  * empty: 14 - IGNORE 
-  * just old: 24 
-    * WHY did new fluxcal ignore?? 
-    * new cuts are A or B and len >= 2 
-  * just new: 117  
-    * are they good?  
-    * why didn't old do it? (cal list and prim flux cal) 
-    * checked cal list and prim flux cal - still 65 that have prim cal and acceptable secondary cal...? 
-  * both: 93 
-    * start by looking at frac diff > 0.5 datasets - which is right? 
-    * explosions may be due to passband failing to converge 
- 
-**Action Items:** 
-  * calibrators list - should we only do certain cals? 
-  * email John for a summary of how his program works 
-  * add something to check for convergence of passband 
-  * 1 bad baseline can kill it - maybe some flagging to check for crazy amps at the start? 
-  * capitalization issue - **DONE** (Amber fixed comparison script) 
-  * log file issue - **DONE** (Amber fixed fluxes_temp.py and run_gainCheck.csh to write two different log files for sci1 and sci2...hopefully it's working...gainCheck hasn't run yet..) 
-===== Telecon October 7, 2011 ===== 
- 
-  * Error discussion: 
-    * Big problem: some tracks have high variation in calculated fluxes from measurement to measurement (bad weather?), but others have small variations but a smooth change from high to low (changing tau and/or RMS?) 
-    * We need to somehow reflect the weather during the track when we report errors on flux measurements...if there are 10 measurements of a calibrator's flux within a week of your track, you want to choose the measurement taken during the best weather, which should be reflected in the error in that measurement. 
-    * How do we robustly "pump up" the statistical errors to reflect the weather?  Use the standard deviation of the results (this was discussed before)? 
-    * What if there are phase variations on timescales smaller than the integration time, even if there's good weather (still get decorrelation)? 
-    * What about when tracks have a smooth change?  Could this be elevation dependence (T_sys should take that out).  If not, how do we deal with that?  Do we take a certain time period during the track?  Do we reject the track altogether?  How do we decide to do so?  Weather grade?  (max-min)/median? 
-      * Is T_sys being taken out????  Should we take it out ourselves?   
-      * If this really isn't being done, should we put a calculator on the CARMA calibration website that corrects for elevation? 
-    * Maybe we need to make the weather-grade cut even higher, because presumably tracks that have a smooth change throughout show smooth changes in tau and/or RMS, which should get worse weather grades. 
-    * This may be an unsolvable problem...we should probably just cut at a high grade, and then report tau and RMS in two columns next to the flux values and be done with it. 
-      * We should report the weather grade (which takes array config. into account), and how the grade is calculated 
-      * We should report the number of times fluxes were calculated 
-      * For the passband calibrators, we should report the errors on the repeatedly observed gain calibrator 
-    * We need to put systematic (model) errors on a fluxcal website, but report our statistical (or modified statistical) errors for each flux measurement. 
-    * Could val Vleck correction be a problem? 
- 
-===== Telecon August 31, 2011 ===== 
- 
-  * Getting John's script to work for us: 
-    * error handling - what is actually a good error estimate? 
-    * should this be run on bad datasets? 
-    * need to check out what script is doing before going live with it 
-      * automatic flagging reasonable? (flags on selfcal gains) 
-  * things to add: 
-    * length of track  
-    * weather grade 
-    * algorithm on bootflux output 
- 
- 
-===== Telecon June 24, 2011 ===== 
- 
-  * Woojin: 
-    * weekly list - 5 calibrators - purpose = secondary flux calibrators (passband) 
-    * monthly = full list = 209 or 290? calibrators = all miriad calibrators  
-      * mainly taken during array config change 
-    * uses Miriad bootflux task - planetary models in source code directory: planet.for 
-  * Planetary models (Andreea) 
-    * compare WMAP planetary models with some of the models: 
-      * Mars looks good 
-      * Neptune, Uranus and Jupiter seem off 
-        * Statia's Neptune model - Andreea email with Statia to compare Neptune model 
-  * Our stuff 
-    * more thought needs to go into errors 
-    * transfer to using John's scrips - uses all bands and also does sci2 properly 
-      * uses all the continuum bands (USB and LSB) 
-      * Woojin raises issue of averaging all continuum bands 
-      * freq reported is LO1 - not good for sci2 especially 
-  * Tom Plagge 
-    * szaflux altered slightly version of smaflux 
-      * has it's own planetary models - Tom added updated version of Mars model 
-      * probably not necessary to switch to this from bootflux for sci2...just make a few tweaks to bootflux code? 
-    * sci2 calibration stuff: 
-      * corrected aperature efficiency for 3.5m's in miriad - fixed now 
-      * MWC349 calibration off of Mars model seems to give consistent results (previous work using Neptune and Uranus yielded inconsistent results) 
-  * Planetary models - compare between different institutions 
-    * Uranus model from Gerwell that SZA has isn't good anymore? 
-    * SMAflux uses Weinstein's model - not quite the same as WMAP 
-      * Tom in contact with Weinstein - should get his code? 
-  * PLAN GOING FORWARD: 
-    * combine fluxcal on science with John's -> talk with John offline 
-      * more simple website for PI's to check flux history - better interface to FluxSource.cat 
-      * Xplore shows flux history?? 
-      * calflux also does this? 
-      * which/how many bands to use for fluxcal reduction -> need to learn about planetary models first 
-    * document the origin of the planetary models 
-      * see how Statia's new models change results from old models 
-      * what models should we be using?? - how do we get these into the Miriad header -> RTS group 
-      * Andreea and Woojin will look at where all the planetary models come from  
-    * Consistency between different bands on MWC349 and other calibrators 
- 
-===== Meeting June 8, 2011 ===== 
- 
-  * look at the not-passed tracks compared to John's 
-    * comparing John's values to historical not conclusive - mostly 1cm. 3C454.3 is half of past average value at 1cm. 3mm data point reasonable. 
-  * email John with our findings and suggestions 
-    * better calculation of errors - 15%?? 
-    * rejection of scripts based on weather and track length 
-    * get the 1cm calibration working properly 
-    * don't assume gains of 1 for tracks going into FluxSource.cat 
- 
-===== Meeting May 23, 2011 ===== 
- 
-  * check our results against Tom P's 1cm results? 
-  * update list of calibrators - 1cm cals from Tom P? 
-  * statia will look at neptune models from Apr 27 email 
-  * amber will keep track of good and bad tracks this week to compare with John's calibrator table 
-    * then send different accept/reject datasets to people to investigate 
-    * perhaps accept/reject is the more important thing (versus flagging ants, etc.) 
-    * if this is the case, produce a short plotting thing to determine whether to accept - then use what script?? 
-  * look at John's script! 
- 
-===== Telecon April 19, 2011 ===== 
- 
-    * Talk to tom plagge about what 1cm sources should look like 
-    * Are the planetary models any good at 1cm? 
- 
- 
-===== Meeting April 6, 2011 ===== 
- 
-Agenda:  
-  * What we're doing 
-    * weekly tasks 
-    * status of script 
-      * look for purpose (in select=) to grab the BP versus phase cals 
-  * How is it used? 
-    * (effort = usefulness?) 
-    * FluxSource.cat used by selfcal 
-      * picks freq in band but does some time averaging? 
-      * if you put a local version of FluxSource.cat, selfcal will read that  
-      *  
-  * How can we make it more efficient? 
-    * more useful 
-      * something like SMA website? (show IDL program) 
-      * script writer uses FluxSource.cat? 
-    * less time consuming 
-  * Support 
-    * for code? 
-  * Other issues: 
-    * who else is adding entries to FluxSource_newadd.cat? 
-    * what is happening to the Flux runs at CARMA? Why? 
-    * errors good? 
-    * could this be done in quality? what about John's script? 
-      * perhaps when quality runs, if track is good, set it aside for fluxcal. Use grep to get grade and time? 
-    * where do the coordinates come from? is this the list of 'normal' calibrators we should be looking at? 
-  * THE PLAN: 
-    * send less files to fluxcal'er based on quality grade? 
-    * or...just making quality run this? Look at script (Katey) 
-    * how is selfcal using this? is it smart? 
-    * getting plots online? - purge obs webpage? put this on external site page (use at your own risk) website run by Nikolaus and Tom 
-    * Talk to Woojin about what he does 
-    * Meredith looking into planet/moon cal