Forum Replies Created
-
Posts
-
First off, I’ve verified my stacking code does the Right Thing by digging out some old images of (532) Herculina where it is by far the brightest object in the field and so there’s no chance of missing it.
To answer your question, the (slightly abridged) MPC ephemeris for Leda gives
Date UT R.A. (J2000) Decl.
2019 06 26 000000 17 02 01.7 -22 07 28
2019 06 26 001500 17 02 01.4 -22 07 27
2019 06 26 003000 17 02 01.1 -22 07 26
2019 06 26 004500 17 02 00.9 -22 07 25
2019 06 26 010000 17 02 00.6 -22 07 25
2019 06 26 011500 17 02 00.3 -22 07 24and my subs were taken between 2019-06-26T00:20:10 and 2019-06-26T01:12:21 inclusive, with a mid-point of 00:46:15.
The brightest pixel in the indicated blob lies at 17:02:01.3 -22:07:26 according to the ds9 viewer.Good agreement, in other words, especially as the plate scale is 1.42 arcsec/pixel..
You are much more experienced at this sort of thing than I — it’s my first attempt — so how much credence would you place on the identification?
It’s pretty clear that when I next attempt to image Leda I should aim for a much longer total exposure time.
Here’s the stack I made. The red arrow might, just might, indicate Leda but I’m far from convinced. It’s in about the right place and it’s not trailed like the other stars. Unfortunately, it also looks like it may be noise.
I’ve long had them all installed. The problems lies in the version mis-matches. The latest tarball still tries to link against versions which are not on my system, they being either newer or older.
I’m quite willing to keep the sources secret if you wish, even though my own code is almost always released under a BSD-like license.
Minor problem. Your tarball contains dynamically linked binaries which link against versions of libraries not installed on this Ubuntu system. For instance:
pcl@thoth:~/Nick$ ./fcombine
./fcombine: error while loading shared libraries: libnetpbm.so.11: cannot open shared object file: No such file or directory
pcl@thoth:~/Nick$ locate libnetpbm
/usr/lib/libnetpbm.so.10
/usr/lib/libnetpbm.so.10.0
/usr/share/doc/libnetpbm10
/usr/share/doc/libnetpbm10/changelog.Debian.gz
/usr/share/doc/libnetpbm10/copyright
/var/lib/dpkg/info/libnetpbm10.list
/var/lib/dpkg/info/libnetpbm10.md5sums
/var/lib/dpkg/info/libnetpbm10.shlibs
/var/lib/dpkg/info/libnetpbm10.triggersLikewise, my libwcs is in /usr/lib/x86_64-linux-gnu/libwcs.so.6 whereas the binary calls for libwcs.so.5
Would it be possible to have either source code (preferable) or statically linked binaries please?
Thanks.
Thanks Nick, this sounds very much like what I’m looking for. As for using the CLI, that’s what I generally do anyway.
This morning I kludged up a Perl script to modify the CRVAL[12] cards in the FITS headers in attempt to persuade SWarp to stack the images with an offset. Not very successful though. Ether I screwed up the code or the total exposure just wasn’t long enough because I can’t see anything circular on the stacked image — just lots of trailed stars.
1/32K difference in flux corresponds to a roughly 1/32 millimag dip in brightness. Either I’m missing something important, which I do quite often, or I’d change “tough” into “a chance somewhere between nil and negligible”. That said, I’m a great fan of understatement.
In the ARPS meeting today we were advised, correctly in my opinion, to concentrate on objects with a transit depth of at least 10 millimags. Three hundred times deeper, in other words.
My experience is that good observations of a transit depth of, say, 5 millimags is achievable but not entirely trivial. I couldn’t manage one millimag.
The optical variability is measurable by amateurs. I was paying attention to your “visual or CCD” request, honest!
See http://www.threehillsobservatory.co.uk/astro/astro_image_33.htm for instance, where Robin Leadbetter presents his images and http://www.threehillsobservatory.co.uk/astro/pulsar_detection_1.htm where the technique is described.
I’d expect more to come from the hemisphere around the solar apex but we’re going to be in the small number statistics regime for a long time yet. Even if interstellar objects are found annually it will be a few decades before the statistics are good enough to make a definitive statement.
I see very little chance of determining their original star. Unless they were ejected very recently from a very close neighbour the perturbations from other stars will make the trajectory very curvy. It takes a long time to travel anywhere at only 30km/s (chosen because it make the arithmetic easier — it is 0.0001c). At that speed it takes over 3 million years to travel 100 parsecs — close by in galactic terms.
Standard false alarm. Happens all the time. Nothing to see here, move along please.
This is one reason why I run local astronomy.net servers on my TCS, laptop and two main analysis machines. If you can spare a few gigabytes of disk space I strongly recommend that you do so as well.
I can now give some limitations for my site. The fork mount on the main scope won’t allow pointing south of -47.5 degrees. In the other direction, the limitation is about +77 degrees, which means I can’t observe some of the BAA-VSS program.
The on-site images of ω Centauri were taken by Kevin Hills some years back. His observatory is a few metres away from mine and his GEM is nowhere near as fussy. It will quite happily point his OTA very close to the nadir, as we discovered some weeks back.
Perhaps I should take a tripod, DSLR and telephoto lens down to Fuencaliente for an uninterrupted southern horizon where -60 declination should be a real possibility. A nice target at this time of the year might be ε Indi which culminates at about 5 degrees altitude.
“I’ve got some commercialy produced Kodak slides that (since 1973) have realy shifted, to the extent that I would not show them again.”
As long as at least some of each of the RGB response is still there they can be restored. Digitize them now while you still can and restore them at your leisure.
Repeated copying is the way to go.
I still have the machine-readable data I took for my DPhil research in 1982. The original 8″ floppy disks are (probably) unreadable but the raw data is still usable. That said, I still have the disks and a couple of drives up in the attic…
MS Office has had the ability to save and load Open Document Format files for many years now, as does free software such as Libre Office …
Looks like shadows cast by some objects (clouds near or below apparent horizon perhaps) on the regular forward-scattered sunlight.
Thanks. I may well add it to my program later this year once the imaging problems are worked out. Just found https://arxiv.org/abs/1607.08082 which contains a finder chart and a comparison sequence. I will investigate further.
Do you have any recent literature references to hand?
A round tuit arrived today so I uploaded the two nights of THL data to the CalTech periodogram engine. The results are (to me at least) are interesting. Several methods of period searching were used. All gave peaks at close to 0.0281 days and twice that (0.0562 days). The former is 40.3 minutes, which seems rather short. Twice that, 80.6 minutes, is absolutely typical of CV binaries. Perhaps a little on the short side but not exceptionally so — that of WZ Sge is 0.05671 days. The 40.3m light curve shows only a single dip. The other, of course, shows two which if real suggests eclipses of two stars of fairly similar magnitudes.
Another period which comes up strongly is at 0.08 days — 2 hours or so — or perhaps twice that. This is doubtless the 0.1 variation mentioned in the earlier post.
Only two nights and 359 measurements were analysed. Time for me to download more of the BAA-VSS database and see whether the patterns hold up.
