NaN is a common value in code that is essentially an error code telling you that that value it found is "not a number". Essentially the calculation of something failed. Perhaps you are dividing by zero or something similar. It is hard to know exactly. Someone will probably have some more specific advice for VPHOT, but I can explain what the error is trying to tell you.
Depends what language the code is. NaN could also mean that you are entering a string (text) rather than a number - but to be fair, the code should take care of this for you!
Attached are two files for which I received "NaN" in the magnitude box. I think this is related to stacking (AIP4WIN version 1) since it seems to happen typically with files that I have stacked because of short individual integration times.
VPHOT is listing the instrumental magnitude as infinity. I've attached the screen shot of that.
Thank you for any suggestions. I can give access to the images in my VPHOT account (in addition to the Dropbox links) if anyone wants to look at the images, FITS headers, etc.
Of note, I uploaded the individual calibrated images and had VPHOT stack them. VPHOT then analyzed the stacked final images without a problem.
Share the images (not just the stacked image) to MZK.
What have you determined from the fits headers yourself? Do they look like your previous images? Note BScale/BZero values. Have you taken such short images before?
I assume your other images have been working correctly? Do you always use SGP?
Clearly something about these images is unusual? How can you say " VPHOT then analyzed the stacked final images without a problem" when you got this report?
Thanks! I've shared the stacked images and the raw images.
The FITS headers look fine to me and consistent between the stacked and raw images.
When exposures are short, I'll typiclly stack as many as it takes to get the total integration time between 10 seconds and 20 seconds. For example, with X Her and 6 second integrations, I had 6 images. One caught scintillation just right and saturated, so I discarded that image. On the second night, 4 of the 6 were saturaged, so I could only stack two, but the total time was still over 10 seconds.
I'm presuming that there is something in the AIP4WIN stacking that caused the problem. When I uploaded the calibrated images to VPHOT, and had VPHOT perform the stack, it was then able to analyze the VPHOT stacked image even though it could not analyze the stacked image from AIP4WIN.
Since I do not know how VPHOT generates the NaN, I'm not sure where to start looking. Best regards.
Hello! I uploaded X HER from last night's run. They stacked fine in MPO Canopus and the stacked image ran fine in VPHOT
Looking over the FITS headers, I wonder if BZERO is causing the problems. I'm not sure how the different programs use this information.
For today's image that works, the values is 3.726800E+004. For the image that gave NaN, it was 0.
I'm not sure how BZERO is used or whether it can or should be edited (if possible) if it might be causing a problem. From what I've been able to find, BZERO should be 32768 for 16-bit images. On the stacked images that did not process, BZERO was 0. I tried to edit this in AIP4WIN FITS editor, but it did not allow me access. Best regards.
Glad you looked at the headers. There are differences! These will cause issues with different software.
Do a search on both "BScale BZero" together to get a little help understanding what they are used for.
Check what each of your different software puts into the fits header and when, i.e., individual vs stacked image.
BTW, why do you choose to stack images outside of VPhot? To reduce the number of images that you need to upload or other? VPhot will easily stack your images.
Hello! I primarily use MPO Canopus for my work flow (particularly for tranformed magnitudes of time series), so I stack with that. Next in line is AIP4WIN since I can put those stacked images into the Canopus work flow easily.
This is the first time I've used VPHOT for stacking. I worked when the other two did not, so I'll compare it for future stacked images.
An interesting thing with the images you shared is that two of them in the VPhot list show exposures of 0 sec even though the headers report 6 sec. Something clearly got messed up with these somewhere along your reduction pipeline. Dividing by zero or working with infinity would certainly not work!
Mike,
This usually means "no data" indicating that the data cell is empty. But I don't know your particular circumstace.
Ed
Hello,
NaN is a common value in code that is essentially an error code telling you that that value it found is "not a number". Essentially the calculation of something failed. Perhaps you are dividing by zero or something similar. It is hard to know exactly. Someone will probably have some more specific advice for VPHOT, but I can explain what the error is trying to tell you.
Thanks,
Bert Pablo
Staff Astronomer, AAVSO
Depends what language the code is. NaN could also mean that you are entering a string (text) rather than a number - but to be fair, the code should take care of this for you!
Please show an example. Is it on the website or in a AAVSOreport?
Thx,
George
Hello! Sorry. I missed the recent posts.
Attached are two files for which I received "NaN" in the magnitude box. I think this is related to stacking (AIP4WIN version 1) since it seems to happen typically with files that I have stacked because of short individual integration times.
https://www.dropbox.com/s/zfeal5jdznhkb00/X%20HER%20V1.fts?dl=0
https://www.dropbox.com/s/5aja1i8g628gk4j/X%20HER%20V2.fts?dl=0
VPHOT is listing the instrumental magnitude as infinity. I've attached the screen shot of that.
Thank you for any suggestions. I can give access to the images in my VPHOT account (in addition to the Dropbox links) if anyone wants to look at the images, FITS headers, etc.
Of note, I uploaded the individual calibrated images and had VPHOT stack them. VPHOT then analyzed the stacked final images without a problem.
Best regards.
Mike
Mike:
Share the images (not just the stacked image) to MZK.
What have you determined from the fits headers yourself? Do they look like your previous images? Note BScale/BZero values. Have you taken such short images before?
I assume your other images have been working correctly? Do you always use SGP?
Clearly something about these images is unusual? How can you say " VPHOT then analyzed the stacked final images without a problem" when you got this report?
Ken
Thanks! I've shared the stacked images and the raw images.
The FITS headers look fine to me and consistent between the stacked and raw images.
When exposures are short, I'll typiclly stack as many as it takes to get the total integration time between 10 seconds and 20 seconds. For example, with X Her and 6 second integrations, I had 6 images. One caught scintillation just right and saturated, so I discarded that image. On the second night, 4 of the 6 were saturaged, so I could only stack two, but the total time was still over 10 seconds.
I'm presuming that there is something in the AIP4WIN stacking that caused the problem. When I uploaded the calibrated images to VPHOT, and had VPHOT perform the stack, it was then able to analyze the VPHOT stacked image even though it could not analyze the stacked image from AIP4WIN.
Since I do not know how VPHOT generates the NaN, I'm not sure where to start looking. Best regards.
Mike
Hello! I uploaded X HER from last night's run. They stacked fine in MPO Canopus and the stacked image ran fine in VPHOT
Looking over the FITS headers, I wonder if BZERO is causing the problems. I'm not sure how the different programs use this information.
For today's image that works, the values is 3.726800E+004. For the image that gave NaN, it was 0.
I'm not sure how BZERO is used or whether it can or should be edited (if possible) if it might be causing a problem. From what I've been able to find, BZERO should be 32768 for 16-bit images. On the stacked images that did not process, BZERO was 0. I tried to edit this in AIP4WIN FITS editor, but it did not allow me access. Best regards.
Mike
Mike:
Glad you looked at the headers. There are differences! These will cause issues with different software.
Do a search on both "BScale BZero" together to get a little help understanding what they are used for.
Check what each of your different software puts into the fits header and when, i.e., individual vs stacked image.
BTW, why do you choose to stack images outside of VPhot? To reduce the number of images that you need to upload or other? VPhot will easily stack your images.
Ken
Hello! I primarily use MPO Canopus for my work flow (particularly for tranformed magnitudes of time series), so I stack with that. Next in line is AIP4WIN since I can put those stacked images into the Canopus work flow easily.
This is the first time I've used VPHOT for stacking. I worked when the other two did not, so I'll compare it for future stacked images.
Thank you for your guidance and best regards.
Mike
Hi Mike:
An interesting thing with the images you shared is that two of them in the VPhot list show exposures of 0 sec even though the headers report 6 sec. Something clearly got messed up with these somewhere along your reduction pipeline. Dividing by zero or working with infinity would certainly not work!
Ken