cclib-devel — Developer's mailing list

Re: [cclib-devel] ADF failures (was Re: cclib 0.8 lock down)

[Adam T. <a-t...@st...>]

I've made a couple of changes to fix the Frags_NiCO4 errors

>> We can try to fix the first issue by looking for "Create" or "create"
>> in the next couple of lines after an INPUT FILE statement.
>
> Sounds fine.

If there is a blank line after an INPUT FILE statement, it looks at  
the following line. It now checks for "create" in addition to "Create".

>> I think the second issue should be addressed either by trying to
>> catch the KeyError or looking for multiple jobs. Either way, we need
>> to warn the user about the "problem" with their file. Comments?
>
> I don't think we should try to handle multiple jobs. All of our
> scripts assume one job per file, and it's quite easy for the user to
> ensure that the input is like this. I say log an error, and return
> None.

When "INPUT FILE" is found, it checks for scftargets as I figure all  
calculations, finished or not, should have scftargets set. If so, it  
logs a warning and skips to the end of the file. Sound reasonable?

Adam

Re: [cclib-devel] ADF output error again

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

This is the thread about Au2.out that died out in March of this year.
Karol seemed to have the last word, but I'm not sure what he is
referring to. The parsing error is:

  File "c:\program files\python25\lib\site-packages\cclib-0.7-py2.5.egg\cclib\pa
rser\adfparser.py", line 702, in extract
    self.mocoeffs[spin][moindices[i],aoindex] = coeffs[i]
IndexError: index (108) out of range (0<=index<108) in dimension 1

Noel

On 28/03/07, Karol Langner <kar...@kn...> wrote:
> On Wednesday 28 of March 2007 02:51, Adam Tenderholt wrote:
> > I've uploaded a new Au2 logfile to the website, but I couldn't put it
> > in the ADF2006.01 directory because I didn't have permissions (Noel,
> > can you take care of this and regressionfiles.txt). I removed the
> > keyword that prints the CF moceoffs and it now finishes correctly. A
> > Mulliken analysis using PyMOlyze gives approximately the same LUMO
> > composition as is printed in the logfile (there are always slight
> > differences since ADF doesn't print every contribution), so
> > everything should be ok.
>
> So the question is how we should handle the core functions - just skip them?
>
> --
> written by Karol Langner
> Wed Mar 28 11:12:09 CEST 2007
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] ADF failures (was Re: cclib 0.8 lock down)

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

Sorry for not replying on this earlier...I was just trying to get an overview.

On 29/08/07, Adam Tenderholt <a-t...@st...> wrote:
> >> 4) Does anyone know how to deal with the current 2 failures in the
> >> ADF tests?
> > We need to decide whether these are actually impossible to fix based
> > on the log file.
>
> I've looked at the Frags_NiCO4_orig file a bit tonight and noticed
> two things.
>
> First, our parser doesn't correctly detect the create run for the Ni
> atom because it is not formatted like we expect. Our parser looks for
> "INPUT FILE" >= 0 and then the next line starting with "Create". The
> regression file has a blank line after the INPUT FILE. This causes
> the parser to parse the O Create job, and thus, creates mosyms and
> symlist (I think), which screws up parsing mocoeffs in the main job.
> I'm not sure if this is related to ADF2006.01 (btw, ADF2007 was just
> released), the Ni create job, or both.
>
> Second, there are actually two calculations in this file: a CO
> fragment and the Ni(CO)4 molecule. I think it can get symmetry labels
> from the CO fragment and then tries to apply them to the Ni(CO)4
> molecule when its mocoeffs are parsed. If all the cruft is deleted
> from this file so that just the calculation for the Ni(CO)4 molecule
> is left, it parses (although I haven't checked whether any of it is
> correct).
>
> We can try to fix the first issue by looking for "Create" or "create"
> in the next couple of lines after an INPUT FILE statement.

Sounds fine.

> I think the second issue should be addressed either by trying to
> catch the KeyError or looking for multiple jobs. Either way, we need
> to warn the user about the "problem" with their file. Comments?

