cclib-devel

[cclib-devel] Progress towards release

[Noel O'B. <no...@ca...>]

It's taking me a while to get an a/c on the Jaguar machine but I would
like to get a release out as soon as possible.

I'd like to add support for atomcoords to all of the main parsers, and
get a release out next week or the week after with good support for ADF,
GAMESS and Gaussian. Once we get Jaguar in shape we can get another
release out.

I've posted on the ADF forum regarding the SCF values, and if we get an
answer I'll be able to fix that once and for all (I see it causes a
unittest failure too).

You or I should do a global rename of nindep to nmo, if you agree.

Oh yes, we/I need to get aonames parsed for GAMESS and Gaussian (I think
that's low-hanging fruit, as they say).

Is there anything else you would like before a release? We can call it
cclib-0.5 or something, what do you think?

Regards,
 Noel

[cclib-devel] Re: Progress towards release

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

> I'd like to add support for atomcoords to all of the main parsers, and
> get a release out next week or the week after with good support for  
> ADF,
> GAMESS and Gaussian. Once we get Jaguar in shape we can get another
> release out.

Sounds reasonable. I agree that it's more important to get an initial  
release out for relatively stable parsers, and have subsequent  
releases once we add support for other formats. Do you think we  
should keep the "broken" parsers in our initial release? I think it  
makes sense to create a SVN branch, and remove parsers other than  
ADF, GAMESS, and Gaussian.

> I've posted on the ADF forum regarding the SCF values, and if we  
> get an
> answer I'll be able to fix that once and for all (I see it causes a
> unittest failure too).

Cool.

> You or I should do a global rename of nindep to nmo, if you agree.

I'll take care of it, unless I encounter problems (going to use sed).

