openbabel-scripting

[OpenBabel-scripting] Atom typing via Perl API

[Kieron T. <kr...@so...>]

Greetings,

I am trying to find ways to use the Patty atom typing in OpenBabel so 
that I can assign types for molecular mechanics forcefields. That part 
of the API doesn't appear to be accessible through the Perl hook-in.

Is this because nobody got around to it yet, or because the feature can 
be accessed somehow through the other classes such as OBMol or OBConversion?

Does anyone have any recommendations on how else I might get access to 
the output of the atom typer?

Regards,

Kieron Taylor

Re: [OpenBabel-scripting] Atom typing via Perl API

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

It's because nobody has gotten around to it yet, as you say.

patty.h (at least?) needs to be added to openbabel-perl.i. If you have
a recent version of Swig installed, and you've run configure with
--enable-maintainer-mode (all explained on the "Install source code"
page on the wiki), you can add it yourself, and play around with it.
Otherwise, sit tight for a couple of days, and then check out the
latest source from SVN...

Regards,
    Noel

On 31/01/07, Kieron Taylor <kr...@so...> wrote:
> Greetings,
>
> I am trying to find ways to use the Patty atom typing in OpenBabel so
> that I can assign types for molecular mechanics forcefields. That part
> of the API doesn't appear to be accessible through the Perl hook-in.
>
> Is this because nobody got around to it yet, or because the feature can
> be accessed somehow through the other classes such as OBMol or OBConversion?
>
> Does anyone have any recommendations on how else I might get access to
> the output of the atom typer?
>
> Regards,
>
> Kieron Taylor
>
>
>
> -------------------------------------------------------------------------
> 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
> _______________________________________________
> OpenBabel-scripting mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openbabel-scripting
>

Re: [OpenBabel-scripting] Atom typing via Perl API

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

On Jan 31, 2007, at 5:36 AM, Noel O'Boyle wrote:

> It's because nobody has gotten around to it yet, as you say.
>> I am trying to find ways to use the Patty atom typing in OpenBabel so
>> that I can assign types for molecular mechanics forcefields. That  
>> part
>> of the API doesn't appear to be accessible through the Perl hook-in.

I should point out that Patty isn't actually used by Open Babel  
itself anymore -- I had considered making it deprecated and removing  
it in 3.0.

So it's good to hear that you find it useful and want it to stay. Out  
of curiosity, what force fields do you want? I ask because there's  
some limited support in the 2.1 development tree for MM2, MMFF94, and  
Tripos-like force fields right now. (I don't believe this is  
accessible from the scripting interface yet, and I think the atom  
typing is still incomplete as well.)

Cheers,
-Geoff

Re: [OpenBabel-scripting] Atom typing via Perl API

[Kieron T. <kr...@so...>]

Geoffrey Hutchison wrote:
> 
> On Jan 31, 2007, at 5:36 AM, Noel O'Boyle wrote:
> 
>> It's because nobody has gotten around to it yet, as you say.
>>
>>> I am trying to find ways to use the Patty atom typing in OpenBabel so
>>> that I can assign types for molecular mechanics forcefields. That  part
>>> of the API doesn't appear to be accessible through the Perl hook-in.
> 
> 
> I should point out that Patty isn't actually used by Open Babel  itself 
> anymore -- I had considered making it deprecated and removing  it in 3.0.

Thank you both for your swift responses. I notice the class OBAtomTyper. 
Is this the successor to Patty? Essentially I require an automated 
assignment of atom types according to the rules file in the source 
distribution, the technology that does the job isn't important to me. I 
just found Patty first.

I am going to attempt to extend the Perl module and SWIG parts, but I am 
unfamiliar with a lot of the methodologies used. I will post some code 
patches if I am successful.

> So it's good to hear that you find it useful and want it to stay. Out  
> of curiosity, what force fields do you want? I ask because there's  some 
> limited support in the 2.1 development tree for MM2, MMFF94, and  
> Tripos-like force fields right now. (I don't believe this is  accessible 
> from the scripting interface yet, and I think the atom  typing is still 
> incomplete as well.)

I am looking to assign Dreiding atom types with a view to also using UFF 
which is very similar.

Kieron

Re: [OpenBabel-scripting] Atom typing via Perl API

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

Dear Kieron,

I've reproduced your error message.