I don't think we should try to handle multiple jobs. All of our
scripts assume one job per file, and it's quite easy for the user to
ensure that the input is like this. I say log an error, and return
None.

> Adam
>
> P.S. I haven't looked at the Au2 file yet, but I vaguely remember
> Karol proposing a fix...

I'll dig up the date of the email...

>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] What remains to be done

[Adam T. <a-t...@st...>]

> There are two ADF failures: now is the time to decide whether we can
> handle these. In the next version of cclib, we seriously need to
> consider parsing the 'checkpoint' files or whatever they're called,
> instead. This should be a lot less work.

I sent a mail (titled ADF failures, August 28th) to the list about  
one of these failures. Basically there are two "problems" with the  
logfile. First, it has an incorrectly formatted create job. Second,  
it actually has two single point calculations in the file. Please  
look back at the email and reply with your comments.

Adam

Re: [cclib-devel] PyVib2

[Karol L. <kar...@kn...>]

Dear Max,

  It has been some time since PyVib was discussed on the cclib list, but I 
stumbled onto this today:
http://www3.interscience.wiley.com/cgi-bin/abstract/114279037/ABSTRACT

 What is the relation between PyVib and PyVib2? Is Mohamed Zerara in the same 
research group as you?

Cheers,
Karol

On Saturday 24 February 2007 18:30, Maxim Fedorovsky wrote:
>        Dear developers of cclib,
>
>     I have started a Python project, called PyVib2
> http://pyvib2.sourceforge.net/ , which probably could be interesting for
> you.
>
>
>     With best regards,
>     Maxim Fedorovsky.

-- 
written by Karol Langner
Mon Sep  3 10:45:25 EDT 2007

Re: [cclib-devel] PyVib2

[Maxim F. <Max...@un...>]

       Dear Karol,

    Mohamed Zerara was a postdoc in our working group. At the time being 
he does work with us anymore. He has written pyVib and I supposed to 
extend it with new developments. But as I started, it became evident 
that it is much more easier to make an own program with an own 
infrastructure to do the job. So PyVib2 came into world.

    A significant difference between pyVib and PyVib2 is the following : 
the former does not have anything new from the scientific point of view, 
since it implements the existing things already done in a Matlab program 
called VOAVIEW of Gerard Zuber and Jacques Haesler. VOAVIEW was done 
already before I and Zerara entered the working group of Prof. Hug. In 
its turn, PyVib2 provides the possibility to compare force fields via 
their normal modes, which is a new development. Furthermore, in a next 
version, a new (currently top-secret) technique for VROA will become 
available -) I hope I clarified the question ;)


    With best regards,
    Maxim Fedorovsky.
> Dear Max,
>
>   It has been some time since PyVib was discussed on the cclib list, but I 
> stumbled onto this today:
> http://www3.interscience.wiley.com/cgi-bin/abstract/114279037/ABSTRACT
>
>  What is the relation between PyVib and PyVib2? Is Mohamed Zerara in the same 
> research group as you?
>
> Cheers,
> Karol
>
> On Saturday 24 February 2007 18:30, Maxim Fedorovsky wrote:
>   
>>        Dear developers of cclib,
>>
>>     I have started a Python project, called PyVib2
>> http://pyvib2.sourceforge.net/ , which probably could be interesting for
>> you.
>>
>>
>>     With best regards,
>>     Maxim Fedorovsky.
>>     
>
>   

Re: [cclib-devel] What remains to be done

[Karol L. <kar...@kn...>]

On Monday 03 September 2007 02:56, Noel O'Boyle wrote:
> There's a Molpro regression failure for C_bigbasis_cart or something.
I moved that from the data directory, becuase it was duplicating C_bigbasis, 
and it is not a correct calculation (augmented basis set in cartesian 
representation) which is why it has bogus output (stars in the mocoeffs 
because the cofficients are too large).

