Dumb PBS tricks

Well, I have had my requisite good idea for the year. If you use a high-performance computing facility, odds are you use some kind of batch job system like PBS to submit and monitor jobs. We use a modified form of qstat to monitor jobs – how much walltime has elapsed, project codes, ram and scratch usage and the like.

The problem:

Unfortunately the program is terminal size-agnostic and as such fits all salient information into 80 characters. Thus the summary truncates job names to the first 8 characters. Granted, 8 characters offers many many unique job names, however I prefer my jobs to be fully summarisable by their titles. I want information on what the molecule is, what the job type is, the charge, spin multiplicity and d electron configuration, cleanly delimited for readability. This means that my job names are often something like dc6_BSLT_108b: a Broken Symmetry Linear Transit on molecule dc6 with a charge of 1, 8 unpaired electrons and a d electron configuration of ‘B’.

Why not just reverse the order?

The name is still truncated. Whilst the fiddly details of each job are now revealed, it’s difficult to see the context of the details – i.e. what the job type is and even what molecule you’re looking at!

What about the lab book?

Lab books document results and process, they shouldn’t be hashtables of job codes. Moreover, I believe that computational jobs should be effectively self-documenting – they should contain sufficient information to make sense on their own, both in the file name and in the internal comments structure.

This said, ‘electron configuration of B’ is not amazingly lucid – as such, I need to draw each configuration out (initially in the lab book, and then presentably in inkscape, illustrator or whatever), and this in some sense does constitute a lookup table. Drawing these out is necessary anyhow for when it comes time to publish/writeup.

Ultimately, the real point is that seeing these descriptors in the PBS queue is actually so that I can keep track of what has been submitted without having to use something so barbaric and crass as a pencil and post-it note. This stops me from submitting the same job twice (which is in clear violation of the no cloning theorem) and causing some combination of the following:

• Abnormal job termination.
• Cosmic horror.
• Weakly acausal behaviour in the spinny thing.
• Corpses half-embedded in walls, floors, etc.
• Excessive IO to /scratch/
• Spontaneous formation of malevolent hyper-intelligences in the cluster.
• Wasted CPU-time quota.
• Stuff like in that movie ‘Jacob’s Ladder’

You’re rambling.

Okay so the dumb PBS trick is to encode information about the job in the least significant digits of the walltime limit. Why set a job time limit at 4:00:00 when you can set it for 4:18:01 and be able to glean the relevant details of the job from that? Anyhow, this is my new tactic to keep track of stuff. And, looking at the queue as a whole, it seems that at least a handful of other people are doing the same thing… I feel validated. Note that they were doing this before I thought of it, so I’ve not started a trend.

Representing spin graphs in GraphViz

I was recently looking for a way to represent systems of interacting spins (e.g. to depict Heisenberg coupling between metal centres) and determined that there had to be some kind of deep, transcendental, graph-theoretic truth underlying coupled metal centres. After meditating hard I had gained no real insight, apart from the fact that I could represent these systems as undirected graphs, with each node representing a center and each edge representing a linear combination of exchange pathway contributions. Happily, there exists a program that is capable of attractively rendering graphs of nodes and edges, called GraphViz. GraphViz is seemingly mostly used for representing IT networks and FSMs, but it’s general enough to depict any kind of directed or undirected graph. I set to work making my dream come true:

graph cadisp1 {
 graph[bgcolor="transparent"];
 node [fontname="calibri", fontsize="14.00", shape=circle, style="bold,filled" fillcolor=white height="0.8"];
 edge [style=bold];
 splines=true;
 overlap=false;
 {node [height="0.8", shape=circle, style="bold,filled" fillcolor=lightgray] B1 B2 B3 B4 C1 C2 C3 C4 D1 D2 D3 D4}
 A1 [label=" 2↑ "];B1 [label="3/2↑"];C1 [label="3/2↑"];D1 [label="3/2↑"];
 A2 [label=" 2↓ "];B2 [label="3/2↑"];C2 [label="3/2↑"];D2 [label="3/2↑"];
 A3 [label=" 2↑ "];B3 [label="3/2↓"];C3 [label="3/2↑"];D3 [label="3/2↑"];
 A4 [label=" 2↑ "];B4 [label="3/2↓"];C4 [label="3/2↓"];D4 [label="3/2↑"];
 B1 -- C1 -- D1 -- B1;
 A1 -- B1;
 A1 -- C1;
 A1 -- D1;
 A2 -- B2 -- C2 -- A2;
 D2 -- A2;
 D2 -- B2;
 D2 -- C2;
 A3 -- B3 -- C3 -- A3;
 D3 -- A3;
 D3 -- B3;
 D3 -- C3;
 A4 -- B4 -- C4 -- A4;
 D4 -- A4;
 D4 -- B4;
 D4 -- C4;
}

And out pops an automatically formatted SVG file. This was quicker to write than it would have been to construct by hand, and required only a little bit of finishing up in Inkscape to seal the deal:

Spin graphs for a tetranuclear clustery thing

Irritatingly, GraphViz requires html character encodings for non-ASCII characters, necessitating the &# codes to render ↑ and ↓ respectively. I see that WordPress has automatically formatted these codes…  Finishing up consisted of shading the dissimilar spin states and using continuous or dashed edges to highlight parallel and antiparallel relationships between centres (all single-determinantial!). Optionally, I could label the edges to show the magnitude of the coupling as some multiple of pairwise J values. I feel that the shading and dashing helps better bring out the symmetry of the broken symmetry states, so that I only need to stare slack-jawed for a short time before I know what to stipulate the symmetry as in the computational chemistry software of my choice after I’ve blu-tacked the graph to my cube (hint: clockwise from top left it’s C_s, C_s, C_3v, C_3v).

The geometry of the cluster in real life is elegant and approximately tetrahedral, however this could also serve as a representation of a tetranuclear cluster with trigonal planar geometry and the appropriate exchange pathways (I have been told such systems are known) or indeed any other crazy asymmetric geometry with the necessary exchange pathways. Edges don’t represent bonds, and as such they may stand in for any number of intervening ligands working in concert for the full pairwise couplings experienced by the metals. In the end however, I will probably decide that I cannot realistically put these into a document on the basis that they are simply too abstract, or worse, too pretentious (these things tend to go hand-in-hand) for people to like. Fantasies of inventing a popular diagram type aside, I acknowledge that people – myself included – usually dig more concrete representations that can be recognised at a glance. For this, traditional molecular stick diagrams – perhaps with attendant spin arrows – serve admirably and are ubiquitous in literature.

Oh well, we shall see.