cclib-devel — Developer's mailing list

Re: [cclib-devel] pseudopotentials

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

I've moved coreelectrons from the Parsed Data page on the wiki to the
Development Parsed Data page. I created a mirror of the Parsed Data
page a while back; one for the released version (which obviously
doesn't yet contain coreelectrons) and one for the development
version. There's a link from the Development page.

Noel

Re: [cclib-devel] pseudopotentials

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

> > Can you suggest an example case that we could probably run for all
> > programs that would contain one or two heavy atoms with
> > pseudopotentials plus one/two light atoms? What's a very commonly
> > available pseudopotential?
>
> I'm going to suggest [MoOCl4]2-, which is a singlet molecule. I'm
> most familiar with the CEP and LanL2 psuedopotentials, and associated
> basis sets (CEP-121G and LanL2DZ) which I use for Mo; there's lots of
> info on the Gaussian website about this stuff. ADF has it's own set
> of basis functions. I don't know about GAMESS or Jaguar.

I've used LanL2DZ and LanL2MB...the latter is a minimal basis.

> Do we only want single point files to test?
I think so, and I don't think there's any need for the overlap matrix;
or is there? If so, it might be better to reduce the basis to a
minimal basis (e.g. LanL2MB instead of LanL2DZ).

> And do these files go in
> the basic* data subdirectories?
I think so. We are going to be running the basic unit tests on them,
e.g. testpseudo.py. And a good rule of thumb is that anything that's
unit tested goes into basic*, and everything else onto the webserver.

Noel

Re: [cclib-devel] Release of cclib 0.6b

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

There is now only a single error in regression.py, which is the
problem 1 below. Can we avoid getting a parse error in this case by
refusing to create moenergies, or by filling MOs 1-25 with moenergies
of 9999 (i.e. to indicate a problem). I think that users should be
able to get the energies of the homo and lumo even though there is a
problem with the rest of them. What do you think?

On 06/10/06, Adam Tenderholt <a-t...@st...> wrote:
> > I've just made a release of cclib 0.6b. I was going to call it
> > cclib 0.6,
> > but several regression tests fail. This is a very good way of
> > marking a bug,
> > as there's no way to forget about it once there's a failing test.
> > Once all
> > tests on the released parsers pass, another release will follow.
>
> The two parser errors are in ADF files. The problems are as follows:
>
> 1) dvb_sp_c.adfout: moenergies isn't created because it is missing
> information for MOs 1-25. I'm not sure why this is the case because
> the only difference between its input file and that of dvb_sp.adfout
> is the additional "symmetry NOSYM" keyword.
>
> 2) mo_sp.adfout: during my symmetry > c1 changes, this apparently
> broke due to the "symlist" dictionary needed for sorting
> mocoefficents based on energy instead of symmetry. Just as E and T
> symmetry labels are looped through a few times, P, D, and F labels
> should also be looped through. This won't be a trivial fix because
> instead of setting up the symlist dictionary with E:1, E:2, etc.
> based on the number of times through the loop, smarter things will
> have to be added like P:x, P:y, D:z2, etc.
>
> I don't think we should worry too much about problem #1 as there
> isn't enough info for us to parse in this case. However, we should
> probably identify an ADF keyword that fixes the problem and add it to
> the wiki. Problem #2 should be fixed, although I'm not sure of the
> best way. I can think of two ways...
>
> A) Add P, D, and F to the multiple dictionary when MO info is being
> parsed. Also create a function that correctly translates P:x, P:y,
> D:xy, D:z2, etc. to something that matches the P:1, P:2, etc. which
> will be in the symlist dictionary when mocoeffs are parsed.
>
> B) When MO info is being parsed, check for cases of P, D, and F and
> correctly create symlist dictionary keys P:x, P:y, D:z2, etc. No
> changes necessary for the part when mocoeffs are parsed.
>
> While B is more "right" based on the actual names, I think
> implementing it will require more convoluted code than option A
> because of the checked needed to change P into P:x, P:y, P:z
> dictionary keys.
>
> What do you think?
>
> Adam
>
>
> -------------------------------------------------------------------------
> 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] pseudopotentials

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

