You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(8) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(21) |
Feb
(20) |
Mar
(40) |
Apr
(38) |
May
(23) |
Jun
(45) |
Jul
(50) |
Aug
(31) |
Sep
(43) |
Oct
(25) |
Nov
(6) |
Dec
(56) |
2003 |
Jan
(54) |
Feb
(23) |
Mar
(23) |
Apr
(24) |
May
(19) |
Jun
(49) |
Jul
(8) |
Aug
(22) |
Sep
(40) |
Oct
(43) |
Nov
(131) |
Dec
(17) |
2004 |
Jan
(79) |
Feb
(110) |
Mar
(52) |
Apr
(42) |
May
(42) |
Jun
(25) |
Jul
(25) |
Aug
(48) |
Sep
(17) |
Oct
(35) |
Nov
(24) |
Dec
(24) |
2005 |
Jan
(50) |
Feb
(37) |
Mar
(33) |
Apr
(17) |
May
(47) |
Jun
(50) |
Jul
(40) |
Aug
(72) |
Sep
(42) |
Oct
(36) |
Nov
(109) |
Dec
(41) |
2006 |
Jan
(33) |
Feb
(50) |
Mar
(65) |
Apr
(54) |
May
(31) |
Jun
(31) |
Jul
(19) |
Aug
(19) |
Sep
(4) |
Oct
(16) |
Nov
(61) |
Dec
(20) |
2007 |
Jan
(24) |
Feb
(40) |
Mar
(15) |
Apr
(25) |
May
(23) |
Jun
(26) |
Jul
(53) |
Aug
(53) |
Sep
(53) |
Oct
(20) |
Nov
(74) |
Dec
(39) |
2008 |
Jan
(67) |
Feb
(26) |
Mar
(28) |
Apr
(47) |
May
(96) |
Jun
(49) |
Jul
(73) |
Aug
(19) |
Sep
(52) |
Oct
(61) |
Nov
(41) |
Dec
(40) |
2009 |
Jan
(47) |
Feb
(53) |
Mar
(79) |
Apr
(64) |
May
(41) |
Jun
(133) |
Jul
(49) |
Aug
(39) |
Sep
(18) |
Oct
(55) |
Nov
(76) |
Dec
(27) |
2010 |
Jan
(48) |
Feb
(39) |
Mar
(66) |
Apr
(35) |
May
(28) |
Jun
(70) |
Jul
(54) |
Aug
(74) |
Sep
(60) |
Oct
(76) |
Nov
(116) |
Dec
(53) |
2011 |
Jan
(68) |
Feb
(67) |
Mar
(116) |
Apr
(63) |
May
(32) |
Jun
(78) |
Jul
(76) |
Aug
(56) |
Sep
(62) |
Oct
(59) |
Nov
(78) |
Dec
(104) |
2012 |
Jan
(53) |
Feb
(57) |
Mar
(79) |
Apr
(82) |
May
(91) |
Jun
(46) |
Jul
(89) |
Aug
(66) |
Sep
(38) |
Oct
(106) |
Nov
(50) |
Dec
(99) |
2013 |
Jan
(48) |
Feb
(64) |
Mar
(66) |
Apr
(85) |
May
(51) |
Jun
(94) |
Jul
(44) |
Aug
(55) |
Sep
(28) |
Oct
(108) |
Nov
(139) |
Dec
(100) |
2014 |
Jan
(54) |
Feb
(57) |
Mar
(37) |
Apr
(47) |
May
(86) |
Jun
(30) |
Jul
(67) |
Aug
(7) |
Sep
(19) |
Oct
(44) |
Nov
(38) |
Dec
(17) |
2015 |
Jan
(14) |
Feb
(29) |
Mar
(40) |
Apr
(42) |
May
(35) |
Jun
(34) |
Jul
(20) |
Aug
(12) |
Sep
(28) |
Oct
(30) |
Nov
(52) |
Dec
(7) |
2016 |
Jan
(16) |
Feb
(16) |
Mar
(46) |
Apr
(17) |
May
(23) |
Jun
(12) |
Jul
(45) |
Aug
(32) |
Sep
(36) |
Oct
(29) |
Nov
(64) |
Dec
(27) |
2017 |
Jan
(30) |
Feb
(43) |
Mar
(55) |
Apr
(21) |
May
(43) |
Jun
(51) |
Jul
(22) |
Aug
(34) |
Sep
(27) |
Oct
(48) |
Nov
(38) |
Dec
(12) |
2018 |
Jan
(42) |
Feb
(29) |
Mar
(21) |
Apr
(10) |
May
(13) |
Jun
(29) |
Jul
(32) |
Aug
(17) |
Sep
(9) |
Oct
(9) |
Nov
(39) |
Dec
(41) |
2019 |
Jan
(32) |
Feb
(12) |
Mar
(13) |
Apr
(41) |
May
(19) |
Jun
(10) |
Jul
(6) |
Aug
(30) |
Sep
(51) |
Oct
(27) |
Nov
(34) |
Dec
(16) |
2020 |
Jan
(9) |
Feb
(13) |
Mar
(65) |
Apr
(39) |
May
(14) |
Jun
(6) |
Jul
(10) |
Aug
(4) |
Sep
(1) |
Oct
(7) |
Nov
(1) |
Dec
(7) |
2021 |
Jan
(3) |
Feb
(6) |
Mar
(4) |
Apr
(11) |
May
(3) |
Jun
|
Jul
(6) |
Aug
(26) |
Sep
(4) |
Oct
(15) |
Nov
(4) |
Dec
(13) |
2022 |
Jan
(7) |
Feb
(8) |
Mar
(6) |
Apr
(3) |
May
(9) |
Jun
(19) |
Jul
(8) |
Aug
(2) |
Sep
|
Oct
(2) |
Nov
(2) |
Dec
(3) |
2023 |
Jan
(12) |
Feb
(13) |
Mar
(10) |
Apr
(5) |
May
(5) |
Jun
(8) |
Jul
(5) |
Aug
(10) |
Sep
(2) |
Oct
(1) |
Nov
(4) |
Dec
(1) |
2024 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
From: Geoff H. <ge...@ge...> - 2005-01-07 14:17:22
|
On Jan 7, 2005, at 5:00 AM, Fabien Fontaine wrote: > Yes, obgrep has some problems to read xyz files and I don't know why. No, there aren't problems reading the XYZ files. The current XYZ code is extremely verbose about warnings, particularly if there are stray empty lines at the end of the file. Don't worry about it much--the files are read correctly. (Otherwise, it would never get through the roundtrip testing and be released.) The warnings will shortly be piped into error logging code that will let you decide how much debugging information/warnings you (or an external program) wants to see. But Fabien was exactly correct -- obgrep was returning the correct information. "CCC" represents three connected aliphatic carbons, which don't exist in your imidazole file. Cheers, -Geoff |
From: Fabien F. <ffo...@im...> - 2005-01-07 09:55:51
|
Yes, obgrep has some problems to read xyz files and I don't know why. I'am sorry I don't have the time to look at it know but what you should do for the moment is: #convert the xyz file to sdf >babel imidazole_verytight.xyz imidazole_verytight.sdf #run obgrep >obgrep -c CCC imidazole_verytight.sdf By the way, this line should return 0 because imidazole don't have 3 consecutive aliphatic carbons. Try this instead >obgrep -c '[#6][#6][#7]' imidazole_verytight.sdf >obgrep -c ccn imidazole_verytight.sdf Cheers, Fabien Dr Seth OLSEN wrote: > I'm training myself on obgrep. I'm getting an error and I don't know what's causing it or how to fix it and I'd like to understand what's going on. I enter the line > > obgrep -c CCC imidazole_verytight.xyz > > on the following file (imidazole_verytight.xyz): > > 9 > scf done: -224.832788 > N 0.000000 0.000000 0.000000 > C 0.000000 0.000000 1.371441 > C 1.243821 0.000000 -0.344335 > C 1.268671 0.000000 1.842053 > N 2.066646 -0.000002 0.726001 > H 3.058941 -0.000003 0.704995 > H 1.612111 0.000000 -1.349873 > H -0.911499 0.000001 1.931190 > H 1.665738 0.000000 2.834137 > > and I get the following error: > WARNING: Problems reading an XYZ file, method 'bool ReadXYZ(istream &,OBMol &,const char *)' > Could not read the first line, file error. > 0 > > According to my (rudimentary) understanding of SMARTS, it seems that this molecule should fit the pattern. Can someone help me understand what's causing this error? > > Cheers, > > Seth Olsen > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms > > Dr Seth Olsen, PhD > Postdoctoral Fellow, Computational Systems Biology Group > Centre for Computational Molecular Science > Chemistry Building, > The University of Queensland > Qld 4072, Brisbane, Australia > > tel (617) 33653732 > fax (617) 33654623 > email: s.o...@uq... > Web: www.ccms.uq.edu.au > > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms > > > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > OpenBabel-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbabel-discuss > -- Fabien Fontaine Engineer in Biotechnology Computer-Assisted Drug Design Laboratory Research Group on Biomedical Informatics (GRIB) - IMIM/UPF Passeig Maritim de la Barceloneta, 37-49 Tel: +34 93 224 08 94 E-08003 Barcelona (Spain) Fax: +34 93 224 08 75 e-mail: ffo...@im... http://www.imim.es/grib |
From: Dr S. O. <s.o...@uq...> - 2005-01-07 06:27:16
|
I'm training myself on obgrep. I'm getting an error and I don't know what's causing it or how to fix it and I'd like to understand what's going on. I enter the line obgrep -c CCC imidazole_verytight.xyz on the following file (imidazole_verytight.xyz): 9 scf done: -224.832788 N 0.000000 0.000000 0.000000 C 0.000000 0.000000 1.371441 C 1.243821 0.000000 -0.344335 C 1.268671 0.000000 1.842053 N 2.066646 -0.000002 0.726001 H 3.058941 -0.000003 0.704995 H 1.612111 0.000000 -1.349873 H -0.911499 0.000001 1.931190 H 1.665738 0.000000 2.834137 and I get the following error: WARNING: Problems reading an XYZ file, method 'bool ReadXYZ(istream &,OBMol &,const char *)' Could not read the first line, file error. 0 According to my (rudimentary) understanding of SMARTS, it seems that this molecule should fit the pattern. Can someone help me understand what's causing this error? Cheers, Seth Olsen ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms Dr Seth Olsen, PhD Postdoctoral Fellow, Computational Systems Biology Group Centre for Computational Molecular Science Chemistry Building, The University of Queensland Qld 4072, Brisbane, Australia tel (617) 33653732 fax (617) 33654623 email: s.o...@uq... Web: www.ccms.uq.edu.au ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms |
From: Li D. <lid...@gm...> - 2005-01-07 04:00:10
|
I think i have got the problem, the new babel execute file use the old libopenbabel.so.0 Cheers, Li Daobing (sid)nichloas@ldblab:7:~$ babel -v Open Babel 1.100.2 -- Jan 7 2005 -- 11:12:13 (sid)nichloas@ldblab:8:~$ babel -H | grep txyz txyz -- Tinker XYZ file (sid)nichloas@ldblab:9:~$ ldd `which babel` libopenbabel.so.0 => /usr/lib/libopenbabel.so.0 (0xb7e80000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb7dc5000) libm.so.6 => /lib/tls/libm.so.6 (0xb7da3000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7d9a000) libc.so.6 => /lib/tls/libc.so.6 (0xb7c66000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fea000) (sid)nichloas@ldblab:10:~$ export LD_LIBRARY_PATH=/usr/local/lib (sid)nichloas@ldblab:11:~$ ldd `which babel` libopenbabel.so.0 => /usr/local/lib/libopenbabel.so.0 (0xb7e96000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb7dc1000) libm.so.6 => /lib/tls/libm.so.6 (0xb7d9f000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7d96000) libc.so.6 => /lib/tls/libc.so.6 (0xb7c62000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fea000) (sid)nichloas@ldblab:12:~$ babel -H | grep txyz txyz -- Tinker XYZ file txyz -- Tinker XYZ file On Thu, 6 Jan 2005 14:57:28 -0500, Geoff Hutchison <ge...@ge...> wrote: > > On Jan 6, 2005, at 1:54 AM, Li Daobing wrote: > > > after i recompile, i find that it still can't recongize the txyz file > > format. I know that the ReadTinker is not good enough and not finished > > yet. but it can't recongize the file format make me much depressed. > > Unfortunately, the process of adding new file formats can be difficult > right now. We're working on a new conversion framework that should make > this much easier. > > Right now, I think your problem is that you are either calling the old > babel executable (e.g., in /usr/local/bin rather than the current > directory via ./babel) or for some reason, babel is reverting to the > extension table that was previously installed (probably in > /usr/local/share). You try calling "./babel" or checking your PATH > environment variable. If that doesn't work, try running "make install" > and see if that helps. > > But reading Tinker XYZ would be nice--and all contributions are > gratefully appreciated! Thanks and please let us know if you have > further questions! > > Cheers, > -Geoff > > |
From: Geoff H. <ge...@ge...> - 2005-01-06 19:57:36
|
On Jan 6, 2005, at 1:54 AM, Li Daobing wrote: > after i recompile, i find that it still can't recongize the txyz file > format. I know that the ReadTinker is not good enough and not finished > yet. but it can't recongize the file format make me much depressed. Unfortunately, the process of adding new file formats can be difficult right now. We're working on a new conversion framework that should make this much easier. Right now, I think your problem is that you are either calling the old babel executable (e.g., in /usr/local/bin rather than the current directory via ./babel) or for some reason, babel is reverting to the extension table that was previously installed (probably in /usr/local/share). You try calling "./babel" or checking your PATH environment variable. If that doesn't work, try running "make install" and see if that helps. But reading Tinker XYZ would be nice--and all contributions are gratefully appreciated! Thanks and please let us know if you have further questions! Cheers, -Geoff |
From: <dr...@ma...> - 2005-01-06 09:22:06
|
Here is a link to a Daylight tutorial on SMARTS http://www.daylight.com/meetings/summerschool01/course/basics/smarts.html > Message: 5 > From: Dr Seth OLSEN <s.o...@uq...> > To: ope...@li... > Date: Thu, 06 Jan 2005 10:43:37 +1000 > Subject: [Open Babel] pattern matching for obgrep and obfit > > > Where can I find a good review of the pattern matching rules used for obgrep and obfit? > > Cheers, > > Seth Olsen > > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms > > Dr Seth Olsen, PhD > Postdoctoral Fellow, Computational Systems Biology Group > Centre for Computational Molecular Science > Chemistry Building, > The University of Queensland > Qld 4072, Brisbane, Australia > > tel (617) 33653732 > fax (617) 33654623 > email: s.o...@uq... > Web: www.ccms.uq.edu.au > > ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms > > > > > > > > --__--__-- > > _______________________________________________ > OpenBabel-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbabel-discuss > > > End of OpenBabel-discuss Digest > -- Whatever you Wanadoo: http://www.wanadoo.co.uk/time/ This email has been checked for most known viruses - find out more at: http://www.wanadoo.co.uk/help/id/7098.htm |
From: Li D. <lid...@gm...> - 2005-01-06 06:54:45
|
Hello, I am a user of openbabel, i want to add Tinker xyz read support for openbabel, but I failed. you can see the diff file in attachment. This is the list what i did: 1. add a function ReadTinker in tinker.cpp 2. modify extable.txt and regenerate extable.h 3. modify fileformat.h and fireformat.cpp after i recompile, i find that it still can't recongize the txyz file format. I know that the ReadTinker is not good enough and not finished yet. but it can't recongize the file format make me much depressed. $ babel -v Open Babel 1.100.2 -- Jan 6 2005 -- 14:03:49 $ babel -itxyz 1.txyz 1.pdb babel: cannot read input format! Open Babel 1.100.2 -- Jan 6 2005 -- 14:03:49 Usage: babel [-i<input-type>] <name> [-o<output-type>] <name> Try `babel -H' for more information. Best Regards Li Daobing |
From: Dr S. O. <s.o...@uq...> - 2005-01-06 00:43:49
|
Where can I find a good review of the pattern matching rules used for obgrep and obfit? Cheers, Seth Olsen ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms Dr Seth Olsen, PhD Postdoctoral Fellow, Computational Systems Biology Group Centre for Computational Molecular Science Chemistry Building, The University of Queensland Qld 4072, Brisbane, Australia tel (617) 33653732 fax (617) 33654623 email: s.o...@uq... Web: www.ccms.uq.edu.au ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms |
From: Geoff H. <ge...@ge...> - 2005-01-05 16:40:51
|
Sounds like a cool project. Unfortunately, the pgfoundry.org website seems to be down right now, but the link should be up within the next day or two on the Open Babel website. Cheers, -Geoff On Jan 5, 2005, at 9:09 AM, ern...@ba... wrote: > Hello, > > i would like to request an additional entry to the 'Projects using > OpenBabel' list on openbabel.sourceforge.net. > > pgchem::tigress -> http://pgfoundry.org/projects/pgchem/ |
From: <ern...@ba...> - 2005-01-05 14:09:46
|
Hello, i would like to request an additional entry to the 'Projects using OpenBabel' list on openbabel.sourceforge.net. pgchem::tigress -> http://pgfoundry.org/projects/pgchem/ pgchem::tigress is a chemoinformatics extension to the PostgreSQL DBMS. It enables PostgreSQL to store, retrieve and search chemical datatypes, i.e. Molecules for the time being, by pure SQL statements. It uses checkmol/matchmol and OpenBabel. License is GPL. regards, Ernst-Georg Schmid |
From: Geoff H. <ge...@ge...> - 2005-01-05 05:10:36
|
> babel: error while loading shared libraries: libopenbabel.so.0: cannot > open shared object file: No such file or directory > > However, I have checked and the required library is in /usr/local/lib. Either make sure the LD_LIBRARY_PATH is set to include /usr/local/lib or edit /etc/ld.so.conf and use ldconfig The problem is that by default, many Linux distributions do not include /usr/local/lib in the shared library search paths. Cheers, -Geoff |
From: Dr S. O. <s.o...@uq...> - 2005-01-05 04:33:41
|
Hello All, I'm trying to compile OpenBabel on a P4 machine running Fedora Core 2. After making the compilation and installation, I get the following error when trying to use the program: babel: error while loading shared libraries: libopenbabel.so.0: cannot open shared object file: No such file or directory However, I have checked and the required library is in /usr/local/lib. The directory is in the path and should be seen. The permissions also appear to be set right, so the file (and the link destination libopenbabel.so.0.0.0) should be readable. Can anyone tell me how to fix this problem? Cheers, Seth Olsen ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms Dr Seth Olsen, PhD Postdoctoral Fellow, Computational Systems Biology Group Centre for Computational Molecular Science Chemistry Building, The University of Queensland Qld 4072, Brisbane, Australia tel (617) 33653732 fax (617) 33654623 email: s.o...@uq... Web: www.ccms.uq.edu.au ccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccmsccms |
From: Chris M. <c.m...@ga...> - 2005-01-03 09:10:54
|
From: "Geoff Hutchison" > What I can't figure out at the moment--though I've only taken a > quick glance, is that the command-line tool rejects them. I'll take > a look soon. The -f and -l options work ok for me with the version of main.cpp I am using. The options unknown to main() are passed on to OBConversion in GenOptions. Maybe the mods you made to main affected this. My current set of main.cpp obconversion.cpp and obconversion.h are in http://www.gaseq.co.uk/OB/mainobconversion.zip These do not suffer from the embarassing command-line bug you mentioned previously, and the options -f and -l work. They also include an option you requested for concatinating the input files before conversion for use (yet to be realised) with formats where the molecular data is in more than one file. I know you need to fix a starting version of the source code soon and maybe this would be the best candidate. > I personally prefer "symmetry" to Get/Set routines, so it might be > nice to have SetInFormat() and SetOutFormat() -- the latter might > also be useful inside a program, e.g., where you already have an > OBMol and just want to export something. I see no problem having these functions in addition to SetInAndOutFormats() there. Like it they should return false if the format is not available. |
From: Geoff H. <ge...@ge...> - 2005-01-03 03:37:41
|
> They are now in OBConversion. There are several different types of > option and I have tried to implement them in the appropriate place. What I can't figure out at the moment--though I've only taken a quick glance, is that the command-line tool rejects them. I'll take a look soon. > Multiple extensionsIDs can be used for each format. The code is the > same but they appear as separate choices. I'm not sure whether this is > used in the code you have, but it is in the attached new format file > for MOL and SDF. This also now handles V3000 version files. It is not > well tested (couldn't find many files - is V3000 much used?) and is > deficient in the stereochemistry - I'm unsure how OB handles this. I'm not sure what you mean about stereochemistry. Can you give me an example? As far as V3000 files, I haven't seen them "in the wild much," but don't worry. When we get closer to a final release, I aim to gather quite a large repository of files of different formats for testing. > I guess it would be possible to add an UNDEFINED format which just did > nothing when used in input and output, but I don't think it is > necessary. The default pointer to a format class is NULL which has the > same effect. You are likely to feel the need for this when used in a > program. I'm going to add that to the documentation. > We could make the second parameter of SetInAndOutFormats() default to > NULL and maybe change its name to SetFormats, which would look tidier: > SetFormats("SMI"). I personally prefer "symmetry" to Get/Set routines, so it might be nice to have SetInFormat() and SetOutFormat() -- the latter might also be useful inside a program, e.g., where you already have an OBMol and just want to export something. > A possiblity which has just occurred to me (and which needs thinking > about) would be to derive most (OBMol-using) formats from an > intermediate class OBMoleculeFormat derived from OBFormat. This new > class would contain the repeated ReadChemObject and WriteChemObject > methods, but still allow different approaches (as in cmlformat.cpp) > and would not exclude the possibility of other chemical objects. I think this is cleaner as you say. It doesn't hinder the code from being expanded to other chemical data independent of an OBMol. I'll see what I can do. > I'm not sure how you are dealing with these things, but clearly it > would be better if the new framework were regarded for the time being > as a separate program at an alpha or early beta stage. Right now it's set as a CVS branch -- though the beauty of version-control systems like this is that anyone can go back to the point before or after the new framework is merged in. I'd like to get a few other opinions before I merge it into the main CVS tree, but I don't see it as a problem--the 1.100.x releases have been off of another CVS branch and won't be affected. > I would be keen on a Windows directory being included at an early > stage. The GUI is much easier for Windows users and exercises much of > the same conversion framework. Hmm. First I'd like to make sure that you can access and commit to the CVS tree yourself. Sending around whole files is a waste of bandwidth and a bit of a pain to merge. I'll contact you off-list about getting that going. Cheers, (and thanks!) -Geoff |
From: Chris M. <c.m...@ga...> - 2005-01-02 14:18:49
|
>From: "Geoff Hutchison" >I finished up the merge of Chris Morley's OBConversion framework into >my source tree this evening. > > I think there are a few things that need to be done before I really > want to merge it into the "live" CVS mainstream. > - Chris, I don't see support for the -f and -l flags in the > main.cpp -- > am I missing something? It'd be nice to pick particular molecules > from the file when needed. They are now in OBConversion. There are several different types of option and I have tried to implement them in the appropriate place. For instance, the -h and -d adding and removing hydrogens are specific to molecules and are now in OBMol. (The framework can be applied to conversion of other objects - currently there is just an illustration of this with RXN files.) More particularly options are implemented: In main(): console specific options, i.e. ones that would be implemented differently in a GUI. -i -o (format choice) -H -V (help) -z (use previous set of options) -m (multiple output files) In OBConversion: options suitable for any chemical object -f -l (select range of objects) -a (multiple input files for one object - you haven't seen this yet) In OBMol: molecule specific -h -d -p (add and remove Hs) -c (centre) -s -v (SMARTS filter) In classes derived from OBFormat: format specific options -x? where ? can be anything. The help information on each option is held with its code and is collated when the -H option is used at the keyboard. (In the GUI it is used to make checkboxes and edit boxes etc.) > - Some of the extensions/IDs used by the various file formats have > changed and need to be fixed -- that won't take too long. It also > looks like the chemical MIME type support has disappeared, which > also needs to be fixed. Multiple extensionsIDs can be used for each format. The code is the same but they appear as separate choices. I'm not sure whether this is used in the code you have, but it is in the attached new format file for MOL and SDF. This also now handles V3000 version files. It is not well tested (couldn't find many files - is V3000 much used?) and is deficient in the stereochemistry - I'm unsure how OB handles this. > - Right now the framework isn't set up well for some of the formats > (like the QM programs) where we can read an output format and write > an input format, but not vice-versa. So we'll need to go through and > split these into individual format classes. Not a big deal, but > it'll take a bit of grunt work. > > - The OBConversion class has a function SetInAndOutFormats -- but > since there's no obvious UNDEFINED format like there was, there's no > easy way to say "I just want to read this one file--leave the output > format unspecified for now." I guess it would be possible to add an UNDEFINED format which just did nothing when used in input and output, but I don't think it is necessary. The default pointer to a format class is NULL which has the same effect. You are likely to feel the need for this when used in a program. The following code would be used conv.SetInAndOutFormats("SMI",NULL)) OBMol mol; if(conv.Read(&mol)) ...manipulate molecule We could make the second parameter of SetInAndOutFormats() default to NULL and maybe change its name to SetFormats, which would look tidier: SetFormats("SMI"). > - I'm also planning on hoisting the default ReadChemObject and > WriteChemObject methods into the base class since they're duplicated > so often. I think it's cleaner if a format doesn't read or write, it > should just {return false;} which takes up much less space and code. > :-) Yes, this repeated code offended me too. Like you, I looked for ways of putting it into base class functions, but I couldn't find a way of doing it cleanly and without macros. I could easily have had a block on this - good luck if you can see a way. Be careful though. The ReadChemObject and WriteChemObject methods handle the construction and destruction of an appropriate object (not always an OBMol) and this aspect took me some time to sort out. Currently OBConversion and OBFormat contain no reference to OBMol and neither do the files obconversion.cpp and obconversion.h (and main.cpp) other than in illustrative documentation. Only the format files and the original OB core files know about OBMol. This separation was done so that new chemical objects (e.g. reactions, different types of molecule, etc) could be handled by just adding their format files and with no change in the existing code. The new framework is designed to try to sort out some of the tangle of dependencies in OB and I would be sorry to see that compromised for the sake of about 15 lines of code in each format. Practically, a new format is likely to be built by modifying the template file exampleformat.cpp and the repeated code is just part of the copy and paste. A possiblity which has just occurred to me (and which needs thinking about) would be to derive most (OBMol-using) formats from an intermediate class OBMoleculeFormat derived from OBFormat. This new class would contain the repeated ReadChemObject and WriteChemObject methods, but still allow different approaches (as in cmlformat.cpp) and would not exclude the possibility of other chemical objects. > > Thoughts are welcome -- particularly comments on whether I should > try to update the main CVS tree with the new framework this week or > wait for some particular reason. I'm not sure how you are dealing with these things, but clearly it would be better if the new framework were regarded for the time being as a separate program at an alpha or early beta stage. I would be keen on a Windows directory being included at an early stage. The GUI is much easier for Windows users and exercises much of the same conversion framework. Chris |
From: Geoff H. <ge...@ge...> - 2005-01-02 04:30:17
|
I finished up the merge of Chris Morley's OBConversion framework into my source tree this evening. I think there are a few things that need to be done before I really want to merge it into the "live" CVS mainstream. - Chris, I don't see support for the -f and -l flags in the main.cpp -- am I missing something? It'd be nice to pick particular molecules from the file when needed. - Some of the extensions/IDs used by the various file formats have changed and need to be fixed -- that won't take too long. It also looks like the chemical MIME type support has disappeared, which also needs to be fixed. - Right now the framework isn't set up well for some of the formats (like the QM programs) where we can read an output format and write an input format, but not vice-versa. So we'll need to go through and split these into individual format classes. Not a big deal, but it'll take a bit of grunt work. - The OBConversion class has a function SetInAndOutFormats -- but since there's no obvious UNDEFINED format like there was, there's no easy way to say "I just want to read this one file--leave the output format unspecified for now." - I'm also planning on hoisting the default ReadChemObject and WriteChemObject methods into the base class since they're duplicated so often. I think it's cleaner if a format doesn't read or write, it should just {return false;} which takes up much less space and code. :-) Thoughts are welcome -- particularly comments on whether I should try to update the main CVS tree with the new framework this week or wait for some particular reason. Cheers, -Geoff |
From: Geoff H. <ge...@ge...> - 2005-01-02 02:08:10
|
> Hint: Why not create a new obenbabel LATEX export filter? Yes, there is > someone who made cemistry drawing for LATEX: > http://www.2k-software.de/ingo/ochem.html Definitely a good idea for a new translator. I'm not sure I'd want to write that LaTeX code myself. :-) Once the new translation framework is in place, it'll be easier to add new formats since fewer files need modification. Cheers, -Geoff |
From: <dr...@ma...> - 2005-01-01 21:17:48
|
Hi, I used babel repeatedly then I used the shell script cat tempfile.sdf >> outputfile.sdf Which works fine, but it might be useful to have a function in babel to combine files, it would be particularly useful for combining lists of different file types. Thanks, Chris > Message date : Jan 01 2005, 07:44 PM > From : dr...@ma... > To : "Geoff Hutchison" <ge...@ge...>, dr...@ma... > Copy to : ope...@li... > Subject : Re: Re: [Open Babel] Multi structure selection > > Hi, > > Thanks, I did think of that but I could not think of an easy way to combine the files, > or can I append to a file? > > Thanks, > > Chris > > > > Message date : Jan 01 2005, 06:36 PM > > From : "Geoff Hutchison" <ge...@ge...> > > To : dr...@ma... > > Copy to : ope...@li... > > Subject : Re: [Open Babel] Multi structure selection > > > > > > On Dec 29, 2004, at 4:30 PM, dr...@ma... wrote: > > > > > way to do something like -f 1 -l 4 -f 12 -l 20 -f 24 -l 30 to select > > > compounds from the > > > file? > > > > No, not at the moment. And if we were to add such a feature, it'd > > probably be something more like > > babel --select=1-4,12-20,24-30 ... > > > > You can, of course, call babel repeatedly with each set of first/last > > criteria. > > > > Cheers, > > -Geoff > > > > > > -- > > Whatever you Wanadoo: > http://www.wanadoo.co.uk/time/ > > This email has been checked for most known viruses - find out more at: http:// www.wanadoo.co.uk/help/id/7098.htm > -- Whatever you Wanadoo: http://www.wanadoo.co.uk/time/ This email has been checked for most known viruses - find out more at: http://www.wanadoo.co.uk/help/id/7098.htm |
From: Geoff H. <ge...@ge...> - 2005-01-01 20:12:33
|
> I have been using babel for various purposes with satisfactory results. > Presently I am trying to convert the trajactory files obtained from > simulatins of CHARMM (.dcd) and CVFF force fields (.arc on insight > II)into > the corresponding pdb files. I wonder if this is possible to do so > using > babel or not. I shall appreciate it if you can tell some other > workaround > in case it is not possible using the babel. Currently, Open Babel does not read trajectory files of any sort, though it is on the wishlist. I'd probably try VMD, which should be able to do what you want, IIRC: http://www.ks.uiuc.edu/Research/vmd/ Best regards, -Geoff |
From: Geoff H. <ge...@ge...> - 2005-01-01 20:05:38
|
On Dec 25, 2004, at 6:59 PM, Sergey Tkachenko wrote: > I tried to convert this PDB: > http://molbio.info.nih.gov/cgi-bin/moldraw?2CMM > to CML using OpenBabel. No, I'm not sure what's going on either. The iron should have six bonds. Sometimes the CONECT records are unreliable, so Open Babel runs a "clean up" routine. But the neighboring atoms are close enough that even this should leave six bonds. I'll investigate more closely--it definitely looks like a bug. Thanks! -Geoff |
From: <dr...@ma...> - 2005-01-01 19:44:36
|
Hi, Thanks, I did think of that but I could not think of an easy way to combine the files, or can I append to a file? Thanks, Chris > Message date : Jan 01 2005, 06:36 PM > From : "Geoff Hutchison" <ge...@ge...> > To : dr...@ma... > Copy to : ope...@li... > Subject : Re: [Open Babel] Multi structure selection > > > On Dec 29, 2004, at 4:30 PM, dr...@ma... wrote: > > > way to do something like -f 1 -l 4 -f 12 -l 20 -f 24 -l 30 to select > > compounds from the > > file? > > No, not at the moment. And if we were to add such a feature, it'd > probably be something more like > babel --select=1-4,12-20,24-30 ... > > You can, of course, call babel repeatedly with each set of first/last > criteria. > > Cheers, > -Geoff > > -- Whatever you Wanadoo: http://www.wanadoo.co.uk/time/ This email has been checked for most known viruses - find out more at: http://www.wanadoo.co.uk/help/id/7098.htm |
From: Geoff H. <ge...@ge...> - 2005-01-01 18:36:13
|
On Dec 29, 2004, at 4:30 PM, dr...@ma... wrote: > way to do something like -f 1 -l 4 -f 12 -l 20 -f 24 -l 30 to select > compounds from the > file? No, not at the moment. And if we were to add such a feature, it'd probably be something more like babel --select=1-4,12-20,24-30 ... You can, of course, call babel repeatedly with each set of first/last criteria. Cheers, -Geoff |
From: <dr...@ma...> - 2004-12-29 21:31:12
|
Hi, I'd like to be able to select specific structures from a multistructure file, I see there is an option to start and stop import but I think these can only be used once, is there a way to do something like -f 1 -l 4 -f 12 -l 20 -f 24 -l 30 to select compounds from the file? Thanks chris -- Whatever you Wanadoo: http://www.wanadoo.co.uk/time/ This email has been checked for most known viruses - find out more at: http://www.wanadoo.co.uk/help/id/7098.htm |
From: Joerg K. W. <we...@in...> - 2004-12-29 15:16:21
|
Hi all, So if you are thinking about possible speed-ups and optimization tasks, here are the most frequent dependencies. They are cached anyway, at least until you do not call molecule.endModify(nukeData=true). Being really exact this means, that the largest runtime for each algorithm bounds the whole dependency tree runtime ... see also Cormen, Leiserson,Rivest: Introduction to Algorithms for O-Notation and runtime-complexity definition: 283 joelib2.feature.types.atomlabel.AtomInRing 196 joelib2.feature.types.atomlabel.AtomIsHydrogen 166 joelib2.feature.types.atomlabel.AtomImplicitValence 162 joelib2.feature.types.atomlabel.AtomHybridisation 162 joelib2.feature.types.atomlabel.AtomHeavyValence 155 joelib2.feature.types.bondlabel.BondInRing 151 joelib2.feature.types.atomlabel.AtomInRing 137 joelib2.feature.types.bondlabel.BondInAromaticSystem 137 joelib2.feature.types.atomlabel.AtomInAromaticSystem 136 joelib2.feature.types.atomlabel.AtomImplicitHydrogenCount 136 joelib2.feature.types.atomlabel.AtomExplicitHydrogenCount 132 joelib2.feature.types.atomlabel.AtomKekuleBondOrderSum 132 joelib2.feature.types.atomlabel.AtomIsElectronegative 132 joelib2.feature.types.atomlabel.AtomInRingsCount 132 joelib2.feature.types.atomlabel.AtomBondOrderSum 131 joelib2.smarts.SMARTSParser 130 joelib2.smarts.SMARTSPattern 99 joelib2.data.AtomTyper 45 joelib2.ring.RingDetector 26 joelib2.feature.types.atomlabel.AtomIsOxygen 24 joelib2.smarts.ProgrammableAtomTyper 22 joelib2.data.ElementHolder 20 joelib2.feature.types.atomlabel.AtomInRing 18 joelib2.feature.types.bondlabel.BondIsClosure 15 joelib2.feature.types.atomlabel.AtomIsNitrogen 13 joelib2.feature.types.atomlabel.AtomIsSulfur 13 joelib2.data.AromaticityTyper 12 joelib2.feature.types.atomlabel.AtomIsCarbon 11 joelib2.algo.BFS 10 joelib2.feature.types.DistanceMatrix Kind regads, Joerg -- Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
From: Joerg K. W. <we...@in...> - 2004-12-29 11:17:29
|
Hi all, Cross-Posting -> please reply ONLY TO the following lists, if your reply affects not your library and software package: joe...@li... and qsa...@li... As you all know the 'in silico' chemistry is pretty complex and i've now implemented a trace back routine to identify how complex. This routine was implemented for JOELib2 (not JOELib1, so use: cvs co joelib2). The complexity is more or less analogue to OpenBabel, since both libraries uses the same SMARTS-matching and text definition files. As already discussed several times, we had serious problems to trace back algorithms (chemical expert systems) and feature calculation algorithms, because the complex dependencies trees hidden to the users. The only way to get a feeling for those dependencies was to read the source code. This is even more serious for using algorithms depending on the underlying expert systems, like file conversion (force fields), QSAR descriptor (feature) calculation, SMARTS substructure search, and so on ... Until now we were unable to formalize and assign a unique version number to the applied algorithms. Hence this may be critical for QSAR, because one single change in the aromaticity typer (source code or text definition file) forwards those changes to all depending algorithms. But which one depends on the aromaticity, and affects this the algorithm of interest? Yes, definitely yes! Now, for JOELib2 we can calculate a hashed dependency tree identifier for each expert system, feature calculation algorithm and this version identifier is calculated automatically using the source code CVS tags, which are unique! And i'm pretty proud to present this hack, because even with Java reflection this was tricky. Here is an admonitory remark for the new year 2005 to all users: 'Never mess around with chemical expert systems, and never believe anyone telling you that a fingerprint is a simple 1D descriptor for screening.' Why not? 1. '1D': As you can see the calculation requires the full chemical expert system and this is at least a 2D dependency, 1D is only valid for primitive elemental counts, without any neighborhood. 2. 'simple': even if you apply a 'simple' Query (e.g. SMARTS) matching task, the underlying complexity is far away from being simple (requires 47 algorithms and feature calculation methods for 'SSKey3DS'). Here are two small examples and the full dependency tree can be calculated with JOELib2, 'sh joelibKernel.sh' (requires Java 1.5) and is available online: http://www-ra.informatik.uni-tuebingen.de/software/joelib/KernelLog.txt Now, the examples: 1. chemical expert system identifier: jk:k-1566956551:softDependencies:joelib2.data.AtomTyper (992650183) joelib2.data.AtomTyper http://joelib.sf.net joelib2/data/plain/atomtype.txt 1.1.1.1 2004-12-06_15-33-18 2. dependency for simple a 'simple' paharmacophore fingerprint: dependency class is: joelib2.feature.types.SSKey3DS dependency version hash code is: 1113779298 (including chemistry kernel hash: -1566956551) dependency algorithm complexity is at least: 47 (+ basic user input graph, + recursive dependencies, + data structure dependencies, + forgotten dependencies) class joelib2.feature.types.SSKey3DS(version 1.4) depends on class joelib2.feature.types.count.AromaticBonds(version 1.2) depends on class joelib2.feature.types.atomlabel.AtomIsHydrogen(version 1.2) class joelib2.feature.types.bondlabel.BondInAromaticSystem(version 1.3) depends on class joelib2.data.AromaticityTyper(version 1.4) depends on class joelib2.smarts.SMARTSPattern(version 1.3) depends on class joelib2.smarts.SMARTSParser(version 1.4) depends on (WARNING: recursively defined dependencies) class joelib2.feature.types.atomlabel.AtomBondOrderSum class joelib2.feature.types.atomlabel.AtomExplicitHydrogenCount class joelib2.feature.types.atomlabel.AtomHeavyValence class joelib2.feature.types.atomlabel.AtomHybridisation class joelib2.feature.types.atomlabel.AtomImplicitHydrogenCount class joelib2.feature.types.atomlabel.AtomImplicitValence class joelib2.feature.types.atomlabel.AtomInAromaticSystem class joelib2.feature.types.atomlabel.AtomInRing class joelib2.feature.types.atomlabel.AtomInRingsCount class joelib2.feature.types.atomlabel.AtomIsElectronegative class joelib2.feature.types.atomlabel.AtomIsHydrogen class joelib2.feature.types.atomlabel.AtomKekuleBondOrderSum class joelib2.feature.types.bondlabel.BondInAromaticSystem class joelib2.feature.types.bondlabel.BondInRing class joelib2.feature.types.atomlabel.AtomHybridisation(version 1.3) depends on class joelib2.data.AtomTyper(version 1.4) depends on class joelib2.smarts.SMARTSPattern(version 1.3) depends on class joelib2.smarts.SMARTSParser(version 1.4) depends on (WARNING: recursively defined dependencies) class joelib2.feature.types.atomlabel.AtomBondOrderSum class joelib2.feature.types.atomlabel.AtomExplicitHydrogenCount class joelib2.feature.types.atomlabel.AtomHeavyValence class joelib2.feature.types.atomlabel.AtomHybridisation class joelib2.feature.types.atomlabel.AtomImplicitHydrogenCount class joelib2.feature.types.atomlabel.AtomImplicitValence class joelib2.feature.types.atomlabel.AtomInAromaticSystem class joelib2.feature.types.atomlabel.AtomInRing class joelib2.feature.types.atomlabel.AtomInRingsCount class joelib2.feature.types.atomlabel.AtomIsElectronegative class joelib2.feature.types.atomlabel.AtomIsHydrogen class joelib2.feature.types.atomlabel.AtomKekuleBondOrderSum class joelib2.feature.types.bondlabel.BondInAromaticSystem class joelib2.feature.types.bondlabel.BondInRing class joelib2.feature.types.atomlabel.AtomImplicitValence(version 1.3) depends on class joelib2.data.AtomTyper(version 1.4) depends on class joelib2.smarts.SMARTSPattern(version 1.3) depends on class joelib2.smarts.SMARTSParser(version 1.4) depends on (WARNING: recursively defined dependencies) class joelib2.feature.types.atomlabel.AtomBondOrderSum class joelib2.feature.types.atomlabel.AtomExplicitHydrogenCount class joelib2.feature.types.atomlabel.AtomHeavyValence class joelib2.feature.types.atomlabel.AtomHybridisation class joelib2.feature.types.atomlabel.AtomImplicitHydrogenCount class joelib2.feature.types.atomlabel.AtomImplicitValence class joelib2.feature.types.atomlabel.AtomInAromaticSystem class joelib2.feature.types.atomlabel.AtomInRing class joelib2.feature.types.atomlabel.AtomInRingsCount class joelib2.feature.types.atomlabel.AtomIsElectronegative class joelib2.feature.types.atomlabel.AtomIsHydrogen class joelib2.feature.types.atomlabel.AtomKekuleBondOrderSum class joelib2.feature.types.bondlabel.BondInAromaticSystem class joelib2.feature.types.bondlabel.BondInRing class joelib2.feature.types.atomlabel.AtomInRing(version 1.3) depends on class joelib2.ring.RingDetector(version 1.3) class joelib2.feature.types.atomlabel.AtomIsHydrogen(version 1.2) class joelib2.feature.types.bondlabel.BondInRing(version 1.2) depends on class joelib2.ring.RingDetector(version 1.3) class joelib2.feature.types.bondlabel.BondIsClosure(version 1.2) class joelib2.feature.types.atomlabel.AtomIsHeteroatom(version 1.2) depends on class joelib2.feature.types.atomlabel.AtomIsHalogen(version 1.3) class joelib2.ring.RingFinderSSSR(version 1.2) depends on class joelib2.feature.types.atomlabel.AtomInRing(version 1.3) depends on class joelib2.ring.RingDetector(version 1.3) class joelib2.feature.types.bondlabel.BondInRing(version 1.2) depends on class joelib2.ring.RingDetector(version 1.3) class joelib2.feature.types.bondlabel.BondIsClosure(version 1.2) class joelib2.feature.types.FractionRotatableBonds(version 1.3) depends on class joelib2.feature.types.atomlabel.AtomIsHydrogen(version 1.2) class joelib2.feature.types.bondlabel.BondIsRotor(version 1.3) depends on class joelib2.feature.types.atomlabel.AtomHeavyValence(version 1.3) depends on class joelib2.feature.types.atomlabel.AtomIsHydrogen(version 1.2) class joelib2.feature.types.atomlabel.AtomHybridisation(version 1.3) depends on class joelib2.data.AtomTyper(version 1.4) depends on class joelib2.smarts.SMARTSPattern(version 1.3) depends on class joelib2.smarts.SMARTSParser(version 1.4) depends on (WARNING: recursively defined dependencies) class joelib2.feature.types.atomlabel.AtomBondOrderSum class joelib2.feature.types.atomlabel.AtomExplicitHydrogenCount class joelib2.feature.types.atomlabel.AtomHeavyValence class joelib2.feature.types.atomlabel.AtomHybridisation class joelib2.feature.types.atomlabel.AtomImplicitHydrogenCount class joelib2.feature.types.atomlabel.AtomImplicitValence class joelib2.feature.types.atomlabel.AtomInAromaticSystem class joelib2.feature.types.atomlabel.AtomInRing class joelib2.feature.types.atomlabel.AtomInRingsCount class joelib2.feature.types.atomlabel.AtomIsElectronegative class joelib2.feature.types.atomlabel.AtomIsHydrogen class joelib2.feature.types.atomlabel.AtomKekuleBondOrderSum class joelib2.feature.types.bondlabel.BondInAromaticSystem class joelib2.feature.types.bondlabel.BondInRing class joelib2.feature.types.count.HBA1(version 1.2) depends on class joelib2.smarts.ProgrammableAtomTyper(version 1.4) depends on class joelib2.smarts.SMARTSPattern(version 1.3) depends on class joelib2.smarts.SMARTSParser(version 1.4) depends on (WARNING: recursively defined dependencies) class joelib2.feature.types.atomlabel.AtomBondOrderSum class joelib2.feature.types.atomlabel.AtomExplicitHydrogenCount class joelib2.feature.types.atomlabel.AtomHeavyValence class joelib2.feature.types.atomlabel.AtomHybridisation class joelib2.feature.types.atomlabel.AtomImplicitHydrogenCount class joelib2.feature.types.atomlabel.AtomImplicitValence class joelib2.feature.types.atomlabel.AtomInAromaticSystem class joelib2.feature.types.atomlabel.AtomInRing class joelib2.feature.types.atomlabel.AtomInRingsCount class joelib2.feature.types.atomlabel.AtomIsElectronegative class joelib2.feature.types.atomlabel.AtomIsHydrogen class joelib2.feature.types.atomlabel.AtomKekuleBondOrderSum class joelib2.feature.types.bondlabel.BondInAromaticSystem class joelib2.feature.types.bondlabel.BondInRing class joelib2.feature.types.count.HBA2(version 1.2) depends on class joelib2.smarts.ProgrammableAtomTyper(version 1.4) depends on class joelib2.smarts.SMARTSPattern(version 1.3) depends on class joelib2.smarts.SMARTSParser(version 1.4) depends on (WARNING: recursively defined dependencies) class joelib2.feature.types.atomlabel.AtomBondOrderSum class joelib2.feature.types.atomlabel.AtomExplicitHydrogenCount class joelib2.feature.types.atomlabel.AtomHeavyValence class joelib2.feature.types.atomlabel.AtomHybridisation class joelib2.feature.types.atomlabel.AtomImplicitHydrogenCount class joelib2.feature.types.atomlabel.AtomImplicitValence class joelib2.feature.types.atomlabel.AtomInAromaticSystem class joelib2.feature.types.atomlabel.AtomInRing class joelib2.feature.types.atomlabel.AtomInRingsCount class joelib2.feature.types.atomlabel.AtomIsElectronegative class joelib2.feature.types.atomlabel.AtomIsHydrogen class joelib2.feature.types.atomlabel.AtomKekuleBondOrderSum class joelib2.feature.types.bondlabel.BondInAromaticSystem class joelib2.feature.types.bondlabel.BondInRing class joelib2.smarts.SMARTSPattern(version 1.3) depends on class joelib2.smarts.SMARTSParser(version 1.4) depends on (WARNING: recursively defined dependencies) class joelib2.feature.types.atomlabel.AtomBondOrderSum class joelib2.feature.types.atomlabel.AtomExplicitHydrogenCount class joelib2.feature.types.atomlabel.AtomHeavyValence class joelib2.feature.types.atomlabel.AtomHybridisation class joelib2.feature.types.atomlabel.AtomImplicitHydrogenCount class joelib2.feature.types.atomlabel.AtomImplicitValence class joelib2.feature.types.atomlabel.AtomInAromaticSystem class joelib2.feature.types.atomlabel.AtomInRing class joelib2.feature.types.atomlabel.AtomInRingsCount class joelib2.feature.types.atomlabel.AtomIsElectronegative class joelib2.feature.types.atomlabel.AtomIsHydrogen class joelib2.feature.types.atomlabel.AtomKekuleBondOrderSum class joelib2.feature.types.bondlabel.BondInAromaticSystem class joelib2.feature.types.bondlabel.BondInRing And a Happy New Year to all ! Kind regards, Joerg -- Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |