cclib-devel

Re: [cclib-devel] [OpenBabel-scripting] OBMol.Rotate() using python wrapper

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

> Thanks for the link! Unfortunately, cclib's makeopenbabel (version
> 0.6) doesn't like it so much. I managed to get pyopenbabel installed
> by checking out revision 1593 of the openbabel svn and altering the
> setup.py file to only install pyopenbabel. Unfortunately, it doesn't
> like _openbabel.OBAtom_SetVector(*args). Do you have any insight into
> this?! My guess is I could make it use the SetVector(double, double,
> double).

First of all, makeopenbabel has needed some attention for some time
now. The first thing I did is remove the dependency on pyopenbabel, so
that it just requires the open babel module.

Secondly, there was some weird Numeric stuff going on that caused me
to tear my hair out for a while. SetVector was working with (1.0, 1.0,
1.0) but choking on (coords[0], coords[1], coords[2]). It only
accepted the latter when I converted coords to a list using
coords.tolist(). I still don't know why :-/ I think this code used to
work...it's time for a test routine that runs the doctests, I think.

In short, it should be fixed now.

> Also, it doesn't look like you've tagged cclib 0.6.1. How's that
> coming along?
Sorry - it has been  tagged and released but not publicised (I kind of
ran out of steam, after rushing out the bug fix). I guess you looked
at the instructions page and didn't see anything written there. I
stopped updating that as I feel more confident using log messages to
keep track of what's been merged/branched/etc.

I'll send around a publicity email asap.

BTW, regarding branches - I'm thinking of creating separate branches
for parsers under development. This will cut down on the error
messages we get when we run the tests on the trunk (too many errors
and the tests become meaningless); and also avoid the mistakes I made
when when creating the 0.6 release. Any thoughts?

Noel

Re: [cclib-devel] [OpenBabel-scripting] OBMol.Rotate() using python wrapper

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

> Secondly, there was some weird Numeric stuff going on that caused me
> to tear my hair out for a while. SetVector was working with (1.0, 1.0,
> 1.0) but choking on (coords[0], coords[1], coords[2]). It only
> accepted the latter when I converted coords to a list using
> coords.tolist(). I still don't know why :-/ I think this code used to
> work...it's time for a test routine that runs the doctests, I think.

Strangely, I only had this problem on Windows. My fix was to to use  
float() on coords first. Maybe its some differences between Numeric  
on Windows and Mac?

> I'll send around a publicity email asap.

I saw the email. Good work.

> BTW, regarding branches - I'm thinking of creating separate branches
> for parsers under development. This will cut down on the error
> messages we get when we run the tests on the trunk (too many errors
> and the tests become meaningless); and also avoid the mistakes I made
> when when creating the 0.6 release. Any thoughts?

I think this is a good idea. We should create a numbered branch for  
our next release. Is that going to be 0.7? And only stuff that we  
agree on goes in the numbered branch? Should we also try to put a  
flexible timeframe on the branch so that we know what goes in it?

My proposal for the 0.7 branch would be:

Initial Jaguar parser (It parses most things, as i recall).
CDA method
DOS stuff?

I'd say the release happens sometime in mid-January (things are a bit  
busy at the moment for me, but I should be able to get around to it  
eventually). What do you think?

About the CDA method: I found the original CDA code for two fragments  
online. Do you think I can just "translate" it into Python and extend  
it for multiple fragments, or do I need to explain on the list what  
the code does and let you implement it for a more cleanroom-style  
implementation.

Adam

Re: [cclib-devel] [OpenBabel-scripting] OBMol.Rotate() using python wrapper

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

> > BTW, regarding branches - I'm thinking of creating separate branches
> > for parsers under development. This will cut down on the error
> > messages we get when we run the tests on the trunk (too many errors
> > and the tests become meaningless); and also avoid the mistakes I made
> > when when creating the 0.6 release. Any thoughts?
>
> I think this is a good idea. We should create a numbered branch for
> our next release. Is that going to be 0.7? And only stuff that we
> agree on goes in the numbered branch? Should we also try to put a
> flexible timeframe on the branch so that we know what goes in it?

I need to think some more about this, as what I was proposing was
slightly different. I think you're saying that we should do
development on the 0.7 branch. I'm afraid it will get slightly
confusing if we are developing both on the branch and the trunk (as
changes may have to be merged in both directions). I was suggesting
that development for new parsers should be done on a branch, e.g. the
molpro parser branch. This would only have tests and data files for
molpro, for instance, and wouldn't contain the bridges, methods, etc.
modules, so that development would be more focused (and the only
changes would be parser related). Since Jaguar is slated for inclusion
in the next release, I think it'd be easier at this stage to leave it
on the trunk and do the final development there.

> My proposal for the 0.7 branch would be:
>
> Initial Jaguar parser (It parses most things, as i recall).
> CDA method
> DOS stuff?

