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.