> There's no immediately obvious name that's quite short but still  
> makes sense. I considered valelectrons (i.e. valence electrons) but  
> that is probably just confusing as they are not just the valence  
> electrons. Coreelectrons seems better than pseudopotential in terms  
> of simplicity and less confusion. As well as this, we may, at a  
> future date, actually extract the form of the pseudopotential from  
> the file for calculating the electron density and it would be nice  
> to keep the pseudopotentials attribute free for that great day.

coreelectrons it is! It will be the number of electrons in the frozen  
core, ie. atomic number minus core electrons equals the number of  
electrons actually used for that atom.

> Can you suggest an example case that we could probably run for all  
> programs that would contain one or two heavy atoms with  
> pseudopotentials plus one/two light atoms? What's a very commonly  
> available pseudopotential?

I'm going to suggest [MoOCl4]2-, which is a singlet molecule. I'm  
most familiar with the CEP and LanL2 psuedopotentials, and associated  
basis sets (CEP-121G and LanL2DZ) which I use for Mo; there's lots of  
info on the Gaussian website about this stuff. ADF has it's own set  
of basis functions. I don't know about GAMESS or Jaguar.

Do we only want single point files to test? And do these files go in  
the basic* data subdirectories?

Adam

Re: [cclib-devel] pseudopotentials

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

There's no immediately obvious name that's quite short but still makes
sense. I considered valelectrons (i.e. valence electrons) but that is
probably just confusing as they are not just the valence electrons.
Coreelectrons seems better than pseudopotential in terms of simplicity and
less confusion. As well as this, we may, at a future date, actually extract
the form of the pseudopotential from the file for calculating the electron
density and it would be nice to keep the pseudopotentials attribute free for
that great day.

Can you suggest an example case that we could probably run for all programs
that would contain one or two heavy atoms with pseudopotentials plus one/two
light atoms? What's a very commonly available pseudopotential?

On 10/10/06, Adam Tenderholt <a-t...@st...> wrote:
>
> Right now, psuedopotential information isn't parsed by cclib. I can
> see this info being useful if things like mulliken charges were to be
> accurately implemented because we can't rely simply on the atomic
> number to get the number of electrons---if I'm not mistaken, there
> are no all-electron basis functions for second- and third- row
> transition metals in Gaussian.
>
> I propose we add an attribute, say coreelectrons or pseudopotentials,
> which is a list that contains the number of electrons in the frozen
> core which uses the same ordering as atomnos.
>
> Comments? Suggestions?
>
> Adam
>
>
> -------------------------------------------------------------------------
> 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] Gaussian: standard versus input orientation

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

Added a fix so that input orientation is used if standard orientation  
isn't found. Info's in the svn log. Also, updated regression.py so  
that it checks for the right dimensions of atomcoords.

Adam

[cclib-devel] pseudopotentials

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

Right now, psuedopotential information isn't parsed by cclib. I can  
see this info being useful if things like mulliken charges were to be  
accurately implemented because we can't rely simply on the atomic  
number to get the number of electrons---if I'm not mistaken, there  
are no all-electron basis functions for second- and third- row  
transition metals in Gaussian.

I propose we add an attribute, say coreelectrons or pseudopotentials,  
which is a list that contains the number of electrons in the frozen  
core which uses the same ordering as atomnos.

Comments? Suggestions?

Adam

Re: [cclib-devel] Release of cclib 0.6b

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

> 2) I would tend to go for the more 'right' solution, which you say  
> is B. This seems also to be the simpler solution (in terms of  
> logic, not necessarily implementation). However, since you are  
> likely to be doing the implementation you may want to reconsider.  
> In either case, since as you say the fix is a bit convoluted, it's  
> probably best to create a function where you pass in a label, and  
> it returns something or other. This will also make it easier to  
> doctest (see normalisesym()). To run the doctests, you just need to  
> run "python adfparser.py".

