cclib-devel — Developer's mailing list

Re: [cclib-devel] Moving towards release

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

> Is there a timeframe you're shooting for with this release? It sounds
> like you want to release soon.
I think "release when ready" but it'd be nice to be ready in the near
future. If we need a date to aim for, how about the end of the month,
which is the 1st anniversary of cclib after all.

> Do we have time to add coreelectrons
> to our other supported parsers?
I think this shouldn't be a big job. Do we need some test files? I'm
going to sort out the remaining failing Jaguar tests first though.

> > (5) I've moved the test code from the end of cda.py to testcda.py.
> > There's a bug in here somewhere though, as the code fails with an
> > error (not due to me moving it). Could you look into this Adam? Once
> > sorted, I rearrange the testcda.py into a more formal unittest.
>
> I cleaned out my cclib installation, and then re-installed from trunk
> (rev. 522). I didn't get any errors from testcda.py. Can you post the
> errors you get?
Will do. Might be something weird at my end.

> Also, I need to alter the code a bit to put the
> "factor of 2" into the result matrix, instead of just having an extra
> 2 added when printing out results. I'll try to get to that sometime
> this afternoon.
Cool.

Noel

Re: [cclib-devel] Moving towards release

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

> (4) Is coreelectrons going to make it into the next release? If so,
> we're going to need some tests on it (although there's not a lot to
> test really, is there?) and the rest of the boxes checked on the wiki
> (only ADF and Gaussian, currently)

The advantage of parsing coreelectrons is the ability to "accurately"  
determine MPA and CSPA atomic charges for atoms with a frozen core.  
As I haven't altered MPA or CSPA to use this info, I don't see any  
real reason to officially include coreelectrons in this release.

Is there a timeframe you're shooting for with this release? It sounds  
like you want to release soon. Do we have time to add coreelectrons  
to our other supported parsers?

> (5) I've moved the test code from the end of cda.py to testcda.py.
> There's a bug in here somewhere though, as the code fails with an
> error (not due to me moving it). Could you look into this Adam? Once
> sorted, I rearrange the testcda.py into a more formal unittest.

I cleaned out my cclib installation, and then re-installed from trunk  
(rev. 522). I didn't get any errors from testcda.py. Can you post the  
errors you get? Also, I need to alter the code a bit to put the  
"factor of 2" into the result matrix, instead of just having an extra  
2 added when printing out results. I'll try to get to that sometime  
this afternoon.

Adam

>
> 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

Re: [cclib-devel] Moving towards release

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

On Saturday 17 of February 2007 13:20, Noel O'Boyle wrote:
> Almost ready to release...we just need to get a few tests to pass and
> polish off some attributes. Here's what I've been doing/thinking as
> well as some suggestions...

> (1) I've uploaded MP files for GAMESS-UK. All that's left is Jaguar,
> which I guess Adam will have to look into. Possibly, PC-GAMESS
> too...I'll look into that.
Thanks for the MP files for GAMESS-UK. Like I said, I'll take care of parsing 
mpenergies, but not before tommorow evening (some other urgent work). I 
already have most of it done.

> (2) I've simplified testMP (no need to overload testsizeandshape and
> testchange), and added the tests for GAMESS-UK (which currently fail).
That was my quick hack to make the docstrings different for MP2/MP3/MP4/MP5.

Cheers,
Karol

-- 
written by Karol Langner
Sat Feb 17 14:00:46 CET 2007

[cclib-devel] Moving towards release

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

Almost ready to release...we just need to get a few tests to pass and
polish off some attributes. Here's what I've been doing/thinking as
well as some suggestions...

(1) I've uploaded MP files for GAMESS-UK. All that's left is Jaguar,
which I guess Adam will have to look into. Possibly, PC-GAMESS
too...I'll look into that.

(2) I've simplified testMP (no need to overload testsizeandshape and
testchange), and added the tests for GAMESS-UK (which currently fail).

(3) I've added N/P "Not possible" and T/D "to do" to some entries in
the table in "Development Parsed Data" on the wiki. There's more to
add, but it's a start.