I added an excpetion for this in the Molpro parser, which calls logger.error() 
with a message so that the parser doesn't crash. Now I see this gives alot of 
output when running the regressions, becuase the loglevel is set to ERROR. 
Should the loglevel be set lower, or should I issue a warning instead of an 
error to the logger in this case?

Karol

-- 
written by Karol Langner
Mon Sep  3 11:31:38 EDT 2007

Re: [cclib-devel] What remains to be done

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

I understand error to mean an error in cclib. "Not a correct
calculation" sounds like a problem with the log file, and should be a
warning.

On 03/09/07, Karol Langner <kar...@kn...> wrote:
> On Monday 03 September 2007 02:56, Noel O'Boyle wrote:
> > There's a Molpro regression failure for C_bigbasis_cart or something.
> I moved that from the data directory, becuase it was duplicating C_bigbasis,
> and it is not a correct calculation (augmented basis set in cartesian
> representation) which is why it has bogus output (stars in the mocoeffs
> because the cofficients are too large).
>
> I added an excpetion for this in the Molpro parser, which calls logger.error()
> with a message so that the parser doesn't crash. Now I see this gives alot of
> output when running the regressions, becuase the loglevel is set to ERROR.
> Should the loglevel be set lower, or should I issue a warning instead of an
> error to the logger in this case?
>
> Karol
>
> --
> written by Karol Langner
> Mon Sep  3 11:31:38 EDT 2007
>

[cclib-devel] What remains to be done

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

Hello all,

We need to resolve the remaining regression and test failures.

Molpro cannot currently handle symmetrical molecules. So we need a
pass on the test failures. For the next version of cclib, we should
try to make it handle these molecules if possible.

There's a Gaussian failure with IOP(7/33)=1 (or something like this).
I think that Karol uploaded this. The input file isn't provided, but
could you redo this with IOP(3/33=1, 3/36=-1) and POP=FULL? I want to
sort out once and for all whether it is possible for us to handle
this, or at least not to crash.

There are two ADF failures: now is the time to decide whether we can
handle these. In the next version of cclib, we seriously need to
consider parsing the 'checkpoint' files or whatever they're called,
instead. This should be a lot less work.

There's a Molpro regression failure for C_bigbasis_cart or something.
Can Molpro do TD-DFT? If so, please upload a test file.

And that's it, I think. The methods and bridges are working fine. I
thought about adding a new feature to ccget for converting to json
format, but we are past the point for new features for cclib 0.8.

Noel

[cclib-devel] [ cclib-Bugs-1756064 ] Gaussian parse error for #T

[SourceForge.net <no...@so...>]

Bugs item #1756064, was opened at 2007-07-18 13:18
Message generated for change (Settings changed) made by baoilleach
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1756064&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: Noel O\'Boyle (baoilleach)
Assigned to: Nobody/Anonymous (nobody)
Summary: Gaussian parse error for #T

Initial Comment:
Christoph Steinbeck reported that a Gaussian file broke GaussSum. It seems that #T files don't include nbasis whereas the parser code assumes that this exists.

File attached, and we have permission from Christoph to make it public domain. (This is an NMR calculation)

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

Comment By: Noel O\'Boyle (baoilleach)
Date: 2007-09-02 12:03

Message:
Logged In: YES 
user_id=850620
Originator: YES

Somehow it seems to be working now, although nobody fixed it! It's in the
regression suite already anyway.

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

Comment By: Noel O\'Boyle (baoilleach)
Date: 2007-09-02 12:03

Message:
Logged In: YES 
user_id=850620
Originator: YES

Somehow it seems to be working now, although nobody fixed it! It's in the
regression suite already anyway.

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

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

[cclib-devel] [ cclib-Bugs-1756064 ] Gaussian parse error for #T

[SourceForge.net <no...@so...>]

Bugs item #1756064, was opened at 2007-07-18 13:18
Message generated for change (Comment added) made by baoilleach
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1756064&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: Fixed
Priority: 5
Private: No
Submitted By: Noel O\'Boyle (baoilleach)
Assigned to: Nobody/Anonymous (nobody)
Summary: Gaussian parse error for #T