It's actually caused by the SetType command, not the Translate
command. You can see this for yourself if you replace the loop text
by:

	my $atom = $obMol->GetAtom($_);
	my $type = $atom->GetType();
	my $newtype = $atom_typer->Translate($type);
	$newtype = $type;
	$atom->SetType($newtype);

This doesn't cause any error message, although it is doing the same
Translate as normal. If you remove the $newtype = $type, the error
messages reappear. It seems that SetType doesn't like the names of the
new types. I'm going to pass this problem onto the C++ whizzes to
figure out why, as I don't think it is a SWIG problem.

Noel

P.S. For the record, the original test code is:
========================
#!/usr/bin/perl -w
#test script to access openBabel's functionality using the perl API

use strict;
use Chemistry::OpenBabel;

my $file_to_read = "test.xyz";
my $obMol = new Chemistry::OpenBabel::OBMol;

my $obConverter = new Chemistry::OpenBabel::OBConversion;

$obConverter->SetInAndOutFormats("xyz","mol2");

$obConverter->ReadFile($obMol,$file_to_read);

my $atom_typer = new Chemistry::OpenBabel::OBTypeTable;

$atom_typer->SetFromType("INT");
$atom_typer->SetToType("DRE");

for (1..$obMol->NumAtoms())
{
	my $atom = $obMol->GetAtom($_);
	my $type = $atom->GetType();
	print $atom->GetAtomicMass."   ".$atom->GetValence."\n";
	my $newtype = $atom_typer->Translate($type);
	#$atom_typer->Translate("INT","DRE");
	#print "Type: $newtype\n";
	$atom->SetType($newtype);
}
if ($obConverter->WriteFile($obMol, "typed_mol.mol2") ) {print
"Writing successful\n";} else {print "OBconversion failed\n";}
========================

On 06/02/07, Kieron Taylor <kr...@so...> wrote:
> Noel O'Boyle wrote:
> > I've applied this change to the development code, and it seems to
> > work, at least in Python. Are you familiar with checking code out of a
> > subversion repository? There are some instructions at:
> >   http://openbabel.sourceforge.net/wiki/Install
> > under "Get latest development code".
> >
> > Noel
> >
>
> Hi Noel,
>
> I've checked out the development branch and tried to use it, but there
> is no apparent change in the output.
>
> Would you mind running my script (attached) with the corresponding data
> file to make sure it's not my local install that's borked?
>
> Just drop the XYZ file into the same directory as the script and run the
> script once you have the Perl module installed.
>
> Thanks,
>
> Kieron
>
>
>
>

Re: [OpenBabel-scripting] Atom typing via Perl API

[Kieron T. <kr...@so...>]

Thanks for your help. For now I will pretend the messages aren't there.

Kieron

Noel O'Boyle wrote:
> Dear Kieron,
> 
> I've reproduced your error message.
> 
> It's actually caused by the SetType command, not the Translate
> command. You can see this for yourself if you replace the loop text
> by:
> 
>     my $atom = $obMol->GetAtom($_);
>     my $type = $atom->GetType();
>     my $newtype = $atom_typer->Translate($type);
>     $newtype = $type;
>     $atom->SetType($newtype);
> 
> This doesn't cause any error message, although it is doing the same
> Translate as normal. If you remove the $newtype = $type, the error
> messages reappear. It seems that SetType doesn't like the names of the
> new types. I'm going to pass this problem onto the C++ whizzes to
> figure out why, as I don't think it is a SWIG problem.
> 
> Noel

Re: [OpenBabel-scripting] Atom typing via Perl API

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

On Feb 7, 2007, at 6:51 AM, Noel O'Boyle wrote:

> It's actually caused by the SetType command, not the Translate
> command.

No, that's certainly not correct. The error message can *only* be  
generated by the Translate command -- that's the only part of the  
code which emits that message.

> 	my $newtype = $atom_typer->Translate($type);
> 	$newtype = $type;
> 	$atom->SetType($newtype);
>
> This doesn't cause any error message, although it is doing the same
> Translate as normal.

I don't know how good Perl is, but I suspect this is an obvious just- 
in-time optimization. It's clear to anyone (e.g. the Perl compiler)  
that the result of the $atom_typer->Translate($type) call is  
immediately thrown away.

