Welcome to iraf.net Thursday, March 28 2024 @ 07:10 PM GMT


 Forum Index > Help Desk > General IRAF New Topic Post Reply
 instrumental magnitudes from
   
BGMB
 06/04/2014 04:53PM (Read 3300 times)  
+----
Newbie

Status: offline


Registered: 06/04/2014
Posts: 3
Hello,

I wrote some Pyraf scripts that preprocess, platesolves, perform aperture photometry of DSLR images. The instrumental values calculated by “phot” are then transformed to standard B,V magnitudes following the so called “CS” (Citizen Sky) method.

I run such scripts on a Fedora11 linux box with Scisoft 7.7.0 (Iraf 2.5).

So, after 4..4 tries - aimed to measure the magnitude of the well known R Leo variable and compare my measures with the AAVSO light curve – I found a systematic error - about +0.3 mags in instrumental G band compared to the average V value of the curve and now I’m checking all the path backwards to find what’s wrong with.

I found that such error is not originated by the magnitude transformation process, because if I consider untrasformed magnitudes I find almost the same error while measuring other comparation stars, having well known catalog magnitudes.

Then I checked the values calculated by the phot task – I placed in a spreadsheet the formulas took from “phot” help page:

Rapert, sum, area, and flux are the radius of the aperture in
scale units, the total number of counts including sky in the
aperture, the area of the aperture in square pixels, and the total
number of counts excluding sky in the aperture. Mag and merr are
the magnitude and error in the magnitude in the aperture (see
below).

flux = sum - area * msky
mag = zmag - 2.5 * log10 (flux) + 2.5 * log10 (itime)
err = sqrt (flux / epadu + area * stdev**2 + area**2 * stdev**2 / nsky)
merr = 1.0857 * err / flux


Then I entered the same input values my script gives to “phot” – note that I set the zmag value to zero.

As results, the flux matches the phot output value, same happens to merr, but mag is very different, the spreadsheet gives -11.349 while phot says -3.964.

I find the same difference measuring other comparation stars, a difference of -7.385 I could not understand from where it comes and I hope someone of you could do that Smile

The phot output files says ZMAG is set to zero as expected.

I post here the output file, probably it tells you more than my words do.


#K IRAF = NOAO/IRAFV2.15.1a version %-23s
#K USER = fedora name %-23s
#K HOST = algol computer %-23s
#K DATE = 2014-04-07 yyyy-mm-dd %-23s
#K TIME = 23:39:53 hh:mm:ss %-23s
#K PACKAGE = apphot name %-23s
#K TASK = phot name %-23s
#
#K SCALE = 1. units %-23.7g
#K FWHMPSF = 4.88 scaleunit %-23.7g
#K EMISSION = yes switch %-23b
#K DATAMIN = INDEF counts %-23.7g
#K DATAMAX = 427.7 counts %-23.7g
#K EXPOSURE = EXPTIME keyword %-23s
#K AIRMASS = AIRMASS keyword %-23s
#K FILTER = FILTER keyword %-23s
#K OBSTIME = DATE-OBS keyword %-23s
#
#K NOISE = poisson model %-23s
#K SIGMA = 0.74 counts %-23.7g
#K GAIN = "" keyword %-23s
#K EPADU = 1.3125 e-/adu %-23.7g
#K CCDREAD = "" keyword %-23s
#K READNOISE = 0. e- %-23.7g
#
#K CALGORITHM = centroid algorithm %-23s
#K CBOXWIDTH = 29.28 scaleunit %-23.7g
#K CTHRESHOLD = 0. sigma %-23.7g
#K MINSNRATIO = 1. number %-23.7g
#K CMAXITER = 10 number %-23d
#K MAXSHIFT = 3. scaleunit %-23.7g
#K CLEAN = no switch %-23b
#K RCLEAN = 1. scaleunit %-23.7g
#K RCLIP = 2. scaleunit %-23.7g
#K KCLEAN = 3. sigma %-23.7g
#
#K SALGORITHM = mode algorithm %-23s
#K ANNULUS = 20. scaleunit %-23.7g
#K DANNULUS = 25. scaleunit %-23.7g
#K SKYVALUE = 19.25 counts %-23.7g
#K KHIST = 3. sigma %-23.7g
#K BINSIZE = 0.1 sigma %-23.7g
#K SMOOTH = no switch %-23b
#K SMAXITER = 10 number %-23d
#K SLOCLIP = 0. percent %-23.7g
#K SHICLIP = 0. percent %-23.7g
#K SNREJECT = 50 number %-23d
#K SLOREJECT = 1. sigma %-23.7g
#K SHIREJECT = 5. sigma %-23.7g
#K RGROW = 0. scaleunit %-23.7g
#
#K WEIGHTING = constant model %-23s
#K APERTURES = 5 scaleunit %-23s
#K ZMAG = 0. zeropoint %-23.7g
#
#N IMAGE XINIT YINIT ID COORDS LID \
#U imagename pixels pixels ## filename ## \
#F %-23s %-10.3f %-10.3f %-6d %-23s %-6d
#
#N XCENTER YCENTER XSHIFT YSHIFT XERR YERR CIER CERROR \
#U pixels pixels pixels pixels pixels pixels ## cerrors \
#F %-14.3f %-11.3f %-8.3f %-8.3f %-8.3f %-15.3f %-5d %-9s
#
#N MSKY STDEV SSKEW NSKY NSREJ SIER SERROR \
#U counts counts counts npix npix ## serrors \
#F %-18.7g %-15.7g %-15.7g %-7d %-9d %-5d %-9s
#
#N ITIME XAIRMASS IFILTER OTIME \
#U timeunit number name timeunit \
#F %-18.7g %-15.7g %-23s %-23s
#
#N RAPERT SUM AREA FLUX MAG MERR PIER PERROR \
#U scale counts pixels counts mag mag ## perrors \
#F %-12.2f %-14.7g %-11.7g %-14.7g %-7.3f %-6.3f %-5d %-9s
#
section_014_G_instr.fit203.000 203.000 1 coords.lst 1 \
204.733 204.471 1.733 1.471 0.145 0.108 0 NoError \
19.17386 0.5521118 0.5185387 3506 1601 0 NoError \
30. 1.186888 G_instr 20:43:52 \
5.00 2150.689 78.82 639.4056 -3.322 0.038 0 NoError
section_017_G_instr.fit203.000 203.000 2 coords.lst 1 \
204.396 204.984 1.396 1.984 0.129 0.097 0 NoError \
18.67055 0.4660479 0.4327427 3838 1271 0 NoError \
30. 1.208265 G_instr 20:43:52 \
5.00 2624.904 78.69117 1155.697 -3.964 0.028 0 NoError


