In this chapter, we will install the necessary softwares/packages that we will use throughout this course. It includes:
Anaconda (including most of necessary Python packages)
IRAF-included Astroconda (including most of astronomy-related packages)
Astropy
photutils
ginga
Editor for Python (only if you dislike Spyder; optional)
Image Displayer
SAO ds9
ginga
The installation may take some time. If you have nothing to do, read the next section during the installation.
All the IRAF/Astropy packages will be downloaded via a platform called Anaconda. So let's download Anaconda. If you are running out of space and really want very small package, try miniconda.
It doesn't matter which one you choose (Python 2 or 3). I recommend to use Anaconda3 and use Python 3, since it is the future of Python.
When the download is done, turn the terminal on and type as the website says.
There have been a lot of different ways to install IRAF: First people had to download with a lot of commands including "cd ..", "wget blahblah", etc. Then STScI developed a huge pack of all necessary softwares, named Ureka. But using Ureka is deprecated since April 2016. Now we use AstroConda. There are reasons for these transformations, and you may be able to find the reasons as time goes, if you are interested.
Anyway, let's do the IRAF installation via Anaconda! The following is identical to the official website of AstroConda.
In terminal, type the followings (This may take tens of minutes depending on the internet connections!)
conda update --all
conda config --add channels http://ssb.stsci.edu/astroconda
conda create -n iraf python=2.7 iraf-all pyraf-all stsci
The name of the environment, iraf, is iraf27 in the original official website, but I just prefer iraf for it's shorter. You can set it as any name you like.
Astropy is the name of a project which devotes its human power in developing a single package containing tools useful for astronomers in Python language(GitHub, Official website, The most recent stable distribution documentation).
You should have Astropy by default if you used Anaconda.
You may have found the so-called "affiliated" packages listed here. Astropy is installed by Anaconda, but not these affiliated packages. Among these, you SHOULD download photutils. To download, type
conda install -c astropy photutils
on the terminal.
Please see the "image displayer" section.
You can simply test the installation by tests. Run ipython from terminal:
ipython
Then you are now in the ipython console, and type
import astropy, photutils
photutils.test()
astropy.test()
These will take quite long time, especially astropy takes very long time. (So I didn't show you the full result)
You need to do it only once when you first installed these packages. If you want to test only some part of the whole package, you can specify the module, e.g., you can test astropy.io.fits by:
astropy.test(package='io.fits')
While the test is going on, look at the names of the directories, like astropy/table, astropy/units, etc. These are the names we will encounter very frequently, so this test is not only to test, but also to get accustomed to the astropy and python language.
Each dot(.) means test passed and x means test failed. But some of the failures are just OK. s means it is skipped for some reason.
I did tests for Astropy 1.3.1 and Photutils 0.3.1 (took ~ 10 mins) and got the following messages:
(long long test explanations....)
======================== 1056 passed, 2 skipped, 2 xfailed in 82.18 seconds ========================
(long long test explanations....)
Some tests are known to fail when run from the IPython prompt; especially, but not limited to tests involving logging and warning handling. Unless you are certain as to the cause of the failure, please check that the failure occurs outside IPython as well. See http://docs.astropy.org/en/stable/known_issues.html#failing-logging-tests-when-running-the-tests-in-ipython for more information.
== 24 failed, 8717 passed, 75 skipped, 42 xfailed, 1 xpassed, 2 pytest-warnings in 573.02 seconds ==
The astropy will do the tests automatically (takes ~ 10 minutes). There might be some errors, but usually they are not important, so you can ignore them. If "astropy.test()" itself does not work, please check whether the installation of Anaconda had been done correctly.
There are bunch of different editors (including IDEs = Integrated Development Environment) to edit the codes. I personally use spyder (it is installed from Anaconda by default, and you can use it by double-click the spyder app icon or type spyder & on the terminal).
Some may prefer Wing IDE, which is widely being used in educational institutions, or PyDev, PyCharm, and even VI or Emacs. VI is quite powerful since it is accessible for virtually all of the computers around the world by default, and the debugger, gdb, is also accessible on terminal. If you have an IDE, it most likely contain its own fancy debugger, too. For Windows computers, Visual Studio is also a good choice. For Ubuntu, gedit or geany are also attractable choices. Atom is also a fancy editor. I use geany for miscellaneous and short works because it is extremely light, and Atom for coding C language-based programs.
I have tried all the aforementioned editors, and settled down to the lightest, fastest, most intuitive/interactive, and yet functional editors after ~ 1 year of trial and error. BUT this is just my personal opinion, and you may find very different solution. I have many friends who use VI only for all the coding works. If you can, I recommend to use VI as your main editor, and at least learn how to use it. I don't use VI just because for me it is too difficult to use it.
In astronomical image reduction process, you need some tools to display images on computer screen to interactively investigate the images. There is a historical standard, which is kind of an affiliated package of IRAF, SAO ds9. The most recent version as of Feb 2017 is ver 7.5. Some people use Maxim DL, but it's commercial and used mostly by amateur astronomers. In the future, as Python gets more and more intention, Ginga will be another powerful option. We are not sure when Ginga will become quite perfect, but until then, I recommend you to use both of them. Their pros and cons will be explained from now.
SAO ds9 was made for Chandra X-ray observation, but became so powerful that it has been used for decades by virtually all astronomers. It has many powerful features, which mostly are not yet fully implemented to Ginga. By the system default, you will use ds9 to open any FITS image.
If you want to run ds9, you can do ds9 & on terminal. Once you've got used to ds9, you can do a bit advanced command such as
ds9 -zscale image01.fits image02.fits image03.fits -single &
or
ds9 -zscale image*.fits -single &.
For more command line options, see this link.
If you want to turn ds9 on IRAF console, put exclamation mark (!):
ecl> !ds9 &
and !ds9 image*.fits -single &, etc, will work identically. There is another task called DISPLAY in IRAF. Type epar display to see the parameters. Some frequently used commands are the zscale command, e.g., displ image*.fits z1=100 z2=3000.
Ginga (pronounced ging-ga, which means galaxy in Japanese; the reason for the name is explained in the link) is an affiliated package of astropy, and is used for FITS image viewer. If you do not want ginga, please refer to SAO ds9 in later section.
If you want to download it, type
conda install -c astropy ginga
It is made to serve the role as SAO ds9, but to perform some useful calculations that ds9 cannot do by default. ds9 has tremendous power when it is used with IRAF, but that is not a favorable solution for Python users. So Ginga is made to fully funtional with Python only, as well as to be able to interact with IRAF as ds9 does.
You can use ginga & on terminal or ecl> !ginga & on IRAF console. Although you can do ginga image.fits & as you did for ds9, it is usually better to use interactive drag-and-drop way to open image than command line. In Ginga, you can also use tools -> FBrowser.
I couldn't find how to use Ginga with IRAF yet.... Though this official site says you can. I think this is a known bug that you actually cannot.
Although it is not recommended, you may want to open ds9 or ginga from Python (e.g., iPython or Spyder), than terminal or Windows command prompt. In such case, you can import a module called subprocess. Using subprocess, you can run the command from Python as if you are typing it on terminal:
import subprocess as sp
# Open SAO ds9:
sp.call("ds9")
# Open ginga:
sp.call("ginga")
You can use various different ways, such as module os, or check_call, Popen, etc. But it is not recommended to open ginga or ds9 from python in most instances, as far as I know.
Python is a programming langauge. Most importantly, it is object oriented and interpreted, high-level language. In short, it means "Python is quite powerful, modern, intuitive, flexible, and easy to use."
The following is so-called The Zen of Python. As the name says, it consist of some morals that python keeps in mind. These are not only for the python developers, but also for any python users to code in pythonic way.
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Unless you're Dutch: See Stack Exchange.
"The inventor of Python is a Dutch programmer named Guido van Rossum. It is probably a reference to the inventor of Perl, Larry Wall who is not Dutch and invented a language where there a at least 50 ways to do any one thing. – ColleenV♦ Mar 24 '16 at 22:29"
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
In Korean,
If you want to see this The Zen of Python, you can type import this:
import this
The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!