The warning comes when the requested type (e.g., from INT) in this  
example, isn't found in the atom type translation table. Let's say,  
for example, you request to translate "Qu". The code has no idea what  
to do, so it leaves the atom type alone, but gives a warning. I felt  
this was a good compromise so we

So if you'd like to see what atom types are getting ignored (and  
generating the warning):

	my $atom = $obMol->GetAtom($_);
	my $type = $atom->GetType();
	my $newtype = $atom_typer->Translate($type);
	print "Requested type: $type Translated type: $newtype\n";
	$atom->SetType($newtype);

Cheers,
-Geoff

Re: [OpenBabel-scripting] Atom typing via Perl API

[Kieron T. <kr...@so...>]

Geoffrey Hutchison wrote:
> 
< snip >
> So if you'd like to see what atom types are getting ignored (and  
> generating the warning):
> 
>     my $atom = $obMol->GetAtom($_);
>     my $type = $atom->GetType();
>     my $newtype = $atom_typer->Translate($type);
>     print "Requested type: $type Translated type: $newtype\n";
>     $atom->SetType($newtype);

Strangely, in the original code that started all this, the error in 
question doesn't appear until I actively call OBConverter's serialising 
routine. ( OBconverter->write )

It then generates one error for each and every atom, none of which have 
particularly exotic atom types.

It seems to me that the conversion operation is somehow invoking an 
additional atom type translation but without passing the atom types 
around. I can only guess that it is detecting the fact that a target 
type has been set. If I have already manually set the new atom types in 
the manner of your code snippet above, the serialisation has those new 
types in spite of the chain of errors that follow.

I hope that helps to clarify things.


Kieron

Re: [OpenBabel-scripting] Atom typing via Perl API

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

On Jan 31, 2007, at 9:51 AM, Kieron Taylor wrote:

> I am looking to assign Dreiding atom types with a view to also  
> using UFF
> which is very similar.

Dreiding atom types should already be available through the  
OBTypeTable class. Use ttab.SetToType("DRE"). Check out data/ 
types.txt -- it's the 14th column.

Of course if you find bugs, please let us know!

Cheers,
-Geoff

Re: [OpenBabel-scripting] Atom typing via Perl API

[Kieron T. <kr...@so...>]

I've written some working code for assigning atom types for the various 
forcefields by Perl API. It's pretty simple, but there are differences 
from the v2.02 API.

I get the following error with each atom, even though it performs the 
appropriate transformation. I am uncertain what it is trying to do that 
fails. Error:
==============================
*** Open Babel Warning  in Translate
   Cannot perform atom type translation: table cannot find requested types.

I have a feeling I may be trying to get it to do the translation twice.

Line 23 of my code $newtype = $atom_typer->Translate($type); does not 
match the API documentation which claims to return Boolean from the 
Translate call, rather than the new atom type.

Here's the code:
---------------
#!/usr/bin/perl

use strict;
use Chemistry::OpenBabel;

my $obMol = new Chemistry::OpenBabel::OBMol;
my $obConverter = new Chemistry::OpenBabel::OBConversion;

$obConverter->SetInAndOutFormats("xyz","mol2");
$obConverter->ReadFile($obMol,"file.xyz");

my $atom_typer = new Chemistry::OpenBabel::OBTypeTable;

$atom_typer->SetFromType("INT");
$atom_typer->SetToType("DRE");
# DRE = Dreiding, INT = internal, others found in
# OpenBabel/data/types.txt

for (1..$obMol->NumAtoms() )
{
	my $atom = $obMol->GetAtom($_);
	my $type = $atom->GetType();
	my $newtype = $atom_typer->Translate($type);
	$atom->SetType($newtype);
}
$obConverter->WriteFile($obMol, "typed_molecule.mol2") ;

----end-of-Perl---------

Any ideas what I'm missing here?

Thanks,

Kieron

Re: [OpenBabel-scripting] Atom typing via Perl API

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

It might be unrelated to your problem, but have you set the
environment variable BABEL_DATADIR to the 'data' directory?

