This is an old revision of the document!
Table of Contents
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
- fluxcal on science
- memo out this week
- maybe try this on dedicated tracks - send script to Woojin
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)
- 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