Initial Comment:
Christoph Steinbeck reported that a Gaussian file broke GaussSum. It seems that #T files don't include nbasis whereas the parser code assumes that this exists.

File attached, and we have permission from Christoph to make it public domain. (This is an NMR calculation)

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

>Comment By: Noel O\'Boyle (baoilleach)
Date: 2007-09-02 12:03

Message:
Logged In: YES 
user_id=850620
Originator: YES

Somehow it seems to be working now, although nobody fixed it! It's in the
regression suite already anyway.

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

Comment By: Noel O\'Boyle (baoilleach)
Date: 2007-09-02 12:03

Message:
Logged In: YES 
user_id=850620
Originator: YES

Somehow it seems to be working now, although nobody fixed it! It's in the
regression suite already anyway.

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

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

[cclib-devel] [ cclib-Bugs-1756064 ] Gaussian parse error for #T

[SourceForge.net <no...@so...>]

Bugs item #1756064, was opened at 2007-07-18 13:18
Message generated for change (Comment added) made by baoilleach
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1756064&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: Fixed
Priority: 5
Private: No
Submitted By: Noel O\'Boyle (baoilleach)
Assigned to: Nobody/Anonymous (nobody)
Summary: Gaussian parse error for #T

Initial Comment:
Christoph Steinbeck reported that a Gaussian file broke GaussSum. It seems that #T files don't include nbasis whereas the parser code assumes that this exists.

File attached, and we have permission from Christoph to make it public domain. (This is an NMR calculation)

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

>Comment By: Noel O\'Boyle (baoilleach)
Date: 2007-09-02 12:03

Message:
Logged In: YES 
user_id=850620
Originator: YES

Somehow it seems to be working now, although nobody fixed it! It's in the
regression suite already anyway.

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

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

Re: [cclib-devel] cclib 0.8 lock down

[Adam T. <a-t...@st...>]

> Don't get me wrong - I trust the ORCA code. It's just that I don't
> want to spend the time now to increase the number of attributes
> parsed. Rather I would like us to focus on getting out a release. By
> using svnmerge.py we can keep the branches up to date with the trunk,
> so that PyMOlyze, for example, loses none of the capabilities of the
> trunk. However, I feel that releasing the ORCA parser now, and
> publicising it, without more coverage of attributes would not the best
> idea.

Ok, that's fine. I agree that we can get out a new release and merge  
those changes into the ORCA branch, which I can use if necessary.

> I find myself short of time, and feel that the more we put in the
> trunk, the further away the release date will move.

I too am finding myself short on time, so I'm not likely to be  
pushing out a new version of PyMOlyze soon.

Adam

Re: [cclib-devel] cclib 0.8 lock down

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

On 29/08/2007, Adam Tenderholt <a-t...@st...> wrote:
> >> 2) Is either the ORCA or Turbomole parser going to be trunked
> >> before the
> >> release?
> > Not at this stage. I want to get the next release out as soon as
> > possible and neither of these have good coverage of the tests.
>
> What tests need to be covered for the ORCA parser? I've been using
> PyMOlyze with the ORCA trunk and haven't run into any problems yet.
> If you just want tests for determining whether arrays and lists have
> the right dimension, I can get on this right away as it *shouldn't*
> take long. If it's something more involved, then I agree it should
> wait until our next release.

Don't get me wrong - I trust the ORCA code. It's just that I don't
want to spend the time now to increase the number of attributes
parsed. Rather I would like us to focus on getting out a release. By
using svnmerge.py we can keep the branches up to date with the trunk,
so that PyMOlyze, for example, loses none of the capabilities of the
trunk. However, I feel that releasing the ORCA parser now, and
publicising it, without more coverage of attributes would not the best
idea.

I find myself short of time, and feel that the more we put in the
trunk, the further away the release date will move.

As ever, if you feel strongly now's the time to say it...

Noel

> Adam
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

[cclib-devel] [ cclib-Bugs-1784327 ] Can't handle GAMESS TD-DFT

