cclib-devel Mailing List for cclib

Thank you.

On Wed, Jun 23, 2010 at 11:03 PM, Noel O'Boyle <bao...@gm...> wrote:

> Hi Marius,
>
> I fixed this in r910. The fix was simply to replace "natom" with "atomnos".
>
> - Noel
>
> On 23 June 2010 09:48, Marius Retegan <mar...@gm...> wrote:
> > Hello
> > I think there is a problem in the gaussian parser since I'm unable to get
> > the atomnos from a Gaussian 09 file.
> > Even though the atomnos are parsed from the log file, they are not
> assigned
> > to the self.atomnos due to the condition at line 187 in gaussianparser.py
> > (if not hasattr(self, "natom")).
> > Attached you will find a Gaussian 09 log file for the water molecule.
> > On a side note. would it be possible to use an internally stored
> dictionary
> > to change these atomic numbers into element symbols?
> > Thank you
> > Marius
> >
> >
> ------------------------------------------------------------------------------
> > ThinkGeek and WIRED's GeekDad team up for the Ultimate
> > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> > lucky parental unit.  See the prize list and enter to win:
> > http://p.sf.net/sfu/thinkgeek-promo
> > _______________________________________________
> > cclib-devel mailing list
> > ccl...@li...
> > https://lists.sourceforge.net/lists/listinfo/cclib-devel
> >
> >
>

Hi Marius,

I fixed this in r910. The fix was simply to replace "natom" with "atomnos".

- Noel

On 23 June 2010 09:48, Marius Retegan <mar...@gm...> wrote:
> Hello
> I think there is a problem in the gaussian parser since I'm unable to get
> the atomnos from a Gaussian 09 file.
> Even though the atomnos are parsed from the log file, they are not assigned
> to the self.atomnos due to the condition at line 187 in gaussianparser.py
> (if not hasattr(self, "natom")).
> Attached you will find a Gaussian 09 log file for the water molecule.
> On a side note. would it be possible to use an internally stored dictionary
> to change these atomic numbers into element symbols?
> Thank you
> Marius
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>
>

Hi Marius,

I'll look into this.

Regarding the second question,

... from cclib.parser.utils import PeriodicTable as pt
... help(pt)
Help on class PeriodicTable in module cclib.parser.utils:

class PeriodicTable(__builtin__.object)
 |  Allows conversion between element name and atomic no.
 |
 |  >>> t = PeriodicTable()
 |  >>> t.element[6]
 |  'C'
 |  >>> t.number['C']
 |  6
 |  >>> t.element[44]
 |  'Ru'
 |  >>> t.number['Au']
 |  79

- Noel

On 23 June 2010 09:48, Marius Retegan <mar...@gm...> wrote:
> Hello
> I think there is a problem in the gaussian parser since I'm unable to get
> the atomnos from a Gaussian 09 file.
> Even though the atomnos are parsed from the log file, they are not assigned
> to the self.atomnos due to the condition at line 187 in gaussianparser.py
> (if not hasattr(self, "natom")).
> Attached you will find a Gaussian 09 log file for the water molecule.
> On a side note. would it be possible to use an internally stored dictionary
> to change these atomic numbers into element symbols?
> Thank you
> Marius
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>
>

On 23 June 2010 20:56, Karol M. Langner <km...@mm...> wrote:
> On Wednesday 23 June 2010 21:01:29 Noel O'Boyle wrote:
>> On 19 June 2010 12:30, Karol M. Langner <km...@mm...> wrote:
>> > I've run into this before, but did not happen to run cclib on the file. I
>> > think this happens when Gaussian detects linear  dependencies in the
>> > basis set, which can happend as the geometry changes.
>>
>> That's right.
>>
>> > So, how do we deal with this? The parser shouldn't break at lease, so do
>> > we loosen the assert here and just issue a warning? Some further parts of
>> > the parser assume that nmo does not change, so it might raise other
>> > problems when nmo changes.
>>
>> I just removed the assert statement in r909. I only added it to be
>> careful. In reality, it doesn't affect anything, as the value will be
>> correct for whatever is parsed after that.
>
> Maybe issue a warning to the logger?

Well, you know, it's really our responsibility to sort it out -
passing the warning onto the user wouldn't be fair. I'm pretty happy
that this is fine. Everything is parsed in order, so the value of
nbasis available at any point will be the correct one.

> --
> written by Karol Langner
> Wed Jun 23 21:56:06 CEST 2010
>

On Wednesday 23 June 2010 21:01:29 Noel O'Boyle wrote:
> On 19 June 2010 12:30, Karol M. Langner <km...@mm...> wrote:
> > I've run into this before, but did not happen to run cclib on the file. I
> > think this happens when Gaussian detects linear  dependencies in the
> > basis set, which can happend as the geometry changes.
>
> That's right.
>
> > So, how do we deal with this? The parser shouldn't break at lease, so do
> > we loosen the assert here and just issue a warning? Some further parts of
> > the parser assume that nmo does not change, so it might raise other
> > problems when nmo changes.
>
> I just removed the assert statement in r909. I only added it to be
> careful. In reality, it doesn't affect anything, as the value will be
> correct for whatever is parsed after that.