Done. Well mostly. When creating the symlist dictionary, it checks if  
it can be degenerate. If so, passes the label and repeat number to  
normalisedegenerates(). If label is P or D, look up in dictionary  
{'P': {0:"P:x", 1:"P:y",...}, 'D': {0:"D:z2", 1:"D:x2-y2"...}}.  
Otherwise, return label + number. The doctest string may need work  
because I just altered what I found easy, and deleted the rest. ;o)

This means that regression.py now has only one error, which we  
decided was ok because it prints an acceptable error message. Should  
we consider removing it from the regression because of this?

I'm not sure what the one failure in the gaussian parser is due to,  
but I'll look into it in the coming days.

> P.S. The gmail/SF issue appears to be resolved.

Glad to hear.

Adam

Re: [cclib-devel] Release of cclib 0.6b

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

I've had a quick look at this...

1) as you say, there's nothing to do here really...a warning message is
fine.
2) I would tend to go for the more 'right' solution, which you say is B.
This seems also to be the simpler solution (in terms of logic, not
necessarily implementation). However, since you are likely to be doing the
implementation you may want to reconsider. In either case, since as you say
the fix is a bit convoluted, it's probably best to create a function where
you pass in a label, and it returns something or other. This will also make
it easier to doctest (see normalisesym()). To run the doctests, you just
need to run "python adfparser.py".

P.S. The gmail/SF issue appears to be resolved.

Noel

On 06/10/06, Adam Tenderholt <a-t...@st...> wrote:
>
> > I've just made a release of cclib 0.6b. I was going to call it
> > cclib 0.6,
> > but several regression tests fail. This is a very good way of
> > marking a bug,
> > as there's no way to forget about it once there's a failing test.
> > Once all
> > tests on the released parsers pass, another release will follow.
>
> The two parser errors are in ADF files. The problems are as follows:
>
> 1) dvb_sp_c.adfout: moenergies isn't created because it is missing
> information for MOs 1-25. I'm not sure why this is the case because
> the only difference between its input file and that of dvb_sp.adfout
> is the additional "symmetry NOSYM" keyword.
>
> 2) mo_sp.adfout: during my symmetry > c1 changes, this apparently
> broke due to the "symlist" dictionary needed for sorting
> mocoefficents based on energy instead of symmetry. Just as E and T
> symmetry labels are looped through a few times, P, D, and F labels
> should also be looped through. This won't be a trivial fix because
> instead of setting up the symlist dictionary with E:1, E:2, etc.
> based on the number of times through the loop, smarter things will
> have to be added like P:x, P:y, D:z2, etc.
>
> I don't think we should worry too much about problem #1 as there
> isn't enough info for us to parse in this case. However, we should
> probably identify an ADF keyword that fixes the problem and add it to
> the wiki. Problem #2 should be fixed, although I'm not sure of the
> best way. I can think of two ways...
>
> A) Add P, D, and F to the multiple dictionary when MO info is being
> parsed. Also create a function that correctly translates P:x, P:y,
> D:xy, D:z2, etc. to something that matches the P:1, P:2, etc. which
> will be in the symlist dictionary when mocoeffs are parsed.
>
> B) When MO info is being parsed, check for cases of P, D, and F and
> correctly create symlist dictionary keys P:x, P:y, D:z2, etc. No
> changes necessary for the part when mocoeffs are parsed.
>
> While B is more "right" based on the actual names, I think
> implementing it will require more convoluted code than option A
> because of the checked needed to change P into P:x, P:y, P:z
> dictionary keys.
>
> What do you think?
>
> Adam
>
>
> -------------------------------------------------------------------------
> 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] Release of cclib 0.6b

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