I'd like to get the volume stuff in shape and add that too. I think
it's important to get some sort of volume data created so that some
progress can be made on pop analysis methods that use volume data. In
the course of getting this ready I will discuss its limitations on the
list, and we can decide if it's enough.

> I'd say the release happens sometime in mid-January (things are a bit
> busy at the moment for me, but I should be able to get around to it
> eventually). What do you think?

Sounds good in general, but I should say that Christmas is an
open-source free zone for me. mid-Jan...isn't that like, cclib's first
anniversary? :-)

> About the CDA method: I found the original CDA code for two fragments
> online. Do you think I can just "translate" it into Python and extend
> it for multiple fragments, or do I need to explain on the list what
> the code does and let you implement it for a more cleanroom-style
> implementation.

I think Step 1 is to reimplement it so that it gives the same answer
as the original code, however you do it. Once this is done we can
think about refactoring it. (I hope there are no computer scientists
reading this list - we can call this prototyping if it makes them
happier :-) )

I was thinking about whether it is important for all of the cclib
algorithms to be 'identically' implemented, etc. In the end, I would
just prefer to have implementations of various algorithms that work,
rather than worry about this too much - after all, we would like
contributions from outside cclib, and it's unlikely they will come
packaged in the same way as our own functions/classes.

> Adam
>
>

Re: [cclib-devel] [OpenBabel-scripting] OBMol.Rotate() using python wrapper

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

> I need to think some more about this, as what I was proposing was
> slightly different. I think you're saying that we should do
> development on the 0.7 branch. I'm afraid it will get slightly
> confusing if we are developing both on the branch and the trunk (as
> changes may have to be merged in both directions). I was suggesting
> that development for new parsers should be done on a branch, e.g. the
> molpro parser branch. This would only have tests and data files for
> molpro, for instance, and wouldn't contain the bridges, methods, etc.
> modules, so that development would be more focused (and the only
> changes would be parser related). Since Jaguar is slated for inclusion
> in the next release, I think it'd be easier at this stage to leave it
> on the trunk and do the final development there.

I hadn't thought about the difficulty in maintaining a 0.7 branch and  
trunk. I do like the idea of a parser-specific branch for new  
parsers. I'm assuming you'll still include the more finished parsers?  
I'll let you handle it since you know what you have in mind.

>> My proposal for the 0.7 branch would be:
>>
>> Initial Jaguar parser (It parses most things, as i recall).
>> CDA method
>> DOS stuff?
>
> I'd like to get the volume stuff in shape and add that too. I think
> it's important to get some sort of volume data created so that some
> progress can be made on pop analysis methods that use volume data. In
> the course of getting this ready I will discuss its limitations on the
> list, and we can decide if it's enough.

Sounds good. You'll move the discussion about volume stuff to a new  
thread when you start working on it?

> Sounds good in general, but I should say that Christmas is an
> open-source free zone for me. mid-Jan...isn't that like, cclib's first
> anniversary? :-)

Ah, ok. I'm looking forward to Christmas break so that I can do some  
hacking. After visiting with the family of course!

> I think Step 1 is to reimplement it so that it gives the same answer
> as the original code, however you do it. Once this is done we can
> think about refactoring it. (I hope there are no computer scientists
> reading this list - we can call this prototyping if it makes them
> happier :-) )

So you don't think there's any problem with me basically translating  
the code I found into Python? Not even from a violating some license  
standpoint? I don't think there is since I'm going to write our  
method from the ground up using the CDA code as a guide, instead of  
just copying the code and altering after the fact. Also, I'm  
translating it to another language! So there will be unique code from  
my side anyways.

> I was thinking about whether it is important for all of the cclib
> algorithms to be 'identically' implemented, etc. In the end, I would
> just prefer to have implementations of various algorithms that work,
> rather than worry about this too much - after all, we would like
> contributions from outside cclib, and it's unlikely they will come
> packaged in the same way as our own functions/classes.

I agree with you, although I think we should try to keep things as  
consistent as possible. If we do get code contributions, I would  
suggest we should still create classes that have attributes which are  
created from a calculate function.

Adam

Re: [cclib-devel] [OpenBabel-scripting] OBMol.Rotate() using python wrapper

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

> I hadn't thought about the difficulty in maintaining a 0.7 branch and
> trunk. I do like the idea of a parser-specific branch for new
> parsers. I'm assuming you'll still include the more finished parsers?
> I'll let you handle it since you know what you have in mind.

I'm in the process of branching off Molpro. At the moment, I'm not
planning on including the other parsers, simply because any
fixes/changes to the other parsers should be done on the trunk; also,
the tests on the branch will only be for the developing parser; the
tests on the trunk will only be for the finished parsers. What will
happen is that people working on a new parser will develop on the
branch. Once all the tests pass, the results are merged into the
trunk.

Regards,
   Noel