Re: [OpenBabel-Devel] CIF vs mmCIF

That change was my doing. It started because chemists on my team found that the mmcif parser was more reliable (email thread ). I agree that the writers should not be merged for all the reasons you said. However, I think the readers

Re: [OpenBabel-Devel] Conda package for OpenBabel

gt; Richard H. West, Ph.D. r.w...@neu.edu > Assistant Professor, Department of Chemical Engineering, > Northeastern University, 360 Huntington Ave, Boston, MA 02115 > http://neu.edu/comochengPhone: 617-373-5163 > > > On Feb 3, 2015, at 10:14 AM, Patrick Fuller > wrote: >

Re: [OpenBabel-Devel] Fwd: Google Summer of Code

we can certainly get a more concrete schedule - > which I think would also help with your frustration at older binary > packaging. > > So if people can provide a little help: > - Website, possibly migrating to GitHub pages / Jekyll (i.e., re-using the > Sphinx documentation) >

[OpenBabel-Devel] pip install git+https://github.com/openbabel/openbabel

Have there been any attempts to make the dev version of open babel installable through pip? I know there's the setup.py in scripts/python, but I believe that just installs the python bindings. -- Download BIRT iHub F-Type -

Re: [OpenBabel-Devel] CIF vs mmCIF Parsing

ich is cifs from the CCDC <http://www.ccdc.cam.ac.uk/pages/Home.aspx>. I think it's worthwhile, but want to see if there are any strong opinions against workflow-breaking edits before making a pull request. Pat ​ On Thu, Aug 21, 2014 at 10:37 AM, Patrick Fuller wrote: > > Since you an

Re: [OpenBabel-Devel] CIF vs mmCIF Parsing

> Since you and others work wit CIFs more than myself, perhaps you’d be willing to take up some “maintenance” of MMCIF? I can also ask Chris Wilmer now that he’s here at Pitt and may have some ideas. I'm willing to help here. A better cif parser means less dropping down to mercury / materials stud

[OpenBabel-Devel] CIF vs mmCIF Parsing

Hi, I learned today that the chemists I work with have been renaming their .cif to .mmcif to get it parsed correctly through openbabel. I thought that was interesting, so I decided to run a folder of ~100 test cifs through the mmcif parser to see if it errors less than the cif parser. Outside of

Re: [OpenBabel-Devel] Creating a release off of master branch

ava without having to build the > project themselves, and would be interested in pushing this as a versioned > artifact into Maven central. > > We can (and will) do all this under our own namespace so there's no > confusion, but if the community would like to collaborate we think

Re: [OpenBabel-Devel] Creating a release off of master branch

Why not just use the git commit uuids? Something like: git clone openbabel/openbabel git checkout 92ab8c8 cmake, make, make install should ensure that everyone is on the same exact version of the code. On Thu, Jul 31, 2014 at 9:05 AM, Ed Kohlwey wrote: > Hi, > I'm working on a project that wo

Re: [OpenBabel-Devel] Big CIF file handling

you can use my "connectthedots" branch at patrickfuller/openbabel. On Mon, Feb 10, 2014 at 11:23 AM, Patrick Fuller wrote: > It was ~5% faster with connect the dots alone, but that's *very* > preliminary. I wrote a Python script that loaded just atoms into an OBMol, > ran Connec

Re: [OpenBabel-Devel] Big CIF file handling

It was ~5% faster with connect the dots alone, but that's *very* preliminary. I wrote a Python script that loaded just atoms into an OBMol, ran ConnectTheDots, and then profiled it (`python -m cProfile -s time test_script.py`). This script looped through a random folder of metal-organic frameworks

Re: [OpenBabel-Devel] Big CIF file handling

The current ConnectTheDots is generally N log N since the atoms are sorted. But my question would be whether the PerceiveBondOrders is being triggered on your CIF files. Try, for example, running: obabel file.cif -O file.cml -as #output only single bonds from ConnectTheDots() I just did this - on

Re: [OpenBabel-Devel] Big CIF file handling

and the internal front-end software at my job) with a ton of CPU work. Maybe this could be run in a background thread with a timeout? Pat On Sun, Feb 9, 2014 at 3:20 PM, Patrick Fuller wrote: > Thanks! I feel rather stupid not checking for ConnectTheDots. > > > On Sun, Feb 9, 2014 a

Re: [OpenBabel-Devel] Big CIF file handling

pp:void ConnectTheDots(RWMol > *mol) > ./Code/GraphMol/FileParsers/ProximityBonds.cpp: ConnectTheDots_Large(mol); > ./Code/GraphMol/FileParsers/PDBParser.cpp:ConnectTheDots(mol); > > - Noel > > On 9 February 2014 00:12, Patrick Fuller wrote: > > Noel - Thanks for the

Re: [OpenBabel-Devel] Big CIF file handling

; repurpose this code considering the licence. > > - Noel > > On 3 February 2014 19:58, Patrick Fuller wrote: > > So you can use -ab or -aB if you want to ignore ConnectTheDots. > > > > Good to know, thanks! > > > > The biggest talk has largely centered on P

Re: [OpenBabel-Devel] Eqeq and eigen2

I see that David's already set up a PR for the switch to HAVE_EIGEN3. Is there any reason to spend some time getting this algorithm to work with eigen 2, or is that not really worth it? On Fri, Feb 7, 2014 at 7:55 PM, Geoffrey Hutchison < geoff.hutchi...@gmail.com> wrote: > > I guess a third opt

Re: [OpenBabel-Devel] Big CIF file handling

So you can use -ab or -aB if you want to ignore ConnectTheDots. Good to know, thanks! The biggest talk has largely centered on PerceiveBondOrders and Kekule / aromatic detection, which are usually slower than ConnectTheDots. If you'd like to take a stab at an improved implementation of ConnectThe

[OpenBabel-Devel] Big CIF file handling

Hi all, Here's the metal-organic framework MIL-100. It has a 12,000-atom unit cell, and it crashes openbabel when it's loaded. Looking through the source, it seems that the crash is due to automatic O(N^2) bond inference on crystals. I was able to ve