(4) Is coreelectrons going to make it into the next release? If so,
we're going to need some tests on it (although there's not a lot to
test really, is there?) and the rest of the boxes checked on the wiki
(only ADF and Gaussian, currently)

(5) I've moved the test code from the end of cda.py to testcda.py.
There's a bug in here somewhere though, as the code fails with an
error (not due to me moving it). Could you look into this Adam? Once
sorted, I rearrange the testcda.py into a more formal unittest.

Regards,
    Noel

Re: [cclib-devel] XML output of comp chem programs

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

Thanks for the info.

Just to be clear. It's not at all the main aim of cclib to XMLise the
output of comp chem programs - we are not even that interested in
extracting data that isn't useful for visualisation (we like
frequencies and cartesian displacement vectors) or implementing
algorithms (we like matrices).

But it would be nice, and not very difficult, to write extracted data
from cclib's internal representation to an XML file if a standard
existed for harmonic frequencies, and so on.

I'm happy to give a demo at the least excuse, although your place is
probably better than mine for that purpose...:-)

Regards,
   Noel


On 16/02/07, peter murray-rust <pm...@ca...> wrote:
> At 10:07 14/02/2007, Noel O'Boyle wrote:
> >Hello Peter,
> >
> >I was wondering do you have any names/contacts who could fill me in on
> >the current state of interoperable XML output for computational
> >chemistry packages. According to google, there have been some meetings
> >regarding this, but this is nothing concrete on the web.
>
> I have now looked at the cclib home page and think progress could be
> made fast. I have copied Toby in case he has comments.  We should
> meet informally soon and you can show me cclib
>
> P.
>
>
>
> The major efforts in this area come from:
> - eMinerals - a uk-based eScience group with some other connections.
> This includes programs such as GULP, SIESTA, CASTEP, METADISE,
> DL_POLY, and some others
> - COST D37. A Euro project at an early stage. We are starting to
> address aspects of interoperability in mainly atomic codes such as
> VAMP, DALTON, etc.
> - MOPAC, GAMESS-US. I am doing this in conjunction with the authors
> - CECAM2006 - this covers ABINIT, MOLPRO, GAMESS-UK, etc.
>
> The key approach is via libraries. Toby White has developed FoX for
> FORTRAN - I have copied him.
>
> In general a code requires a dictionary. The creation of a stub
> dictionary and CMLised code is of the order of 2-4 weeks depending on
> the level of rigour and comprehensiveness. (There are some outputs
> which never need to be marked up)
>
> >There has been some talk among the cclib developers regarding this,
> >but I'm not keen on doing it if there isn't an agreed standard. It
> >doesn't have to be a complete spec from our point of view, but just
> >enough to cover information that is commonly read into visualisation
> >programs, for example.
>
> Java programs can use JUMBO. C++ is not formally supported, nor is
> Python. It shouldn't be too difficult to extract those from (say)
> OpenBabel and other sources if you only want a library.
>
> What programs do you wish to do and what does it entail?
>
> P.
>
>
>
> >Regards,
> >   Noel
>
> Peter Murray-Rust
> Unilever Centre for Molecular Sciences Informatics
> University of Cambridge,
> Lensfield Road,  Cambridge CB2 1EW, UK
> +44-1223-763069
>
>

Re: [cclib-devel] XML output of comp chem programs

[peter murray-r. <pm...@ca...>]

At 10:07 14/02/2007, Noel O'Boyle wrote:
>Hello Peter,
>
>I was wondering do you have any names/contacts who could fill me in on
>the current state of interoperable XML output for computational
>chemistry packages. According to google, there have been some meetings
>regarding this, but this is nothing concrete on the web.

I have now looked at the cclib home page and think progress could be 
made fast. I have copied Toby in case he has comments.  We should 
meet informally soon and you can show me cclib

P.



The major efforts in this area come from:
- eMinerals - a uk-based eScience group with some other connections. 
This includes programs such as GULP, SIESTA, CASTEP, METADISE, 
DL_POLY, and some others
- COST D37. A Euro project at an early stage. We are starting to 
address aspects of interoperability in mainly atomic codes such as 
VAMP, DALTON, etc.
- MOPAC, GAMESS-US. I am doing this in conjunction with the authors
- CECAM2006 - this covers ABINIT, MOLPRO, GAMESS-UK, etc.