On 05/02/07, Kieron Taylor <kr...@so...> wrote:
> I've written some working code for assigning atom types for the various
> forcefields by Perl API. It's pretty simple, but there are differences
> from the v2.02 API.
>
> I get the following error with each atom, even though it performs the
> appropriate transformation. I am uncertain what it is trying to do that
> fails. Error:
> ==============================
> *** Open Babel Warning  in Translate
>    Cannot perform atom type translation: table cannot find requested types.
>
> I have a feeling I may be trying to get it to do the translation twice.
>
> Line 23 of my code $newtype = $atom_typer->Translate($type); does not
> match the API documentation which claims to return Boolean from the
> Translate call, rather than the new atom type.
>
> Here's the code:
> ---------------
> #!/usr/bin/perl
>
> use strict;
> use Chemistry::OpenBabel;
>
> my $obMol = new Chemistry::OpenBabel::OBMol;
> my $obConverter = new Chemistry::OpenBabel::OBConversion;
>
> $obConverter->SetInAndOutFormats("xyz","mol2");
> $obConverter->ReadFile($obMol,"file.xyz");
>
> my $atom_typer = new Chemistry::OpenBabel::OBTypeTable;
>
> $atom_typer->SetFromType("INT");
> $atom_typer->SetToType("DRE");
> # DRE = Dreiding, INT = internal, others found in
> # OpenBabel/data/types.txt
>
> for (1..$obMol->NumAtoms() )
> {
>         my $atom = $obMol->GetAtom($_);
>         my $type = $atom->GetType();
>         my $newtype = $atom_typer->Translate($type);
>         $atom->SetType($newtype);
> }
> $obConverter->WriteFile($obMol, "typed_molecule.mol2") ;
>
> ----end-of-Perl---------
>
> Any ideas what I'm missing here?
>
> Thanks,
>
> Kieron
>
>
>
> -------------------------------------------------------------------------
> 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
> _______________________________________________
> OpenBabel-scripting mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openbabel-scripting
>

Re: [OpenBabel-scripting] Atom typing via Perl API

[Kieron T. <kr...@so...>]

Noel O'Boyle wrote:
> It might be unrelated to your problem, but have you set the
> environment variable BABEL_DATADIR to the 'data' directory?

Nice try but no banana. The error is still forthcoming. I hasten to add 
that the atom types are actually assigned and serialised, in spite of 
the error. This means that it is finding the appropriate data files (I 
hope).

Thanks anyway.

Kieron

> 
> On 05/02/07, Kieron Taylor <kr...@so...> wrote:
> 
>> I've written some working code for assigning atom types for the various
>> forcefields by Perl API. It's pretty simple, but there are differences
>> from the v2.02 API.
>>
>> I get the following error with each atom, even though it performs the
>> appropriate transformation. I am uncertain what it is trying to do that
>> fails. Error:
>> ==============================
>> *** Open Babel Warning  in Translate
>>    Cannot perform atom type translation: table cannot find requested 
>> types.
>>
>> I have a feeling I may be trying to get it to do the translation twice.
>>
>> Line 23 of my code $newtype = $atom_typer->Translate($type); does not
>> match the API documentation which claims to return Boolean from the
>> Translate call, rather than the new atom type.
>>
>> Here's the code:
>> ---------------
>> #!/usr/bin/perl
>>
>> use strict;
>> use Chemistry::OpenBabel;
>>
>> my $obMol = new Chemistry::OpenBabel::OBMol;
>> my $obConverter = new Chemistry::OpenBabel::OBConversion;
>>
>> $obConverter->SetInAndOutFormats("xyz","mol2");
>> $obConverter->ReadFile($obMol,"file.xyz");
>>
>> my $atom_typer = new Chemistry::OpenBabel::OBTypeTable;
>>
>> $atom_typer->SetFromType("INT");
>> $atom_typer->SetToType("DRE");
>> # DRE = Dreiding, INT = internal, others found in
>> # OpenBabel/data/types.txt
>>
>> for (1..$obMol->NumAtoms() )
>> {
>>         my $atom = $obMol->GetAtom($_);
>>         my $type = $atom->GetType();
>>         my $newtype = $atom_typer->Translate($type);
>>         $atom->SetType($newtype);
>> }
>> $obConverter->WriteFile($obMol, "typed_molecule.mol2") ;
>>
>> ----end-of-Perl---------
>>
>> Any ideas what I'm missing here?
>>
>> Thanks,
>>
>> Kieron
>>
> 

Re: [OpenBabel-scripting] Atom typing via Perl API

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

I think I know the problem. When the SWIG wrappers are generated, the
following error appears (copied by hand):
"""
data.h: Overloaded Translate(std::string const &) is shadowed by
Translate(std::string &, std::string const &) at line 245.
"""