Maybe issue a warning to the logger?

-- 
written by Karol Langner
Wed Jun 23 21:56:06 CEST 2010

On 19 June 2010 12:30, Karol M. Langner <km...@mm...> wrote:
> I've run into this before, but did not happen to run cclib on the file. I
> think this happens when Gaussian detects linear  dependencies in the basis
> set, which can happend as the geometry changes.

That's right.

> So, how do we deal with this? The parser shouldn't break at lease, so do we
> loosen the assert here and just issue a warning? Some further parts of the
> parser assume that nmo does not change, so it might raise other problems when
> nmo changes.

I just removed the assert statement in r909. I only added it to be
careful. In reality, it doesn't affect anything, as the value will be
correct for whatever is parsed after that.

> - Karol
>
> On Thursday 17 June 2010 07:24:53 SourceForge.net wrote:
>> Bugs item #3017436, was opened at 2010-06-16 22:24
>> Message generated for change (Tracker Item Submitted) made by atenderholt
>> You can respond by visiting:
>> https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3017436&group_
>>id=161285
>>
>> Please note that this message will contain a full copy of the comment
>> thread, including the initial issue submission, for this request,
>> not just the latest update.
>> Category: Parsers
>> Group: None
>> Status: Open
>> Resolution: None
>> Priority: 5
>> Private: No
>> Submitted By: Adam Tenderholt (atenderholt)
>> Assigned to: Nobody/Anonymous (nobody)
>> Summary: assert nmo == self.nmo fails
>>
>> Initial Comment:
>> Gaussian 03 log file from an optimization fails to parse correctly. NBsUse
>> changes during the optimization. I initially thought it was dropping
>> functions when converting from cartesian to spherical coordinates (d
>> orbitals), but specifying 5D didn't help.
>>
>> This is using Python 2.6.x on a Mac with cclib trunk (r908).
>
> --
> written by Karol Langner
> Sat Jun 19 13:25:50 CEST 2010
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Bugs item #3017436, was opened at 2010-06-17 06:24
Message generated for change (Comment added) made by baoilleach
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3017436&group_id=161285

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parsers
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Adam Tenderholt (atenderholt)
Assigned to: Nobody/Anonymous (nobody)
Summary: assert nmo == self.nmo fails

Initial Comment:
Gaussian 03 log file from an optimization fails to parse correctly. NBsUse changes during the optimization. I initially thought it was dropping functions when converting from cartesian to spherical coordinates (d orbitals), but specifying 5D didn't help. 

This is using Python 2.6.x on a Mac with cclib trunk (r908). 

----------------------------------------------------------------------

>Comment By: Noel O'Boyle (baoilleach)
Date: 2010-06-23 19:59

Message:
Fixed in r909.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3017436&group_id=161285

I've run into this before, but did not happen to run cclib on the file. I 
think this happens when Gaussian detects linear  dependencies in the basis 
set, which can happend as the geometry changes.

So, how do we deal with this? The parser shouldn't break at lease, so do we 
loosen the assert here and just issue a warning? Some further parts of the 
parser assume that nmo does not change, so it might raise other problems when 
nmo changes.

- Karol

On Thursday 17 June 2010 07:24:53 SourceForge.net wrote:
> Bugs item #3017436, was opened at 2010-06-16 22:24
> Message generated for change (Tracker Item Submitted) made by atenderholt
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3017436&group_
>id=161285
>
> Please note that this message will contain a full copy of the comment
> thread, including the initial issue submission, for this request,
> not just the latest update.
> Category: Parsers
> Group: None
> Status: Open
> Resolution: None
> Priority: 5
> Private: No
> Submitted By: Adam Tenderholt (atenderholt)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: assert nmo == self.nmo fails
>
> Initial Comment:
> Gaussian 03 log file from an optimization fails to parse correctly. NBsUse
> changes during the optimization. I initially thought it was dropping
> functions when converting from cartesian to spherical coordinates (d
> orbitals), but specifying 5D didn't help.
>
> This is using Python 2.6.x on a Mac with cclib trunk (r908).

-- 
written by Karol Langner
Sat Jun 19 13:25:50 CEST 2010

Bugs item #3017436, was opened at 2010-06-16 22:24
Message generated for change (Tracker Item Submitted) made by atenderholt
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3017436&group_id=161285

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parsers
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Adam Tenderholt (atenderholt)
Assigned to: Nobody/Anonymous (nobody)
Summary: assert nmo == self.nmo fails

Initial Comment:
Gaussian 03 log file from an optimization fails to parse correctly. NBsUse changes during the optimization. I initially thought it was dropping functions when converting from cartesian to spherical coordinates (d orbitals), but specifying 5D didn't help. 

This is using Python 2.6.x on a Mac with cclib trunk (r908). 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=3017436&group_id=161285