The key approach is via libraries. Toby White has developed FoX for 
FORTRAN - I have copied him.

In general a code requires a dictionary. The creation of a stub 
dictionary and CMLised code is of the order of 2-4 weeks depending on 
the level of rigour and comprehensiveness. (There are some outputs 
which never need to be marked up)

>There has been some talk among the cclib developers regarding this,
>but I'm not keen on doing it if there isn't an agreed standard. It
>doesn't have to be a complete spec from our point of view, but just
>enough to cover information that is commonly read into visualisation
>programs, for example.

Java programs can use JUMBO. C++ is not formally supported, nor is 
Python. It shouldn't be too difficult to extract those from (say) 
OpenBabel and other sources if you only want a library.

What programs do you wish to do and what does it entail?

P.



>Regards,
>   Noel

Peter Murray-Rust
Unilever Centre for Molecular Sciences Informatics
University of Cambridge,
Lensfield Road,  Cambridge CB2 1EW, UK
+44-1223-763069  

Re: [cclib-devel] XML output of comp chem programs

[peter murray-r. <pm...@ca...>]

At 10:07 14/02/2007, Noel O'Boyle wrote:
>Hello Peter,
>
>I was wondering do you have any names/contacts who could fill me in on
>the current state of interoperable XML output for computational
>chemistry packages. According to google, there have been some meetings
>regarding this, but this is nothing concrete on the web.

The major efforts in this area come from:
- eMinerals - a uk-based eScience group with some other connections. 
This includes programs such as GULP, SIESTA, CASTEP, METADISE, 
DL_POLY, and some others
- COST D37. A Euro project at an early stage. We are starting to 
address aspects of interoperability in mainly atomic codes such as 
VAMP, DALTON, etc.
- MOPAC, GAMESS-US. I am doing this in conjunction with the authors
- CECAM2006 - this covers ABINIT, MOLPRO, GAMESS-UK, etc.

The key approach is via libraries. Toby White has developed FoX for 
FORTRAN - I have copied him.

In general a code requires a dictionary. The creation of a stub 
dictionary and CMLised code is of the order of 2-4 weeks depending on 
the level of rigour and comprehensiveness. (There are some outputs 
which never need to be marked up)

>There has been some talk among the cclib developers regarding this,
>but I'm not keen on doing it if there isn't an agreed standard. It
>doesn't have to be a complete spec from our point of view, but just
>enough to cover information that is commonly read into visualisation
>programs, for example.

Java programs can use JUMBO. C++ is not formally supported, nor is 
Python. It shouldn't be too difficult to extract those from (say) 
OpenBabel and other sources if you only want a library.

What programs do you wish to do and what does it entail?

P.



>Regards,
>   Noel

Peter Murray-Rust
Unilever Centre for Molecular Sciences Informatics
University of Cambridge,
Lensfield Road,  Cambridge CB2 1EW, UK
+44-1223-763069 

[cclib-devel] XML output of comp chem programs

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

Hello Peter,

I was wondering do you have any names/contacts who could fill me in on
the current state of interoperable XML output for computational
chemistry packages. According to google, there have been some meetings
regarding this, but this is nothing concrete on the web.

There has been some talk among the cclib developers regarding this,
but I'm not keen on doing it if there isn't an agreed standard. It
doesn't have to be a complete spec from our point of view, but just
enough to cover information that is commonly read into visualisation
programs, for example.

Regards,
   Noel

Re: [cclib-devel] Jaguar basis sets

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

Thanks for the help. In the end ,I agree and I've just removed Jaguar gbasis.

Rick Muller also checked:
"""
Briefly, I don't have any idea what Jaguar is doing. I just ran H2
using STO-3G with Jaguar, and the basis print out is essentially the
same as that which you reference below. Which looks like it would lead
to 4 bfns for H2, but in fact leads to only 2. Maybe the column
labeled "jconst" isn't what they say it is in the manual. Note that
the basis function index (which I believe is column 6, labeled nfsh)
shows that all three primatives are in the same basis function. But
maybe I'm getting "basis functions" confused with "shells".

I also checked the internal Jaguar basis set data file, and it has
coefficients equivalent to what you quoted from PyQuante (0.154,
0.535, 0.444...). So they just must be printing their output in a
weird way.
"""