[SourceForge.net <no...@so...>]

Bugs item #1784327, was opened at 2007-08-29 19:23
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=819222&aid=1784327&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: Noel O\'Boyle (baoilleach)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't handle GAMESS TD-DFT

Initial Comment:
Vitaliy Gorbenko contacted GaussSum. It seems that cclib can't handle GAMESS and PC GAMESS TD-DFT. I haven't verified the problem.

He provided an input and output file but I include here only the keywords for the input:

GAMESS:
 $CONTRL SCFTYP=RHF DFTTYP=B3LYP TDDFT=EXCITE $END
 $SYSTEM TIMLIM=3000 MWORDS=50 $END
 $BASIS  GBASIS=N21 ngauss=3 NDFUNC=1 $END
 $TDDFT NSTATE=10 $END
 $DAT

He also reported problems with PC GAMESS:

 $CONTRL SCFTYP=RHF CITYP=CIS COORD=CART MAXIT=1000 $END                      
 $SYSTEM TIMLIM=3000 MEMORY=10000000 $END                                       
 $BASIS  GBASIS=N21 ngauss=3 NDFUNC=1 $END                                      
 $SCF DIIS=.F. SHIFT=.T. SOSCF=.T. $END                                         
 $CIS NSTATE=80 ISTSYM=0 ISTATE=1 $END                                          
 $DAT

and also:

 $CONTRL SCFTYP=RHF DFTTYP=B3LYP CITYP=TDDFT COORD=CART MAXIT=1000 $END       
 $SYSTEM TIMLIM=3000 MEMORY=10000000 $END                                        
 $BASIS  GBASIS=STO ngauss=3 NDFUNC=1 $END                                      
 $SCF DIIS=.F. SHIFT=.T. SOSCF=.T. $END                                         
 $TDDFT NSTATE=80 ISTSYM=0 ISTATE=1 TDA=.t. $END                                
 $DAT


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

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

Re: [cclib-devel] cclib 0.8 lock down

[Adam T. <a-t...@st...>]

>> 2) Is either the ORCA or Turbomole parser going to be trunked  
>> before the
>> release?
> Not at this stage. I want to get the next release out as soon as
> possible and neither of these have good coverage of the tests.

What tests need to be covered for the ORCA parser? I've been using  
PyMOlyze with the ORCA trunk and haven't run into any problems yet.  
If you just want tests for determining whether arrays and lists have  
the right dimension, I can get on this right away as it *shouldn't*  
take long. If it's something more involved, then I agree it should  
wait until our next release.

Adam

[cclib-devel] ADF failures (was Re: cclib 0.8 lock down)

[Adam T. <a-t...@st...>]

>> 4) Does anyone know how to deal with the current 2 failures in the  
>> ADF tests?
> We need to decide whether these are actually impossible to fix based
> on the log file.

I've looked at the Frags_NiCO4_orig file a bit tonight and noticed  
two things.

First, our parser doesn't correctly detect the create run for the Ni  
atom because it is not formatted like we expect. Our parser looks for  
"INPUT FILE" >= 0 and then the next line starting with "Create". The  
regression file has a blank line after the INPUT FILE. This causes  
the parser to parse the O Create job, and thus, creates mosyms and  
symlist (I think), which screws up parsing mocoeffs in the main job.  
I'm not sure if this is related to ADF2006.01 (btw, ADF2007 was just  
released), the Ni create job, or both.

Second, there are actually two calculations in this file: a CO  
fragment and the Ni(CO)4 molecule. I think it can get symmetry labels  
from the CO fragment and then tries to apply them to the Ni(CO)4  
molecule when its mocoeffs are parsed. If all the cruft is deleted  
from this file so that just the calculation for the Ni(CO)4 molecule  
is left, it parses (although I haven't checked whether any of it is  
correct).

We can try to fix the first issue by looking for "Create" or "create"  
in the next couple of lines after an INPUT FILE statement.

I think the second issue should be addressed either by trying to  
catch the KeyError or looking for multiple jobs. Either way, we need  
to warn the user about the "problem" with their file. Comments?