I'll have to read up a bit on this, but the bottom line is that you
only have one of the above two functions as Swig thinks they are too
similar to include both. This explains why you're getting the wrong
return value as you're actually calling the wrong function. There's
sure to be a way around this. I'll look into it, if Geoff doesn't get
there first.

Noel

On 05/02/07, Kieron Taylor <kr...@so...> wrote:
> Noel O'Boyle wrote:
> > It might be unrelated to your problem, but have you set the
> > environment variable BABEL_DATADIR to the 'data' directory?
>
> Nice try but no banana. The error is still forthcoming. I hasten to add
> that the atom types are actually assigned and serialised, in spite of
> the error. This means that it is finding the appropriate data files (I
> hope).
>
> Thanks anyway.
>
> Kieron
>
> >
> > On 05/02/07, Kieron Taylor <kr...@so...> wrote:
> >
> >> I've written some working code for assigning atom types for the various
> >> forcefields by Perl API. It's pretty simple, but there are differences
> >> from the v2.02 API.
> >>
> >> I get the following error with each atom, even though it performs the
> >> appropriate transformation. I am uncertain what it is trying to do that
> >> fails. Error:
> >> ==============================
> >> *** Open Babel Warning  in Translate
> >>    Cannot perform atom type translation: table cannot find requested
> >> types.
> >>
> >> I have a feeling I may be trying to get it to do the translation twice.
> >>
> >> Line 23 of my code $newtype = $atom_typer->Translate($type); does not
> >> match the API documentation which claims to return Boolean from the
> >> Translate call, rather than the new atom type.
> >>
> >> Here's the code:
> >> ---------------
> >> #!/usr/bin/perl
> >>
> >> use strict;
> >> use Chemistry::OpenBabel;
> >>
> >> my $obMol = new Chemistry::OpenBabel::OBMol;
> >> my $obConverter = new Chemistry::OpenBabel::OBConversion;
> >>
> >> $obConverter->SetInAndOutFormats("xyz","mol2");
> >> $obConverter->ReadFile($obMol,"file.xyz");
> >>
> >> my $atom_typer = new Chemistry::OpenBabel::OBTypeTable;
> >>
> >> $atom_typer->SetFromType("INT");
> >> $atom_typer->SetToType("DRE");
> >> # DRE = Dreiding, INT = internal, others found in
> >> # OpenBabel/data/types.txt
> >>
> >> for (1..$obMol->NumAtoms() )
> >> {
> >>         my $atom = $obMol->GetAtom($_);
> >>         my $type = $atom->GetType();
> >>         my $newtype = $atom_typer->Translate($type);
> >>         $atom->SetType($newtype);
> >> }
> >> $obConverter->WriteFile($obMol, "typed_molecule.mol2") ;
> >>
> >> ----end-of-Perl---------
> >>
> >> Any ideas what I'm missing here?
> >>
> >> Thanks,
> >>
> >> Kieron
> >>
> >
>
>
>
>
> -------------------------------------------------------------------------
> 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
> _______________________________________________
> OpenBabel-scripting mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openbabel-scripting
>

Re: [OpenBabel-scripting] Atom typing via Perl API

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

The reason these are shadowed is due to the following statement in
openbabel-perl.i:
"""
%apply std::string &OUTPUT  {std::string &to};
"""

This causes the &to in the function header of Translate(std::string
&to, std::string const &from) to be removed from the parameter list,
and set as a return value instead, and this makes the two functions
equivalent from the point of view of Swig.

Geoff, does this line serve any useful purpose? I'll remove it
otherwise. AFAIK, it's only possible to set the return types to
integers and floats, not std::strings, so I don't think this line does
anything helpful in any case. The relevant SWIG section is:
   http://www.swig.org/Doc1.3/Arguments.html#Arguments_nn5

Noel