Interestingly, Rick points out that the data file *does* have the
correct coefficients.

All gbasis tests now pass.

Noel

On 14/02/07, Karol Langner <kar...@kn...> wrote:
> I tried to look into this yesterday for a bit, but couldn't come up with
> anything else, again, than that there might be an adidtional sum in the
> contraction.
>
> I think eliminating gbasis from the Jaguar parser is the best thing to do for
> the moment, since there is no way be sure what exactly is going on. In the
> long run, it might be possible to get the infromation from the Jaguar people,
> but that not top-priority now, I guess.
>
> Karol
>
> On Tuesday 13 of February 2007 14:29, Noel O'Boyle wrote:
> > You're right - there's still something weird going on, since the total
> > number of basis functions (which is listed in the output file) adds up
> > to the same as in Gaussian. That is, the three GTOs are regarded as a
> > single basis function.
> >
> > I've posted a question to the CCL (no response) and now I'm asking
> > Rick Muller (of PyQuante) in case he has any ideas. I think that if
> > this remains unresolved, we'll just have to exclude Jaguar gbasis and
> > go with the rest.
> >
> > On 12/02/07, Karol Langner <kar...@kn...> wrote:
> > > On Friday 09 of February 2007 09:09, Noel O'Boyle wrote:
> > > > STO-3G is defined differently as a set of 3 GTOs (1S), 2 GTOs + 1 GTO
> > > > (2S), 2GTOs + 1 GTO (2P).
> > > >
> > > > Now that we've figured this out, I will add gbasis to the Jaguar
> > > > parser over the next few days.
> > >
> > > That's a little surprising, that STO-3G is defined differently. Also, the
> > > energy zomes out exactly the same.
> > >
> > > Karol
> > >
> > > --
> > > written by Karol Langner
> > > Mon Feb 12 19:14:36 CET 2007
>
> --
> written by Karol Langner
> Wed Feb 14 10:41:13 CET 2007
>

Re: [cclib-devel] Molpro parser

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

Hi Grant!

 I can encourage you by saying that I starting helping out with cclib very 
recently. In my case, since that time I have also been using cclib steadily 
more often in my research work.

As to Molpro, I haven't used it too much, but I do have access and sometimes 
run multireference jobs, since they go pretty fast. I haven't even heard 
anything about the XML output, but that would be sooo nice if all programs 
printed xml output :). On a side note, maybe saving xml files of parsed data 
would be a nice feature for cclib in the future?

