Modifications to VPhot

All VPhot Users:

Over the past two weeks and especially over the last two days, Geir, George and I have made some changes to VPhot that we hope will significantly improve the queue processing speed. I am not going to go into excruciating detail but give you a summary of what we changed and mention how the changes may impact your images and photometry.

Change 1: Two queue processing operations that support the VSS (Variable Star Search) function in the VPhot webapp (where you conduct your photometry) were deactivated (commented out in the code). These operations added significant delays to queue processing time with perhaps only limited use by members. In other words, it appears that very few members use the VSS tool?

Impact 1: The VSS function no longer works. We hope to move the two queue processing operations into the VPhot webapp in the future but cannot tell you when. I would appreciate knowing who uses the VSS function, not just once or twice but regularly. 

Change 2. One of these two operations also wrote the FWHM value to the database. This parameter is used in the Time Series (which most members use) function. The FWHM values continues to be calculated and saved for images that are plate-solved by VPhot but not for images that are pre-plate-solved and thus do not need additional plate-solving in VPhot. The FWHM keyword is provided in the Fits keyword provided by some plate-solving software (e.g., Maxim). If you make sure it is added this can be used to easily solve this issue. 

Impact 2:   For all those who pre-plate solve their images (I do and have been pushing hard for others to do the same), you can continue to use Time Series but you need to THINK about the procedure rather than just press the button. Since the FWHM of each image is not available, the use of the "automatic" aperture selection skips to the "fixed" aperture selection while the time series runs. Therefore, the value in the fixed aperture box needs to be set carefully. The default of 5 pixels works but that may not be the best choice for your images! So you should determine what the best aperture (radius) in pixels is for your system. I use one value for virtually all my images. My system parameters are stable (e.g., I bin 2x2 on my scope) and never (rarely) changed. I suspect the same is true for your system. You can confirm the FWHM after you run the Time Series and look at the FWHM graph shown on the time series results page. This info can be used to determine what fixed aperture value works best for your system. If needed you can change the fixed value on the time series execute page and run the series again to get the best photometry. You can leave the default at 5 pixels and it will work for most images but I have noticed that the photometry of fainter targets are impacted in a small but measurable way. So be careful!

Conclusions: We have made these changes to significantly improve queue processing speed. I feel that these changes do that. George is creating some new metrics to prove whether I am correct (or not). It does impact some users. In fact, one user has just reported the loss of VSS functionality while I'm writing this post!

We are able to revert to the original code at any time but need to be convinced that this is worth it as it relates to the improvement in processing speed. We also are planning to move these functions into the webapp.

I have now told you what has been done. Now I'll have to deal with the fallout from this modification. I know everyone will not be happy. I'm strong but please understand what we are trying to do in terms of throughput! I'm listening.  

Ken