> I've just made a release of cclib 0.6b. I was going to call it  
> cclib 0.6,
> but several regression tests fail. This is a very good way of  
> marking a bug,
> as there's no way to forget about it once there's a failing test.  
> Once all
> tests on the released parsers pass, another release will follow.

The two parser errors are in ADF files. The problems are as follows:

1) dvb_sp_c.adfout: moenergies isn't created because it is missing  
information for MOs 1-25. I'm not sure why this is the case because  
the only difference between its input file and that of dvb_sp.adfout  
is the additional "symmetry NOSYM" keyword.

2) mo_sp.adfout: during my symmetry > c1 changes, this apparently  
broke due to the "symlist" dictionary needed for sorting  
mocoefficents based on energy instead of symmetry. Just as E and T  
symmetry labels are looped through a few times, P, D, and F labels  
should also be looped through. This won't be a trivial fix because  
instead of setting up the symlist dictionary with E:1, E:2, etc.  
based on the number of times through the loop, smarter things will  
have to be added like P:x, P:y, D:z2, etc.

I don't think we should worry too much about problem #1 as there  
isn't enough info for us to parse in this case. However, we should  
probably identify an ADF keyword that fixes the problem and add it to  
the wiki. Problem #2 should be fixed, although I'm not sure of the  
best way. I can think of two ways...

A) Add P, D, and F to the multiple dictionary when MO info is being  
parsed. Also create a function that correctly translates P:x, P:y,  
D:xy, D:z2, etc. to something that matches the P:1, P:2, etc. which  
will be in the symlist dictionary when mocoeffs are parsed.

B) When MO info is being parsed, check for cases of P, D, and F and  
correctly create symlist dictionary keys P:x, P:y, D:z2, etc. No  
changes necessary for the part when mocoeffs are parsed.

While B is more "right" based on the actual names, I think  
implementing it will require more convoluted code than option A  
because of the checked needed to change P into P:x, P:y, P:z  
dictionary keys.

What do you think?

Adam

Re: [cclib-devel] Recent svn commit (missing email from 29Sep)

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

Haha, perhaps. I can't really imagine any malicious output file being  
able to exploit some hole and gain root privileges on a machine though.

On Oct 5, 2006, at 7:42 AM, Noel O'Boyle wrote:

> Should we be worried about carefully-crafted malicious output  
> files. :-)
>
> On 02/10/06, Adam Tenderholt <a-t...@st... > wrote:Ah,  
> crap. I tried out testall.py, but forgot to even think about
> regression.py . It looks like "Gaussian, Inc." might be a good pattern
> to match on because it appears in every file in the Gaussian data
> directory during the first 10 lines. What do you think?
>
> My main concern is we should avoid looking for single words like
> "Gaussian", "ADF", "Jaguar", etc in case those appear in the comment
> or title sections.
>
> Adam
>
> On Oct 2, 2006, at 1:36 PM, Noel O'Boyle wrote:
>
> > Sorry Adam, I've rolled back r351 (the fix for ccopen for Mo5Obdt2-
> > sp.adfout)
> > as it prevent multiple Gaussian files from being recognised,
> > according to
> > regression.py. We may need to do something more sophisticated like
> > searching
> > for one thing and then another, and only the two together mean a
> > particular
> > file type??
> >
> > Noel
> >
> >
> >
> >  
> ----------------------------------------------------------------------
> > ---
> > 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
>
>
> ---------------------------------------------------------------------- 
> ---
> 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
>
> ---------------------------------------------------------------------- 
> ---
> 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] jaguar files

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

I also don't have direct access to Jaguar, but one of my labmates  
should be able to run a few jobs if I pressure her. I believe she's  
running Jaguar 6.0 though.

Adam

On Oct 5, 2006, at 7:39 AM, Noel O'Boyle wrote:

