cclib-devel Mailing List for cclib

Fixed in SVN. Thanks for reporting.

On 10 September 2012 14:21, Björn Dahlgren <bd...@kt...> wrote:
> Dear Noel O'Boyle,
>
> I guess this should go to the devel mailing list but I never figured out how
> to deal with mailing lists so I send this directly to you. I hope it is not
> a problem.
>
> There is a bug in cclib 1.0.1
>
> when parsing a gaussian log file with coincidently reoccuring CCSD(T)=
> statements ccenergies attribute is set twice. (affected gaussian log file
> attached to this email)
>
> Changing line 353 in cclib/parser/gaussianparser.py to:
>
>             if not hasattr(self, 'ccenergy'):
>                 self.ccenergy = self.float(line.split()[1])
>
> fixes the bug
>
> All the best
> /Björn Dahlgren, KTH Royal Institute of Technology

Hi there,

I just noticed two cases of testing for "Leaving Link XXX" in the
Gaussian parser. Just to note that we should avoid this as the "Link"
statement is not present unless the user specified "#P", as far as I
know.

I'm removing one of them in the course of fixing a bug of Bjorn's...

- Noel

I have just checked this with the development version and it seems to
be fine; that is, with the attached logfile, I see 36 vibfreqs not 72.

- Noel

On 9 October 2012 14:55, Björn Dahlgren <bd...@kt...> wrote:
> Dear all,
>
> I just wanted to raise the question if the following is a desired behaviour:
>
> parsing a combined Gaussian `opt=(calcall) freq` job logfile yields spurious
> copies of frequencies from optimization in `vibfreqs`.
>
> I attach a zipped logfile to illustrate the problem. i.e. this 14 atom
> structure have 72 vibfreqs (!) instead of 36...
>
> Cheers,
> /Björn
>

Fixed as you suggested in revision 1024. No need for the test case
(but thanks!), as we had examples already in the suite. The problem
was a change in the format between Gaussian 03 and Gaussian 09.

- Noel

On 7 January 2013 13:49, Björn Dahlgren <bd...@kt...> wrote:
> Dear all,
>
> in the latest version of cclib there is a bug in gaussianparser.py (line 772
> in svn revision 1021) for assigning vibdisps:
>
> if line[1:29] == "Atom AN      X      Y      Z":
>
> where the line in attached h2o_freq.log looks like:
>
>   Atom  AN      X      Y      Z        X      Y      Z        X      Y
> Z
>
> That is 2 spaces + 'Atom' + 2 spaces + 'AN' etc.
> This causes cclib not to assign vibdisps for this freqency job.
>
> Changing the line with the if statement into:
>
>                  if line.strip().split()[:5] == ['Atom', 'AN', 'X', 'Y',
> 'Z']:
>
> Makes it less sensitive to varying spaces.
>
> Best regards,
> Björn Dahlgren
>
> P.S. you may of course include attached log file into test-suite and make it
> public
>
> On Tue, Oct 9, 2012 at 1:59 PM, Björn Dahlgren <bd...@kt...> wrote:
>>
>> Dear all,
>>
>> I just wanted to raise the question if the following is a desired
>> behaviour:
>>
>> parsing a combined Gaussian `opt=(calcall) freq` job logfile yields
>> spurious copies of frequencies from optimization in `vibfreqs`.
>>
>> I attach a logfile to illustrate the problem. i.e. this 14 atom structure
>> have 72 vibfreqs (!) instead of 36...
>>
>> Cheers,
>> /Björn
>>
>

Done.