On 05/02/07, Noel O'Boyle <bao...@gm...> wrote:
> I think I know the problem. When the SWIG wrappers are generated, the
> following error appears (copied by hand):
> """
> data.h: Overloaded Translate(std::string const &) is shadowed by
> Translate(std::string &, std::string const &) at line 245.
> """
>
> I'll have to read up a bit on this, but the bottom line is that you
> only have one of the above two functions as Swig thinks they are too
> similar to include both. This explains why you're getting the wrong
> return value as you're actually calling the wrong function. There's
> sure to be a way around this. I'll look into it, if Geoff doesn't get
> there first.
>
> Noel
>
> On 05/02/07, Kieron Taylor <kr...@so...> wrote:
> > Noel O'Boyle wrote:
> > > It might be unrelated to your problem, but have you set the
> > > environment variable BABEL_DATADIR to the 'data' directory?
> >
> > Nice try but no banana. The error is still forthcoming. I hasten to add
> > that the atom types are actually assigned and serialised, in spite of
> > the error. This means that it is finding the appropriate data files (I
> > hope).
> >
> > Thanks anyway.
> >
> > Kieron
> >
> > >
> > > On 05/02/07, Kieron Taylor <kr...@so...> wrote:
> > >
> > >> I've written some working code for assigning atom types for the various
> > >> forcefields by Perl API. It's pretty simple, but there are differences
> > >> from the v2.02 API.
> > >>
> > >> I get the following error with each atom, even though it performs the
> > >> appropriate transformation. I am uncertain what it is trying to do that
> > >> fails. Error:
> > >> ==============================
> > >> *** Open Babel Warning  in Translate
> > >>    Cannot perform atom type translation: table cannot find requested
> > >> types.
> > >>
> > >> I have a feeling I may be trying to get it to do the translation twice.
> > >>
> > >> Line 23 of my code $newtype = $atom_typer->Translate($type); does not
> > >> match the API documentation which claims to return Boolean from the
> > >> Translate call, rather than the new atom type.
> > >>
> > >> Here's the code:
> > >> ---------------
> > >> #!/usr/bin/perl
> > >>
> > >> use strict;
> > >> use Chemistry::OpenBabel;
> > >>
> > >> my $obMol = new Chemistry::OpenBabel::OBMol;
> > >> my $obConverter = new Chemistry::OpenBabel::OBConversion;
> > >>
> > >> $obConverter->SetInAndOutFormats("xyz","mol2");
> > >> $obConverter->ReadFile($obMol,"file.xyz");
> > >>
> > >> my $atom_typer = new Chemistry::OpenBabel::OBTypeTable;
> > >>
> > >> $atom_typer->SetFromType("INT");
> > >> $atom_typer->SetToType("DRE");
> > >> # DRE = Dreiding, INT = internal, others found in
> > >> # OpenBabel/data/types.txt
> > >>
> > >> for (1..$obMol->NumAtoms() )
> > >> {
> > >>         my $atom = $obMol->GetAtom($_);
> > >>         my $type = $atom->GetType();
> > >>         my $newtype = $atom_typer->Translate($type);
> > >>         $atom->SetType($newtype);
> > >> }
> > >> $obConverter->WriteFile($obMol, "typed_molecule.mol2") ;
> > >>
> > >> ----end-of-Perl---------
> > >>
> > >> Any ideas what I'm missing here?
> > >>
> > >> Thanks,
> > >>
> > >> Kieron
> > >>
> > >
> >
> >
> >
> >
> > -------------------------------------------------------------------------
> > 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
> > _______________________________________________
> > OpenBabel-scripting mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/openbabel-scripting
> >
>

Re: [OpenBabel-scripting] Atom typing via Perl API

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

I've applied this change to the development code, and it seems to
work, at least in Python. Are you familiar with checking code out of a
subversion repository? There are some instructions at:
   http://openbabel.sourceforge.net/wiki/Install
under "Get latest development code".

Noel

