Gaussview is not always able to read Gaussian C01 or D01 formchk files for cubegen. The problem appears when one reads in a chk file in order to visualize MO's. The error looks like this:
Executing Formchk =>
"/usr/software/gaussian/gv/bin/gv_formchk.csh" "/home/kathy/test.chk"
"/scr/gv-11_7_2011_10_36_10/dsdkz.fch"
Read checkpoint file /home/kathy/test.chk
Write formatted file /scr/gv-11_7_2011_10_36_10/dsdkz.fch
Formchk Job Completed (PID = 14f8, status = 0)
Executing Gaussian Cubegen =>
"/usr/software/gaussian/g09.revC01/cubegen" 0 mo=113
"/scr/gv-11_7_2011_10_36_10/dsdkz.fch"
"/scr/gv-11_7_2011_10_36_10/6e63q.cub" -3 h
Data for Alpha MO coefficients on fchk file has wrong length/type:
IsReal=T GotReal=T NReq= 218089 NGot= 215287.
Error termination via Lnk1e at Mon Nov 7 11:02:14 2011.
Error: segmentation violation
rax 0000000000000000, rbx 0000000000d0d808, rcx ffffffffffffffff
rdx 0000000000001502, rsp 00007fffffff9688, rbp 00007fffffff96e0
rsi 000000000000000b, rdi 0000000000001502, r8 00002aaaaaadfbb0
r9 0000000000000000, r10 0000000000000000, r11 0000000000000206
r12 0000000000d0c86b, r13 0000000006e15c08, r14 0000000000d0c918
r15 00007fffffff9ac8
--- traceback not available
Cubegen Job Completed (PID = 1502, status = 6)
This problem is triggered by specific basis sets and is caused by a slight mismatch between Gaussview 5.0.8 and Gaussian 09 revisions C01, D01.
A workaround is to use the command line versions of formchk and cubegen.
If you run the command line versions, the output cube files then be viwed in Gaussview.
The commands are:
formchk test.chk
cubegen 0 mo=113 test.fchk test-113.cub -2 h
The first command generates the test.fchk file which is required in
the second command. The second command generates a cube file for MO 113.
See the
cubegen web page
for more syntax data.
On Feb/24/2015, we implemented a solution for Gaussview 5.0.8 and Gaussian 09 rev D01. This involved changing the default behavior of how Gaussview creates formchk files. We also changed the default behavior of cubegen so that it tests to see if there is a formchk file created by Gaussview and if so, compensate for the slightly different formatting.
We outline the solution here for others who might have the same issue.
Using the ideas presented here, we changed
$GV_DIR/bin/gv_formchk.csh so that is has this syntax:
#!/bin/csh -f
# $1 : Input file (fileroot.chk)
# $2 : Output file (fileroot.fchk)
#
# Converts <.chk> files to <.fchk> files.
#
limit coredumpsize 0
#
formchk -c "${1}" "${2}".gv-orig
sed 's/independent/independant/' "${2}".gv-orig > "${2}"
This runs formchk normally to make a file called "${2}".gv-orig (fileroot.fch.gv-orig) and then runs sed to put a typo into a second version of the fchk file, now called "${2}" (fileroot.fch). Gaussview needs this second version whereas cubegen needs the unmodified version.
We replaced cubegen with a script that includes a test if there is a formcheck file named fileroot.fch.gv-orig as would be made by gv_formchk.csh. If that file exists, then cubegen is run on it instead of on fileroot.fch. If fileroot.fch.gv-orig does not exist, then cubegen runs normally on whatever formchk file that is passed to it.
Here are our commands and script:
cd $g09root/g09.revD01
mv cubegen cubegen.orig
cp $GV_DIR/bin/gv_cubegen.csh cubegen
vi cubegen
and then changed the new cubegen file so that it has these contents:
#!/bin/csh -f
# $1 : memory
# $2 : kind
# $3 : fchkfile
# $4 : cubefile
# $5 : npts
# $6 : format
# $7 : points file (only if npts == -5)
#
# Generates <.cub> files from <.fchk> files.
#
limit coredumpsize 0
#
if (-e "$3".gv-orig ) then
$g09root/g09.revD01/cubegen.orig "$1" "$2" "$3".gv-orig "$4" "$5" "$6" "$7"
else
$g09root/g09.revD01/cubegen.orig "$1" "$2" "$3" "$4" "$5" "$6" "$7"
endif
Ideally one would leave cubegen alone and just change $GV_DIR/bin/gv_cubegen.csh in situ but Gaussview seems to ignore it and instead calls cubegen directly. So we have chosen to use it as a template for a wraparound for cubegen itself. Cubegen still seems to work on the command line even though it too calls the script.
If anyone comes up with a better solution, please email durkin at berkeley edu. Thanks. I suppose one could modify the PATH but that gets tricky to get consistent behavior.