On 8 October 2012 18:56, Adam Tenderholt <ate...@gm...> wrote:
> I've added a regression test for Gaussian 09 Lowdin charges (dvb_lowdin).
> The logfile should be wget-able, and the regression file currently fails
> because it can't find lowdin in atomcharges (but can find mulliken).
>
>
> On Mon, Oct 8, 2012 at 9:14 AM, Karol M. Langner <kar...@gm...>
> wrote:
>>
>> Sure, if you can spare the time, add them as a regression or replace the
>> current unit test.
>>
>> - Karol
>>
>> P.S. I also took a stab at updating the wiki for atomcharges/atomspins,
>> but in the end it would be good to generate some of the wiki (parsed data
>> tables) automatically.
>>
>> On Oct 08 2012, Adam Tenderholt wrote:
>> > Hi Karol,
>> >
>> > Thanks for working on these attributes. Looks like you covered the big
>> > five
>> > (Gaussian, ADF, ORCA, GAMESS, and GAMESS-UK). I think there's an iop for
>> > Gaussian that causes Lowdin charges to be printed. Want me to try this?
>> >
>> > Adam
>> >
>> >
>> > On Sat, Oct 6, 2012 at 11:33 AM, Karol M. Langner
>> > <kar...@gm...>wrote:
>> >
>> > > On Oct 06 2012, Karol M. Langner wrote:
>> > > > On Oct 05 2012, Noel O'Boyle wrote:
>> > > > > On 5 October 2012 18:53, Adam Tenderholt <ate...@gm...>
>> > > wrote:
>> > > > > > Copying to cclib-dev instead of cclib-users...
>> > > > > >
>> > > > > >> So, Noel, Adam... what do you think? We can't have na attribute
>> > > > > >> for
>> > > > > >> every type of population analysis parsed. I see two options:
>> > > > > >> 1) use a dictionary, with keys like 'Mulliken', 'Loewdin'
>> > > > > >> 2) use a list of tuples consisting of a string and an array of
>> > > charges
>> > > > > >
>> > > > > >
>> > > > > > I agree that it's bad form to have to deal with all permutations
>> > > > > > of
>> > > > > > attributes like mulliken_charges, loewdin_charges, etc, so it's
>> > > > > > best
>> > > to have
>> > > > > > just have charges and densities attributes.
>> > > > > >
>> > > > > > I think dictionaries are more elegant than a list of tuples. For
>> > > example,
>> > > > > > getting the Mulliken charges is simply charges["Mulliken"]
>> > > > > > instead
>> > > of having
>> > > > > > to iterate over the elements in a charges list looking for
>> > > "Mulliken" in
>> > > > > > tuple[0].
>> > > > >
>> > > > > +1
>> > > >
>> > > > I just implemented this in recent commits, for several parsers and
>> > > > Mulliken/Lowdin charges where they are printed. In some cases
>> > > > (Molpro
>> > > > and Jaguar) I could not find them and I think some flag in the input
>> > > > would need to be turned on in order to print them. I don't think I
>> > > > will
>> > > > update the data files and parsers for that unless somebody asks,
>> > > > though.
>> > > >
>> > > > The attribute is called atomcharges and I added unit tests for their
>> > > > length (should equal natom) and sum (should be zero for the unit
>> > > > tests).
>> > > >
>> > > > As far as spin densities are concerned, this is also easily done --
>> > > > should we call the corresponding attribute atomspins?
>> > >
>> > > I went ahead and implemented this for ORCA, too. If you guys think a
>> > > different attribute name will better, jsut change it. Implementing
>> > > this
>> > > for other parsers will require updating output files to have spin
>> > > densities. I might do that for GAMESS and one more sometime in the
>> > > future, but I suppose the rest will be upon request.
>> > >
>> > > - Karol
>> > >
>> > > --
>> > > written by Karol M. Langner
>> > > Sat Oct  6 20:32:38 CEST 2012
>> > >
>>
>> --
>> written by Karol M. Langner
>> Mon Oct  8 18:13:15 CEST 2012
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Thanks Björn. I'm getting back into some cclib development and have
made a note to look into this.

- Noel

On 7 January 2013 13:49, Björn Dahlgren <bd...@kt...> wrote:
> Dear all,
>
> in the latest version of cclib there is a bug in gaussianparser.py (line 772
> in svn revision 1021) for assigning vibdisps:
>
> if line[1:29] == "Atom AN      X      Y      Z":
>
> where the line in attached h2o_freq.log looks like:
>
>   Atom  AN      X      Y      Z        X      Y      Z        X      Y
> Z
>
> That is 2 spaces + 'Atom' + 2 spaces + 'AN' etc.
> This causes cclib not to assign vibdisps for this freqency job.
>
> Changing the line with the if statement into:
>
>                  if line.strip().split()[:5] == ['Atom', 'AN', 'X', 'Y',
> 'Z']:
>
> Makes it less sensitive to varying spaces.
>
> Best regards,
> Björn Dahlgren
>
> P.S. you may of course include attached log file into test-suite and make it
> public
>
> On Tue, Oct 9, 2012 at 1:59 PM, Björn Dahlgren <bd...@kt...> wrote:
>>
>> Dear all,
>>
>> I just wanted to raise the question if the following is a desired
>> behaviour:
>>
>> parsing a combined Gaussian `opt=(calcall) freq` job logfile yields
>> spurious copies of frequencies from optimization in `vibfreqs`.
>>
>> I attach a logfile to illustrate the problem. i.e. this 14 atom structure
>> have 72 vibfreqs (!) instead of 36...
>>
>> Cheers,
>> /Björn
>>
>

Hi there,

Just to remind you that it's a waste of time to commit to the old
subversion (as far as I understand). If you commit by accident, just
re-commit to the new one.

Details of the new one can be found on the project page.

- Noel