Earthshine blog

MOON.csv – uses the GOTOMOON and MOVEMOONTOREF script commands to take lots of images in all filters. Takes 11 images at a time through B,V,VE1,VE2, and IRCUT filters, then loops back. 100 times.

The present version of GOTOMOON does not put the Moon in the center of the image field. We understand why that is, now: Ingemar Lundström spotted that there is a table-lookup based on ‘nearest previous neighbor’ rather than an actual interpolation. As the table is spaced at 2-minute intervals the Moon will slide from image-edge to image-center at 2-minute intrvals, which is what we see. This will be fixed in a later version of GOTOMOON.

DOMEAZ placed in a script appears to work well – i.e. no crazy round-trips, and works well in the East at azimuths like 75 degrees.

DITHERMOON.csv – takes ‘dithered’ images of the Moon – i.e. Moon moves about in two nested Releaux triangles. All filters. Takes about an hour to go through all filters at all dithered positions.

LOOPING.csv and FFdusk.csv – a pair of scripts that are used to start and do flat-fields at DUSK (i.e. not dawn). LOOPING.csv is started before dusk and takes B-band images on the NAS – the user checks if the exposure level is such that the event has begun. When the level is right (i.e. not saturated and in the 50000s) then a Normal Shutdown is performed, System_Data_Table.csv is edited and FFdusk.csv is placed instead of LOOPING.csv. Then that is started in the MASTER CONTROLLER and that should now run through the dusk event for about 20-30 minutes extending the exposure times in such a way that well-exposed images are obtained all the way until full darkness. Tricky to do due to the ‘bump’ during dusk and also if there are any clouds, watch out.Well, the ‘bump’ is NOT visible here. Typical. But usually there is a ‘bump’ on the dusk part of the bottom curve for illumination (at 6PM). That bump can cause you to make a false start so that later the light is too high and all the images end up over-exposed. The nump lasts about 15-20 minutes. Good example on the dawn shoulder! Might be clouds low on the horizon or whatnot.

ALTAIR.csv, JUPITER.csv and all STARNAME.csv scripts – have the coordinates of the star in the script, so only start these scripts if that object is above the horizon! Loops through all filters with (somewhat) appropriate exposure times.

Lots of thin cirrus! 9 degrees C. Taking lunar images. Will follow the Moon up in case it clears before dawn.

Can confirm that GOTOMOON script command works – goes right to the Moon. [Added later:] but, weirdly, seems to drift slightly. Since the table is OK it must be the calibration that goes slightly off – polar axis alignment issue?

DOMEAZ was supposed to put the dome where the telescope is pointing – and it worked for a while, and then started sending the dome off to strange places. Perhaps some homing is needed on the dome before using the command?

Testing the combination

GOTOMOON
MOVEMOONTOREF

to see if it keeps the Moon centered. At least the MOVEMOONTOREF does not send the telescope anywhere crazy.

Nice screendump of what the Front Camera Saw earlier today. The Pleiades!

I have spent some time examining to what extent GPUs could help us speed up scattered light fitting of ideal moon images to the observed images, while visiting Swinburne in Melbourne.

Ben Barsdell (Swinburne) had some c++ code to convolve two fits files using an NVIDIA compatible GPU (GTX480) running CUDA. The FFT library is FFTW, the same as I have been using for CPU-based modeling of the scattered light.

Upper left: ideal lunar image (intensity is log scale).
Upper right: convolved with our best PSF using CPU based FFT.
Lower left : convolved with PSF using GPU.
Lower right: ratio of the two methods (seen in more detail below).

On a desktop my fortran code calling FFTW does the three FFTs needed —
ideal moon image, psf image, their multiplication in the Fourier
domain, and the inverse FFT for the final result — in about 1100
milliseconds (ms). (This excludes the time needed to insert the 512×512
images into 1536×1536 images to sufficiently reduce edge wrapping
effects, which brings the total runtime to about 3000 ms). So the FFTs
are taking about 300 ms each.

Using the GPU, we attained FFT
speeds of about 40 ms each, a speed of a factor of 10 or so. This is
typical of what Ben expects for such applications (he is doing a careful
study of the types of astronomical problems GPUs can be profitably
applied to, and where the bottlenecks typically lie.)

Ostensibly
this means we can speed up our light modeling code by about 10 times — possibly
quite a bit more because the overheads per modeled image can be reduced
quite a lot by careful programming, since we want to explore a large
parameter space, but don’t need to do the same overheads each time we
run.

VERY IMPORTANT: the CPU code did the FFTs in double complex precision, whereas the GPU was doing single complex precision.

We
compared the output images of both methods — for the case of scattered
light from an ideal moon with a power law fall off PSF with a slope of
about r^-2.8.

VERY IMPORTANT: there is significant structure left in the methods if we divide the CPU output by the GPU output, as shown int he image above.

The scatter in the mean about 1.0000 is 2.028E-4 and there is a frame minimum of 0.9936 and frame maximum of 1.003, so the deviation from unity in the ratio of the two methods is not worse than ~0.7% anywhere on the frame. There is certainly structure, and it looks like it might be too much for our purposes! (We would like this to be better than 0.1% at the very worst). We are checking if this has to do with the single precision used.

Unless this problem can be solved, it is not clear that the speed gain with the GPUs
is worth having!