> Regarding Jaguar mocoeffs, you're right of course, there are no  
> mocoeffs in the output file. I think this is a modification of an  
> input file that a colleague prepared...I see that the mocoeffs are  
> actually in the input file!
>
> I think I should be firm with myself and say that my direct Jaguar  
> access is over. I hope you will be able to run some jobs.  
> Otherwise, I can ask a colleague to run them.
>
> Regards,
>    Noel
>
> On 28/09/06, Adam Tenderholt <a-t...@st...> wrote: >  
> Am currently at conference (just presented cclib), so will just
> > give a brief answer. No mocoeffs! Yikes! Are you sure? I'm pretty
> > sure I tried to get the mocoeffs printed out.
>
> I'm pretty sure there aren't mocoeffs. If there are, it's not labeled
> the same was as jaguar files I have.
>
> How'd the poster on cclib go over?
>
> > Do I still have access to Jaguar?? Hmmm...not officially; will
> > probably need to co-opt someone to help. Otherwise, I can certainyl
> > create the appropriate input file as the manual is on the web. Can
> > you wait until next week when I'll have a chance to look at what we
> > have?
>
> It can wait until next week, and I still do have (indirect) access to
> Jaguar 6.0.
>
> Adam
>
>
> ---------------------------------------------------------------------- 
> ---
> 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] cclib 0.5 presented at CompLife 06

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

Nice talk. So we're going to implement CDA and AIM at some point?!?  
How exciting! I've actually started looking at implementing Lowdin  
population analysis since it looks like it's basically a few matrix  
multiplications, inversions, and some addition...although I don't  
completely understand the advantages it has over Mulliken.

Adam

On Oct 5, 2006, at 8:57 AM, Noel O'Boyle wrote:

> I recently presented cclib 0.5 at CompLife '06 at the Uni of  
> Cambridge, U.K. (where I am based). For some nice pictures along  
> with a brief discussion, please see http://cclib.sourceforge.net/ 
> wiki/index.php/Complife06. (I will put a link to this from the main  
> cclib page eventually)
>
> Regards,
>     Noel
> ---------------------------------------------------------------------- 
> ---
> 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

[cclib-devel] cclib 0.5 presented at CompLife 06

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

I recently presented cclib 0.5 at CompLife '06 at the Uni of Cambridge, U.K.
(where I am based). For some nice pictures along with a brief discussion,
please see http://cclib.sourceforge.net/wiki/index.php/Complife06. (I will
put a link to this from the main cclib page eventually)

Regards,
    Noel

Re: [cclib-devel] Recent svn commit (missing email from 29Sep)

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

Should we be worried about carefully-crafted malicious output files. :-)

On 02/10/06, Adam Tenderholt <a-t...@st...> wrote:
>
> Ah, crap. I tried out testall.py, but forgot to even think about
> regression.py. It looks like "Gaussian, Inc." might be a good pattern
> to match on because it appears in every file in the Gaussian data
> directory during the first 10 lines. What do you think?
>
> My main concern is we should avoid looking for single words like
> "Gaussian", "ADF", "Jaguar", etc in case those appear in the comment
> or title sections.
>
> Adam
>
> On Oct 2, 2006, at 1:36 PM, Noel O'Boyle wrote:
>
> > Sorry Adam, I've rolled back r351 (the fix for ccopen for Mo5Obdt2-
> > sp.adfout)
> > as it prevent multiple Gaussian files from being recognised,
> > according to
> > regression.py. We may need to do something more sophisticated like
> > searching
> > for one thing and then another, and only the two together mean a
> > particular
> > file type??
> >
> > Noel
> >
> >
> >
> > ----------------------------------------------------------------------
> > ---
> > 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
>
>
> -------------------------------------------------------------------------
> 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] jaguar files

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

Regarding Jaguar mocoeffs, you're right of course, there are no mocoeffs in
the output file. I think this is a modification of an input file that a
colleague prepared...I see that the mocoeffs are actually in the input file!

I think I should be firm with myself and say that my direct Jaguar access is
over. I hope you will be able to run some jobs. Otherwise, I can ask a
colleague to run them.

