I can confirm that removing the conditional compilation directive
#ifdef RDK_BUILD_DESCRIPTORS3D
(and the corresponding #endif)
from PMI.h allows compilation without having to worry about the
-DRDK_BUILD_DESCRIPTORS3D directive. I think this is a worthwhile change.
Any thoughts about the numerical PMI and NPR values produced by the current
implementation? I still can't make any sense of them.
Chris
On 9 January 2017 at 05:18, Greg Landrum <greg.land...@gmail.com> wrote:
> A more straightforward solution to this one, and what I probably should
> have done in the first place, would be to not include the conditional
> compilation directives in the PMI.h header file. It should be fine to have
> the declarations in the header even if there is no corresponding
> definition, and then client code wouldn't need to know about the extra
> options.
>
> PR coming.
>
> On Sun, Jan 8, 2017 at 7:17 PM, Brian Kelley <fustiga...@gmail.com> wrote:
>
>> I think the relevant issue is that if you are using an existing build, we
>> don't yet have the capability for you to know what was built and what was
>> not. I.e. You need to add the compiler flag to indicate that the 3D stuff
>> was actually built.
>>
>> I had a PR to fix this a while ago that was postponed that we should
>> probably resurrect. Basically it is an rdkit.h header file that has these
>> flags built in so you won't have to include them yourself.
>>
>> ----
>> Brian Kelley
>>
>> On Jan 8, 2017, at 11:31 AM, Greg Landrum <greg.land...@gmail.com> wrote:
>>
>> Hi Chris,
>>
>> The RDKit should automatically build with the new descriptors enabled if
>> eigen3 can be found when cmake is run. When you run cmake you should see a
>> message if/when the build is disabled.
>>
>> If you want to call the functions, the best documentation available is
>> the standard C++ API documentation, but something seems to have gone wrong
>> when I ran doxygen. I'll look into this. That documentation is generated
>> from the header file, so you can just look there:
>> https://github.com/rdkit/rdkit/blob/master/Code/GraphMol/
>> Descriptors/PMI.h
>> not that there's a huge amount of documentation available.
>>
>> W.r.t. efficiency: you do need to call the functions individually, but
>> the expensive calculation of the moments will only be done once, so it
>> doesn't end up doing repeated work.
>>
>> And, finally, on the values themselves: I will have to take a look at
>> that.
>> -greg
>>
>>
>>
>>
>> On Sun, Jan 8, 2017 at 11:17 AM, Chris Earnshaw <cgearns...@gmail.com>
>> wrote:
>>
>>> Hi
>>>
>>> A while ago I had a project which needed PMI descriptors (specifically
>>> NPR1 and NPR2) which were not available in the main branch of RDKit at the
>>> time. At the time I used the fork by 'hahnda6' which provided the
>>> calcPMIDescriptors() function, and this worked well. Now that PMI
>>> descriptors are available in the main RDKit distrubution I thought I'd
>>> rewrite my code to use the official version.
>>>
>>> Building the new RDKit was no problem, but things went downhill shortly
>>> after that. There's every chance that I've missed the relevant
>>> documentation (I hope someone can point me in the right direction if so)
>>> and done something stupid!
>>>
>>> The issues are -
>>> 1) I can't find any documentation of the C++ API - the only reference to
>>> PMI in the online RDKit documentation appears to be to the PMI.h file
>>> 2) Having written a program using the PMI[123] and/or NPR[12] functions,
>>> I couldn't get it to compile until I added the -DRDK_BUILD_DESCRIPTORS3D
>>> directive -
>>> g++ -o sdf_pmi_blob sdf_pmi.cpp -I/packages/rdkit/include/rdkit
>>> -L/packages/rdkit/lib -lDescriptors -lGraphMol -lFileParsers
>>> -Wno-deprecated -O2 -DRDK_BUILD_DESCRIPTORS3D
>>> This seems a bit odd...
>>> 3) Is it necessary to make separate calls to the individual PMI() and/or
>>> NPR() functions? Surely this results in duplication of some of the heavier
>>> calculations? I can't find any equivalent of calcPMIDescriptors() which
>>> returned a 'Moments' struct containing all the PMI and NPR values in one go.
>>> 4) The big one! The returned results look very odd. They appear to
>>> relate more to the dimensions of the molecule than the moments of inertia.
>>> For a rod-like molecule (dimethylacetylene) I'd expect two large and one
>>> small PMI (e.g. PMI1: 6.61651 PMI2: 150.434 PMI3: 150.434 NPR1:
>>> 0.0439828 NPR2: 0.999998) but actually get PMI1: 0.061647 PMI2: 0.061652
>>> PMI3: 25.3699 NPR1: 0.002430 NPR2: 0.002430.
>>> For disk-like (benzene) the result should be one large and two medium
>>> (e.g. PMI1: 89.1448 PMI2: 89.1495 PMI3: 178.294 NPR1: 0.499987 NPR2:
>>> 0.500013) but get PMI1: 2.37457e-10 PMI2: 11.0844 PMI3: 11.0851 NPR1:
>>> 2.14213e-11 NPR2: 0.999933.
>>> Finally for a roughly spherical molecule (neopentane) the NPR values
>>> look reasonable (no great surprise) but the absolute PMI values may be too
>>> small: old program - PMI1: 114.795 PMI2: 114.797 PMI3: 114.799
>>> NPR1: 0.999966 NPR2: 0.999988, new program - PMI1: 6.59466 PMI2:
>>> 6.59488 PMI3: 6.59531 NPR1: 0.999902 NPR2: 0.999935
>>>
>>> As I say, it's entirely likely that I'm doing something stupid here so
>>> any pointers will be gratefully received. FWIW, the core of my program is -
>>> mol = MolBlockToMol(ctab, true, false);
>>> double pmi1 = RDKit::Descriptors::PMI1(*mol);
>>> double pmi2 = RDKit::Descriptors::PMI2(*mol);
>>> double pmi3 = RDKit::Descriptors::PMI3(*mol);
>>> double npr1 = RDKit::Descriptors::NPR1(*mol);
>>> double npr2 = RDKit::Descriptors::NPR2(*mol);
>>>
>>> Thanks for any help!
>>> Chris
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Rdkit-discuss mailing list
>>> Rdkit-discuss@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
>>>
>>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>
>> _______________________________________________
>> Rdkit-discuss mailing list
>> Rdkit-discuss@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
>>
>>
>
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Rdkit-discuss mailing list
Rdkit-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