On 05/02/07, Noel O'Boyle <bao...@gm...> wrote:
> The reason these are shadowed is due to the following statement in
> openbabel-perl.i:
> """
> %apply std::string &OUTPUT  {std::string &to};
> """
>
> This causes the &to in the function header of Translate(std::string
> &to, std::string const &from) to be removed from the parameter list,
> and set as a return value instead, and this makes the two functions
> equivalent from the point of view of Swig.
>
> Geoff, does this line serve any useful purpose? I'll remove it
> otherwise. AFAIK, it's only possible to set the return types to
> integers and floats, not std::strings, so I don't think this line does
> anything helpful in any case. The relevant SWIG section is:
>    http://www.swig.org/Doc1.3/Arguments.html#Arguments_nn5
>
> Noel
>
> On 05/02/07, Noel O'Boyle <bao...@gm...> wrote:
> > I think I know the problem. When the SWIG wrappers are generated, the
> > following error appears (copied by hand):
> > """
> > data.h: Overloaded Translate(std::string const &) is shadowed by
> > Translate(std::string &, std::string const &) at line 245.
> > """
> >
> > I'll have to read up a bit on this, but the bottom line is that you
> > only have one of the above two functions as Swig thinks they are too
> > similar to include both. This explains why you're getting the wrong
> > return value as you're actually calling the wrong function. There's
> > sure to be a way around this. I'll look into it, if Geoff doesn't get
> > there first.
> >
> > Noel
> >
> > On 05/02/07, Kieron Taylor <kr...@so...> wrote:
> > > Noel O'Boyle wrote:
> > > > It might be unrelated to your problem, but have you set the
> > > > environment variable BABEL_DATADIR to the 'data' directory?
> > >
> > > Nice try but no banana. The error is still forthcoming. I hasten to add
> > > that the atom types are actually assigned and serialised, in spite of
> > > the error. This means that it is finding the appropriate data files (I
> > > hope).
> > >
> > > Thanks anyway.
> > >
> > > Kieron
> > >
> > > >
> > > > On 05/02/07, Kieron Taylor <kr...@so...> wrote:
> > > >
> > > >> I've written some working code for assigning atom types for the various
> > > >> forcefields by Perl API. It's pretty simple, but there are differences
> > > >> from the v2.02 API.
> > > >>
> > > >> I get the following error with each atom, even though it performs the
> > > >> appropriate transformation. I am uncertain what it is trying to do that
> > > >> fails. Error:
> > > >> ==============================
> > > >> *** Open Babel Warning  in Translate
> > > >>    Cannot perform atom type translation: table cannot find requested
> > > >> types.
> > > >>
> > > >> I have a feeling I may be trying to get it to do the translation twice.
> > > >>
> > > >> Line 23 of my code $newtype = $atom_typer->Translate($type); does not
> > > >> match the API documentation which claims to return Boolean from the
> > > >> Translate call, rather than the new atom type.
> > > >>
> > > >> Here's the code:
> > > >> ---------------
> > > >> #!/usr/bin/perl
> > > >>
> > > >> use strict;
> > > >> use Chemistry::OpenBabel;
> > > >>
> > > >> my $obMol = new Chemistry::OpenBabel::OBMol;
> > > >> my $obConverter = new Chemistry::OpenBabel::OBConversion;
> > > >>
> > > >> $obConverter->SetInAndOutFormats("xyz","mol2");
> > > >> $obConverter->ReadFile($obMol,"file.xyz");
> > > >>
> > > >> my $atom_typer = new Chemistry::OpenBabel::OBTypeTable;
> > > >>
> > > >> $atom_typer->SetFromType("INT");
> > > >> $atom_typer->SetToType("DRE");
> > > >> # DRE = Dreiding, INT = internal, others found in
> > > >> # OpenBabel/data/types.txt
> > > >>
> > > >> for (1..$obMol->NumAtoms() )
> > > >> {
> > > >>         my $atom = $obMol->GetAtom($_);
> > > >>         my $type = $atom->GetType();
> > > >>         my $newtype = $atom_typer->Translate($type);
> > > >>         $atom->SetType($newtype);
> > > >> }
> > > >> $obConverter->WriteFile($obMol, "typed_molecule.mol2") ;
> > > >>
> > > >> ----end-of-Perl---------
> > > >>
> > > >> Any ideas what I'm missing here?
> > > >>
> > > >> Thanks,
> > > >>
> > > >> Kieron
> > > >>
> > > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------------------------
> > > 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
> > > _______________________________________________
> > > OpenBabel-scripting mailing list
> > > Ope...@li...
> > > https://lists.sourceforge.net/lists/listinfo/openbabel-scripting
> > >
> >
>

Re: [OpenBabel-scripting] Atom typing via Perl API

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

On Feb 5, 2007, at 11:16 AM, Noel O'Boyle wrote:

> Geoff, does this line serve any useful purpose? I'll remove it
> otherwise.

It did at one point -- it was a contributed change before I added the  
alternate C++ function:

       //! Translate atom types
       //! \return the translated atom type, or an empty string if  
not possible
       std::string Translate(const std::string &from);

Sorry if I forgot to remove the SWIG workaround.

Thanks,
-Geoff