Adam

P.S. I haven't looked at the Au2 file yet, but I vaguely remember  
Karol proposing a fix...

Re: [cclib-devel] cclib 0.8 lock down

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

On 28/08/07, Karol Langner <kar...@kn...> wrote:
> As far as the next release is concerned, I know Noel is getting a list
> prepared.... but here are some "issues" I haven't seen a clear answer to:
>
> 1) Is the Molpro parser staying in the trunk?
We moved it there because it was thought ready to release. Do you
still think so?

> 2) Is either the ORCA or Turbomole parser going to be trunked before the
> release?
Not at this stage. I want to get the next release out as soon as
possible and neither of these have good coverage of the tests.

> 3) Should any of the new attributes since 0.7 be excluded? charge and mult
> obviously not, but what about nocoeffs? The first unittests are there, and
> I'm planning on adding new ones.
I'm happy leaving it in. I think that this is one of the smallest
changes in the new release.

> 4) Does anyone know how to deal with the current 2 failures in the ADF tests?
We need to decide whether these are actually impossible to fix based
on the log file.

Noel

>
> --
> written by Karol Langner
> Mon Aug 27 19:46:35 EDT 2007
>

Re: [cclib-devel] cclib 0.8 lock down

[Karol L. <kar...@kn...>]

As far as the next release is concerned, I know Noel is getting a list 
prepared.... but here are some "issues" I haven't seen a clear answer to:

1) Is the Molpro parser staying in the trunk?
2) Is either the ORCA or Turbomole parser going to be trunked before the 
release?
3) Should any of the new attributes since 0.7 be excluded? charge and mult 
obviously not, but what about nocoeffs? The first unittests are there, and 
I'm planning on adding new ones.
4) Does anyone know how to deal with the current 2 failures in the ADF tests?

-- 
written by Karol Langner
Mon Aug 27 19:46:35 EDT 2007

Re: [cclib-devel] orbitals for correlated methods

[Karol L. <kar...@kn...>]

On Monday 27 August 2007 12:54, Adam Tenderholt wrote:
> > Now to the issue in cclib...
> > I acted hastily on adding the nocoeffs attribute. There are many
> > types of
> > orbital coefficients (NOs, NBOs, optimized MCSCF coefficients) and
> > I now see
> > it is better to leave only one attribute for parsing them all. My
> > incentive
> > was that sometimes both MO and NO coefficients are printed (see the
> > GAMESS-US/water_cis* tests for example) and you may need both (I
> > often do).
> > It is more natural for mocoeffs to contain both sets of
> > coefficients - so
> > that it would be a list of length 2 (or 4 for unrestricted
> > calculations).
> > Similarly, if coefficients are printed in each step of a N-step
> > geometry
> > optimization, they should also be parsed and appended in every
> > step, giving a
> > length N list (or 2*N).
>
> For the unrestricted calculation, are you proposing indices 0/1 are
> for the alpha/beta MOs, and 2/3 for the alpha/beta NOs?
Exactly - and similarly for geomatry optimizations even/odd for alpha/beta. If 
the calculation is restricted, then only alpha of course.

> Also, how do you propose determining whether a calculation is a
> 4-step restricted with just MOs or a single step unrestricted
> calculation with both MOs and NOs?
Yes, that is a bit problematic. You can check if geovalues exists, for 
example, but at present we don't parse mocoeffs each time if they are printed 
in each step anyway (we should, I guess, alhtough I don't need that). 
Ultimately, the user would need to know what kind of job was being parsed.

I just imagined a geometry optimization with both MOs and NOs printed :) so 
this idea is getting pretty complicated. Do you think the implementation with 
nocoeffs is a better idea?

-- 
written by Karol Langner
Mon Aug 27 19:00:29 EDT 2007

Re: [cclib-devel] orbitals for correlated methods

[Adam T. <a-t...@st...>]

