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.clsfile 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
\authorcommand for author name. - Uses
\yearcommand to specify the year of the class. - Uses
\classcommand to specify the name and number of the class.Expects something like
Math 197: Senior Thesisas its argument. - Uses
\advisorcommand 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.
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.
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
nicecommand 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 withnice my_jobIf you want be especially nice, try
nice -n 19 my_jobto 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.eduto tell me- The name of your program
- The name(s) of the machine(s) you're running the program on
- 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
/tmpor/scratchdirectories 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.