From: Noel O'B. <no...@ca...> - 2006-05-17 17:08:46
|
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 |