CSAR Bulletin issued in May 2003

LSF jobs must be submitted with a wall clock time

Please note that from Tuesday 3rd June, all LSF jobs must specify a realistic wall clock time limit, using the -W option. You may also specify a CPU time limit, but remember to allow for the number of processors you require.

This aids in the overall scheduling of jobs, particularly prior to scheduled maintenance sessions, allowing us to better schedule jobs by backfilling appropriately leading up to shutdowns. If everyone follows this practice, your jobs will have a better chance of being scheduled to run within the rundown periods. This will also enable your jobs to run in a more controlled manner and avoid runaway processes (for example code being stuck in an infinite loop).

By default, the time specified is in minutes but you may specify it as hour:minute.

Please see the LSF User Guide for further information.

Currently, a warning message is issued if jobs do not specify either CPU or wall clock time.

Accordingly, any jobs which do not specify wall clock time will be rejected at the time of submission from Tuesday 3rd June 2003.

Moving codes from turing to newton/green

Current users of the Cray T3E, Turing, should already be aware that the machine is due to be retired at the end of 2003. The extension of the CSAR contract means that a new SGI Altix machine called Newton will begin service at the beginning of October 2003 and will provide an additional capacity of 256 Megabytes of memory and around 1 Teraflop peak performance.

In order to facilitate a smooth transfer of users from Turing to one of the other CSAR machines, the CfS consortium has agreed that current Turing users will be given free porting assistance from the application/optimisation support team in Manchester to transfer their codes to either the current Origin 3800 Green, or the new Altix Newton.

In order for the porting work to be effective, users should begin to consider which of their codes need to be ported so that work can begin as soon as possible. Porting assistance can range from help and advice about transferring to the new architectures, through to full porting of codes by the team in Manchester. However, given the number of codes which may need to be transferred, it is important that the CSAR support team have access to information regarding the number and type of codes which need to be ported as soon as possible.

If you require further information please contact the CSAR Helpdesk.

New tape drives and DMF "Good Habits"

CfS are pleased to announce that an additional 4 drives have been installed in the tape silo for use by dmf. These should enable us to improve the response times for dmf, provided that users follow a few simple practices, viz

• ensure that files in the /hold area are at least 40Mbytes in size (files smaller than this may be unmigratable and large numbers of unmigratable files can seriously affect dmf performance)
• do not work in the /hold area copy input files to a home or temporary area and work there; copy new or changed results files for migration back to the /hold area only as a final step)
• the recommended way to achieve this is to use the cross file system copy command, xcp, which retrieves the migrated file and copies in the most efficient way to the system you select. xcp incorporates the dmget command, which allows dmf to queue requests optimally. See the man page for xcp for further details. (Note this command is currently being enhanced to include a multiple file retrieval facility, which should be available by Friday 6th June).

All users are asked to follow these practices - otherwise dmf performance will suffer.

Users with large number of small files are being contacted by the helpdesk and will be advised how best to work.