> > I wonder does this mean that it's not possible for us to parse these
> > output files. Rather we would need to parse the 'checkpoint file' or
> > an XML file or something else (which I think is what Mehdi suggested
> > but I wasn't really familiar with these problems at that stage).
>
> I would imagine it will certainly make things more difficult, I'm
> guessing it should be somewhat similar to parsing a Gaussian output
> that contains several calculations linked together. But, that is a
> guess.
I don't think that means it's not possible to parse these output files, given 
the parsing function is properly contructed. After all, certain blocks in the 
output still have a constant structure, and that's what the parsers use.

Cheers,
Karol

-- 
written by Karol Langner
Wed Feb 14 10:46:09 CET 2007

Re: [cclib-devel] Jaguar basis sets

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

I tried to look into this yesterday for a bit, but couldn't come up with 
anything else, again, than that there might be an adidtional sum in the 
contraction.

I think eliminating gbasis from the Jaguar parser is the best thing to do for 
the moment, since there is no way be sure what exactly is going on. In the 
long run, it might be possible to get the infromation from the Jaguar people, 
but that not top-priority now, I guess.

Karol

On Tuesday 13 of February 2007 14:29, Noel O'Boyle wrote:
> You're right - there's still something weird going on, since the total
> number of basis functions (which is listed in the output file) adds up
> to the same as in Gaussian. That is, the three GTOs are regarded as a
> single basis function.
>
> I've posted a question to the CCL (no response) and now I'm asking
> Rick Muller (of PyQuante) in case he has any ideas. I think that if
> this remains unresolved, we'll just have to exclude Jaguar gbasis and
> go with the rest.
>
> On 12/02/07, Karol Langner <kar...@kn...> wrote:
> > On Friday 09 of February 2007 09:09, Noel O'Boyle wrote:
> > > STO-3G is defined differently as a set of 3 GTOs (1S), 2 GTOs + 1 GTO
> > > (2S), 2GTOs + 1 GTO (2P).
> > >
> > > Now that we've figured this out, I will add gbasis to the Jaguar
> > > parser over the next few days.
> >
> > That's a little surprising, that STO-3G is defined differently. Also, the
> > energy zomes out exactly the same.
> >
> > Karol
> >
> > --
> > written by Karol Langner
> > Mon Feb 12 19:14:36 CET 2007

-- 
written by Karol Langner
Wed Feb 14 10:41:13 CET 2007

Re: [cclib-devel] Molpro parser

[Grant H. <Hi...@ca...>]

On 13 Feb 2007, at 13:24, Noel O'Boyle wrote:

>>
>> Molpro does have a mini scripting-type language that you can use for
>> the input. In addition to running loops over user-defined arrays you
>> can store calculated information in variables for processing at the
>> end of the job.
>
> I wonder does this mean that it's not possible for us to parse these
> output files. Rather we would need to parse the 'checkpoint file' or
> an XML file or something else (which I think is what Mehdi suggested
> but I wasn't really familiar with these problems at that stage).

I would imagine it will certainly make things more difficult, I'm  
guessing it should be somewhat similar to parsing a Gaussian output  
that contains several calculations linked together. But, that is a  
guess.


>> It can also provide some output in XML format, but I've never really
>> played with it.
> I know that PMR (Peter Murray-Rust) is pushing strongly for comp chem
> packages to output data in XML, and I had the impression that Molpro
> was somehow taking the lead (in the quan chem world at least) in this.
> The Molpro website has little information.

The website isn't always the most useful place for information on  
Molpro ;-) I have easy access to the package so I'll try to have a  
play with the xml options. I currently don't even know if it outputs  
CML or conforms to some other custom DTD.


Grant

Re: [cclib-devel] Jaguar basis sets

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

You're right - there's still something weird going on, since the total
number of basis functions (which is listed in the output file) adds up
to the same as in Gaussian. That is, the three GTOs are regarded as a
single basis function.

I've posted a question to the CCL (no response) and now I'm asking
Rick Muller (of PyQuante) in case he has any ideas. I think that if
this remains unresolved, we'll just have to exclude Jaguar gbasis and
go with the rest.

On 12/02/07, Karol Langner <kar...@kn...> wrote:
> On Friday 09 of February 2007 09:09, Noel O'Boyle wrote:
> > STO-3G is defined differently as a set of 3 GTOs (1S), 2 GTOs + 1 GTO
> > (2S), 2GTOs + 1 GTO (2P).
> >
> > Now that we've figured this out, I will add gbasis to the Jaguar
> > parser over the next few days.
>
> That's a little surprising, that STO-3G is defined differently. Also, the
> energy zomes out exactly the same.
>
> Karol
>
> --
> written by Karol Langner
> Mon Feb 12 19:14:36 CET 2007
>

Re: [cclib-devel] Molpro parser

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

Hello Grant,

On 13/02/07, Grant Hill <Hi...@ca...> wrote:
> Hello,
>
> Long time lurker, first time poster here.
>
> On 13 Feb 2007, at 12:49, Noel O'Boyle wrote:
> >
> > Are you familiar with Molpro? If so, perhaps you know the answers to
> > the following questions.  I read on the web something about the output
> > files of Molpro being described in a sort of mini-language in the
> > input file...do you know anything about this? Rumour has it that
> > Molpro can write data in XML format...this is the way of the future,
> > and would make it trivial to parse.
>
> Molpro does have a mini scripting-type language that you can use for
> the input. In addition to running loops over user-defined arrays you
> can store calculated information in variables for processing at the
> end of the job.

I wonder does this mean that it's not possible for us to parse these
output files. Rather we would need to parse the 'checkpoint file' or
an XML file or something else (which I think is what Mehdi suggested
but I wasn't really familiar with these problems at that stage).

> It can also provide some output in XML format, but I've never really
> played with it.
I know that PMR (Peter Murray-Rust) is pushing strongly for comp chem
packages to output data in XML, and I had the impression that Molpro
was somehow taking the lead (in the quan chem world at least) in this.
The Molpro website has little information.

> For reference, I'm interested in contributing to cclib but I'm only
> just picking up the basics of python. If it goes well you may hear
> more from me in the future.
We would welcome any contributions you can make. If you have any
questions about our code, how it works, and so on, feel free to ask.

>
>
> Grant
>

Re: [cclib-devel] Molpro parser

[Grant H. <Hi...@Ca...>]

Hello,

Long time lurker, first time poster here.

On 13 Feb 2007, at 12:49, Noel O'Boyle wrote:
>
> Are you familiar with Molpro? If so, perhaps you know the answers to
> the following questions.  I read on the web something about the output
> files of Molpro being described in a sort of mini-language in the
> input file...do you know anything about this? Rumour has it that
> Molpro can write data in XML format...this is the way of the future,
> and would make it trivial to parse.

Molpro does have a mini scripting-type language that you can use for  
the input. In addition to running loops over user-defined arrays you  
can store calculated information in variables for processing at the  
end of the job.

It can also provide some output in XML format, but I've never really  
played with it.

For reference, I'm interested in contributing to cclib but I'm only  
just picking up the basics of python. If it goes well you may hear  
more from me in the future.



Grant

Re: [cclib-devel] Molpro parser

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

Mehdi Bounouar started work on that late last year, but there hasn't
been much activity on it since then, except to move it to a branch.

Are you familiar with Molpro? If so, perhaps you know the answers to
the following questions.  I read on the web something about the output
files of Molpro being described in a sort of mini-language in the
input file...do you know anything about this? Rumour has it that
Molpro can write data in XML format...this is the way of the future,
and would make it trivial to parse.

Noel

On 13/02/07, Karol Langner <kar...@kn...> wrote:
> What is the situation with the Molpro parser - is anyone working on that?
>
> Karol
>
> --
> written by Karol Langner
> Tue Feb 13 12:43:15 CET 2007
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

[cclib-devel] Molpro parser

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

What is the situation with the Molpro parser - is anyone working on that?

Karol

-- 
written by Karol Langner
Tue Feb 13 12:43:15 CET 2007

Re: [cclib-devel] Refactoring

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

On 13/02/07, Karol Langner <kar...@kn...> wrote:
> On Tuesday 13 of February 2007 08:51, Noel O'Boyle wrote:
> > > > Things to do...MP2 energies for remaining parsers, gbasis for Jaguar,
> > > > final Jaguar tests.
> >
> > The merging is going to happen after release; we now need to stabilise
> > the branch, get all tests to pass, and *release*.
>
> OK.... so I understand that the trunk is the priority now. I'll start to help
> out with that soon, I did a little travelling recently.
>
> As to mpenergies, I don't have access to a new version of GAMESS-UK, so could
> someone upload an MPx test for that program, too (also Jaguar). I can take
> care of parsing.

I'll upload water sto3g mp2 for GAMESS-UK. It make take a while, as I
may need to get a new copy of the software...

> Karol
>
> --
> written by Karol Langner
> Tue Feb 13 11:23:25 CET 2007
>

Re: [cclib-devel] Refactoring

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

On Tuesday 13 of February 2007 08:51, Noel O'Boyle wrote:
> > > Things to do...MP2 energies for remaining parsers, gbasis for Jaguar,
> > > final Jaguar tests.
>
> The merging is going to happen after release; we now need to stabilise
> the branch, get all tests to pass, and *release*.

OK.... so I understand that the trunk is the priority now. I'll start to help 
out with that soon, I did a little travelling recently.

As to mpenergies, I don't have access to a new version of GAMESS-UK, so could 
someone upload an MPx test for that program, too (also Jaguar). I can take 
care of parsing.

Karol

-- 
written by Karol Langner
Tue Feb 13 11:23:25 CET 2007

Re: [cclib-devel] Refactoring

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

On 12/02/07, Karol Langner <kar...@kn...> wrote:
> On Friday 09 of February 2007 14:51, Noel O'Boyle wrote:
> > cclib 0.7 release branch created based on trunk revision 479.
> > Development should still occur on the trunk (or the parser refactoring
> > branch). I'll look after merging stable changes to the release branch
> > every so often.
> >
> > Things to do...MP2 energies for remaining parsers, gbasis for Jaguar,
> > final Jaguar tests.
> >
> > Noel
>
> I'll take care of the MP2 energies, except for Jaguar which I don't have
> access to (unless someone uploads a test, then I can do that, too).
>
> I'm not eager to do any more major refactoring in the parsers at the moment
> (except perhaps splitting _extract() into a dictionary of functions, but that
> needs to be discussed more thouroughly). Nor do I have any more interesting
> ideas for this. Also, I would rather go about adding functionality and
> resolving bugs. So what are your views on the current revision of the
> parser-refactoring branch - can it be merged with trunk? I ask, because
> merging later can be a pain if we add things to the parser long the way.

The merging is going to happen after release; we now need to stabilise
the branch, get all tests to pass, and *release*.

> Karol
>
> --
> written by Karol Langner
> Mon Feb 12 19:01:33 CET 2007
>

Re: [cclib-devel] Jaguar basis sets

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

On Friday 09 of February 2007 09:09, Noel O'Boyle wrote:
> STO-3G is defined differently as a set of 3 GTOs (1S), 2 GTOs + 1 GTO
> (2S), 2GTOs + 1 GTO (2P).
>
> Now that we've figured this out, I will add gbasis to the Jaguar
> parser over the next few days.

That's a little surprising, that STO-3G is defined differently. Also, the 
energy zomes out exactly the same.

Karol

-- 
written by Karol Langner
Mon Feb 12 19:14:36 CET 2007

Re: [cclib-devel] Refactoring

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

On Friday 09 of February 2007 14:51, Noel O'Boyle wrote:
> cclib 0.7 release branch created based on trunk revision 479.
> Development should still occur on the trunk (or the parser refactoring
> branch). I'll look after merging stable changes to the release branch
> every so often.
>
> Things to do...MP2 energies for remaining parsers, gbasis for Jaguar,
> final Jaguar tests.
>
> Noel

I'll take care of the MP2 energies, except for Jaguar which I don't have 
access to (unless someone uploads a test, then I can do that, too).

I'm not eager to do any more major refactoring in the parsers at the moment 
(except perhaps splitting _extract() into a dictionary of functions, but that 
needs to be discussed more thouroughly). Nor do I have any more interesting 
ideas for this. Also, I would rather go about adding functionality and 
resolving bugs. So what are your views on the current revision of the 
parser-refactoring branch - can it be merged with trunk? I ask, because 
merging later can be a pain if we add things to the parser long the way.

Karol

-- 
written by Karol Langner
Mon Feb 12 19:01:33 CET 2007

Re: [cclib-devel] Refactoring

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

cclib 0.7 release branch created based on trunk revision 479.
Development should still occur on the trunk (or the parser refactoring
branch). I'll look after merging stable changes to the release branch
every so often.

Things to do...MP2 energies for remaining parsers, gbasis for Jaguar,
final Jaguar tests.

Noel

On 02/02/07, Adam Tenderholt <a-t...@st...> wrote:
> > Sounds like this is starting to turn into a major refactoring, and I'm
> > a bit wary of having this on the trunk, especially as it will be
> > experimental for the first while. Can you put this on a branch instead
> > and just test with a single parser for the moment?
>
> Karol, it does sound like you are doing some interesting work, but I
> agree with Noel that this should be developed someplace other than
> where our current changes are. Especially since my most recent
> version of PyMOlyze uses trunk as that's where the CDA and
> FragmentAnalysis code is.
>
> What are the current features we are hoping to have in cclib 0.7? If
> there aren't going to be many changes (esp to parsers), I think it
> makes sense to merge trunk (from before the refactoring) into a
> cclib-0.7 branch. If we decide we like the refactoring changes, we
> can merge those into cclib-0.7 once its stable. What do y'all think?
>
> Adam
>
>
>

Re: [cclib-devel] Jaguar basis sets

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

On 31/01/07, Karol Langner <kar...@kn...> wrote:
> Hi,
>
>  I'm wondering about the basis sets output by Jaguar... they have me stumped,
> since the contraction coefficients for the SP gaussian primitives are totally
> different than those given by GAMESS and Gaussian.
>
>  Compare the STO-3G function for carbon that I found in the cclib test
> logfiles.
>
> Gaussian:
>  S   3 1.00       0.000000000000
>       0.7161683735D+02  0.1543289673D+00
>       0.1304509632D+02  0.5353281423D+00
>       0.3530512160D+01  0.4446345422D+00
>  SP   3 1.00       0.000000000000
>       0.2941249355D+01 -0.9996722919D-01  0.1559162750D+00
>       0.6834830964D+00  0.3995128261D+00  0.6076837186D+00
>       0.2222899159D+00  0.7001154689D+00  0.3919573931D+00

STO-3G is defined as a set of 3 GTOs (1S), 3 GTOs (2S), and 3 GTOs(2P).

> Jaguar:
>              s    j
>              h    c  i       n
>              e    o  s       f
>              l    n  h       s
>   atom       l    t  l  l    h          z              coef            rcoef
> --------    ---  --- -- --  ---     ----------      ----------       ---------
>  C1          1    3  0  1    0      71.6168373       0.1543290       2.7078144
>  C1          2   -1  0  1    0      13.0450963       0.5353281       2.6188802
>  C1          3   -1  0  1    0       3.5305122       0.4446345       0.8161906
>  C1          4    2  2  1    1       2.9412494      -0.2956454      -0.4732386
>  C1          5   -4  2  1    1       0.6834831       1.1815287       0.6329949
>  C1          6    2 -1  2    2       2.9412494       0.2213487       1.2152952
>  C1          7   -6 -1  2    2       0.6834831       0.8627064       0.7642102
>  C1          8    1  1  1    1       0.2222899       1.0000000       0.2307278
>  C1          9    1 -1  2    2       0.2222899       1.0000000       0.2175654
>
> The coefficient for the S shells are the same, but the ones for SP are not.
> Does anybody know how to explain this, and eventually how to interconvert? I
> assume that the STO-3G functions used in both programs are identical, so it
> should be possible. Or, where should I ask about this? Maybe this is the
> reason why there's no gbasis attribute for the Jaguar parser yet?

STO-3G is defined differently as a set of 3 GTOs (1S), 2 GTOs + 1 GTO
(2S), 2GTOs + 1 GTO (2P).

Now that we've figured this out, I will add gbasis to the Jaguar
parser over the next few days.

Noel

Re: [cclib-devel] parser-refactoring

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

On Tuesday 06 of February 2007 19:38, Adam Tenderholt wrote:
> Hi Karol,
>
> That fixed it.
>
> However, using PyMOlyze this morning exposed another bug. ADF parsers
> should have frags and fragnames attributes because ADF sometimes
> alters the atom order so that there isn't a direct mapping between
> fonames (ie. C1_3s) and atomcoords. Look in the svn log and ADF test
> files for more details.
>
> Adam

Yes... this is a side-effect of a new thing I introduced in LogFile.parse() - 
attributes that do not exist before parsing or are not in _attrlist are 
deleted after parsing - this way parsers can create temporary attributes for 
the object when needed across calls of _extract(). I'm not sure if this 
work-around is good  practice in general, but it does require we keep the 
list of attributes (_attrlist) up-to-date, which is probably a good thing :)

In any case, in revision 511 I added the ADF-specific attributes (4 of them, 
in fact) to _attrlist in the __init__ method of class ADF.. I would add them 
to the docstring, but I don't have the time to read into their meanings 
today.

Let me now if there are any other problems,
Karol

-- 
written by Karol Langner
Tue Feb  6 20:56:45 CET 2007