Tue Apr 25 16:50:12 PDT 2006

New Release of hmcposter LaTeX Class

A new release (2.0) of the hmcposter class is now available.

It can be downloaded from the poster class home page.

There is no longer an hmcposter document class (for this release). Instead, there are two new document class files:

hmcclinicposter.cls
At the moment, the only change from the original hmcposter.cls file is that this version of the class will put this year as the copyright year in the footnote.
hmcthesisposter.cls
This class replaces hmcposter.cls for use with thesis (or other class-based) posters.
Differences from the old hmcposter class include:
  • Larger base font size.
  • Uses \author command for author name.
  • Uses \year command to specify the year of the class.
  • Uses \class command to specify the name and number of the class.

    Expects something like Math 197: Senior Thesis as its argument.

  • Uses \advisor command to specify one or more advisors. Multiple names should be separated by \and .

The sample-thesis-poster.tex document provides a sample thesis-style poster.

Comments and feedback much appreciated.


Posted by Claire Connelly | Permalink

Fri Apr 14 20:05:11 PDT 2006

Updates to LaTeX Classes for Clinic and Thesis

New versions of the hmcclinic and the hmcthesis classes and the sample report that uses these classes are now available.

The hmcclinic class has had a minor update (from 2.7 to 2.8), fixing a bug in which consultants supplied in the argument to the (optional) \consultant command were not typeset on the title page (or anywhere else!).

The updates to the hmcthesis class are a bit more substantial (meriting a bump from 2.8 to 3.0), and will require users to modify their master document before typesetting a final version of their thesis.

We have added a new copyright page for theses. The copyright page asserts the author's copyright, and includes a statement that allows the college to make your thesis available for noncommercial, educational use.

The thesis class has also been updated to allow the author to "hardcode" a date into the thesis. The required \thesisyear command should be set to the year in which you're submitting your thesis. (For current users, that means 2006.). The class now also supports an optional \thesismonth command that can be set to the full name of the month your thesis is being submitted. It defaults to "May", so for most people it doesn't need to be set at all.

The sample and template documents have been updated to set the necessary commands so that the sample thesis will be typeset correctly.

Examples of the new typeset samples are available on the sample-report page.


Posted by Claire Connelly | Permalink

Mon Apr 3 12:07:35 PDT 2006

Running Long Jobs for Thesis and Scientific Computing Projects

The end of the year is rapidly approaching, and with it the need for thesis students to run programs to generate the data they need to complete their theses. At the same time, the lab machines are being used by other students for homework and classes, so they must be kept available for those uses.

The department has a policy on long jobs that lays out the ground rules for sharing our limited resources. The key points are:

  • Make sure that your job is running in the background (i.e., no locked screens).
  • Use the nice command to set the priorities for your job so that it runs at full speed when no one else is using the machine, but throttles down when someone else is using the computer for other (nonniced) programs. You should start your job with

    nice my_job

    If you want be especially nice, try

    nice -n 19 my_job

    to more or less suspend your job when someone else is working on the machine.

  • Use a sensible name -- something related to your project is good.
  • Most importantly, make sure you've sent mail to system@math.hmc.edu to tell me
    1. The name of your program
    2. The name(s) of the machine(s) you're running the program on
    3. How long you think your job will have to run

In addition, you will probably want to

  • Write your programs so they can be started at the command line (i.e., not require a bunch of UI tweaking to get started), unless you're connecting from another machine with a X server so you can display your program's interface remotely.
  • Store data in /tmp or /scratch directories rather than your home directory. (Especially important if the data is thrown away once your job is complete and returns a result!)
  • Write your programs so that they can be restarted from a save point, and periodically write their status out to data files. This approach is most useful for jobs that take a very long time to run, where starting them from scratch is likely to be a painful proposition.

Posted by Claire Connelly | Permalink