cclib-devel — Developer's mailing list

Re: [cclib-devel] Gaussianparser frequency parse bug

[Karol M. L. <kar...@gm...>]

Great to see this fixed!

- Karol

On Oct 30 2013, Noel O'Boyle wrote:
> Thanks Clyde. Fixed in dev version as follows:
> http://sourceforge.net/p/cclib/code/1064/tree//trunk/src/cclib/parser/gaussianparser.py?diff=50d38e5fe88f3d233d970f93:1063
> 
> The problem was that IRC calculations must put the frequency number,
> i.e. 1, 2, 3, etc. in a different column (off-by-one). Don't ask me
> why.
> 
> - Noel
> 
> On 3 October 2013 15:58, Clyde Fare <cly...@gm...> wrote:
> > Hi,
> >
> > Enclosed is a log file that causes problems extracting frequencies, in
> > particular of the 11 frequencies recorded in the log file only 10 and 11 are
> > extracted.
> >
> > I think the problem is due to the following lines of code:
> >
> >                 # The line with indices
> >                 if line[1:15].strip() == "" and
> > line[15:22].strip().isdigit():
> >                     freqbase = int(line[15:22])
> >                     if freqbase == 1 and hasattr(self, 'vibfreqs'):
> >                         # This is a reparse of this information
> >                         removeold = True
> >
> > and
> >
> >                     if removeold: # This is a reparse, so throw away the old
> > info
> >                         if hasattr(self, "vibsyms"):
> >                             # We have already parsed the vibsyms so don't
> > throw away!
> >                             self.vibsyms =
> > self.vibsyms[-len(line[15:].split()):]
> >                         if hasattr(self, "vibirs"):
> >                             self.vibirs = []
> >                         if hasattr(self, 'vibfreqs'):
> >                             self.vibfreqs = []
> >                         if hasattr(self, 'vibramans'):
> >                             self.vibramans = []
> >                         if hasattr(self, 'vibdisps'):
> >                             self.vibdisps = []
> >                         removeold = False
> >
> > Which mean once the 10th frequency is reached all frequencies are deleted
> > and parsing begins again.
> >
> > In my local copy I've changed the line:
> >
> > freqbase = int(line[15:22])
> >
> > to
> >
> > freqbase = int(line.split()[0])
> >
> > which I think covers the case the code is intended to cover.
> >
> > Cheers
> >
> > Clyde
> >
> >
> >
> > ------------------------------------------------------------------------------
> > October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> > from
> > the latest Intel processors and coprocessors. See abstracts and register >
> > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> > _______________________________________________
> > cclib-devel mailing list
> > ccl...@li...
> > https://lists.sourceforge.net/lists/listinfo/cclib-devel
> >
> 
> ------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

-- 
written by Karol M. Langner
Wed Oct 30 22:10:24 EDT 2013

Re: [cclib-devel] Gaussianparser frequency parse bug

[Noel O'B. <bao...@gm...>]

Thanks Clyde. Fixed in dev version as follows:
http://sourceforge.net/p/cclib/code/1064/tree//trunk/src/cclib/parser/gaussianparser.py?diff=50d38e5fe88f3d233d970f93:1063

The problem was that IRC calculations must put the frequency number,
i.e. 1, 2, 3, etc. in a different column (off-by-one). Don't ask me
why.

- Noel

On 3 October 2013 15:58, Clyde Fare <cly...@gm...> wrote:
> Hi,
>
> Enclosed is a log file that causes problems extracting frequencies, in
> particular of the 11 frequencies recorded in the log file only 10 and 11 are
> extracted.
>
> I think the problem is due to the following lines of code:
>
>                 # The line with indices
>                 if line[1:15].strip() == "" and
> line[15:22].strip().isdigit():
>                     freqbase = int(line[15:22])
>                     if freqbase == 1 and hasattr(self, 'vibfreqs'):
>                         # This is a reparse of this information
>                         removeold = True
>
> and
>
>                     if removeold: # This is a reparse, so throw away the old
> info
>                         if hasattr(self, "vibsyms"):
>                             # We have already parsed the vibsyms so don't
> throw away!
>                             self.vibsyms =
> self.vibsyms[-len(line[15:].split()):]
>                         if hasattr(self, "vibirs"):
>                             self.vibirs = []
>                         if hasattr(self, 'vibfreqs'):
>                             self.vibfreqs = []
>                         if hasattr(self, 'vibramans'):
>                             self.vibramans = []
>                         if hasattr(self, 'vibdisps'):
>                             self.vibdisps = []
>                         removeold = False
>
> Which mean once the 10th frequency is reached all frequencies are deleted
> and parsing begins again.
>
> In my local copy I've changed the line:
>
> freqbase = int(line[15:22])
>
> to
>
> freqbase = int(line.split()[0])
>
> which I think covers the case the code is intended to cover.
>
> Cheers
>
> Clyde
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] Gaussianparser frequency parse bug