> Now to the issue in cclib...
> I acted hastily on adding the nocoeffs attribute. There are many  
> types of
> orbital coefficients (NOs, NBOs, optimized MCSCF coefficients) and  
> I now see
> it is better to leave only one attribute for parsing them all. My  
> incentive
> was that sometimes both MO and NO coefficients are printed (see the
> GAMESS-US/water_cis* tests for example) and you may need both (I  
> often do).
> It is more natural for mocoeffs to contain both sets of  
> coefficients - so
> that it would be a list of length 2 (or 4 for unrestricted  
> calculations).
> Similarly, if coefficients are printed in each step of a N-step  
> geometry
> optimization, they should also be parsed and appended in every  
> step, giving a
> length N list (or 2*N).

For the unrestricted calculation, are you proposing indices 0/1 are  
for the alpha/beta MOs, and 2/3 for the alpha/beta NOs? Or something  
else? Also, how do you propose determining whether a calculation is a  
4-step restricted with just MOs or a single step unrestricted  
calculation with both MOs and NOs?

Adam

Re: [cclib-devel] orbitals for correlated methods

[Karol L. <kar...@kn...>]

On Wednesday 08 August 2007 11:13, Adam Tenderholt wrote:
> > I wrote about this some time ago (see the above), and some thinking
> > made me
> > confident to create a new attribute - nocoeffs. Natural orbitals are
> > mathematically totally different numbers than MO coefficients,
> > although their
> > print-out usually looks very similar. I added code for them in
> > Gaussian and
> > GAMESS for CIS and MP2 - see my commit for details.
>
> Out of curiosity, how do natural orbitals for correlated methods
> differ from those determined from DFT MOs during Weinhold's natural
> bond orders (NBO) method?

MOs, NOs (Natural Orbitals) and NBOs are all orthonormal orbital sets and 
carry the same information - you can use any of them to get properties of the 
entire molecular wavefunction. But they are quite different in how they 
describe the wavefunction. In practice, that means each orbital type is 
different when you visualize it. Also, atomic properties will be different 
since the density is distributed differently among orbitals.

Correlated NOs (Natural Orbitals) are calculated the same way as for 
Hartree-Fock wavefunctions - by diagonalizing the first order reduced density 
matrix (ex. the one-electron CI density). They are eigenorbitals of the 
density operator, and as such provide the most compact description of the 
wavefunction (maximum occupancy). They are indexed by (eigen)occupancies 
instead of (eigen)energies like "regular" MOs.

NBOs AFAIK are certain combinations of Natural Orbitals with the property of 
being localized on a few chemically relevent centers. As the NBO 
documentation states, they "give the most accurate possible Lewis-like 
description of the total N-electron density".

Now to the issue in cclib...
I acted hastily on adding the nocoeffs attribute. There are many types of 
orbital coefficients (NOs, NBOs, optimized MCSCF coefficients) and I now see 
it is better to leave only one attribute for parsing them all. My incentive 
was that sometimes both MO and NO coefficients are printed (see the 
GAMESS-US/water_cis* tests for example) and you may need both (I often do). 
It is more natural for mocoeffs to contain both sets of coefficients - so 
that it would be a list of length 2 (or 4 for unrestricted calculations). 
Similarly, if coefficients are printed in each step of a N-step geometry 
optimization, they should also be parsed and appended in every step, giving a 
length N list (or 2*N).

This solution does not disrupt the current implementation unless a method 
assumes len(mocoeffs)<2, and will limit the number of attributes in the 
future. Finally, all this refers to a pretty rare situation, since most of 
the time molecular orbitals are only printed once in the output as they take 
up alot of space. In the cases where len(mocoeffs)>2, though, it provides a 
nice loophole when using cclib with such output.

Let me know what you think.

Karol

-- 
written by Karol Langner
Mon Aug 27 17:36:45 EDT 2007

[cclib-devel] cclib reference

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

I just came across a reference to cclib (and PyMOlyze) at:
http://dx.doi.org/10.1103/PhysRevA.76.011201

Noel

Re: [cclib-devel] Morokuma EDA analysis