> Oh yes, we/I need to get aonames parsed for GAMESS and Gaussian (I  
> think
> that's low-hanging fruit, as they say).

I thought Gaussian had aonames.

> Is there anything else you would like before a release? We can call it
> cclib-0.5 or something, what do you think?

I'd like to finish up the calculation methods, since I'll need those  
for PyMOlyze if I'm going to use cclib. Might as well kill two birds  
with one stone.  While we're talking about it, I'm going to implement  
the following:

--Methods base class
   --Population class (implements repartition function which accepts  
a list of lists)
      -- MPA (implements calculate, and accepts an optional lists of  
lists; if absent, does atoms)
      -- CSPA (same as MPA)
   -- Overlap population (not a subclass of population because can't  
have repartition function as the expensive calculation depends on the  
partitioning)
   --Density class (implements calculate)
     --MBO class (mayer's), which implements a calculate that calls  
Density.calculate()

I figure that should only take a few hours more work, so I'll try to  
get to it this week, although no promises. I have to give group  
meeting, and analyze some new data and calculations.

Also, it might be nice if we included a routine in the parser that  
opens a file, tries to determine the file type, and returns an  
instance of the appropriate class. What do you think?

cclib-0.5 sounds fine, and we can increment by 0.1 as we add more  
parsers.

Adam

Re: [cclib-devel] Re: Progress towards release

[Noel O'B. <no...@ca...>]

On Tue, 2006-05-16 at 11:14 -0700, Adam Tenderholt wrote:
> > I'd like to add support for atomcoords to all of the main parsers, and
> > get a release out next week or the week after with good support for  
> > ADF,
> > GAMESS and Gaussian. Once we get Jaguar in shape we can get another
> > release out.
> 
> Sounds reasonable. I agree that it's more important to get an initial  
> release out for relatively stable parsers, and have subsequent  
> releases once we add support for other formats. Do you think we  
> should keep the "broken" parsers in our initial release? I think it  
> makes sense to create a SVN branch, and remove parsers other than  
> ADF, GAMESS, and Gaussian.

Well, I wouldn't be too worried about it. A stable release (1.0) is one
thing. A 0.5 or less release is another. We can simply not mention the
other parsers. Also, I do not think that maintaining branches is a fun
task. It *is* possible though, and with the tests that we have, we can
ensure that it still works.

> > I've posted on the ADF forum regarding the SCF values, and if we  
> > get an
> > answer I'll be able to fix that once and for all (I see it causes a
> > unittest failure too).
> 
> Cool.

Yeah, 500 reads and no answers - still waiting.

> > You or I should do a global rename of nindep to nmo, if you agree.
> 
> I'll take care of it, unless I encounter problems (going to use sed).

Cool.

> > Oh yes, we/I need to get aonames parsed for GAMESS and Gaussian (I  
> > think
> > that's low-hanging fruit, as they say).

> I thought Gaussian had aonames.

So I did I, but there was a question mark in front of the √ in the
cclib wiki. Anyway I've looked in this, and into filling the last few
checkboxes for GAMESS and Gaussian.

> > Is there anything else you would like before a release? We can call it
> > cclib-0.5 or something, what do you think?
> 
> I'd like to finish up the calculation methods, since I'll need those  
> for PyMOlyze if I'm going to use cclib. Might as well kill two birds  
> with one stone.  While we're talking about it, I'm going to implement  
> the following:
> 
> --Methods base class
>    --Population class (implements repartition function which accepts  
> a list of lists)
>       -- MPA (implements calculate, and accepts an optional lists of  
> lists; if absent, does atoms)
>       -- CSPA (same as MPA)
>    -- Overlap population (not a subclass of population because can't  
> have repartition function as the expensive calculation depends on the  
> partitioning)
>    --Density class (implements calculate)
>      --MBO class (mayer's), which implements a calculate that calls  
> Density.calculate()
> 
> I figure that should only take a few hours more work, so I'll try to  
> get to it this week, although no promises. I have to give group  
> meeting, and analyze some new data and calculations.

Yeah, real life - it does get in the way. I will have some time in the
evenings next week and would like to get an initial release put together
and sent off sometime that week. We probably need some more man pages on
the wiki showing how to use cclib: the parser and the analysers.

> Also, it might be nice if we included a routine in the parser that  
> opens a file, tries to determine the file type, and returns an  
> instance of the appropriate class. What do you think?
Wait a second, I was thinking of exactly the same thing! I was thinking
of a method of the Logfile, that either returns an instance of the
appropriate parser or returns None.

> cclib-0.5 sounds fine, and we can increment by 0.1 as we add more  
> parsers.

Cool

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

Re: [cclib-devel] Re: Progress towards release

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

> Well, I wouldn't be too worried about it. A stable release (1.0) is  
> one
> thing. A 0.5 or less release is another. We can simply not mention the
> other parsers. Also, I do not think that maintaining branches is a fun
> task. It *is* possible though, and with the tests that we have, we can
> ensure that it still works.

Ok, that's fine. I suspect there aren't going to be many user of  
cclib immediately.

> Yeah, 500 reads and no answers - still waiting.

That's a lot. I'm surprised nobody has answered yet.

> So I did I, but there was a question mark in front of the √  
> in the
> cclib wiki. Anyway I've looked in this, and into filling the last few
> checkboxes for GAMESS and Gaussian.

Oh yeah. I had added that when I noticed that the aonames didn't fit  
our naming scheme (lowercase u/g). I think it's ok.

> Yeah, real life - it does get in the way. I will have some time in the
> evenings next week and would like to get an initial release put  
> together
> and sent off sometime that week. We probably need some more man  
> pages on
> the wiki showing how to use cclib: the parser and the analysers.

I have added a page about using the methods, but it's not too detailed.

> Wait a second, I was thinking of exactly the same thing! I was  
> thinking
> of a method of the Logfile, that either returns an instance of the
> appropriate parser or returns None.

Sounds good.

Adam

Re: [cclib-devel] Re: Progress towards release

[Noel O'B. <no...@ca...>]

On Wed, 2006-05-17 at 10:28 -0700, Adam Tenderholt wrote:
> > Well, I wouldn't be too worried about it. A stable release (1.0) is  
> > one
> > thing. A 0.5 or less release is another. We can simply not mention the
> > other parsers. Also, I do not think that maintaining branches is a fun
> > task. It *is* possible though, and with the tests that we have, we can
> > ensure that it still works.
> 
> Ok, that's fine. I suspect there aren't going to be many user of  
> cclib immediately.

If we get a couple of command-line enthusiasts we'll be lucky. We could
try to get BKChem on board too, and any other Python programs in a
similar area. PyQuante too (although I'm not sure how this would work).

> > Yeah, 500 reads and no answers - still waiting.
> 
> That's a lot. I'm surprised nobody has answered yet.
Nobody knows the answer or I didn't phrase it correctly, I guess.

> > So I did I, but there was a question mark in front of the √  
> > in the
> > cclib wiki. Anyway I've looked in this, and into filling the last few
> > checkboxes for GAMESS and Gaussian.
> 
> Oh yeah. I had added that when I noticed that the aonames didn't fit  
> our naming scheme (lowercase u/g). I think it's ok.
What's the naming scheme again? Check out the wiki for examples of
what's extracted from GAMESS and Gaussian and let me know if this needs
to be improved.

> > Wait a second, I was thinking of exactly the same thing! I was  
> > thinking
> > of a method of the Logfile, that either returns an instance of the
> > appropriate parser or returns None.

I'll try and add a method today that reads the first 10 lines of the
file and guesses the identity, how does that sound?

In PyMOlyze/GaussSum we can flash a box up that asks people to send us
their log file if it doesn't guess correctly, and they want to help us
improve it.

Noel

Re: [cclib-devel] Re: Progress towards release

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

> What's the naming scheme again? Check out the wiki for examples of
> what's extracted from GAMESS and Gaussian and let me know if this  
> needs
> to be improved.

Ooh, I wasn't thinking of aonames but mosymms. The aonames look fine,  
although we may want to consider normalizing the GAMESS names at some  
point.

> I'll try and add a method today that reads the first 10 lines of the
> file and guesses the identity, how does that sound?

Sounds good.

> In PyMOlyze/GaussSum we can flash a box up that asks people to send us
> their log file if it doesn't guess correctly, and they want to help us
> improve it.

Yeah, makes sense. I'll make a note of that.

Adam

Re: [cclib-devel] Re: Progress towards release

[Noel O'B. <no...@ca...>]

On Thu, 2006-05-18 at 08:19 -0700, Adam Tenderholt wrote:
> > What's the naming scheme again? Check out the wiki for examples of
> > what's extracted from GAMESS and Gaussian and let me know if this  
> > needs
> > to be improved.
> 
> Ooh, I wasn't thinking of aonames but mosymms. The aonames look fine,  
> although we may want to consider normalizing the GAMESS names at some  
> point.

We'll need a bigger sample though - maybe a one-atom calc on a metal ion
with a massive basis set, like you did with ADF...I'll look into it.

> > I'll try and add a method today that reads the first 10 lines of the
> > file and guesses the identity, how does that sound?
> 
> Sounds good.

It's done now (requires first 20 lines for the test files). Check out
the SVN log though as it involved a couple of rearrangements of imports.

Regards,
 Noel