Thanks



 
Profile Email
 Quote
fitz
 06/08/2014 06:58PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040

I don't see anything obviously wrong, systematic errors like this are usually tracked down to something simple such as a missing/incorrect gain or zmag value, a background value error, integration time scaling etc.

Since you mentioned this was using a DSLR then there may be other considerations such as non-linearity in the detector. A discussion of this can be found at e.g. http://articles.adsabs.harvard.edu//full/2007SASS...26...67H/0000067.000.html, the upshot is that DSLR is good for differential photometry but not absolute. Perhaps the reference will help, otherwise I hope somebody else has done something similar and can offer advice.

 
Profile Email
 Quote
BGMB
 06/08/2014 09:21PM  
+----
Newbie

Status: offline


Registered: 06/04/2014
Posts: 3
Hello Fitz,

Quote by: fitz


I don't see anything obviously wrong, systematic errors like this are usually tracked down to something simple such as a missing/incorrect gain or zmag value, a background value error, integration time scaling etc.
Since you mentioned this was using a DSLR then there may be other considerations such as non-linearity in the detector. A discussion of this can be found at e.g. http://articles.adsabs.harvard.edu//full/2007SASS...26...67H/0000067.000.html, the upshot is that DSLR is good for differential photometry but not absolute. Perhaps the reference will help, otherwise I hope somebody else has done something similar and can offer advice.



yes, I read that article and faced almost all the problems you listed above. Despite the long post I wrote, my question was not about
why I have this 0.3 error because I know there could be plenty of causes for.

My question was: why - taking the same input data - the instrumental magnitude resulting from phot output is different from the value I can calculate manually following the formulas listed in phot's help page.
I'm quite sure that phot output is right, but maybe the magnitude calculation takes in count some other parameter that has not been reported in the formula listed in phot's help page, and I'd like to know about.

Thank you

 
Profile Email
 Quote
fitz
 06/08/2014 11:16PM  
AAAAA
Admin

Status: offline


Registered: 09/30/2005
Posts: 4040
why - taking the same input data - the instrumental magnitude resulting from phot output is different from the value I can calculate manually following the formulas listed in phot's help page.


By my calculation the phot value is correct. Using the values from the output for the 'flux' and 'itime' I see

vocl\$this->_split2($m[0]) = 0.0 - 2.5 * log10(1155.696) + 2.5 * log10 (30)
-3.9643058885391

So what are the input values to your spreadsheet? Any chance you used a log() function that isn't really log10()?

 
Profile Email
 Quote
BGMB
 06/09/2014 06:24AM  
+----
Newbie

Status: offline


Registered: 06/04/2014
Posts: 3
Quote by: fitz

why - taking the same input data - the instrumental magnitude resulting from phot output is different from the value I can calculate manually following the formulas listed in phot's help page.


By my calculation the phot value is correct. Using the values from the output for the 'flux' and 'itime' I see

vocl\$this->_split2($m[0]) = 0.0 - 2.5 * log10(1155.696) + 2.5 * log10 (30)
-3.9643058885391

So what are the input values to your spreadsheet? Any chance you used a log() function that isn't really log10()?



Exclaimation
Naah!!! i used log10(), the mistake was caused by redundant parenthesis I placed in the formula:

0.0 - ((2.5 * log10(1155.696)) + (2.5 * log10 (30)))

I should definitely renew my glasses Geek

thank you again


 
Profile Email
 Quote
   
Content generated in: 0.24 seconds
New Topic Post Reply

Normal Topic Normal Topic
Sticky Topic Sticky Topic
Locked Topic Locked Topic
New Post New Post
Sticky Topic W/ New Post Sticky Topic W/ New Post
Locked Topic W/ New Post Locked Topic W/ New Post
View Anonymous Posts 
Anonymous users can post 
Filtered HTML Allowed 
Censored Content 
dog allergies remedies cialis 20 mg chilblain remedies


Privacy Policy
Terms of Use

User Functions

Login