Regards,
   Noel

On 28/09/06, Adam Tenderholt <a-t...@st...> wrote:
>
> > Am currently at conference (just presented cclib), so will just
> > give a brief answer. No mocoeffs! Yikes! Are you sure? I'm pretty
> > sure I tried to get the mocoeffs printed out.
>
> I'm pretty sure there aren't mocoeffs. If there are, it's not labeled
> the same was as jaguar files I have.
>
> How'd the poster on cclib go over?
>
> > Do I still have access to Jaguar?? Hmmm...not officially; will
> > probably need to co-opt someone to help. Otherwise, I can certainyl
> > create the appropriate input file as the manual is on the web. Can
> > you wait until next week when I'll have a chance to look at what we
> > have?
>
> It can wait until next week, and I still do have (indirect) access to
> Jaguar 6.0.
>
> Adam
>
>

Re: [cclib-devel] OpenBabel bridge

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

pyopenbabel.py depends on openbabel.py. So it either depends on both, or
just on the latter. However, since apparently pyopenbabel.py has not been
released, it should just depend on openbabel.py. It's on my things to do...


On 04/10/06, Adam Tenderholt <a-t...@st...> wrote:
>
> I'm just curiuos, but does the openbabel bridge method really depend
> on both OpenBabel python bindings (openbabel and pyopenbabel)? I'm
> not all that familiar with either bindings, but it seems to me like
> one of them ought to be sufficient.
>
> Adam
>
>
> -------------------------------------------------------------------------
> 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
>

[cclib-devel] ANN: cclib 0.6 beta released

