Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

boost::bad_any_cast error when calling getProp<string> on properties set by applyMolListPropsToAtoms<int64_t> #6465

Closed
rachelnwalker opened this issue Jun 15, 2023 · 1 comment · Fixed by #6467
Labels
Milestone

Comments

@rachelnwalker
Copy link
Contributor

Describe the bug
As described in title -- a boost::any_cast error is thrown when you try to cast a property set by applyMolListPropsToAtoms<int64_t> to a string.

Steps to reproduce
To reproduce from C++:

std::unique_ptr<RWMol> m(SmilesToMol("CCC"));
m->setProp("atom.iprop.foo1", "1   6 9");
FileParserUtils::applyMolListPropsToAtoms<std::int64_t>(*m, "atom.iprop.");
int int_res = m->getAtomWithIdx(0)->getProp<std::int64_t>("foo1"); // this is fine
std::string str_res = m->getAtomWithIdx(0)->getProp<std::string>("foo1"); // this is not fine

that last line will throw

due to unexpected exception with message:
  boost::bad_any_cast: failed conversion using boost::any_cast

This seems like a bug to me, because we can cast between property types when we set properties using setProp. This can be reproduced from python by reading a molblock that has property lists:

mb = """
    RDKit  2D

  3  3  0  0  0  0  0  0  0  0999 V2000
    0.8660    0.0000    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0
   -0.4330    0.7500    0.0000 N   0  0  0  0  0  0  0  0  0  0  0  0
   -0.4330   -0.7500    0.0000 C   0  0  0  0  0  0  0  0  0  0  0  0
  1  2  1  0
  2  3  1  0
  3  1  1  0
M  END
>  <atom.dprop.PartialCharge>  (1) 
0.008 -0.314 0.008

>  <atom.iprop.NumHeavyNeighbors>  (1) 
2 2 2

>  <atom.prop.AtomLabel>  (1)
C1 N2 C3

>  <atom.bprop.IsCarbon>  (1) 
1 0 1

>  <atom.prop.PartiallyMissing>  (1) 
one n/a three

>  <atom.iprop.PartiallyMissingInt>  (1) 
[?] 2 2 ?

$$$$"""
suppl = Chem.SDMolSupplier()
suppl.SetData(mb)
at = next(suppl).GetAtomWithIdx(0)

print(f"Atom label: {at.GetProp('AtomLabel')}")
print(f"Has prop: {at.HasProp('NumHeavyNeighbors')}")
print(at.GetProp('NumHeavyNeighbors'))

Atom label: C1
Has prop: 1
Traceback (most recent call last):
File "../rdkit/testing.py", line 91, in
print(at.GetProp('NumHeavyNeighbors'))
ValueError: key NumHeavyNeighbors exists but does not result in unregistered C++ type reason: boost::bad_any_cast: failed conversion using boost::any_cast

It looks like this is just an issue for integers (you can't even use GetIntProp from python?):

print(f"PartialCharge: {at.GetDoubleProp('PartialCharge')}, {at.GetProp('PartialCharge')}")
print(f"IsCarbon: {at.GetBoolProp('IsCarbon')}, {at.GetProp('IsCarbon')}")
print(at.GetIntProp('NumHeavyNeighbors'))

PartialCharge: 0.008, 0.0080000000000000002
IsCarbon: True, 1
Traceback (most recent call last):
File "../rdkit/testing.py", line 89, in
print(at.GetIntProp('NumHeavyNeighbors'))
ValueError: key NumHeavyNeighbors exists but does not result in an integer value reason: boost::bad_any_cast: failed conversion using boost::any_cast

Additional comments

I noticed this when working on #6453 when @bp-kelley suggested testing with atom property lists. Because of this issue, the substructure search option added in that PR will not work for int properties set using property lists.

Configuration

RDKit version: '2023.09.1pre'
OS: Mac
Are you using conda? No

bp-kelley pushed a commit to bp-kelley/rdkit that referenced this issue Jun 16, 2023
@bp-kelley
Copy link
Contributor

I added a PR to fix this, thanks for checking the atom lists. We didn't have conversions for int64 from boost::any to std::string, just long which is an odd type anyway.

greglandrum pushed a commit that referenced this issue Jun 22, 2023
Co-authored-by: Brian Kelley <bkelley@relaytx.com>
@greglandrum greglandrum added this to the 2023_03_3 milestone Jun 22, 2023
greglandrum pushed a commit that referenced this issue Aug 17, 2023
Co-authored-by: Brian Kelley <bkelley@relaytx.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants