Molden: increasing File Select window size

 For any who know me, it is likely no surprise I make obscenely descriptive file names which contain all of the pertinent input parameters for a given electronic structure program. Molden, however, is not so keen on displaying my beautiful, long file names. After a bit of sleuthing through the source code, here is what I came up with for increasing the size of the File Select box. These are pixel-based sizes and positions (as opposed to percentages or anything that scales in relative size), and I increased mine by 100. Below is the diff file capturing the increases.

< #define QBOXWIDE  450
---
> #define QBOXWIDE  550
7993c7993
< #define DIRW 255
---
> #define DIRW 355
8000c8000
< #define DDIRW 255
---
> #define DDIRW 355
20819c20819
<     butje(fs->win,320,40,80,70,1,0,0,1,None,0,0,0,0);
---
>     butje(fs->win,420,40,80,70,1,0,0,1,None,0,0,0,0);
20825,20828c20825,20828
<     LineString(fs->win, "Filter:", 322, 150);
<     LineString(fs->win, "Replace", 350, 75);
<     LineString(fs->win, "Add", 350, 105);
<     LineString(fs->win, "Show", 350, 130);
---
>     LineString(fs->win, "Filter:", 422, 150);
>     LineString(fs->win, "Replace", 450, 75);
>     LineString(fs->win, "Add", 450, 105);
>     LineString(fs->win, "Show", 450, 130);
20852c20852
<     butje(fs->win,320,40,80,70,1,0,0,1,None,0,0,0,0);
---
>     butje(fs->win,420,40,80,70,1,0,0,1,None,0,0,0,0);
20860,20861c20860,20861
<   ULineString(fs->win, "Files", 325, 55);
<   ULineString(fs->win, "Directories", 325, 265);
---
>   ULineString(fs->win, "Files", 425, 55);
>   ULineString(fs->win, "Directories", 425, 265);
20863,20866c20863,20866
<     LineString(fs->win, "Filter:", 322, 150);
<     LineString(fs->win, "Replace", 350, 75);
<     LineString(fs->win, "Add", 350, 105);
<     LineString(fs->win, "Show", 350, 130);
---
>     LineString(fs->win, "Filter:", 422, 150);
>     LineString(fs->win, "Replace", 450, 75);
>     LineString(fs->win, "Add", 450, 105);
>     LineString(fs->win, "Show", 450, 130);
21355c21355
<     DefBut(&fs->rbut[BDIR],  fs->win, 325, 275            , 110, BUTTH,
---
>     DefBut(&fs->rbut[BDIR],  fs->win, 425, 275            , 110, BUTTH,
21359c21359
<     DefBut(&fs->rbut[BCAN],  fs->win, 325, 275+BUTTN      , 50, BUTTH,
---
>     DefBut(&fs->rbut[BCAN],  fs->win, 425, 275+BUTTN      , 50, BUTTH,
21362c21362
<     DefBut(&fs->rbut[BREP],  fs->win, 325, 65            , 15, 15,
---
>     DefBut(&fs->rbut[BREP],  fs->win, 425, 65            , 15, 15,
21364c21364
<     DefBut(&fs->rbut[BADD],  fs->win, 325, 90            ,15, 15,
---
>     DefBut(&fs->rbut[BADD],  fs->win, 425, 90            ,15, 15,
21366c21366
<     DefBut(&fs->rbut[BPDB],  fs->win, 380, 216           ,65, BUTTH,
---
>     DefBut(&fs->rbut[BPDB],  fs->win, 480, 216           ,65, BUTTH,
21368c21368
<     DefBut(&fs->rbut[BSPDB],  fs->win, 355, DEFQY        ,90, BUTTN,
---
>     DefBut(&fs->rbut[BSPDB],  fs->win, 455, DEFQY        ,90, BUTTN,
21371c21371
<     DefBut(&fs->rbut[BSAVE],  fs->win, 310, DEFQY        ,40, BUTTN,
---
>     DefBut(&fs->rbut[BSAVE],  fs->win, 410, DEFQY        ,40, BUTTN,
21373c21373
<     DefBut(&fs->rbut[BSHOW],  fs->win, 325, 115          ,15, 15,
---
>     DefBut(&fs->rbut[BSHOW],  fs->win, 425, 115          ,15, 15,
21378c21378
<     DefBut(&fs->rbut[BCAN],  fs->win, 325, 275+BUTTN      , 50, BUTTH,
---
>     DefBut(&fs->rbut[BCAN],  fs->win, 425, 275+BUTTN      , 50, BUTTH,
21420c21420
<        qboxstr(&qboxes[QSUBSTR],&fs->win,0,0,190,322,
---
>        qboxstr(&qboxes[QSUBSTR],&fs->win,0,0,190,422,
21424c21424
<     qboxstr(&qboxes[QPDB],&fs->win,0,0,190,322,
---
>     qboxstr(&qboxes[QPDB],&fs->win,0,0,190,422,
benjfitz@ansible:/cluster/software$

Compiling Molden 7.3 from scratch on Ubuntu 22.04

 

etablues (on Reddit) did the heavy lifting on this one with Molden 6.9 and below is the original link.

https://www.reddit.com/r/comp_chem/comments/v7865d/tutorial_compiling_molden_from_source_on_debian/

 

For Molden 7.3 I made a few changes.

1) Two of the packages listed on Molden's site were no longer available on Ubuntu, so no need to install them.

sudo apt-get install libX11-6
sudo apt-get install libX11-dev

2) The addition to FFLAG (-w -fallow-argument-mismatch) is also needed for ./docker/Makefile.

3) ./surf/makefile needs one line changed

@ makedepend $(INCLUDE) -f makedep $(DEPEND)

to

@ $(CC) $(INCLUDE) -M $(DEPEND) > makedep

per this blog: http://verahill.blogspot.com/2012/09/molden-on-debian-testing.html

4) utils/register_extension_gio.sh needs to comment out line:

#sudo cp ~/.local/share/applications/$APP.desktop /usr/share/app-install/desktop/$APP:$APP.desktop

 

 Something new for me in 2021, Q-Chem! Ok, well not exactly new as I have been using it for the past 3 years, but only in little bits and pieces.

 

The goal is to create a series of files with slightly different bond lengths (frozenscan can do this, but the resulting table pulls in the SCF energies instead of the CCSD energies), and then pull out the energies easily.

Creating the files using a template, no-A-sp-eomeaccsdft-avdz-c.qin. The 00 in the for loop helps with the file naming so 1.01 A does not end up as 1.1 in the file name. The general idea is to create the bond length using the loop counter and bc, copy the template to a new file name, and then use sed replace the bond length (this needs to be a unique name or number) with the desired one.

for i in {00..30} ; do j=$(echo "1+$i*0.01" | bc) ; echo $j ; cp /cluster/n2-no/no-A-sp-eomeaccsdft-avdz-c.qin /cluster/n2-no/no-A-sp-eomeaccsdft-avdz-1pt${i}-c.qin ; sed -i "s/1.060669/${j}/g" /cluster/n2-no/no-A-sp-eomeaccsdft-avdz-1pt${i}-c.qin ; done

 

Pulling out the A state CCSD-EA energies (the ground state is degenerate, so the first excited state is #3 in EA when no symmetry is used. EE would be state #2 because the degenerate ground state would be #1) using the for loop below with grep and gawk.

for i in $( ls no-A-sp-*1pt*-c.qout* ) ; do grep "EOMEA transition 3/A" ${i} -A1 | grep "Total energy" | gawk '{print $4}' ; done

 

Now on to the triples contribution using (fT):

for i in $( ls no-A-sp-*1pt*-c.qout* ) ; do grep "EOMEA-CCSD transition 3/A" ${i} -A1 | grep "(fT)" | gawk '{print $4}' ; done

The same process forks for totally ground state calculations using non-EOM CCSD, but the grep terms need to be adjusted.

Creating higher level single point input files (for MOLPRO) from an xyz file and a MOLPRO input template can be rather tedious. The hitch with this one is sometimes the default (designated by -a) geometry optimization fails, and I need to run one or more subsequent geometry optimizations (designated -a2, -a3, etc). The original method I had used the below bash line:

 for i in $( ls geom-method-tests/c6h7-int*rowb97xd-631*.xyz ) ; do outname="$( basename $i "-a.xyz" )-uccsdtf12-vtzf12-ad.inp" ; echo $outname; cp c6h7-template-uccsdtf12-vtzf12-ad.inp $outname ; tail -n13 $i >tmpfile ; sed -i -e '/geom={/r tmpfile' $outname ; done

One downside with the above code is when the xyz file ends with something other than -a.xyz basename does not properly parse the file name (the new input file ends up with -a2.xyz in the middle of it). Thankfully, replacing basename with parameter expansion (## and % in this case) solves this.

for i in $( ls geom-method-tests/c6h7-int*rohcth407hcth407-631*.xyz ) ; do filename=${i##*/} ; basename1=${filename%.xyz} ; suffix=${basename1##*-a} ; basename2=${basename1%-*} ; outname="${basename2}-uccsdtf12-vtzf12-ad${suffix}.inp" ; echo ${outname} ; cp c6h7-template-uccsdtf12-vtzf12-ad.inp $outname ; tail -n13 $i >tmpfile ; sed -i -e '/geom={/r tmpfile' $outname; echo "---------------" ; done

While the above is rather long, I left in all of the steps for clarity. Thus far it has worked like a champ!

X11SDV-12C-TLN2F stability issues

This post fits with the other X11SDV posts in 2H of 2019. Both of my X11SDV-12C-TLN2F boards had problems where they would run fine for hours or days at full load, but then randomly I would find them shut down.


Things I tried that did not work:

 - separating their electrical connections onto independent battery backups (previously they both shared a single 1500 VA UPS). This was about the same time I was replacing batteries in the UPS units and thought power blips might then lead to overload situations.

- swapping RAM between the units

- swearing a lot

- removing the AOC-SHG3-4M2P cards having the scratch SSD drives


Things I tried that did work:

 - Replacing the Fortron 250 W PSU (FSP250-60FAG) with a Fortron 300 W PSU (FSP300-57FCB)


Running these boards with 128 GB of RAM, boot SSD, and the PCI-E card + 2 SSDs drew 150-180 W. Hence, I figured the 250 W PSU would be fine, but one of the rails must not have been sufficient to supply the required load.

Extracting xyz geometries from Gaussian output files (cclib)

Turns out my G09 geometry optimization output files are split between listing the optimized coordinates (if the calc began with a z-matrix) and the xyz coordinates. The above split makes it difficult to extract geometries in an automated fashion. Several tools came up during a Google search, but these only work to pull out the xyz coordinates if G09 lists the final geometry in the cartesian format.

Surprisingly, cclib was nowhere near the top of my search results after multiple different sets of search terms, though it eventually came up and it looked like a perfect solutions. My initial stab at installing it using:

$ sudo apt-get install python3-numpy cclib python3-cclib

was not met with resounding success as the former did not really give much of anything useful (no ccget or ccwrite), and the latter still lacked ccwrite. Moreover, the current Ubuntu 18.04 package is a rather ancient 1.3 (perhaps this explains the lack of ccwrite).

My next step was finding the source for 1.6.2 and attempting to install that (which worked, but ccwrite barfed on itself when I tried the xyz option). This made me think it was not quite ready, and some Ubuntu pages listed 1.6-1 as the most current stable branch, so I started over with this slightly older version. Instead of manually installing, I thought it might be useful to try pip3 (my pip instance links to python 2, so I had to be careful to tack 3s on the end of most of these).

$ sudo apt-get install python3-setuptools python3-pip
$ tar xzvf cclib-1.6.tar.gz
$ cd cclib-1.6
$ pip3 install .

This worked like a charm (using -t to install cclib in a different location did not, and browsing cclib bug reports makes me think this feature is not currently working), and I now had ccget, cda, ccwrite, etc in ~/.local/bin.

$ ~/.local/bin/ccwrite xyz test.log

produced a decent xyz file at test.xyz. Success!

Cooling X11SDV-12C-TLN2F

Unlike the custom heatsinks I designed and procured for the X10SDVs, I thought it would be worth looking at off-the-shelf HSFs for cooling the X11SDV boards. That being said, there are no HSFs available for BGA 2518 except through Supermicro (and maybe Cooljag at this point). One point worth mentioning, all of the geometry is different from the X10SDV, which requires a complete reworking of any work I did before. There is plenty of room, given all of these units are in 4U cases.

Full load constitutes 12 threads in MOLPRO for a DFT calculation, which gave the highest temperatures. Using stress in the bash shell was lower by at least 5 C.

The baseline for the OEM heatsink (this was the non + version, so no active cooling here) was 70+ C at full load with a 70 mm fan resting on the heatsink. Making a fan shroud and using a high pressure Delta brought this down to 60-65 C at full load (needless to say, this solution was rather loud). Additionally, replacing the standard goop with Arctic Silver 5 certainly did not hurt (it was probably work a few degrees Celsius).

Now on to the off-the-shelf HSF, I went with a Noctua NH-L12S after reading through all of the other posts I could find, primarily the one below.

https://forums.servethehome.com/index.php?threads/cooling-the-cpu-x11sdv-4c-tln2f.22285/

This HSF is relatively low profile (in that it has 1" of clearance in a 4U case) and the heatpipes should not block any of the memory slots because they are fairly vertical (another option might be the Noctua NH-D9DX i4 3U). Looking at the included mounting hardware and the X11SDV heatspreader and mounting holes I came to the conclusion that modifying them was not going to work, here goes a voyage into making custom mounting bracket.

Using aluminum angle seemed like the way to go because:
  1) aluminum is easy to work with using hand tools and common power tools.
  2) the vertical bit of the angle should provide far more rigidity than a flat bar of aluminum.

The trick with fashioning custom brackets was to get both sets of holes in the right place relative to each other and the 3 mm x 40 mm section that had to be removed so the bracket did not hit the CPU heatspreader. Ideally, I would have good enough measurements to mark off all of the holes and such, which I would then machine using a grinder and drill. Reality set in and made me realize the HSF and brackets could not be placed and marked prior to removing the 3 mm x 40 mm section.

NOTE: The HSF base is not as large as the heatspreader, so the position of the holes will dictate if the gap is spread evenly on both sides.

I tried making these brackets 2 ways, and will go into the first method because it turned out the best.
  1) Cut 85 mm of aluminum angle (3/4" by 1/8").
  2) Mark the center so the removed material and sets of holes span equally on either side of this mark.
  3) Make 6-32 (M3 would also work) tapped holes 4 mm in from the edge of the angle and 48 mm apart and make sure the HSF can bolt onto the brackets.
  4) Mark drill spots 69.25 mm apart, again symmetric about the center line from (2), and 3 mm in from the edge (these will be for the larger shoulder screws going into the HSF support on the mobo.
    - Overdrilling these holes (15/64") should be just fine because the retaining rings will keep them in place, and larger holes will give you room to move the shoulder screws around to line up with the backplane holes.
  5) Grind out 3 mm x 40 mm on each bracket (this got infinitely easier once I used an electric grinder instead of a file).
  6) Use a screwdriver to pry off the retaining washers on the OEM heatsink and install them in the larger outer holes.
  7) Use a 1/4" to 3/8" drill bit to make 4 holes through the HSF fins so you can get a screwdriver through them to tighten the shoulder screws (this looks pretty gross and there is likely a better way to accomplish this step).
  8) Add heatsink compound and install on motherboard.
  9) Install the fan (the CPU will get up to 80 C without it under load).

This post has gone on far longer than expected, so I am going to wrap up with some pics that are hopefully helpful. The end result was temps at full load of 50 C and nearly silent operation.

X11SDV U.2 boot challenges

After switching over the head node to an X11SDV-4C-TLN2F board (my original X10SDV-4C did not have 10G ports, and I wanted the PCI-E slot for a graphics card), I figured putting together a couple compute nodes using X11SDV-12C-TLN2F models would be a good idea for having a larger number of cores (all of the previous compute nodes have 8) and testing out AVX-512.

The one hitch to using the new X11SDV offerings is the lack of a M.2 slot, and a U.2 port + Oculink in its place. Said U.2 port did not work with M.2 adapters, so I got a couple Intel Optane 905P drives having U.2 connectors. The first board worked flawlessly, and I used it to set up both Optane drives. The second X11SDV would never see the Optane drive no matter what BIOS options I tried (EFI only and dual were both attempted as first measures), though the USB thumb drive with Ubuntu 18.04.2 server worked just fine. Even more maddening was the Ubuntu installer saw the U.2 drive just fine, only the BIOS was myopic when it came to detecting this boot drive.

After much fussing (and swearing), I finally remembered the most recent version of the BIOS was 1.1a, but the second board was only blessed with 1.0b. Why these two boards, from the same vendor and bought at the same, had different BIOS versions is beyond me. Long story short, updating the BIOS on the second board to 1.1a solved the boot issue.

Cooling X10SDV (Xeon D-1540/1541)

This all began with the purchase of an X10SDV-TLN4F-O for Gaussian09 and MOLPRO calculations (using tmpfs, so IO should not be limiting). When running calculations on all 8 cores I noticed that the cores were rarely above 2100 MHz and the temperatures were in the 60 - 75 °C. For comparison, my two X99 systems with Core i7 5960X processors having water cooling rarely get above 47 °C and alway ran at maximum turbo speed of 3500 MHz.

Time for a couple related notes. I changed the governor to performance using cpufreq and intel_pstate. Disabling pstate was not helpful because the BIOS does not deal properly with turbo (so far as I can tell) because the maximum speed was 2100 MHz when I tried that. This led me to believe thermal throttling was causing the issues.

What to do about the temperatures? Would changing the heatsink compound be enough? Should I just change the fan? Do I need a complete HSF overhaul? Finally, how would I test and assess performance of different solutions? The short answers were I wanted to try everything and HPCC is a decent stand in for Gaussian09 and MOLPRO because it has DGEMM and Linpack sections pretty much represent the computations in those programs (and previous testing with AMD systems showed it produced similar temperatures). HPCC with N = 24000 provided 25 minutes of run time (most of that being in the linpack section). Ambient temperatures fluctuated 1 - 2 °C, and were measured using a calibrated thermistor accurate to better than 0.1 °C. The CPU temperatures were measured using the built-in temperature sensor, and all reported temperatures are differentials. A bash script recorded the CPU temperatures every minute.

As for the heatsink, Alpha Nova Tech produced some custom 70 mm x 70 mm x 40 mm aluminum heatsinks having the same footprint as the stock heatsink (so I could reuse the screws and springs). Next up came the fan ducts, which I designed using OnShape. The two basic geometries involve one fan blowing down or a push-pull arrangement (at 50 ° from horizontal). These were printed using HIPS on a Lulzbot Mini.

Enough details, now on to the results.

HSF	Max	Avg
Stock	42	38
Stock-AS5	39	37
60 mm Everflow	23	20
60 mm Fractal	32	31
60 mm Panaflo	28	25
60 mm San Ace	30	28
60 mm YS Tech	28	25
60 mm Everflow	24	22
60 mm Fractal	32	31
60 mm San Ace	56	53
60 mm YS Tech	55	53
80 mm Akasa	29	27
80 mm Noctua	32	30
80 mm Sunon	23	21
80 mm Vantec	32	30
80 mm Sunon	24	22
92 mm Everflow	28	26
92 mm Gelid	30	27
92 mm Noctua	31	29
PP 60mm Everflow/San Ace	21	19
PP 60 mm Fractal/Noctua	29	26
PP 60 mm Noctua/Fractal	37	35
PP 60 mm Noctua/San Ace	30	27
PP 60 mm San Ace/Everflow	23	21
PP 60 mm San Ace/Fractal	27	26
PP 60 mm San Ace/Noctua	27	25
PP 70 mm Everflow15/Everflow15	23	20
PP 70 mm Everflow15/Everflow25	23	21
PP 70 mm Everflow25/Everlfow15	23	21
PP 70 mm Everflow25/Everflow25	23	21

Ok, so that tells us a couple things. The heatsink compound does reduce the temperature by a few degrees. The custom heatsink lowers the temperatures by approximately 10 °C, and the fan choice provides another 10 °C drop.

High static pressure fans reduce the temperature more than high flow rate fans (no real surprise here). Hence, the 60 mm San Ace and YS Tech, 80 mm Sunon, and 92 mm Everflow are the winners for single fan setups. The push-pull setup definitely lowers the temperatures drastically, especially the maxima. The Everflow 25 mm fans having the lowest noise output.

The losers were the Noctua and Gelid fans, though these were also the lowest noise models.

During all of the tests the processor frequency (as monitored by cat /proc/cpuinfo | grep MHz remained near 2600 MHz. Returning to the Gaussian09 and MOLPRO calculations still showed throttling, though not as bad as before (on average the frequencies remain around 2400 MHz). Hmmmmm...perhaps it is not thermal throttling after all, but at least I feel much better about running these X10SDV units full throttle.

Getting useful XYZ geometries from G09 and transforming them (to angstroms)

I finally got to the point when optimizing geometries of many, many molecules led me to needing more automation to create input files for the subsequent single-point calculations. Methinks this is as good of a time as any to learn python (and by learn I mean cobble together something functional, but ugly). Ok, with that truth out of the way, on to the goal of this exercise. I wanted to optimize geometries in G09, export the geometry (some of the geometry optimizations were in cartesian space and some used an input Z-matrix, so XYZ coordinates are the common output), and use the exported geometries to calculate single-point energies using MOLPRO.

1) First hurdle, getting a useful XYZ coordinates from G09 (also known as, why is there no easy way to grep a final set of cartesian coordinates from the log file?). There are lots of punch options and IOPs, but none that dump the geometry to the log file. This means using "punch=coord" and dealing with the fort.7 file that is generated. Here is the line from my bash script that submits all of the geometry optimizations.

$ for i in $( ls *pbe1pbe-vtz*.com ) ; do echo ${i}; NAME=$(basename $i ".com" ) ; /cluster/software/g09/g09 <./${NAME}.com >./${NAME}.log ; mv fort.7 ${NAME}.xyz ; done

2) Ok, that really was not so terrible, and I will stop complaining now. Second hurdle, transforming the fort.7 file into something useful because it writes the XYZ coordinates using the atomic number (instead of the associated element abbreviation) and the units are bohr. The basic parts of the python script that follow are reading and parsing the input file (this includes substituting "C" for "6", etc), finding the center of mass, shifting all of the atoms so the center of mass is at the origin, converting the distances to angstroms, and writing a new XYZ file. HUGE NOTE: Any improvements would be greatly appreciated.

#!/bin/python

bohr_per_ang = 1.88971616463207
ang_per_bohr = 0.5291772109217

from sys import argv

script, filename = argv

infile1 = open(filename,"r") #opens file with name of "test.txt"

geom1 = []

count = 0
for temp_line in infile1 :
        temp_line = temp_line.strip()
        line = temp_line.split()
        if int(line[0]) == 1 :
                atom = "H"
        elif int(line[0]) == 5 :
                atom = "B"
        elif int(line[0]) == 6 :
                atom = "C"
        parsed_line = [ atom, int(line[0]), float(line[1].replace("D","E")), float(line[2].replace("D","E")), float(line[3].replace("D","E")) ]
        count += 1
        geom1.append(parsed_line)

infile1.close()

#calculate the center of mass in x, y, and z directions
mx = 0
my = 0
mz = 0
mass_total = 0

for i in range(0,count) :
        mx = mx + geom1[i][1]*geom1[i][2]
        my = my + geom1[i][1]*geom1[i][3]
        mz = mz + geom1[i][1]*geom1[i][4]
        mass_total = mass_total + geom1[i][1]

com1 = [mx/mass_total, my/mass_total, mz/mass_total]

#shift all atoms so the center of mass is at 0,0,0
geom1_shifted=[[0 for j in range(0,3)] for i in range(0,count)]

for i in range(0, count) :
        geom1_shifted[i][0] = geom1[i][2] - com1[0]
        geom1_shifted[i][1] = geom1[i][3] - com1[1]
        geom1_shifted[i][2] = geom1[i][4] - com1[2]


outfile1 = open(filename, "w")
outfile1.write("%d\n" % (count) )
outfile1.write("\n")
for i in range(0, count) :
        outfile1.write( "%s %14.10f %14.10f %14.10f\n" % (geom1[i][0]  ,  geom1[i][2]*ang_per_bohr  ,  geom1[i][3]*ang_per_bohr  ,  geom1[i][4]*ang_per_bohr ))

outfile1.close()

And the bash line:

$ for i in $( ls c6h7-int*ub3lyp-6311ppg*.xyz ) ; do echo $i ; python bohr_to_ang.py ./${i} ; done

3) Now that we have that out of the way all we need to do is create a MOLPRO input file. The top part of my template is below, along with the bash line I use to create all of the input files for a given set of geometries (usually belonging to a particular method/basis set).

***,template
memory,800,M
gthresh,oneint=1.d-14,twoint=1.d-14,zero=1.d-14

angstrom
symmetry,nosym
geomtyp=xyz
geom={
}
    basis=6-31G*;
 {multi;canon,3100.2;
 occ,22;closed,21}

    basis=6-311G**;
 {multi;canon,3101.2;
 occ,22;closed,21}

    basis=aug-cc-pvtz;
 {multi;canon,3102.2;
 occ,22;closed,21}

basis={
default,vtz-f12
...

$ for i in $( ls geom-method-tests/c6h7-int*ub3lyp-6311ppg*.xyz ) ; do outname="$( basename $i "-a.xyz" )-uccsdtf12-vtzf12-ad.inp" ; echo $outname; cp c6h7-template-uccsdtf12-vtzf12-ad.inp $outname ; tail -n13 $i >tmpfile ; sed -i -e '/geom={/r tmpfile' $outname ; done

This last bash line uses the bulk of the coordinate filename and concatenates the single-point method and basis set onto the end when making the MOLPRO input file name. I then use sed to put the geometry into the newly minted template just after geom={. Voila!

Installing 7zip on CentOS 7.0

CentOS does not come with 7zip installed, and it is not even readily available on the installation media or default repository. Looks like the next step is to tell yum about another repository and install 7zip from there. Here we go:

# wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.3-1.el7.rf.x86_64.rpm

# rpm -ivh rpmforge-release-0.5.3-1.el7.rf.x86_64.rpm

# yum install p7zip

That's it (other than typing "y" when asked if you really want to install 7zip), and now you should have access to the binary, 7za.

Inconsistent booting on Intel 5960X/Asus X99-deluxe

I just put together a 5960X node because 8 cores and AVX2 should do very well at electronic structure calculations (or anything using matrix-matrix and matrix-vector multiplication). I ran into a problem after it had run flawlessly for a day with half of the RAM. I added in the rest of the RAM (G.Skill Ripjaws DDR4 2400, 8 x 8 GB) and two more SSDs, and then it would no longer POST. After removing the drives and the RAM it was fine, but various combinations of the new hardware did not work, and the Qcode would stop at 00 (not used) or Ad (not even listed). I found out that I had routinely bumped the video card while putting in the RAM (this is not in a case, so nudging the card can lead to poor contact), and it was this improper seating of the vid card in its PCI-E slot that was causing the boot process to hang before getting to POST.

segmented basis sets

Some days a generally contracted basis set won't do, such as when you are trying to calculate CADPAC energy gradients using MCSCF in MOLPRO (namely, you want to use state-averaged calculations). In that case I suffer through using the Pople basis sets for a bit until I feel they are not cutting it, in which case I supply an external basis set using the below library developed in Japan.

http://sapporo.center.ims.ac.jp/sapporo/Welcome.do

Here is an example for C, using their 2012 DZP basis set.

basis={
!******************************************************************************
! Element : C
! Basis : Sapporo-DZP-2012 = gtf non-relativistic ([4s3p1d]{5211/131/2})
! Term : 3P   Valence configuration : 1s(2)2s(2)2p(2)
! SCF energy : -37.67927012 a.u.   
! Valence Correlation energy : -0.11425744 a.u.
! Reference
! Authors : T. Noro, M. Sekiya, T. Koga,  
! Journal : Theoret. Chem. Acc. 131, 1124 (2012)
!******************************************************************************
s,C,2.804431e+003,4.212028e+002,9.581016e+001,2.692019e+001,8.564436e+000,5.147134e+000,4.760360e-001,2.873528e+000,1.497890e-001
c,1.5,2.7210000e-003,2.0759000e-002,1.0106300e-001,3.3470600e-001,6.4691300e-001
c,6.7,-1.5724400e-001,1.0550390e+000
c,8.8,1.0000000e+000
c,9.9,1.0000000e+000
p,C,1.208140e+001,9.439681e+000,2.000405e+000,5.449160e-001,1.514610e-001
c,1.1,1.0000000e+000
c,2.4,5.6939000e-002,3.1332600e-001,7.6035500e-001
c,5.5,1.0000000e+000
d,C,1.251463e+000,3.377940e-001
c,1.2,3.5720487e-001,7.7365173e-001
}

follow up to MOLPRO ROHF convergence difficulties (optimizing a geometry using procedures)

The end result of the last post was that I found level shifts of -0.3, 0.3 worked for my system. A brief tangent for those of you who have perused the manual and saw their suggestion of -1.0,-0.5, I did try that one as well and it does not work in this particular case. Ok, back to the question at hand, how do I optimize a geometry when ROHF won't even converge for a structure that is a local minimum? One way around this is to use MCSCF with one open orbital and run the converged orbitals through ROHF using only one iteration. However, that is a story for another day, in this case I will use the level shifts I listed above. My basic thought was that I really only want to use the level shifts if they are needed, otherwise I will use the default values. These two ideas lead to using a procedure and boolean logic within said procedure.

basis=aug-cc-pvdz

proc autoshift
   rhf
   if(status.lt.0) then
     status,rhf,clear                          !make sure calc does not abort when stock rohf does not converge
     {rhf,shifta=-0.3,shiftb=0.3;        !shifts found using grid search
     start,atden}                              !start with atomic densities again, otherwise rohf will use same "bad" orbitals
  endif
  uccsd(t)
endproc

{optg,proc=autoshift,root=1,energy=1.d-11,step=1.d-5,gradient=1.d-5,displace=symm,numhess=2,hessproc=b3lyphess}

proc b3lyphess
  rhf
  if(status.lt.0) then
    status,rhf,clear                           !same as for autoshift
    {rhf,shifta=-0.3,shiftb=0.3;                                                   
    start,atden}
  endif
  ks,b3lyp
endproc

Here I have made two procedures, one for the optimization using CCSD(T) and one for the Hessian (MOLPRO does far better with frequent numerical hessians when optimizing open-shell doublet molecules) using B3LYP. I will talk about the first one because they are almost identical. Beginning with the if statement, I hate it check if the stock ROHF calculation finished properly. If it did not, then I run ROHF with the level shifts I found in the previous post, taking care to start with the atomic densities and not the orbitals from the previous ROHF calculation. I could put in several of these if statements with various values for the level shifts to be on the safe side, but I wanted to keep this example on the simple side. If this ROHF calculation fails then I still want MOLPRO to error out, so I do not have a status,rhf,clear statement in the if structure. After that I run the UCCSD(T) calculation. The only other bit to include is telling optg that I want to use a procedure, which is accomplished with the proc=autoshift. This is currently running, but it made it past the initial calculation which is progress.

automation of MOLPRO and ROHF convergence testing

Every now and again I run across cases where open-shell systems cause ROHF in MOLPRO to choke. Usually this is easily solved by starting out with STO-3G, stepping up to 6-31G(d), cc-pVDZ, and, finally, aug-cc-pVXZ. MOLPRO seamlessly reads the orbitals from the previous calculation, if available, and projects these onto the new basis set. However, this approach does not work on some occasions and neither does increasing the maximum number of iterations (I have never run into an example where increasing maxit past 100 has helped). This left me with wanting to try level shifts, which would be tedious for anything more than 3 or 4 tries. This leads me to use BASH scripting to automatically generate input files covering a range of level shifts.

for SHIFTA in -0.5 -0.4 -0.3 -0.2 -0.1 0.0 0.1 0.2 0.3 ; do for SHIFTB in -0.5 -0.4 -0.3 -0.2 -0.1 0.0 0.1 0.2 0.3 ; do echo $SHIFTA $SHIFTB ; cp testt-a.inp test-shift${SHIFTA}${SHIFTB}.inp ; sed -i "s/shifta=-0.5,shiftb=-0.5/shifta=${SHIFTA},shiftb=${SHIFTB}/g" test-shift${SHIFTA}${SHIFTB}.inp ; done ; done

The nested for loops generate 81 input files, each having a different set of alpha and beta shifts, ranging from -0.5 to +0.3. The echo line lets you know how far along in the process it is. The cp line creates the input file from a template, test-a.inp. Now to the most interesting line where sed replaces the shift values from the template with the values held in variables shifta and shiftb.

The next step is to run all of these calculations. I opted for simplicity and used the same nested for loops.

module load molpro/2012.1.8 ; for SHIFTA in -0.5 -0.4 -0.3 -0.2 -0.1 0.0 0.1 0.2 0.3 ; do for SHIFTB in -0.5 -0.4 -0.3 -0.2 -0.1 0.0 0.1 0.2 0.3 ; do echo $SHIFTA $SHIFTB ; molpro -n1 <./test-shift${SHIFTA}${SHIFTB}.inp >./test-shift${SHIFTA}${SHIFTB}.out; done ; done

Finally, one needs to look at the results. I echo the shift values and then the ROHF energy. The gawk bit just gets rid of the grep term I use to pull this energy from the output file.

for SHIFTA in -0.5 -0.4 -0.3 -0.2 -0.1 0.0 0.1 0.2 0.3 ; do for SHIFTB in -0.5 -0.4 -0.3 -0.2 -0.1 0.0 0.1 0.2 0.3 ; do echo $SHIFTA $SHIFTB $( grep "RHF STATE 1.1 Energy" ./test-shift${SHIFTA}${SHIFTB}.out | gawk ' { print $5 } ') ; $( grep "No convergence" ./test-shift${shifta}${shiftb}.out ) ; done ; done >./631gs-shift.txt

From here it is easier to change other aspects with one line, such as the basis set, maxit, etc. If I am trying to get the ROHF calculation to converge I should really have grep find convergence issues. On top of that I would like to know which parameters, if any, worked and which were bogus. I modified the above line to add in a grep for "No convergence" and I dump all of the results to a file, which allows me to use the BASH sort function to parse the data either by energy or by convergence. The below line sorts based upon the energy, but one could change 3,3 to 4,4 and sort by convergence.

sort -t$' ' -k 3,3 631gs-shift.txt

pulling useful information from G03/G09 calculations

A short while after I began grad school, which was years ago now, I realized that checking on the progress of a G03/G09 calculation often required sifting through massive amounts of detritus. Rather than use less and then search through the entire file, I began learning grep, sed, and awk. This post deals with the first command, grep, and how to make custom versions that can pull out specific information. Perhaps the example I use most often is checking on the progress of a geometry optimization. G03/G09 spit out the 4 convergence criteria after each iteration, as shown below.

$ grep -iA3 "maximum force" test.log
 Maximum Force            0.009759     0.000450     NO 
 RMS     Force            0.001640     0.000300     NO 
 Maximum Displacement     0.380695     0.001800     NO 
 RMS     Displacement     0.042164     0.001200     NO 
--
 Maximum Force            0.001122     0.000450     NO 
 RMS     Force            0.000200     0.000300     YES
 Maximum Displacement     0.117795     0.001800     NO 
 RMS     Displacement     0.034630     0.001200     NO 
--
 Maximum Force            0.000796     0.000450     NO 
 RMS     Force            0.000091     0.000300     YES
 Maximum Displacement     0.290041     0.001800     NO 
 RMS     Displacement     0.065495     0.001200     NO 
--
 Maximum Force            0.000462     0.000450     NO 
 RMS     Force            0.000095     0.000300     YES
 Maximum Displacement     0.245764     0.001800     NO 
 RMS     Displacement     0.018789     0.001200     NO 
--
 Maximum Force            0.000530     0.000450     NO 
 RMS     Force            0.000087     0.000300     YES
 Maximum Displacement     0.268022     0.001800     NO 
 RMS     Displacement     0.026751     0.001200     NO 
--
 Maximum Force            0.000268     0.000450     YES
 RMS     Force            0.000051     0.000300     YES
 Maximum Displacement     0.268678     0.001800     NO 
 RMS     Displacement     0.020944     0.001200     NO 

The above command grew tedious when I wanted to monitor more than a couple jobs, hence I made an alias in the .bashrc file in my home directory. This way I only had to type the alias and not the entire grep line.

# extracts geometry convergence criteria
alias grepmax='grep -A3 -i "maximum force"'

# extracts time stamps for each CCSD gradient calc
alias grepccsd='grep "Leave Link  106"'

# extracts the number of steps taken during a geometry opt, IRC, or PES scan
alias grepstep='grep "Step number"'

# extracts the rotational constants (in GHz)
alias greprot='grep "Rotational constants"'

# extracts the harmonic vibrational frequencies (3 columns)
alias grepfreq='grep "Frequencies"'

# extracts the G3 energy (at 0 K and at finite T, but not the enthalpy or free energy)
alias grepg3='grep "G3(0 K)"'

G03 failing with "end of file in zsymb"

I recently came across an error I had not seen before while running Gaussian03. Right after the input file is read was the line,

End of file in ZSymb.

I had deleted one too many blank lines after the geometry input (G03 needs at least one), and adding a new line back in at the end fixed this right up.

radeon 7xxx video cards throttling

I have several rigs with 2 x 7950 or 2 x 7970 and on some of them (m4a79t + 7950 and m5a97 r2.0 + 7950) the gpu and memory clock is throttled under high load. After some searching around I found this utility that enables the cards to increase the power consumption of each card (gcc and the amd adl-sdk are required):

https://bitcointalk.org/index.php?topic=8384.0

I have included the code here for the impatient.

#include <iostream>
#include <cstdlib>
#include <adl_sdk.h>

using namespace std;

extern "C"
{
    int ADL_Main_Control_Create (ADL_MAIN_MALLOC_CALLBACK, int);
    int ADL_Adapter_NumberOfAdapters_Get(int *);
    int ADL_Overdrive5_PowerControl_Set(int, int);
    int ADL_Overdrive5_PowerControl_Get(int, int *, int *);
}

void* __stdcall Alloc ( int iSize )
{
    void* lpBuffer = malloc ( iSize );
    return lpBuffer;
}

void __stdcall ADL_Main_Memory_Free ( void** lpBuffer )
{
    if ( NULL != *lpBuffer )
    {
        free ( *lpBuffer );
        *lpBuffer = NULL;
    }
}

int main()
{
        int adapters, a=99, b=99;
        if(ADL_Main_Control_Create (Alloc, 1) != ADL_OK)
        {
                cout << "ADL initialization error!" << endl;
                return -1;
        }
        
        if(ADL_Adapter_NumberOfAdapters_Get(&adapters) != ADL_OK)
        {
                cout << "Cannot get the number of adapters!" << endl;
                return -1;
        }
        cout << "Found " << adapters << " adapters" << endl;
        for(int i=0; i<adapters; i++)
        {
                if(ADL_Overdrive5_PowerControl_Set(i, 10) != ADL_OK)
                {
                        cout << "Failed to set " << i << " power control" << endl;
                        return -1;
                } else { cout << "Value set for " << i << endl; }
                
                if(ADL_Overdrive5_PowerControl_Get(i, &a, &b) != ADL_OK)
                {
                        cout << "Failed to get " << i << " power control" << endl;
                        return -1;
                }
                cout << "result: " << a << "%, b: " << b << endl;
        }
        return 0;
}

The key line here is if(ADL_Overdrive5_PowerControl_Set(i, 10) != ADL_OK), and you can change the 10 to any integer up to 20. In my case 5 didn't quite work, so I had to use 10. Then to compile it you use g++, and run it using the 2nd line.

# g++ -DLINUX -o powercontrol powercontrol.cpp -latiadlxx

# ./powercontrol

Found 12 adapters

Value set for 0

result: 10%, b: 0

Value set for 1

result: 10%, b: 0

Value set for 2

result: 10%, b: 0

Value set for 3

result: 10%, b: 0

Value set for 4

result: 10%, b: 0

Value set for 5

result: 10%, b: 0

Value set for 6

result: 10%, b: 0

Value set for 7

result: 10%, b: 0

Value set for 8

result: 10%, b: 0

Value set for 9

result: 10%, b: 0

Value set for 10

result: 10%, b: 0

Value set for 11

result: 10%, b: 0

When X/kdm do not start properly

These problems go into the pile labeled, "duh, I should have tried that first." Inevitably when I make changes to the graphics hardware or complete a new install of gentoo I get to the final stage of starting X and am left with a black screen (the monitor is still receiving a signal, there's just nothing there). Usually I check Xorg.0.log and kdm.log and find that there were no issues. In this case it probably means I forgot to set the opengl renderer.

# eselect opengl set ati

After a reboot the system comes right up into kde.

The second variation is an old school X cursor, but nothing else resembling a gui (black screen), and Xorg.0.log whines about fglrx_dri.so. In this case I needed to switch the order of the graphics cards in my xorg.conf. The below command spits out the graphics adapters, and the first column is the information we want to put into xorg.conf. In this case I already had the correct pci-e device numbers, but I had them in the wrong order. A simple swap of 2:0:0 and 6:0:0 in xorg.conf (NOTE the syntax change when putting these into xorg.conf) and everything was back to functional. (SIDE NOTE: removing a graphics adapter can alter these numbers, in this rig with one card it sits at 05:00.0)

# lspci | grep -i vga

02:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]

06:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Tahiti XT [Radeon HD 7970]

xorg.conf lines

Section "Device"

        Identifier  "aticonfig-Device[0]-0"

        Driver      "fglrx"

        BusID       "PCI:6:0:0"

EndSection

Section "Device"

        Identifier  "aticonfig-Device[1]-0"

        Driver      "fglrx"

        BusID       "PCI:2:0:0"

EndSection

To give a bit of background about my Linux usage; I began with Mandrake, Suse, and Redhat back in 2001. By 2004 I decided that if I were ever to become proficient using Linux I needed to use it 24/7. At this point I had been trying Gentoo, so I loaded it on all of my boxes and have bounced around with various spin offs of Gentoo (Vidalinux and Funtoo). These days I have moved back to vanilla Gentoo and generally have a small installation of Ubuntu one each box for installing Gentoo.

I suppose if this blog has a purpose, it is primarily to list problems I've run across and fixed. The hope is that writing these solutions down will help my brain cell remember the solutions the next time around.

Now on to the fun stuff, which was udev automagically renaming ethernet devices. The standard tell comes about during system initialization, and rc screams about not being able to start eth0.

$ ifconfig -a

The above command should show the device labeled as something not eth0 (if you don't see anything promising there at all it could be the kernel does not have the driver you need). Now that we know some sort of network device exists there is hope of fixing it. In this case we need to tell udev to stop being so clever and give us back our preciously boring eth0. The solution I decided upon (there were several, I'll try to find links to the others) was adding a rule to /etc/udev/rules.d.

# ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules
# /etc/init.d/udev restart
# /etc/init.d/net.eth0 start