[Noel O'B. <bao...@gm...>]

Hi Clyde,

Sorry - it's taken me a while to come back to this.

Unfortunately you have removed too much of the header. We rely on the
phrase "Gaussian, Inc." in the header to identify Gaussian files
automatically. Could you just make the minimal changes required or
replace filenames and usernames with generic filenames and usernames.

- Noel

On 7 October 2013 12:37, Clyde Fare <cly...@gm...> wrote:
> Hi Noel, here's a version (just removed the header) I'm happy for you to put
> into the public domain.
>
> Cheers
>
> Clyde
>
>
>
>
> On 6 October 2013 11:15, Noel O'Boyle <bao...@gm...> wrote:
>>
>> Thanks for this Clyde. Are you happy to place this log file in the
>> public domain?
>>
>> - Noel
>>
>> On 3 October 2013 15:58, Clyde Fare <cly...@gm...> wrote:
>> > Hi,
>> >
>> > Enclosed is a log file that causes problems extracting frequencies, in
>> > particular of the 11 frequencies recorded in the log file only 10 and 11
>> > are
>> > extracted.
>> >
>> > I think the problem is due to the following lines of code:
>> >
>> >                 # The line with indices
>> >                 if line[1:15].strip() == "" and
>> > line[15:22].strip().isdigit():
>> >                     freqbase = int(line[15:22])
>> >                     if freqbase == 1 and hasattr(self, 'vibfreqs'):
>> >                         # This is a reparse of this information
>> >                         removeold = True
>> >
>> > and
>> >
>> >                     if removeold: # This is a reparse, so throw away the
>> > old
>> > info
>> >                         if hasattr(self, "vibsyms"):
>> >                             # We have already parsed the vibsyms so
>> > don't
>> > throw away!
>> >                             self.vibsyms =
>> > self.vibsyms[-len(line[15:].split()):]
>> >                         if hasattr(self, "vibirs"):
>> >                             self.vibirs = []
>> >                         if hasattr(self, 'vibfreqs'):
>> >                             self.vibfreqs = []
>> >                         if hasattr(self, 'vibramans'):
>> >                             self.vibramans = []
>> >                         if hasattr(self, 'vibdisps'):
>> >                             self.vibdisps = []
>> >                         removeold = False
>> >
>> > Which mean once the 10th frequency is reached all frequencies are
>> > deleted
>> > and parsing begins again.
>> >
>> > In my local copy I've changed the line:
>> >
>> > freqbase = int(line[15:22])
>> >
>> > to
>> >
>> > freqbase = int(line.split()[0])
>> >
>> > which I think covers the case the code is intended to cover.
>> >
>> > Cheers
>> >
>> > Clyde
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > October Webinars: Code for Performance
>> > Free Intel webinars can help you accelerate application performance.
>> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> > from
>> > the latest Intel processors and coprocessors. See abstracts and register
>> > >
>> >
>> > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > cclib-devel mailing list
>> > ccl...@li...
>> > https://lists.sourceforge.net/lists/listinfo/cclib-devel
>> >
>
>

Re: [cclib-devel] GAMESS + CClib not working

[Noel O'B. <bao...@gm...>]

Hi Benjamin,

I've just checked and it works for me with the current development
code. I suggest you try the latest version. If that doesn't work, then
you will either have to wait for the next release or use the
development code yourself. These last options requires Python 3.

- Noel

On 23 October 2013 23:19, benjamin sanchez lengeling
<bea...@gm...> wrote:
> Yes I am willing to place it into public domain.
>
>
> On Fri, Oct 18, 2013 at 2:00 AM, Noel O'Boyle <bao...@gm...> wrote:
>>
>> Hello Benjamin,
>>
>> We only fix bugs for public domain log files. Are you happy to place
>> this log file in the public domain?
>>
>> Regards,
>>    Noel
>>
>> On 14 October 2013 23:35, benjamin sanchez lengeling
>> <bea...@gm...> wrote:
>> > hi all,
>> > script and ouput is provided.
>> > CClib not working :(
>> >
>> > Exits with error:
>> > "
>> > File "CheckGeometry.py", line 17, in <module>
>> >     data = myfile.parse()
>> >   File
>> > "/usr/local/lib/python2.7/dist-packages/cclib/parser/logfileparser.py",
>> > line
>> > 221, in parse
>> >     self.extract(inputfile, line)
>> >   File
>> > "/usr/local/lib/python2.7/dist-packages/cclib/parser/gamessparser.py",
>> > line
>> > 676, in extract
>> >     assert line == blank
>> > AssertionError
>> >
>> > "
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > October Webinars: Code for Performance
>> > Free Intel webinars can help you accelerate application performance.
>> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> > from
>> > the latest Intel processors and coprocessors. See abstracts and register
>> > >
>> >
>> > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > cclib-devel mailing list
>> > ccl...@li...
>> > https://lists.sourceforge.net/lists/listinfo/cclib-devel
>> >
>
>

Re: [cclib-devel] GAMESS + CClib not working

[Noel O'B. <bao...@gm...>]

Hello Benjamin,

We only fix bugs for public domain log files. Are you happy to place
this log file in the public domain?

Regards,
   Noel

On 14 October 2013 23:35, benjamin sanchez lengeling
<bea...@gm...> wrote:
> hi all,
> script and ouput is provided.
> CClib not working :(
>
> Exits with error:
> "
> File "CheckGeometry.py", line 17, in <module>
>     data = myfile.parse()
>   File
> "/usr/local/lib/python2.7/dist-packages/cclib/parser/logfileparser.py", line
> 221, in parse
>     self.extract(inputfile, line)
>   File
> "/usr/local/lib/python2.7/dist-packages/cclib/parser/gamessparser.py", line
> 676, in extract
>     assert line == blank
> AssertionError
>
> "
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] [cclib-users] FMO properties

[Karol M. L. <kar...@gm...>]

Well, anything >=7.0 would be OK, I guess. If it's newer than 7.0, it would be best to rerun our whole test suite and update the files.

The main thing would be to add population analysis (at least Mulliken), which the Manual says can be chosen in the Method section.

- Karol

On Sep 27 2013, Adam Tenderholt wrote:
> Turns out my former lab does actually have access to Jaguar. I don't know
> which version though. Are there any specific calculations I should try to
> have run?
> 
> 
> 
> On Mon, Sep 23, 2013 at 4:01 PM, Adam Tenderholt <ate...@gm...>wrote:
> 
> > I also don't have access to Jaguar, and my former lab no longer licenses
> > it. So I guess we have a few options: don't provide support, ask
> > Schroedinger for a complimentary license, or seek out potential
> > collaborators (i.e. ccl.net). Thoughts?
> >
> >
> > On Mon, Sep 23, 2013 at 8:51 AM, Noel O'Boyle <bao...@gm...>wrote:
> >
> >> I no longer have access to any of these I'm afraid...
> >>
> >> On 19 September 2013 05:18, Karol M. Langner <kar...@gm...>
> >> wrote:
> >> > I looked at the atomcharges code, and fixed the GAMESS-US parser a bit.
> >> >
> >> > One more thing, though. Our current Jaguar and Molpro log files for
> >> unit testing do not contain any partial charges, so there is nothing to
> >> test at this point. I could update the Molpro files, but does anyone have
> >> access to Jaguar now?
> >> >
> >> > - Karol
> >> >
> >> > On Sep 18 2013, Karol M. Langner wrote:
> >> >> Yeah, forwarding to the dev list.
> >> >>
> >> >> So... any thoughts for/against these candidates:
> >> >> 1. aopop
> >> >> 2. aopops
> >> >> 3. aopopulation
> >> >> 4. aopopulations
> >> >> 5. populations
> >> >>
> >> >> I think I prefer the first one, for its brevity.
> >> >>
> >> >> Cheers,
> >> >> Karol
> >> >>
> >> >> On Sep 18 2013, Adam Tenderholt wrote:
> >> >> > Hi Karol,
> >> >> >
> >> >> > Thanks for taking care of this. I forgot that an atomcharges
> >> attribute was
> >> >> > added. As far as aopop or aopopuations, perhaps that discussion
> >> should be
> >> >> > moved to cclib-devel?
> >> >> >
> >> >> > Adam
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Wed, Sep 18, 2013 at 3:24 PM, Karol M. Langner
> >> >> > <kar...@gm...>wrote:
> >> >> >
> >> >> > > Hi,
> >> >> > >
> >> >> > > Some time ago we actually created the 'atomcharges' attribute:
> >> >> > > http://cclib.sourceforge.net/wiki/index.php/Atomcharges
> >> >> > > (see that page for the data description)
> >> >> > >
> >> >> > > So I went ahead and extended that to NPA charges and just commited
> >> >> > > code that parses them for Gaussian09. And the newest trunk code
> >> >> > > should parse the output file you sent, Fedor.
> >> >> > >
> >> >> > > We don't have atomcharges coded yet for Turbomole or Jaguar, but it
> >> >> > > should not be hard and this would be a good time to do it.
> >> >> > >
> >> >> > > As far as populations go, I believe we would need to create a new
> >> attribute
> >> >> > > for that, since it doesn't fit anywhere else. It should probably
> >> also
> >> >> > > be a dictionary.
> >> >> > >
> >> >> > > To keep with our current naming scheme, how about 'aopop' or
> >> >> > > 'aopopulation'?
> >> >> > >
> >> >> > > Cheers,
> >> >> > > Karol
> >> >> > >
> >> >> > > On Sep 13 2013, Fedor Zhuravlev wrote:
> >> >> > > > Hi Adam and Karol,
> >> >> > > >
> >> >> > > > Frontier Molecular Orbitals: This is exactly what I was looking
> >> for
> >> >> > > folks,  thanks!
> >> >> > > >
> >> >> > > > For the NPA analysis:  I have included 3 log files from g09,
> >> Jaguar 7
> >> >> > > and Turbomole 6.1, all containing the output from the NPA
> >> calculations (at
> >> >> > > the end of the file, they look very similar). The values of
> >> interest could
> >> >> > > be the Natural Charge and Natural Electron Population. Those would
> >> be nice
> >> >> > > to extract.
> >> >> > > >
> >> >> > > > Fedor
> >> >> > > >
> >> >> > > > From: Adam Tenderholt [mailto:ate...@gm...]
> >> >> > > > Sent: 12 September 2013 18:08
> >> >> > > > To: Fedor Zhuravlev
> >> >> > > > Cc: Karol M. Langner; ccl...@li...
> >> >> > > > Subject: Re: [cclib-users] FMO properties
> >> >> > > >
> >> >> > > > Hi Fedor,
> >> >> > > >
> >> >> > > > Getting the energies of the HOMO and LUMO is pretty
> >> straight-forward:
> >> >> > > >
> >> >> > > > from cclib.parser import ccopen
> >> >> > > >
> >> >> > > > parser = ccopen(logfile)
> >> >> > > > data = parser.parser()
> >> >> > > > homo = data.homos[0] # assuming spin-restricted
> >> >> > > > lumo = homo + 1
> >> >> > > >
> >> >> > > > homo_energy = data.moenergies[0][homo]
> >> >> > > > lumo_energy = data.moenergies[0][lumo]
> >> >> > > >
> >> >> > > > As far as parsing population analyses, Noel, Karol, and I will
> >> have to
> >> >> > > discuss the potential implementation details. Do you have a
> >> favorite QM
> >> >> > > package?
> >> >> > > >
> >> >> > > > Adam
> >> >> > > >
> >> >> > > >
> >> >> > > > On Thu, Sep 12, 2013 at 12:45 AM, Fedor Zhuravlev <fe...@dt...
> >> <mailto:
> >> >> > > fe...@dt...>> wrote:
> >> >> > > > Hi Karol and Adam,
> >> >> > > >
> >> >> > > > Thanks much for the prompt reply. I was looking for the energies
> >> of HOMO
> >> >> > > and LUMO. From there, using the Koopman's theorem one gets the
> >> ionization
> >> >> > > energy (HOMO=IE). (HOMO + LUMO)/2 is chemical potential (CP);
> >> LUMO-HOMO is
> >> >> > > chemical hardness (H), while CP^2/2H is Parr's electrophilicity
> >> (JACS,
> >> >> > > 1999, 121, 1922).  4 very useful, easily chemically interpretable
> >> chemical
> >> >> > > descriptors for the price of two frontier MO!  Would be very nice
> >> to have!
> >> >> > > >
> >> >> > > > As for the natural population analysis the QM code would
> >> normally do it
> >> >> > > itself (at least Gaussian, Turbomole, and Jaguar), so it is just
> >> the
> >> >> > > question of proper parsing the data.  Most people would normally be
> >> >> > > interested in the natural charge and natural population.
> >> >> > > >
> >> >> > > > That was my wish list for Christmas :)
> >> >> > > >
> >> >> > > > Fedor Zhuravlev
> >> >> > > > Senior Researcher
> >> >> > > > DTU Nutech
> >> >> > > > Technical University of Denmark
> >> >> > > > Center for Nuclear Technologies
> >> >> > > > Hevesy Laboratory
> >> >> > > > DTU Risø Campus
> >> >> > > >
> >> >> > > > Frederiksborgvej 399 Building 202
> >> >> > > > Building 202
> >> >> > > > 4000 Roskilde
> >> >> > > > fe...@dt...<mailto:fe...@dt...>
> >> >> > > > www.nutech.dtu.dk<http://www.nutech.dtu.dk>
> >> >> > > >
> >> >> > > >
> >> >> > > >
> >> >> > > >
> >> >> > > >
> >> >> > > >
> >> >> > > > -----Original Message-----
> >> >> > > > From: Karol M. Langner [mailto:kar...@gm...<mailto:
> >> >> > > kar...@gm...>]
> >> >> > > > Sent: 12 September 2013 00:31
> >> >> > > > To: Adam Tenderholt
> >> >> > > > Cc: Fedor Zhuravlev; ccl...@li...<mailto:
> >> >> > > ccl...@li...>
> >> >> > > > Subject: Re: [cclib-users] FMO properties
> >> >> > > >
> >> >> > > > I assumed fragment energies in the fragment molecular orbital
> >> method in
> >> >> > > GAMESS-US...
> >> >> > > >
> >> >> > > > On Sep 11 2013, Adam Tenderholt wrote:
> >> >> > > > > Hi Fedor,
> >> >> > > > >
> >> >> > > > > I wanted to follow up on Karol's email. I'm not familiar with
> >> the
> >> >> > > > > details of NPA, and I briefly looked up the
> >> Reed/Weinstock/Weinhold
> >> >> > > > > paper. Adding it as a method in cclib is likely possible, but
> >> it would
> >> >> > > > > probably take several hours to fully understand the algorithm,
> >> and
> >> >> > > > > then implement and test it. This does interest me, although
> >> I'm not
> >> >> > > > > sure when I could get around to it.
> >> >> > > > >
> >> >> > > > > Also, what exactly do you mean by FMO energies? To me, FMO
> >> could stand
> >> >> > > > > for either fragment molecular orbitals or frontier molecular
> >> orbitals.
> >> >> > > > > Do you have a concrete example?
> >> >> > > > >
> >> >> > > > > Adam
> >> >> > > > >
> >> >> > > > >
> >> >> > > > >
> >> >> > > > > On Wed, Sep 11, 2013 at 8:01 AM, Karol M. Langner
> >> >> > > > > <kar...@gm...<mailto:kar...@gm...
> >> >>wrote:
> >> >> > > > >
> >> >> > > > > > On Sep 11 2013, Fedor Zhuravlev wrote:
> >> >> > > > > > > Dear cclib development team,
> >> >> > > > > > >
> >> >> > > > > > > Just had a first look at cclib and here's my questions:
> >> >> > > > > > >
> >> >> > > > > > >
> >> >> > > > > > > 1.       Is there a single-liner to get FMO energies only?
> >> >> > > > > > >
> >> >> > > > > > > 2.       What about natural population analysis?
> >> >> > > > > > >
> >> >> > > > > > > Thanks much,
> >> >> > > > > > >
> >> >> > > > > > > Fedor
> >> >> > > > > >
> >> >> > > > > > Hi Fedor,
> >> >> > > > > >
> >> >> > > > > > Nice to hear from you. I've used cclib to parse FMO output
> >> from
> >> >> > > > > > GAMESS-US in the past, but it involved a quick custom hack,
> >> which I
> >> >> > > > > > still may have somewhere I guess (I did this outside of
> >> version
> >> >> > > > > > control). However, this was some years ago, and I think the
> >> format
> >> >> > > > > > has changed significantly since then.
> >> >> > > > > >
> >> >> > > > > > As far as population analyses are concerned, we do not parse
> >> them,
> >> >> > > > > > although there was a discussion about that in the past. We
> >> have
> >> >> > > > > > implemented several population analysis algorithms alongside
> >> cclib,
> >> >> > > though:
> >> >> > > > > >
> >> http://cclib.sourceforge.net/wiki/index.php/Calculation_methods
> >> >> > > > > > ... although NAO is not among them. If you're thinking about
> >> the
> >> >> > > > > > original approach published by Reed/Weinstock/Weinhold, I
> >> think it's
> >> >> > > > > > a modification of Lowdin's orthoganolization, which we do.
> >> So you
> >> >> > > > > > could try to extend it to get what you want. Maybe Noel or
> >> Adam has
> >> >> > > more thoughts about this?
> >> >> > > > > >
> >> >> > > > > > If you want something specific parsed, you will generally
> >> need to
> >> >> > > > > > provide us with an example output file that we can use for
> >> testing.
> >> >> > > > > >
> >> >> > > > > > Cheers,
> >> >> > > > > > Karol
> >> >> > > > > >
> >> >> > > > > > --
> >> >> > > > > > written by Karol M. Langner
> >> >> > > > > > Wed Sep 11 10:51:11 EDT 2013
> >> >> > > > > >
> >> >> > > > > >
> >> >> > > > > >
> >> --------------------------------------------------------------------
> >> >> > > > > > ---------- How ServiceNow helps IT people transform IT
> >> departments:
> >> >> > > > > > 1. Consolidate legacy IT systems to a single system of
> >> record for IT
> >> >> > > > > > 2. Standardize and globalize service processes across IT 3.
> >> >> > > > > > Implement zero-touch automation to replace manual, redundant
> >> tasks
> >> >> > > > > >
> >> http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg
> >> >> > > > > > .clktrk _______________________________________________
> >> >> > > > > > cclib-users mailing list
> >> >> > > > > > ccl...@li...<mailto:
> >> >> > > ccl...@li...>
> >> >> > > > > > https://lists.sourceforge.net/lists/listinfo/cclib-users
> >> >> > > > > >
> >> >> > > >
> >> >> > > > --
> >> >> > > > written by Karol M. Langner
> >> >> > > > Wed Sep 11 18:30:58 EDT 2013
> >> >> > > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > --
> >> >> > > written by Karol M. Langner
> >> >> > > Wed Sep 18 18:11:05 EDT 2013
> >> >> > >
> >> >>
> >> >> --
> >> >> written by Karol M. Langner
> >> >> Wed Sep 18 22:29:09 EDT 2013
> >> >
> >> > --
> >> > written by Karol M. Langner
> >> > Thu Sep 19 00:14:43 EDT 2013
> >> >
> >> >
> >> ------------------------------------------------------------------------------
> >> > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> >> > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> >> SharePoint
> >> > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> >> includes
> >> > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> >> >
> >> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> >> > _______________________________________________
> >> > cclib-devel mailing list
> >> > ccl...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/cclib-devel
> >>
> >
> >

-- 
written by Karol M. Langner
Mon Oct  7 07:47:56 EDT 2013

Re: [cclib-devel] Gaussianparser frequency parse bug

[Noel O'B. <bao...@gm...>]

Thanks for this Clyde. Are you happy to place this log file in the
public domain?

- Noel

On 3 October 2013 15:58, Clyde Fare <cly...@gm...> wrote:
> Hi,
>
> Enclosed is a log file that causes problems extracting frequencies, in
> particular of the 11 frequencies recorded in the log file only 10 and 11 are
> extracted.
>
> I think the problem is due to the following lines of code:
>
>                 # The line with indices
>                 if line[1:15].strip() == "" and
> line[15:22].strip().isdigit():
>                     freqbase = int(line[15:22])
>                     if freqbase == 1 and hasattr(self, 'vibfreqs'):
>                         # This is a reparse of this information
>                         removeold = True
>
> and
>
>                     if removeold: # This is a reparse, so throw away the old
> info
>                         if hasattr(self, "vibsyms"):
>                             # We have already parsed the vibsyms so don't
> throw away!
>                             self.vibsyms =
> self.vibsyms[-len(line[15:].split()):]
>                         if hasattr(self, "vibirs"):
>                             self.vibirs = []
>                         if hasattr(self, 'vibfreqs'):
>                             self.vibfreqs = []
>                         if hasattr(self, 'vibramans'):
>                             self.vibramans = []
>                         if hasattr(self, 'vibdisps'):
>                             self.vibdisps = []
>                         removeold = False
>
> Which mean once the 10th frequency is reached all frequencies are deleted
> and parsing begins again.
>
> In my local copy I've changed the line:
>
> freqbase = int(line[15:22])
>
> to
>
> freqbase = int(line.split()[0])
>
> which I think covers the case the code is intended to cover.
>
> Cheers
>
> Clyde
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>