The computer and web capabilities given to you by the university and by the department can be overwhelming at first, so we offer some advice for keeping it straight.
General Department Info
A good thing to check out is Jon’s Department User Guide, which includes information about the Linux systems in general, email accounts, locally installed applications, peripherals, etc. Jon recently installed a few more programs which are not mentioned in the Software/data resources section of the Users Guide:
- IRAF (v2.15.1a) This version features separate 64-bit executables. It also features a newer command line interface, ecl (note that using cl as before just starts ecl, so you don’t have to do anything different).
- DS9 Fine FITS viewer
- ifort, icc/icpc The latest and greatest intel compilers
- Kile Awesome latex editor
- Texmaker Another good latex editor
- Geany Great gedit like editor with lots of advanced programming editor capabilities like hiding functions and syntax highlighting etc.
- Terminator Very nice terminal with ability to split windows and other stuff (GNOME terminals)
- Mercurial Version control software for editing code and keeping track of versions. Mercurial developers are clever = big damn nerds. The executable is named ‘hg’.
- Git Also version control software
- Synergy Program that allows you to control one computer with a mouse and keyboard plugged into another computer
- plplot A pgplot-like plotting program
- Libreoffice An offshoot of open office. If you have a problem with open office (soffice from command line) try using Libre Office instead (loffice from command line)
- Google Desktop Allows you to easily find files and other stuff (like Spotlight for Macs).
Also, we pooled our collective knowledge of useful programs and languages in a series of 15 Minute Lectures meant as introductions to various topics.
You will be able to set up two email addresses: NMSU (firstname.lastname@example.org) and astro department (email@example.com). Your NMSU email is checked via myNMSU, and your astro email can be checked via webmail, in addition to whatever mail program you prefer to use. Make it easier for everyone and ensure your username is the same for both emails. We have control over astro usernames, so set up your NMSU email account first to make sure your desired account name isn’t already taken by someone else. To do this, go to myNMSU, and follow the directions for setting up an account. To set up your astro department email, talk to Jon.
Why the fuss about emails? Students and collaborators will try to contact you. Your contact information (including email) is automatically visible to the rest of the world on the main department student directory, your individual department page, and the department aliases for mass emails. These use your astro username, assumed to be your NMSU email as well (firstname.lastname@example.org). If you don’t have one set up, or if you don’t check it or haven’t forwarded it to an account you do check, you won’t get intra-department emails and out-of-department people won’t know how to contact you. Moreover, your NMSU and astro email accounts know nothing about each other unless you set up email forwarding. Pick an account to serve as your main email (NMSU, astro, gmail, etc.), and have all other email accounts forward their mail to that one.
Forward your astro email by using a .forward file:
Create a .forward file in your home directory (/home/users/username) using a text editor of your choice (vi, emacs, pico, textedit, etc.). This file should contain, as the first and only line the address where the mail should be forwarded.
Forward your NMSU email by changing your account settings:
Log into myNMSU and click on the Email tab on the right. In the window that pops up, click on the Options tab. There is a section at the bottom dealing with email forwarding. We suggest you don’t ‘leave a copy on the server’ since that will only waste space on the NMSU mail server.
There is also a series of useful department email aliases. Who is allowed to use them? Anyone. Just make sure the email you are sending is a) appropriate material for everyone to see and b) something everyone on the list should see. People get irritated at getting “spammed” by department-wide emails.
Computers and Servers
Welcome to the department, you get a computer! Each desk has a tower computer (of varying strength) and a monitor (of varying size). The tower runs on the UNIX operating system, but you are free to choose your own shell. A shell’s just a program which interprets how to run the commands your type into a terminal. When you first arrive, you might not have been given access to your own folder on your tower (ask Jon or Joni to change the permissions for you). Each machine has a name, so be sure to find out what yours is called. Curious to see what other machines in the department are called?
As always with computers, at some point you may need to restart it — wait! Check with Jon or Joni before you restart your tower. That’s so weird; why? You share the hard drive in your tower with other users. If you restart when the server is accessing those files, it causes things to choke and croak. Also, if you restart when access to the astro server is down, your computer with hang because it needs to access files stored on the server. This is a common problem after a power outage, when the server gets knocked off-line.
In addition to the the hard drive space on your tower, you get 3GB of space located in your home directory (/home/users/username) on the main astro server, astronomy. When you read and write files in your home directory, you are accessing the astro server. If you run code that constantly does this, you will slow down the entire server. Before long some vengeful person with root access will kill your process, so don’t do it. If you run a major program, do so on your tower or on one of the department machines.
|Name||Status (Owner)||Number of Cores||RAM (Gb)|
There are public machines with multiple processors for you to use; all the computers are based on AMD 64bit processors. Code compiled on any of these public machines will run on any of the others. You simply ssh into the machine and run your program; for example: ssh -X myname@praesepe to login to praesepe. Just keep track of where (on what machine, too) you write output files. The different machines may have different efficiencies for different types of jobs, i.e. whether you are running true parallel-processing jobs or not; for such jobs, significant efficiency differences may exist, even on a given machine, depending on how many cores you use. People interested in this should consult with Anatoly, who has done some testing.
There are two ways of dealing with the data distributed on different disks. For example, you have files on pleiades disk, but you want to use praesepe to analyze the files.
- ssh -X myname@praesepe
- cd /home/pleiades/myname/myproject
- run your code
- ssh -X myname@praesepe
- cd /praesepe/myname
- mkdir myproject
- cd myproject
- ln -s /home/pleiades/myname/myproject/* .
This creates ‘soft-link’ files in local directory. For most of purposes those files are as good as the files on pleiades. This does not make copies of the files. So, there is no replication of the data. When you read the files, you read the files on pleiades disk. When you write to the files, you change the files on pleiades. The only difference is when you ‘rm’ the files: in this case ‘rm’ command removes the soft link, not the files on pleiades.
- Run your code. All new files will be physically located on praesepe
What about the mysterious Windows Machine you’ve heard about? That’s the tower in the upstairs printer room (Ay 217). What’s so special about it? Well, aside from running Windows, it also has a scanner attached to it. The password for the general astro user is on a sticky note under the keyboard. When you’re done using the machine, please remember to delete your files and log out of Windows. If something is wrong with the Windows machine, or you’d like some special software, let the AGSO Windows Admin know.
Say you’ve written awesome programs and reduced really cool data; how do you back up all your files? Both your tower space and your server space are periodically backed up by the main server, but it is strongly recommended that you back up important files someplace else (a laptop or home computer, your own external hard drive, butterflies, etc.). How often and what files are backed up? Check out Jon’s page on it. You can back up on your own using a perl script provided by Nicole.
We have an awesome copier/fax machine you can use. For copying there are two general codes written on the bottom of the upper shelf in the copier room: one for research-related copies and one for education-related copies. If you’re making copies for personal use, you can set up your own ID code with Lorenza. You can fax locally and internationally. The copier now acts as a black and white scanner; you can scan as a multi-page PDF or a single TIFFs. If you have an entry in the address book, you can send your scan there; otherwise, selecting ‘astronomy’ will send your fax to a public directory. Periodically, Jon clears out this directory, so don’t forget to download your scan.
Signing Out Laptops and Projectors
The department has a few laptops and portable projectors which you may temporarily sign out. They are stored in the server room (Ay 116A). There is a sign out sheet which should be on a clipboard on the table. Please remember to sign out and sign back in anything you take, otherwise we have people wandering around the department looking for, say, the Dell projector. Remember to test your talk before you leave the building to ensure the presentation file, laptop, and projector are all working. There’s a general username and password for the laptops, and Tom will be happy to tell you what it is.
Jon wrote extensive notes on the printing capabilities in the department, as well as useful options in the lpr command. As with all computer networks, sometimes the printers can act glitchy (never printing, printing one word per page, printing the postscript code, etc.). Jon and Joni suggest the following things before you go postal on the printers (or them):
- if your document didn’t print, don’t send the job again; ssh into the astronomy server and check the queue (using the lpq command) to see if it is stuck behind a massive file
- delete duplicate jobs (using the lprm command) from the queue so you don’t waste paper or slow down anyone else
- if the printer isn’t responding, you may have to cycle the printer power, and then you may have to ask Jon or Joni to restart the printer queue
- don’t print to the color printer if you don’t explicitly need a color printout, or Joni will kill you. (It’s named “expensive” for a reason)
- don’t print the entire lab manual, especially during the day
- if you are using special paper (ie, thesis paper) in the printer, send an email in advance or let people know ; otherwise no one will know and you’ll get a Sky Map on your expensive paper
To avoid annoying everyone else in the department, follow basic printer etiquette:
- Before you print something, ask yourself “Do I really need a hard copy of this?”. If you really need it, print double-sided.
- When you print something, pick it up right away.
- Check to make sure all the papers you pick up are yours. This is especially important when using the copier as it will interleave different tasks as it receives them.
- Replace paper if it is out.
- Tell Ofelia when the ink levels are low.
- Printing from evince can sometimes lead to trouble. Use a different program like kpdf. Printing from the command line with lpr only works about half the time.
- If you print something and nothing happens, check the queue with ‘lpq’. To remove a job from the queue, use ‘lprm’. The status of the printer can be determined using ‘lpstat’. If you prefer a GUI, point your browser to http://localhost:631/. Never press the “self test” button on the web interface since it could result in a job you don’t own getting stuck in the queue.
- If you need to print out some code, the enscript command is very good at formatting it well.
- If you have a large print job (100+ pages), save it for early morning or evening when fewer people are using the printer.
One of the cooler things about this department is that we have our own poster printer with matte and glossy paper rolls, however this single piece of equipment has caused more frustration than a stack of annoy-a-trons. There might be problems with colors not matching, symbols getting messed up, or getting an 8.5×11 when you wanted 42×42. Lynn methodically investigated advanced poster printer settings using Adobe Acrobat Pro. Unfortunately, this is the poster printer, so there are no such thing as guaranteed results. If you wish to print a poster, consult with Lynn or take your poster-printing-destiny into your own hands. For now,to print a poster just give your PDF to Lynn and let him know how large to make the poster.
If Lynn is unavailable or you are feeling overconfident in your abilities, your can try your luck using the department Mac. First open the pdf version of your poster in Preview. Open the print menu. You want to change the following settings:
|Printer:||DesignJet 500 PS+HPGL2 (C7770C) (0001E65225A5)|
|Paper Size:||Manage Custom Size. Set the width and height to the poster size you’re using and set Non-Printable Area to the same printer as above|
|Scale to Fit:||Fit Entire Paper|
Make sure you are connected to the network through Ethernet (not wireless), and hit print. You should be good to go!
Jon suggests using the lpr command from your UNIX box as follows for a 40″x40″ poster:
lpr -Php_poster-usb -pagesize=Custom.2880×2880 -oColorMode=FloydSteinbergColor -oresolution=600x600dpi myposter.pdf
- If your poster is not 40″x40″ you’ll need to change the page size. The custom value represents the size in inches multiplied by 72.
- The Floyd-Steinberg color profile seems to give a reasonable mapping from screen to printer colors
- If you are having trouble with this command, try changing -Php_poster-usb to -Php_poster. This will send the command over Ethernet rather than USB.
Before you print on glossy paper, please do a final check to make sure it looks okay (either on screen or by printing out a small version on the poster printer). If it looks good, go ahead and print your final copy on glossy paper. Instructions for changing the paper are on the printer itself. You can post the “mini-me” version on the grad student research board, which is outside of the conference room.
The printer displays shows roughly how much ink of each color is left. Don’t wait til the night before you leave for a conference to print your poster. Doing so tempts the printer gods to cause trouble. While there is usually a spare of each cartridge in the storage closet (across from the main office and not something our building keys unlock), do not rely on that. Even if there is one, if no one’s around you won’t be able to get into the locked closet.
Apache Point Observatory
Since our department maintains APO, chances are pretty good that you’ll get time on the 3.5m if you submit a decent proposal. Time is usually allotted in half nights:
- A half from sunset to midnight
- B half from midnight to sunrise
The year is divided into quarterly observing periods:
- Q1: January – March
- Q2: April – June
- Q3: July – September
- Q4: October – December
After you take ASTR535 and have visited APO for three nights, you should be certified to observe at APO remotely and your name will be added to the list of trained remote observers. With the aid of the nightly obs-spec, you can control the awesome power of the 3.5m from the comfort of your own office/apartment/home! You just need to download and install the latest version of the Telescope User Interface (TUI). Currently TUI is supported for Mac OS 10.5 (Leopard), but that will end as of Summer 2012.
If you applied for and were given time on the telescope, you already have an ID. In case you don’t know your ID, check the observing calender. TUI requires a password to connect to APO; they will only gives this out over thephone.
For your convenience, we provide a simple observing log to keep track of your run.
Off-Campus Access to Journal Articles
Tired of working in your office? Many people work from home or their coffee shop of choice at some point. To help facilitate this, here is a list of steps to let you read journal articles without being on campus.
- Go to library.nmsu.edu
- In the menu on the left-hand side, under Find Information, click the “Articles, Books, Journals, etc.” link.
- Search Articles Indexes using the pull-down list for “Subject Area” (right-hand side of the page), and select “Physical Sciences”.
- Click on the NASA/ADS link.
- Enter your my.nmsu.edu username and password when prompted.
- You can now view articles thorugh NASA/ADS! This should be good once per browser — so don’t close the window unless you’re done searching. This works because the library is opening the NASA/ADS page using a frame, so the request looks like it’s coming from campus.
Regardless of the project you chose to undertake for the N-body assignment, at some point you will have to parallelize your code so it will actually run in a realistic amount of time. There are a few ways to do this, depending on if you are using FORTRAN or C, but there are a few things to be aware of. Done right, the code will run as expected and produce beautiful results. However, poorly done parallelization will crash the network, which tends to upset other students. Here are a few guidelines to help avoid irate e-mails.
- Start early!
- Limit the number of cores you are using. In C use omp_set_num_threads(numcorse). In FORTRAN this is call OMP_SET_NUM_THREADS(num_threads). Not doing this causes your program to use as many cores as it can, which is inefficient and slows down everything on the computer. Also try to keep the number of cores an even number. The splitting is more efficient that way. Usually 16 cores is plenty.
- Don’t use more cores than are available.
- Be aware of other people using the computers. Check the using with the top command. In the upper left is the CPU usage given by “CPU(s): ##.#$us”. If this is above ~75%, find a new computer.
- Don’t write data over the network. Always write to local directories on the computer you are on.
- Test your code with small sections before doing the full run. Make sure it is acting as it should so you don’t waste processor time.
- Talk to your fellow classmates to coordinate who will use how many cores on which machine.
- Check on the codes progress as it goes to ensure it is working as it should (i.e. not consuming the entire processing power of the computer)
- Backup your results regularly!. If the power goes out and the servers crash (which has happened), you don’t want to have to start over from the beginning.
- If someone is running code without limiting the number of cores they’re using, feel free to (politely) e-mail them to let them know. If you don’t recognize the username, use the finger command to determine who they are.
- The safest machines to use are praesepe and hyades, but they tend to have high traffic. Euredica has fewer cores but also less traffic. Pleiades is great for testing the parallelization before the full run. Solarstorm and seismo belong to the solar group, but may be available for night runs. Check with Jason first!
- If your code is not parallelized, don’t run it on astro. Run the code on your local machine. If you do not have a directory on your machine, ask Jon to make one for you.