Bug in gaussian parsing polarizability
See original GitHub issueIn my .log file the gaussian parser chokes trying to parse polarizabilities:
Attempting to read foo.log
[Gaussian foo.log ERROR] Encountered error when parsing.
[Gaussian foo.log ERROR] Last line read: Exact polarizability: -20751.174 -0.389 1217.309 -6307.929 0.037 -646.713
Traceback (most recent call last):
File "/home/oliver/.local/bin/ccget", line 8, in <module>
sys.exit(ccget())
File "/home/oliver/.local/lib/python3.8/site-packages/cclib/scripts/ccget.py", line 176, in ccget
data = ccread(filename, **kwargs)
File "/home/oliver/.local/lib/python3.8/site-packages/cclib/io/ccio.py", line 169, in ccread
return log.parse()
File "/home/oliver/.local/lib/python3.8/site-packages/cclib/parser/logfileparser.py", line 315, in parse
self.extract(inputfile, line)
File "/home/oliver/.local/lib/python3.8/site-packages/cclib/parser/gaussianparser.py", line 2110, in extract
polarizability[indices] = [utils.float(x) for x in
File "/home/oliver/.local/lib/python3.8/site-packages/cclib/parser/gaussianparser.py", line 2110, in <listcomp>
polarizability[indices] = [utils.float(x) for x in
File "/home/oliver/.local/lib/python3.8/site-packages/cclib/parser/utils.py", line 74, in float
return _BUILTIN_FLOAT(number.replace("D", "E"))
ValueError: could not convert string to float: '.309 -'
This happens because the parsing is based on exact line positions, which does not apply in this case at least:
polarizability[indices] = [utils.float(x) for x in
[line[23:31], line[31:39], line[39:47], line[47:55], line[55:63], line[63:71]]]
It can presumably be fixed by using line.split() or similar instead. I can submit a PR but not the .log file sadly as it is private.
Issue Analytics
- State:
- Created 2 years ago
- Comments:8 (8 by maintainers)
Top Results From Across the Web
REV C - Gaussian.com
TD Freq=Raman computes the polarizability by numerical differentiation with respect to an electric field, so the cost of Freq=Raman for ...
Read more >Changelog — cclib 1.7.1 documentation
Fixed polarizability parsing bug in DALTON (Maxim Stolyarchuk). Fixed IRC parsing in Gaussian for large trajectories (Dénes Berta, LaTruelle).
Read more >Leave a question! - Dr. Joaquin Barroso's Blog
Hello, i am facing one problem related to my calculation. When i upload my input file having B3LYP/6-31G (d) set to gaussian then...
Read more >Release Notes version 1.4 - ECCE
This includes a brief description of new features, known bugs, ... Geometries not parsed for Gaussian-94 molecules without Standard orientation.
Read more >Gaussian 09 Revision D.01 Release Notes 4 June 2013
*Bug Fixes between Gaussian 09 Revisions D.01 and C.01: ... polarizability derivatives (and the other two tensor derivatives for ROA) be computed and ......
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@ghutchis I was thinking that the older format could possibly work but put nonsense in each of the slices of the line, since the older line is shorter than the new format. If we try the new format first, we would get an out of range error triggering the except.
@shivupa - would it be better to
try
the old one by default and use theexcept
as the newer version? I’m guessing there are far more files with the older format.@oliver-s-lee - would you be able to run the testdata file with
C01
for a regression test?