[Karol L. <kar...@kn...>]

I'd like to return to the threads that I didn't have time to answer to in the 
past month... this one I'm interested in especially, since my research 
involves also interaction energy calcualtions.

On Monday 30 July 2007 02:54, Noel O'Boyle wrote:
> Sure, Morokuma decomposition would be great. In fact, I was looking
> for this a couple of years ago during my PhD. I think that it's built
> into GAMESS, but not in Gaussian, so I tried to run my calculation
> with GAMESS but it failed to converge. And that was the end of that...

Yes, the Morokums decomposition scheme, and a few variants of it, are 
implemented in GAMESS.

> On 25/07/07, Karol Langner <kar...@kn...> wrote:
> > >>> Hi,
> > >>>
> > >>> Has anyone considering implementing Ziegler-Morokuma energy
> > >>> decomposition analysis into cclib? I don't know everything that is
> > >>> involved in the calculation off hand, but I don't think it would
> > >>> be an
> > >>> enormous job considering that CDA is already implemented. It's
> > >>> something
> > >>> I would consider doing, once I'm done with the turbomole binding.
> > >>>
> > >>> Chris
> > >>
> > >> I would be very interested in this, but I don't share your enthusiasm
> > >> about how easy it would be.
> > >>
> > > I must admit I've never heard of this EDA. How does it differ from
> > > CDA, and what exactly is involved? Do you have a link to a paper or
> > > website?

A good overview of the methodology is in this paper by the people from GAMESS 
and many relevant references therein:
"Energy decomposition analysis for many-body interactions,
 and application to water complexes"
W.Chen, M.S.Gordon   J.Phys.Chem. 100, 14316-14328(1996)

The thing is, for EDS you need the overlap and Fock matrices. You don't 
normally have the Fock matrix in the output of programs. You could construct 
it by yourself, then you need to calculate two-electron Coulumbic repulsion 
integrals for the system. Although PyQuante does this, it would probably be a 
bottleneck (not sure how small).

With that said, I still think it is worthwhile to try to get this implemented, 
since decompositions are used alot and don't have that many implementations. 
It would be great to be able to do them for output from a number of programs!

Cheers,
Karol

-- 
written by Karol Langner
Fri Aug 17 18:51:42 EDT 2007

Re: [cclib-devel] Dropped Numeric support & misc.

[Karol L. <kar...@kn...>]

On Tuesday 07 August 2007 11:34, Noel O'Boyle wrote:
> > On a related note - while working on the Molpro parser today I ran into
> > the situation where you have only partial data in the output to parse
> > some attribute. For example, Molpro by default prints the SCF cycle only
> > for the first/last point in a gopt, therefore scfvalues is not of the
> > expected dimensions. I know that for tests we should always have proper
> > output, but I wonder how we are to deal with this in general. I mean, we
> > don't want the user to get an attribute with dimensions he doesn't
> > understand, right? To me it seems reasonable to fill up the gaps - put
> > something in place of the lacking elements. I see two possibilities: 1)
> > always use None 2) use numpy.nan. What re your thoughts?
>
> First of all, is it possible to create the correct test file? If so,
> I'd appreciate if you could do so.

AFAIK it is not possible to get Molpro to print the SCF microiterations to the 
principal output file (*.out). Reading both that one and the *.log file gives 
the correct attribute.

> Secondly, IMO I wouldn't fill the gaps for the general case. Rather I
> would return an array of size 2 in that dimension. I won't argue this
> too much but if you fill the gap, you will probably cause a users
> program to fail (e.g. GaussSum will fail with this information),
> rather than plot something. Also there is the problem that we haven't
> taken this attitude with the other programs. I don't feel that this
> information is so important that we need to spend too much time
> getting this perfect. It's easy for user to construct a calculation
> where there are more SCF cycles than GeoOpts. For example, an IR
> calculation in some programs. cclib just extracts the SCF information
> wherever it is, and doesn't worry about the context.

OK

-- 
written by Karol Langner
Fri Aug 17 18:15:13 EDT 2007