[Noel O'B. <noe...@ma...>]

cclib 0.6b is now available for download from http://cclib.sf.net.

cclib is an open source library, written in Python, for parsing and inter=
preting
the results of computational chemistry packages. It currently parses outp=
ut
files from ADF, GAMESS (US), GAMESS-UK, Gaussian, and PC GAMESS.

The main changes are:
    * addition of a GAMESS-UK parser
    * Overlap Population analysis now much faster
    * renamed guesstype to ccopen
    * Several bug fixes for the ADF and Gaussian parsers
For more details, see http://cclib.sf.net/wiki/index.php/Changelog

Among other data, cclib extracts:

    * coordinates
    * atomic orbital information
    * molecular orbital information
    * information on vibrational modes
    * the results of a TD-DFT calculation 

(For a complete list see http://cclib.sf.net/wiki/index.php/Parsed_Data).=


cclib also provides some calculation methods for interpreting some electr=
onic
properties of molecules using analyses such as:

    * Mulliken population analysis
    * Overlap population analysis
    * Calculation of Mayer's bond orders. 

For information on how to use cclib, see
      http://cclib.sf.net/wiki/index.php/Using_cclib.

If you need help, find a bug, want new features or have any questions, pl=
ease
send an email to our mailing list:
	https://lists.sourceforge.net/lists/listinfo/cclib-users

Regards,

 The cclib development team

[cclib-devel] Release of cclib 0.6b

[Noel O'B. <noe...@ma...>]

Dear all

I've just made a release of cclib 0.6b. I was going to call it cclib 0.6,=

but several regression tests fail. This is a very good way of marking a b=
ug,
as there's no way to forget about it once there's a failing test. Once al=
l
tests on the released parsers pass, another release will follow.

Regards,
   Noel

[cclib-devel] OpenBabel bridge

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

I'm just curiuos, but does the openbabel bridge method really depend  
on both OpenBabel python bindings (openbabel and pyopenbabel)? I'm  
not all that familiar with either bindings, but it seems to me like  
one of them ought to be sufficient.

Adam

Re: [cclib-devel] adf and symmetry > C1

[Noel O'B. <noe...@ma...>]

>-- Original Message --
>From: Adam Tenderholt <a-t...@st...>
>Subject: Re: [cclib-devel]  adf and symmetry > C1
>Date: Mon, 2 Oct 2006 15:57:21 -0700
>To: "Noel O'Boyle" <noe...@ma...>
>
>
>> I also had some problems with ADF files with E symmetries (which  
>> involved
>> a bug fix or two back in August). It might be good to see whether  
>> the parser
>> also handles correctly the mocoeffs in ADF/ADF2005.01/Os3(CO)12- 
>> D3h.out.
>
>As far as I can tell, the Os3(CO)12-D3h.out file works. I looked a  
>couple of the mocoeffs and ran an MPA using PyMOlyze with Os z2, Os  
>rest, C, and O fragments. The mocoeffs numbers matched, although it's  
>not easy to check if they occur at exactly the correct spot due to  
>the symmetry grouping of the aonames. The MPA matched for the MOs  
>around the homo-lumo gap within a small error, which I've always  
>assumed is due to ADF not printing contributions less than 1%.
>
>If anyone wants to look in more depth than I have, be my guest....

Sounds like you've done a comprehensive job.

>And as this is a huge improvement over the previous ADF code, I think  
>it should make it into the 0.6 release.

Since it's dragged on a bit, let's now say that everything will be includ=
ed,
except obviously new features.

>Adam
>

Re: [cclib-devel] adf and symmetry > C1

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

> I also had some problems with ADF files with E symmetries (which  
> involved
> a bug fix or two back in August). It might be good to see whether  
> the parser
> also handles correctly the mocoeffs in ADF/ADF2005.01/Os3(CO)12- 
> D3h.out.

As far as I can tell, the Os3(CO)12-D3h.out file works. I looked a  
couple of the mocoeffs and ran an MPA using PyMOlyze with Os z2, Os  
rest, C, and O fragments. The mocoeffs numbers matched, although it's  
not easy to check if they occur at exactly the correct spot due to  
the symmetry grouping of the aonames. The MPA matched for the MOs  
around the homo-lumo gap within a small error, which I've always  
assumed is due to ADF not printing contributions less than 1%.

If anyone wants to look in more depth than I have, be my guest....

And as this is a huge improvement over the previous ADF code, I think  
it should make it into the 0.6 release.

Adam

Re: [cclib-devel] Recent svn commit (missing email from 29Sep)

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

Ah, crap. I tried out testall.py, but forgot to even think about  
regression.py. It looks like "Gaussian, Inc." might be a good pattern  
to match on because it appears in every file in the Gaussian data  
directory during the first 10 lines. What do you think?

My main concern is we should avoid looking for single words like  
"Gaussian", "ADF", "Jaguar", etc in case those appear in the comment  
or title sections.

Adam

On Oct 2, 2006, at 1:36 PM, Noel O'Boyle wrote:

> Sorry Adam, I've rolled back r351 (the fix for ccopen for Mo5Obdt2- 
> sp.adfout)
> as it prevent multiple Gaussian files from being recognised,  
> according to
> regression.py. We may need to do something more sophisticated like  
> searching
> for one thing and then another, and only the two together mean a  
> particular
> file type??
>
> Noel
>
>
>
> ---------------------------------------------------------------------- 
> ---
> 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

[cclib-devel] adf and symmetry > C1

[Noel O'B. <noe...@ma...>]

I also had some problems with ADF files with E symmetries (which involved=

a bug fix or two back in August). It might be good to see whether the par=
ser
also handles correctly the mocoeffs in ADF/ADF2005.01/Os3(CO)12-D3h.out.

Noel

[cclib-devel] Recent svn commit (missing email from 29Sep)

[Noel O'B. <noe...@ma...>]

Sorry Adam, I've rolled back r351 (the fix for ccopen for Mo5Obdt2-sp.adf=
out)
as it prevent multiple Gaussian files from being recognised, according to=

regression.py. We may need to do something more sophisticated like search=
ing
for one thing and then another, and only the two together mean a particul=
ar
file type??

Noel