openbabel-scripting

[openbabel-scripting] Accessing SSSR or Internal Coordinates from Python

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

What can I do with a molecule's SSSR or Internal Coordinates if it's in
the following state?

>>> from pyopenbabel import *
>>> text = open("3d.head.sdf","r").read()
>>> mol = readstring("sd",text)
>>> mol
<pyopenbabel.Molecule object at 0x4020930c>
>>> mol.sssr
<Swig Object at _a4b82008_p_std__vectorTOpenBabel__OBRing_p_std__allocatorTOpenBabel__OBRing_p_t_t>
>>> dir(mol.sssr)
[]
>>> mol.internalcoord
<Swig Object at _28fc1f08_p_std__vectorTOpenBabel__OBInternalCoord_p_std__allocatorTOpenBabel__OBInternalCoord_p_t_t>

Are these not accessible from Python/Perl then?

Regards,
 Noel

Re: [openbabel-scripting] Accessing SSSR or Internal Coordinates from Python

[Geoffrey H. <ge...@ge...>]

On Feb 23, 2006, at 11:40 AM, Noel O'Boyle wrote:

> What can I do with a molecule's SSSR or Internal Coordinates if  
> it's in
> the following state?
> ...
> Are these not accessible from Python/Perl then?

Guess not. That wasn't intentional. For SSSR, OBRing isn't wrapped,  
so I'll add that to the SWIG file. I'm also going to add  
OBSmartsPattern.

I need to go back and revisit the SWIG documentation about internal  
coordinates. Certainly the OBInternalCoord class is wrapped, but I  
seem to remember there were issues about templates -- that you needed  
to do some renaming to make sure they mapped to valid symbols in the  
scripting language.

e.g., std::vector<OBInternalCoord>   ->   vectorInternals

Cheers,
-Geoff

Re: [openbabel-scripting] Accessing SSSR or Internal Coordinates from Python

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

I'd like to help with this if I can - I think this issue is going to
occur more than once. Is there some particularly good documentation
available somewhere on wrapping with SWIG, that can make this all very
clear to me?

Regards,
 Noel

On Thu, 2006-02-23 at 13:18 -0500, Geoffrey Hutchison wrote:
> On Feb 23, 2006, at 11:40 AM, Noel O'Boyle wrote:
> 
> > What can I do with a molecule's SSSR or Internal Coordinates if  
> > it's in
> > the following state?
> > ...
> > Are these not accessible from Python/Perl then?
> 
> Guess not. That wasn't intentional. For SSSR, OBRing isn't wrapped,  
> so I'll add that to the SWIG file. I'm also going to add  
> OBSmartsPattern.
> 
> I need to go back and revisit the SWIG documentation about internal  
> coordinates. Certainly the OBInternalCoord class is wrapped, but I  
> seem to remember there were issues about templates -- that you needed  
> to do some renaming to make sure they mapped to valid symbols in the  
> scripting language.
> 
> e.g., std::vector<OBInternalCoord>   ->   vectorInternals
> 
> Cheers,
> -Geoff

Re: [openbabel-scripting] Accessing SSSR or Internal Coordinates from Python

[Geoffrey H. <ge...@ge...>]

On Feb 24, 2006, at 4:19 AM, Noel O'Boyle wrote:

> I'd like to help with this if I can - I think this issue is going to
> occur more than once. Is there some particularly good documentation
> available somewhere on wrapping with SWIG, that can make this all very
> clear to me?


Well, SWIG has a pretty decent manual. I've been living pretty  
bleeding-edge for SWIG, since the C++ support is continually  
improving and I've found periodic bugs in the SWIG releases (e.g.,  
1.3.28 doesn't work, but the current CVS does).

So I download the SWIG CVS: (See the SWIG directory)
http://sourceforge.net/cvs/?group_id=1645

Documentation for SWIG is in SWIG/Doc/Manual/index.html
C++ documentation is in SWIG/Doc/Manual/SWIGPlus.html

There's also a pretty responsive mailing list:
http://lists.sourceforge.net/lists/listinfo/swig-user

I've found a few catches, which is why this is somewhat slow-going:
* Sometimes I'll add in a new header to openbabel.i, and everything  
dies. More recently, I've been carefully adding in #ifndef SWIG /  
#endif  lines in the header to tell SWIG to ignore certain parts of  
the code. This seems to help, since some C++ syntax apparently  
confuses SWIG or simply cannot be wrapped correctly.

* It's not always clear to me what needs to be explicitly added to  
openbabel.i (e.g., this vector issue) and what SWIG figures out for  
itself. In retrospect, the SWIG documentation now makes perfect sense  
-- but I think the scripting language wrappers will be evolving for  
the foreseeable future.

* The current modules are growing pretty large. It's probably going  
to be a good idea to start splitting openbabel.i into multiple pieces  
so that compiling openbabel_python.cpp and openbabel_perl.cpp don't  
take so long. The current file on my disk is ~1.3MB of C++ code.

And of course, I'd be glad to give pointers/tips/feedback to anyone  
willing to help out with the wrappers.
-Geoff