Re: [BlueObelisk-discuss] ACS meeting - dinner?

[Robert Hanson]

Let's see if this works...

I'm arriving in LA on Saturday and will have time to help organize this.
Monday night would be by far the best for me; Sunday would be OK; I'm
leaving Tuesday. I have a strong visual memory of the area but am unsure if
I was walking North or East when we were last there, in 2004.
Here are some possibilities:

McCormick and Schmicks
http://www.mccormickandschmicks.com/Locations/southern-california-los-angeles/anaheim-california/KatellaAve.aspx

California Pizza Kitchen
http://www.cpk.com/

Bubba Gump Shrimp Co.
http://www.bubbagump.com/

Ghandi Palace
http://www.gandhipalace.com/

Fire and Ice Grill and Bar
http://www.fire-ice.com/

comments?

Bob

-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] ACS meeting - dinner?

[Robert Hanson]

Is this taken care of? Didn't we meet at a nice restaurant a few blocks from
the hotels last time? Up on Katella Ave?

On Thu, Mar 24, 2011 at 8:57 PM, Robert Belford rebelf...@ualr.edu wrote:

 Bob,

 You should have gotten this.

 Cheers,




 -- Forwarded message --
 From: Robert Belford rebelf...@ualr.edu
 Date: Thu, Mar 24, 2011 at 2:14 PM
 Subject: Re: [BlueObelisk-discuss] ACS meeting - dinner?
 To: Peter Murray-Rust pm...@cam.ac.uk
 Cc: BlueObelisk-Discuss blueobelisk-discuss@lists.sourceforge.net


 All,

 I am willing to try and help out with organizing the BO dinner in Anaheim.
 I took a quick look at restaurants and it looked like most are chain
 restaurants.  Does anyone have any suggestions?  Even if you are not going
 and have some advice on a restaurant your input would be appreciated.

 I also do not have the ability to edit the BO meetings page, even after I
 log into Sourceforge. If someone gave me access to that for a week I can
 take care of it.  In the mean-time we can use the following Google Doc.


 https://docs.google.com/document/d/1e22eKKM883fXTRRi9lNLZnSfWr_48rXk8Dpn664HrwU/edit?hl=enauthkey=CIiZ6LAM

 I set it up so no log-in is required and anyone can edit, (but you need to
 use the link).

 I took the liberty to add Peter.

 Cheers,
 Bob




 On Thu, Mar 24, 2011 at 3:39 AM, Peter Murray-Rust pm...@cam.ac.ukwrote:

 We haven't yet done anything about a Blue Obelisk dinner at ACS Anaheim. I
 am there from Friday to Wed evening  - so will go along with what anyone
 else organizes.

 But I would prefer someone else to organize it - I am down for 5 talks. At
 the least I suggest we have a list of participants . So far I know the
 following are going:

 PMR
 Robert Belford
 Marcus Hanwell
 Sam Adams
 Henry Rzepa
  and several more...

 Do we have a wiki page where this can be entered?


 --
 Peter Murray-Rust
 Reader in Molecular Informatics
 Unilever Centre, Dep. Of Chemistry
 University of Cambridge
 CB2 1EW, UK
 +44-1223-763069


 --
 Enable your software for Intel(R) Active Management Technology to meet the
 growing manageability and security demands of your customers. Businesses
 are taking advantage of Intel(R) vPro (TM) technology - will your software
 be a part of the solution? Download the Intel(R) Manageability Checker
 today! http://p.sf.net/sfu/intel-dev2devmar

 ___
 Blueobelisk-discuss mailing list
 Blueobelisk-discuss@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss






-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] Mini Blue Obelisk meeting at 5th Meeting on U.S. Government Chemical Databases and Open Chemistry?

[Robert Hanson]

Sounds fun. Unfortunately, I'll miss BOTH of these this time around; I'll be
at the CRYSTAL workshop learning all about solid state chemistry:
http://www.crystal.unito.it/mssc2011/

On Thu, Aug 18, 2011 at 3:32 AM, Noel O'Boyle baoille...@gmail.com wrote:

 Hi all,

 I'll be attending the database meeting organising by the NCI on Aug
 25-26, and arriving on the afternoon of the 24th. Anyone interested in
 meeting up for dinner?

 (Unfortunately, unable to make the ACS)

 - Noel


 --
 Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
 user administration capabilities and model configuration. Take
 the hassle out of deploying and managing Subversion and the
 tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
 ___
 Blueobelisk-discuss mailing list
 Blueobelisk-discuss@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss




-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] [BlueObelisk-SMILES] help needed -- SMILES and MMFF94 atom types

[Robert Hanson]

[switching to BlueObelisk-Discuss from BlueOblelisk-Smiles here]

Geoff, I will look at that. What does fully validated mean exactly?

I have the SMARTS business for MMFF94 charges working in Jmol now for
getting the atom types -- obviously not validated! -- and I suspect it will
require a bit of hand-crafting.

Egon, I'm using your CDK interpretation of how to handle MMFF94 bci and
pbci. That looks relatively simple.

Still, I would like to know more details. I'll look at that code, Geoff,
and see what I can see about some of those groups. Thanks.

Others with insight into MMFF94 charge calculation?

Bob


On Thu, Apr 26, 2012 at 8:11 PM, Geoff Hutchison
ge...@geoffhutchison.netwrote:

  Today I decided I wanted Jmol to be able to generate MEP mapped van der
 Waals surfaces, and the way I see to do that is to use the MMFF94
 algorithms. Especially because I should be able to easily validate with
 PubChem, because their structures are delivered with MMFF94 charges.

 Open Babel has a fully validated implementation of MMFF94 and charges,
 thanks to Tim Vandermeersch. I think ChemKit also has a full MMFF94
 implementation, although you'd have to ask Kyle if he validated it.

 The MMFF94 atom types are quite opaque, and I'm not sure they can all be
 done via SMARTS. Tim hand-coded the aromaticity model and typing in
 src/forcefields/forcefieldmmff94.cpp.

 -Geoff




-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] [BlueObelisk-SMILES] help needed -- SMILES and MMFF94 atom types

[Robert Hanson]

OK, SMARTS-based MMFF94 charges are now checked in for Jmol.

Obviously the settings are not perfect and will take some tweaking. I'm
sure it's more complicate than I make it out to be -- probably some very
odd definitions in there; certainly some I could not fathom on this first
pass. I haven't taken a full look at OpenBabel's definitions, but I did use
the algorithm in OBForceFieldMMFF94::SetPartialCharges() as my basis (even
though some of that makes almost no sense to me -- for example:

  switch (type1) {
  case 32:
// 32  OXYGEN IN CARBOXYLATE ANION
// 32  NITRATE ANION OXYGEN
// 32  SINGLE TERMINAL OXYGEN ON TETRACOORD SULFUR
// 32  TERMINAL O-S IN SULFONES AND SULFONAMIDES
// 32  TERMINAL O IN SULFONATES
  case 35:
// 35  OXIDE OXYGEN ON SP2 CARBON, NEGATIVELY CHARGED
  case 72:
// 72  TERMINAL SULFUR BONDED TO PHOSPHORUS
factor = 0.5f;
break;
  case 62:
// 62  DEPROTONATED SULFONAMIDE N-; FORMAL CHARGE=-1
  case 76:
// 76  NEGATIVELY CHARGED N IN, E.G, TRI- OR TETRAZOLE ANION
factor = 0.25f;
break;
  }

What the heck is that? Convince me that is reasonable! (Or are these not
the MMFF94type numbers in MMFF-I_AppendixB.ascii?)

Jmol's aromatic definition is structural, not electronic, so that certainly
would be one point of difference.

Ideally it would be verified, but for a lot of purposes at least for now
I'll be satisfied with an approximation.

I can get partial charges from MMFF94 far easier from PubChem than I can
from OpenBabel, I think. All I have to do is

load :x

then  save the partial charges in an array and compare them with calculated
values:

load :methanol
A = {*}.partialcharge.all
calculate partialCharge
{*}.partialcharge = A.sub({*}.partialcharge.all)
label %[partialcharge]
print {*}.partialcharge.all.stddev

This will display the differences and print the standard deviation. I must
be doing something right, because I do get this:

$ load :methanol
...
0.0

$ load :acetone
...
8.1649824E-4

$ load :ethyl acetate
...
3.9223014E-4

$ load :benzene
...
0.0

$ load :pyridine
...
0.0

But I'm sure there are plenty that are problematic.

Caffeine must assign different atom types --

load :caffeine
A = {*}.partialcharge.all
calculate partialCharge
{*}.partialcharge = A.sub({*}.partialcharge.all)
label %[partialcharge]
print {*}.partialcharge.all.stddev
0.10437195

But that's what I expect at this stage. Can't expect everything to be
perfect in a day!

Can I get OpenBabel to report what MMFF94 atom types it is assigning?

Bob


On Fri, Apr 27, 2012 at 8:00 PM, Geoffrey Hutchison geo...@pitt.edu wrote:



  Geoff, I will look at that. What does fully validated mean exactly?

 There's an MMFF94 validation set:
 http://ccl.net/cca/data/MMFF94/

 This includes 761 structures, plus energies, etc. But one reason I bring
 this up, is that you can use Babel to generate partial charges (e.g., for
 mol2 files):
 echo c(s1)ccc1Cl | babel -ismi --gen3d --partialcharge mmff94 -omol2

 In short, feel free to use Babel to generate a pile of MMFF94 charges for
 testing. IIRC, the structures in the test set also have MMFF94 charges.

  I have the SMARTS business for MMFF94 charges working in Jmol now for
 getting the atom types -- obviously not validated! -- and I suspect it will
 require a bit of hand-crafting.

 We'd be interested in testing SMARTS versus the hand-crafted rules in Open
 Babel.

 Hope that helps,
 -Geoff




-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] [BlueObelisk-SMILES] help needed -- SMILES and MMFF94 atom types

[Robert Hanson]

I'm not understanding  the MMFF94 assumptions about formal charges. For
example, I have acetic acid

CC(=O)[O-1]

I believe both of these oxygens are MMFF94 type 32 (O, CARBOXYLATE ANION),
Is that correct? If so, how does MMFF94 handle the two different formal
charges? I'm not seeing that...



On Sat, Apr 28, 2012 at 1:03 AM, Robert Hanson hans...@stolaf.edu wrote:

 OK, SMARTS-based MMFF94 charges are now checked in for Jmol.

 Obviously the settings are not perfect and will take some tweaking. I'm
 sure it's more complicate than I make it out to be -- probably some very
 odd definitions in there; certainly some I could not fathom on this first
 pass. I haven't taken a full look at OpenBabel's definitions, but I did use
 the algorithm in OBForceFieldMMFF94::SetPartialCharges() as my basis (even
 though some of that makes almost no sense to me -- for example:

   switch (type1) {
   case 32:
 // 32  OXYGEN IN CARBOXYLATE ANION
 // 32  NITRATE ANION OXYGEN
 // 32  SINGLE TERMINAL OXYGEN ON TETRACOORD SULFUR
 // 32  TERMINAL O-S IN SULFONES AND SULFONAMIDES
 // 32  TERMINAL O IN SULFONATES
   case 35:
 // 35  OXIDE OXYGEN ON SP2 CARBON, NEGATIVELY CHARGED
   case 72:
 // 72  TERMINAL SULFUR BONDED TO PHOSPHORUS
 factor = 0.5f;
 break;
   case 62:
 // 62  DEPROTONATED SULFONAMIDE N-; FORMAL CHARGE=-1
   case 76:
 // 76  NEGATIVELY CHARGED N IN, E.G, TRI- OR TETRAZOLE ANION
 factor = 0.25f;
 break;
   }

 What the heck is that? Convince me that is reasonable! (Or are these not
 the MMFF94type numbers in MMFF-I_AppendixB.ascii?)

 Jmol's aromatic definition is structural, not electronic, so that
 certainly would be one point of difference.

 Ideally it would be verified, but for a lot of purposes at least for now
 I'll be satisfied with an approximation.

 I can get partial charges from MMFF94 far easier from PubChem than I can
 from OpenBabel, I think. All I have to do is

 load :x

 then  save the partial charges in an array and compare them with
 calculated values:

 load :methanol
 A = {*}.partialcharge.all
 calculate partialCharge
 {*}.partialcharge = A.sub({*}.partialcharge.all)
 label %[partialcharge]
 print {*}.partialcharge.all.stddev

 This will display the differences and print the standard deviation. I must
 be doing something right, because I do get this:

 $ load :methanol
 ...
 0.0

 $ load :acetone
 ...
 8.1649824E-4

 $ load :ethyl acetate
 ...
 3.9223014E-4

 $ load :benzene
 ...
 0.0

 $ load :pyridine
 ...
 0.0

 But I'm sure there are plenty that are problematic.

 Caffeine must assign different atom types --

 load :caffeine
 A = {*}.partialcharge.all
 calculate partialCharge
 {*}.partialcharge = A.sub({*}.partialcharge.all)
 label %[partialcharge]
 print {*}.partialcharge.all.stddev
 0.10437195

 But that's what I expect at this stage. Can't expect everything to be
 perfect in a day!

 Can I get OpenBabel to report what MMFF94 atom types it is assigning?

 Bob



 On Fri, Apr 27, 2012 at 8:00 PM, Geoffrey Hutchison geo...@pitt.eduwrote:



  Geoff, I will look at that. What does fully validated mean exactly?

 There's an MMFF94 validation set:
 http://ccl.net/cca/data/MMFF94/

 This includes 761 structures, plus energies, etc. But one reason I bring
 this up, is that you can use Babel to generate partial charges (e.g., for
 mol2 files):
 echo c(s1)ccc1Cl | babel -ismi --gen3d --partialcharge mmff94 -omol2

 In short, feel free to use Babel to generate a pile of MMFF94 charges for
 testing. IIRC, the structures in the test set also have MMFF94 charges.

  I have the SMARTS business for MMFF94 charges working in Jmol now for
 getting the atom types -- obviously not validated! -- and I suspect it will
 require a bit of hand-crafting.

 We'd be interested in testing SMARTS versus the hand-crafted rules in
 Open Babel.

 Hope that helps,
 -Geoff




 --
 Robert M. Hanson
 Professor of Chemistry
 St. Olaf College
 1520 St. Olaf Ave.
 Northfield, MN 55057
 http://www.stolaf.edu/people/hansonr
 phone: 507-786-3107


 If nature does not answer first what we want,
 it is better to take what answer we get.

 -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900




-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114

[BlueObelisk-discuss] OpenBabel question

[Robert Hanson]

OK, I'm stumped. How does one get to Rule d? Does anyone know if this code
was ever tested?

03131 if (b-GetBond
http://fossies.org/dox/openbabel-2.3.1/classOpenBabel_1_1OBAtom.html#a1383e1d49338b8ee6784b8b9ef889ba4(c)-IsAromatic
http://fossies.org/dox/openbabel-2.3.1/classOpenBabel_1_1OBBond.html#a737ac5dd55e68e9d29f6d368b403c7b1())
{03132   double Ub, Uc, pi_bc, beta;03133   Ub =
GetUParam 
http://fossies.org/dox/openbabel-2.3.1/classOpenBabel_1_1OBForceFieldMMFF94.html#a4dd261dbea68ff31a17a777e3a9efc8f(b);03134
  Uc = GetUParam
http://fossies.org/dox/openbabel-2.3.1/classOpenBabel_1_1OBForceFieldMMFF94.html#a4dd261dbea68ff31a17a777e3a9efc8f(c);03135
03136   if (!HasPilpSet
http://fossies.org/dox/openbabel-2.3.1/classOpenBabel_1_1OBForceFieldMMFF94.html#a01072db9ce803fb91ff6b73cd62ac03a(type_b)
 !HasPilpSet 
http://fossies.org/dox/openbabel-2.3.1/classOpenBabel_1_1OBForceFieldMMFF94.html#a01072db9ce803fb91ff6b73cd62ac03a(type_c))03137
pi_bc = 0.5;03138   else03139 pi_bc =
0.3;03140 03141   if (((GetVal
http://fossies.org/dox/openbabel-2.3.1/classOpenBabel_1_1OBForceFieldMMFF94.html#adf66fb6159cb5cfb695ef10ea85f9c43(type_b)
== 3)  (GetVal
http://fossies.org/dox/openbabel-2.3.1/classOpenBabel_1_1OBForceFieldMMFF94.html#adf66fb6159cb5cfb695ef10ea85f9c43(type_c)
== 4)) ||03142   ((GetVal
http://fossies.org/dox/openbabel-2.3.1/classOpenBabel_1_1OBForceFieldMMFF94.html#adf66fb6159cb5cfb695ef10ea85f9c43(type_b)
== 4)  (GetVal
http://fossies.org/dox/openbabel-2.3.1/classOpenBabel_1_1OBForceFieldMMFF94.html#adf66fb6159cb5cfb695ef10ea85f9c43(type_c)
== 3)))03143 beta = 3.0;03144   else03145
   beta = 6.0;03146 03147   torsioncalc.v1
http://fossies.org/dox/openbabel-2.3.1/classOpenBabel_1_1OBFFTorsionCalculationMMFF94.html#a56e54b9521cb38b2eaec90d6530ca46b
= 0.0;03148   torsioncalc.v2
http://fossies.org/dox/openbabel-2.3.1/classOpenBabel_1_1OBFFTorsionCalculationMMFF94.html#af5a97920571660315ee3a8bbbd8c90a0
= beta * pi_bc * sqrt(Ub * Uc);03149   torsioncalc.v3
http://fossies.org/dox/openbabel-2.3.1/classOpenBabel_1_1OBFFTorsionCalculationMMFF94.html#a2cf47c38afaedf54148e8ff0eae629f8
= 0.0;03150   found_rule = true;03151 } else {03152
   // rule (c) page 63103153   double Ub, Uc, pi_bc,
beta;03154   Ub = GetUParam
http://fossies.org/dox/openbabel-2.3.1/classOpenBabel_1_1OBForceFieldMMFF94.html#a4dd261dbea68ff31a17a777e3a9efc8f(b);03155
  Uc = GetUParam
http://fossies.org/dox/openbabel-2.3.1/classOpenBabel_1_1OBForceFieldMMFF94.html#a4dd261dbea68ff31a17a777e3a9efc8f(c);03156
03157   if (((GetMltb
http://fossies.org/dox/openbabel-2.3.1/classOpenBabel_1_1OBForceFieldMMFF94.html#a8d8291470b39dfecb4c66362b5e302c4(type_b)
== 2)  (GetMltb
http://fossies.org/dox/openbabel-2.3.1/classOpenBabel_1_1OBForceFieldMMFF94.html#a8d8291470b39dfecb4c66362b5e302c4(type_c)
== 2))  a-GetBond
http://fossies.org/dox/openbabel-2.3.1/classOpenBabel_1_1OBAtom.html#a1383e1d49338b8ee6784b8b9ef889ba4(b)-IsDouble
http://fossies.org/dox/openbabel-2.3.1/classOpenBabel_1_1OBBond.html#a51a42be9b514d0250330eb4204276d35())03158
pi_bc = 1.0;03159   else03160 pi_bc =
0.4;03161 03162   beta = 6.0;03163   torsioncalc.v1
http://fossies.org/dox/openbabel-2.3.1/classOpenBabel_1_1OBFFTorsionCalculationMMFF94.html#a56e54b9521cb38b2eaec90d6530ca46b
= 0.0;03164   torsioncalc.v2
http://fossies.org/dox/openbabel-2.3.1/classOpenBabel_1_1OBFFTorsionCalculationMMFF94.html#af5a97920571660315ee3a8bbbd8c90a0
= beta * pi_bc * sqrt(Ub * Uc);03165   torsioncalc.v3
http://fossies.org/dox/openbabel-2.3.1/classOpenBabel_1_1OBFFTorsionCalculationMMFF94.html#a2cf47c38afaedf54148e8ff0eae629f8
= 0.0;03166   found_rule = true;03167 }03168 03169
// rule (d) page 63203170 if (!found_rule)03171
if (((GetCrd 
http://fossies.org/dox/openbabel-2.3.1/classOpenBabel_1_1OBForceFieldMMFF94.html#a7c08f7eff3b784428708f49582334a5c(type_b)
== 4)  (GetCrd
http://fossies.org/dox/openbabel-2.3.1/classOpenBabel_1_1OBForceFieldMMFF94.html#a7c08f7eff3b784428708f49582334a5c(type_c)
== 4))) {03172 double Vb, Vc;03173


-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. 

Re: [BlueObelisk-discuss] help needed -- SMILES and MMFF94 atom types

[Robert Hanson]

follow-up on this. Over the last few days I was able to extend this to
fully validated MMFF94 minimization capability in Jmol with empirical
rules. Here's a summary of what I just checked in.

version=12.3.26_dev

# code: adding empirical rules to MMFF94 calculation
#
# checkmm.spt;checkAllEnergies

#   checking calculated energies for 761 models
#  1  COMKAQ E=   -7.3250003   Eref=  -7.6177diff=  0.2926998
#  2  DUVHUX10   E=   64.759995Eref=  64.082855  diff=  0.6771393
#  3  FORJIF E=   35.978   Eref=  35.833878  diff=  0.14412308
#  4  JADLIJ E=   25.104   Eref=  24.7038diff=  0.4001999
#  5  PHOSLA10   E=   111.232994   Eref=  112.07078  diff=  0.8377838
#  6  PHOSLB10   E=   -93.479004   Eref=  -92.64081  diff=  0.8381958
#  7  OHMW1  E=   -20.78   Eref=  -21.726902 diff=  0.9469013

# for 761 atoms, 7 have energies differences outside the
# range -0.1 to 0.1 with a standard deviation of 0.06309618


COMKAQ
 -- BATCHMIN ignores 1 of 5-membered ring torsions for a
1-oxo-2-oxa-bicyclo[3.2.0]heptane
 -- MMFF94_bmin.log: WARNING - Conformational Energies May Not Be Accurate

DUVHUX10
 -- BATCHMIN ignores 5-membered ring issue for S-S-containing ring
 -- MMFF94_bmin.log: WARNING - Conformational Energies May Not Be Accurate

FORJIF
 -- BATCHMIN misses four standard 5-membered C-C ring bonds
 -- MMFF94_bmin.log: WARNING - Conformational Energies May Not Be Accurate

JADLIJ
 -- BATCHMIN ignores 5-membered ring for S (note, however, this is not the
case in BODKOU)
 -- MMFF94_bmin.log: WARNING - Conformational Energies May Not Be Accurate

PHOSLA10
 -- BATCHMIN ignores all 5-membered ring torsions in ring with P
 -- (note, however, this is not the case in CUVGAB)
 -- MMFF94_bmin.log: WARNING - Conformational Energies May Not Be Accurate

PHOSLB10
 -- BATCHMIN ignores all 5-membered ring torsions in ring with P
 -- (note, however, this is not the case in CUVGAB)
 -- MMFF94_bmin.log: WARNING - Conformational Energies May Not Be Accurate

OHMW1
 -- H2O complexed with hydroxide OH(-)
 -- I don't understand (a) why the OH(-) bond has mltb=1, and even with that
I am not getting the correct ro/kb for that bond from empirical rules.
Still working on that


I think SMARTS was definitely the way to go on this.
-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] help needed -- SMILES and MMFF94 atom types

[Robert Hanson]

Here's my final result. I'm satisfied; I'm pretty sure there is no way to
reproduce the results of the OPTIMOL results exactly. In the cases below
I'm convinced there are bugs in OPTIMOL -- mostly in not consistently
recognizing  5-membered rings, but also there is something odd going on in
the empirical bond parameter calculation.

Bob

# version=12.3.26_dev
#
# code: adding empirical rules to MMFF94 calculation
#
# checkmm.spt;checkAllEnergies
#
# checking calculated energies for 761 models
# 1 COMKAQ E=   -7.3250003   Eref=  -7.6177diff=  0.2926998
# 2 DUVHUX10   E=   64.759995Eref=  64.082855  diff=  0.6771393
# 3 FORJIF E=   35.978   Eref=  35.833878  diff=  0.14412308
# 4 JADLIJ E=   25.104   Eref=  24.7038diff=  0.4001999
# 5 PHOSLA10   E=   111.232994   Eref=  112.07078  diff=  0.8377838
# 6 PHOSLB10   E=   -93.479004   Eref=  -92.64081  diff=  0.8381958
#
# for 761 models, 6 have energy differences outside the range -0.1 to 0.1
# with a standard deviation of 0.05309403
#
# a comment about empirical bond parameter calculation:
#
#// Well, guess what? As far as I can tell, in Eqn 18 on page 625,
#// the reduction term and delta are zero.
#
#// -- at least in the program run that is at the validation site:
#//  OPTIMOL: Molecular and Macromolecular Optimization Package
17-Nov-98 16:01:23
#// SGI double-precision version ... Updated 5/6/98
#//
#// This calculation is run only for the following three structures. In
each case the
#// reported validation values and values from Jmol 12.3.26_dev are
shown. Clearly
#// the r0 calculated and final energies are very good. subtracting off
0.008 from
#// r0 would certainly not give the reported values. Something is odd
there.
#//
#// bond  red* r0(here/valid)  kb(here/valid)
Etotal(here/valid)
#//
---
#// OHWM1   H1-O1 0.03  0.978/0.978   7.510/7.51
-21.727/-21.72690
#// ERULE_03Si1-P10.0   2.223/2.224   1.614/1.609
-2.983/ -2.93518
#// ERULE_06N1-F1 0.0   1.381/1.379   5.372/5.438
1.582/  1.58172
#//
#// *reduction and delta terms not used in Jmol's calculation
#
#

-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] OpenBabel question

[Robert Hanson]

Hi, Tim, what are you up to these days?

Please take a look at the code I just checked in for Jmol --
org.jmol.minimize.forcefieldsForceFieldMMFF.java

http://jmol.svn.sourceforge.net/viewvc/jmol/trunk/Jmol/src/org/jmol/minimize/forcefield/ForceFieldMMFF.java?view=markup

  private Integer applyEmpiricalRules(MinObject o, double[] ddata, int
ktype)

I think I simplified that logic considerably. Also, I would appreciate it
if you would take a look at

  private static double getRuleBondLength(MinAtom a, MinAtom b, int boAB,
boolean isAromatic)

Seems odd, and there are so few examples that I can't be sure what the
issue is. It validates, but...

Bob

On Sat, May 19, 2012 at 10:29 AM, Tim Vandermeersch 
tim.vandermeer...@gmail.com wrote:

 Hi,

 This is obviously a bug, I'll try to correct this in the following
 week unless you beat me to it.

 Tim

 On Fri, May 18, 2012 at 5:03 AM, Robert Hanson hans...@stolaf.edu wrote:
  OK, I'm stumped. How does one get to Rule d? Does anyone know if this
 code
  was ever tested?
 
  03131 if (b-GetBond(c)-IsAromatic()) {
  03132   double Ub, Uc, pi_bc, beta;
  03133   Ub = GetUParam(b);
  03134   Uc = GetUParam(c);
  03135
  03136   if (!HasPilpSet(type_b)  !HasPilpSet(type_c))
  03137 pi_bc = 0.5;
  03138   else
  03139 pi_bc = 0.3;
  03140
  03141   if (((GetVal(type_b) == 3)  (GetVal(type_c) == 4)) ||
  03142   ((GetVal(type_b) == 4)  (GetVal(type_c) == 3)))
  03143 beta = 3.0;
  03144   else
  03145 beta = 6.0;
  03146
  03147   torsioncalc.v1 = 0.0;
  03148   torsioncalc.v2 = beta * pi_bc * sqrt(Ub * Uc);
  03149   torsioncalc.v3 = 0.0;
  03150   found_rule = true;
  03151 } else {
  03152   // rule (c) page 631
  03153   double Ub, Uc, pi_bc, beta;
  03154   Ub = GetUParam(b);
  03155   Uc = GetUParam(c);
  03156
  03157   if (((GetMltb(type_b) == 2)  (GetMltb(type_c) == 2)) 
  a-GetBond(b)-IsDouble())
  03158 pi_bc = 1.0;
  03159   else
  03160 pi_bc = 0.4;
  03161
  03162   beta = 6.0;
  03163   torsioncalc.v1 = 0.0;
  03164   torsioncalc.v2 = beta * pi_bc * sqrt(Ub * Uc);
  03165   torsioncalc.v3 = 0.0;
  03166   found_rule = true;
  03167 }
  03168
  03169 // rule (d) page 632
  03170 if (!found_rule)
  03171   if (((GetCrd(type_b) == 4)  (GetCrd(type_c) == 4))) {
  03172 double Vb, Vc;
  03173
 
 
  --
  Robert M. Hanson
  Professor of Chemistry
  St. Olaf College
  1520 St. Olaf Ave.
  Northfield, MN 55057
  http://www.stolaf.edu/people/hansonr
  phone: 507-786-3107
 
 
  If nature does not answer first what we want,
  it is better to take what answer we get.
 
  -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
 
 
 --
  Live Security Virtual Conference
  Exclusive live event will cover all the ways today's security and
  threat landscape has changed and how IT managers can respond. Discussions
  will include endpoint security, mobile security and the latest in malware
  threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
  ___
  Blueobelisk-discuss mailing list
  Blueobelisk-discuss@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
 




-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] Java Vulnerability Note VU#636312

[Robert Hanson]

One point might be being missed here. All this is in relation to Java
applets, not any stand-alone Java applications. It's a browser problem
only. So the concern should be for the Jmol applet, not the Jmol
application or JmolData (server-side Jmol).

We've already started porting Jmol to JavaScript. We'll see about
performance, but we believe we can implement essentially all the capability
of Jmol, including scripting, in JavaScript. Won't be this week

Bob Hanson



-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Chemistry Department
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] [Jmol-users] PDB - OK, who's the wise guy?

[Robert Hanson]

Thanks, Andrew, that history helps. And I must say, the hybrid-36 scheme
really is very clever. You would probably like the base-90 scheme I cooked
up for the JVXL surface file format.

Unlike Peter, I have no problem with custom specifications, as long as they
are clear, unambiguous, and published. Something like this should not have
to be discovered 100,000 lines into a file. It would have been immensely
helpful if there had been a required REMARK record to the effect that atom
numbers/residue numbers were in some specific format. Far too often someone
comes up with a solution to their problem for their program and implements
it without ever considering how it might impact other programs. As it is,
Jmol, for instance, with some tweaks, can now read a file with both the
hybrid-36 and Schroedinger's HEX solution (upon the next release), but it
involves additional checking just to be able to be on the look-out for this
issue, and that potentially slows down all PDB file reading by Jmol (or any
other program).

Bob



On Sun, Jan 20, 2013 at 8:14 PM, Andrew Dalke da...@dalkescientific.comwrote:

 On Jan 20, 2013, at 1:08 PM, Andrew Dalke wrote:
  For kicks, I pulled up my copy of the PDB format from 1974. It says that
  the PDB file has: COMPND, AUTHOR, CRYST1, DECODE, REMARK

 Err, that was supposed to be deleted. I found that I didn't have a complete
 spec, dug through the old PDB newsletters, looked for old printouts in my
 files, couldn't find it, got distracted, and managed to forget to delete
 these two lines.

 So I don't know if the 1970s spec says that those files were supposed to
 be in every PDB file, but I'm pretty certain that they were in every file
 that they distributed.

 Andrew
 da...@dalkescientific.com




 --
 Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
 MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
 with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
 MVPs and experts. SALE $99.99 this month only -- learn more at:
 http://p.sf.net/sfu/learnmore_122412
 ___
 Blueobelisk-discuss mailing list
 Blueobelisk-discuss@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss




-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Chemistry Department
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] dinner at ACS meeting in New Orleans?

[Robert Hanson]

I will be there just Sat - Tuesday. Either a late dinner Sunday (8 pm) or
anytime Monday would work for me. Very eager to reconnect with my favorite
group!

Bob



On Thu, Mar 7, 2013 at 2:53 AM, John P. Overington j...@ebi.ac.uk wrote:

 I'll be there too.

 jpo

 --
 John P. Overington, BSc PhD MBCS FRSC C.Chem.

 Head of Chemistry and Molecular Systems Resources
 European Bioinformatics Institute (EMBL-EBI)
 Wellcome Trust Genome Campus
 Hinxton
 Cambridgeshire
 CB10 1SD
 United Kingdom

 mail: j...@ebi.ac.uk   admin: khol...@ebi.ac.uk
 phone: +44-1223-492666skype: john.overington
  twitter: @chembl








 On 6 Mar 2013, at 15:52, Egon Willighagen egon.willigha...@gmail.com
 wrote:

 Hi all,

 who else is going to the ACS meeting in New Orleans in April and like
 to join a Blue Obelisk dinner/drink?

 Egon


 --
 Dr E.L. Willighagen
 Postdoctoral Researcher
 Department of Bioinformatics - BiGCaT
 Maastricht University (http://www.bigcat.unimaas.nl/)
 Homepage: http://egonw.github.com/
 LinkedIn: http://se.linkedin.com/in/egonw
 Blog: http://chem-bla-ics.blogspot.com/
 PubList: http://www.citeulike.org/user/egonw/tag/papers


 --
 Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
 Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the
 endpoint security space. For insight on selecting the right partner to
 tackle endpoint security challenges, access the full report.
 http://p.sf.net/sfu/symantec-dev2dev
 ___
 Blueobelisk-discuss mailing list
 Blueobelisk-discuss@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss




 --
 Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
 Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the
 endpoint security space. For insight on selecting the right partner to
 tackle endpoint security challenges, access the full report.
 http://p.sf.net/sfu/symantec-dev2dev
 ___
 Blueobelisk-discuss mailing list
 Blueobelisk-discuss@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss




-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Chemistry Department
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] dinner at ACS meeting in New Orleans?

[Robert Hanson]

ps --  if you haven't been following the Jmol list, maybe you don't know,
but we have a fully functional JavaScript-only version of Jmol now. Totally
optimized, compartmentalized, and language-localized duplicate of Jmol but
without Java. And it's speed is reasonably good. Best of all, all the
development is done in Java still. See
http://chemapps.stolaf.edu/jmol/jsmol/jsmol.htm  - reads PyMOL session
files, too!

Bob



On Wed, Mar 20, 2013 at 4:52 PM, Robert Hanson hans...@stolaf.edu wrote:

 I will be there just Sat - Tuesday. Either a late dinner Sunday (8 pm) or
 anytime Monday would work for me. Very eager to reconnect with my favorite
 group!

 Bob



 On Thu, Mar 7, 2013 at 2:53 AM, John P. Overington j...@ebi.ac.uk wrote:

 I'll be there too.

 jpo

   --
 John P. Overington, BSc PhD MBCS FRSC C.Chem.

 Head of Chemistry and Molecular Systems Resources
 European Bioinformatics Institute (EMBL-EBI)
 Wellcome Trust Genome Campus
 Hinxton
 Cambridgeshire
 CB10 1SD
 United Kingdom

 mail: j...@ebi.ac.uk   admin: khol...@ebi.ac.uk
 phone: +44-1223-492666skype: john.overington
  twitter: @chembl








 On 6 Mar 2013, at 15:52, Egon Willighagen egon.willigha...@gmail.com
 wrote:

 Hi all,

 who else is going to the ACS meeting in New Orleans in April and like
 to join a Blue Obelisk dinner/drink?

 Egon


 --
 Dr E.L. Willighagen
 Postdoctoral Researcher
 Department of Bioinformatics - BiGCaT
 Maastricht University (http://www.bigcat.unimaas.nl/)
 Homepage: http://egonw.github.com/
 LinkedIn: http://se.linkedin.com/in/egonw
 Blog: http://chem-bla-ics.blogspot.com/
 PubList: http://www.citeulike.org/user/egonw/tag/papers


 --
 Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
 Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the
 endpoint security space. For insight on selecting the right partner to
 tackle endpoint security challenges, access the full report.
 http://p.sf.net/sfu/symantec-dev2dev
 ___
 Blueobelisk-discuss mailing list
 Blueobelisk-discuss@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss




 --
 Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
 Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the
 endpoint security space. For insight on selecting the right partner to
 tackle endpoint security challenges, access the full report.
 http://p.sf.net/sfu/symantec-dev2dev
 ___
 Blueobelisk-discuss mailing list
 Blueobelisk-discuss@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss




 --
 Robert M. Hanson
 Larson-Anderson Professor of Chemistry
 Chair, Chemistry Department
 St. Olaf College
 Northfield, MN
 http://www.stolaf.edu/people/hansonr


 If nature does not answer first what we want,
 it is better to take what answer we get.

 -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900




-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Chemistry Department
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] dinner at ACS meeting in New Orleans?

[Robert Hanson]

suberb idea!!


On Wed, Apr 3, 2013 at 12:35 PM, Egon Willighagen 
egon.willigha...@gmail.com wrote:

 On Wed, Apr 3, 2013 at 10:35 AM, Noel O'Boyle baoille...@gmail.com
 wrote:
  Sunday after CINF reception?

 Yeah, that should work for me too, I think.

 Egon

 --
 Dr E.L. Willighagen
 Postdoctoral Researcher
 Department of Bioinformatics - BiGCaT
 Maastricht University (http://www.bigcat.unimaas.nl/)
 Homepage: http://egonw.github.com/
 LinkedIn: http://se.linkedin.com/in/egonw
 Blog: http://chem-bla-ics.blogspot.com/
 PubList: http://www.citeulike.org/user/egonw/tag/papers


 --
 Minimize network downtime and maximize team effectiveness.
 Reduce network management and security costs.Learn how to hire
 the most talented Cisco Certified professionals. Visit the
 Employer Resources Portal
 http://www.cisco.com/web/learning/employer_resources/index.html
 ___
 Blueobelisk-discuss mailing list
 Blueobelisk-discuss@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss




-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Chemistry Department
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] Best wishes from the COD team!

[Robert Hanson]

Saulius,

Welcome!

Do you know about all the cool crystallographic capabilities of Jmol?
Latest is incommensurately modulated structures.

Let's talk!

Bob Hanson



On Mon, Feb 10, 2014 at 5:37 AM, Saulius Gražulis grazu...@ibt.lt wrote:

 Dear colleagues,

 during the two very exciting weeks of hacking with Peter Murray-Rust, in
 Vilnius, he suggested that I join the Blue Obelisk community and the
 mailing list.

 Let me introduce myself: I am currently heading the Vilnius team of the
 Crystallography Open Database, and maintain the database site at the
 Vilnius University Institute of Biotechnology
 (http://www.crystallography.net). As such, I am very interested in
 (co)-developing free software for chemistry and crystallography, and
 sharing data. You are cordially invited to use COD, to download COD and
 to contribute to its development if you wish.

 Another project which we have started recently, and which I would like
 to discuss and coordinate with you, is the Theoretical Crystallography
 Open Database (TCOD, http://www.crystallography.net/tcod/). After our
 successful development of COD (which contains experimental crystal
 structures), and after several requests from a community, we have
 started TCOD to collect published structures, computed using DFT and
 other methods.

 Peter has told me that the NWChem group, who is present on this mailing
 list :), has done a large work in developing ontologies to describe
 various computational methods and encode (meta)data in CML. It seems to
 me like a good idea to join our efforts, to make a set of descriptions
 and quality criteria endorsed by computational community, and to have a
 comprehensive representation of computation results in TCOD.

 I'm looking forward to hear from you!

 Sincerely,
 Saulius

 P.S. In a short while, I'll post another message regarding presentation
 of TCOD at the IUCr 2014 Congress in Montreal.

 --
 Dr. Saulius Gražulis
 Vilnius University Institute of Biotechnology, Graiciuno 8
 LT-02241 Vilnius, Lietuva (Lithuania)
 fax: (+370-5)-2602116 / phone (office): (+370-5)-2602556
 mobile: (+370-684)-49802, (+370-614)-36366


 --
 Managing the Performance of Cloud-Based Applications
 Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
 Read the Whitepaper.

 http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk
 ___
 Blueobelisk-discuss mailing list
 Blueobelisk-discuss@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss




-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Androidtrade; apps run on BlackBerryreg;10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] BODR covalent radii patch (all elements)

[Robert Hanson]

Thank you very much for this update, Bert. I have added it to Jmol as
atom.covalentRadius, and you can, for example, illustrate those in Jmol
14.1.11 using

  {*}.radius = {*}.covalentRadius.all




On Thu, Feb 20, 2014 at 1:07 AM, Wibe de Jong wadej...@lbl.gov wrote:

 Hi,

 I have updated the covalent radii for all 118 elements following the
 definition of one consistent set of radii published Pyykko and Atsumi in
 Chem. Eur. J. published in 2009. This addresses all elements for which the
 radii were not given (mainly heavy elements), and updates others.

 The git pull request can be found at https://github.com/egonw/bodr

 Please peer review, comment, and apply.

 Thanks,

 Bert


 --
 Managing the Performance of Cloud-Based Applications
 Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
 Read the Whitepaper.

 http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk
 ___
 Blueobelisk-discuss mailing list
 Blueobelisk-discuss@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss




-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

[BlueObelisk-discuss] referencing of data

[Robert Hanson]

Can someone explain to me the general schema for referencing data in the
BODR? I'm not seeing it. For example, at

https://github.com/wadejong/bodr/tree/c7917225cad829507bdd4c8c2fe7ebd3d795c021/bodr/elements

I see xml and bibxml files, but I see nothing that connects those. Just
randomly named files. Is there something in, for example, elements.xml,
that points one to the specific bibxml for a specific entry?

Bob


-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

[BlueObelisk-discuss] great InChI JavaScript library

[Robert Hanson]

inchi.js is great fun. It is now part of JSmol. See the demo at:

http://chemapps.stolaf.edu/jmol/jsmol/inchi.htm

and http://chemapps.stolaf.edu/jmol/zip/jmol-14.4.3_2016.03.08.zip

Whom do we have to thank for this? Noel?

Bob



-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Department of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

[BlueObelisk-discuss] inchi.js

[Robert Hanson]

This is quite cool. Does anyone know how to make it work? What its API
looks like? I would like to add this to JSmol. But  when I followed the
instructions at

https://github.com/metamolecular/inchi-js

using Firefox I see in the developer console:

*Successfully compiled asm.js code (loaded from cache in 148ms)*

but no InChI object is present on the page. What am I doing wrong?

Bob Hanson

-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Department of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] Two Google Summer of Code projects related to the CDK

[Robert Hanson]

On Tue, Mar 1, 2016 at 7:49 AM, Egon Willighagen  wrote:

> Hi all,
>
> Now, Noel asked about a JS translation of the CDK stack. That would be
> a lot more work, and not sure if it is entirely feasible, but I'm more
> than happy to discuss that with the student applicant and co-mentor.
>
>
Now THERE's a challenge! Java2Script could probably manage this. But in my
experience, performance would suffer considerably without careful attention
to detail. The cool thing, of course, is that if you used Java2Script, then
you would have a consistent Java/JavaScript code synchronization. This is
probably the
coolest thing about Java2Script. You get to keep going with all development
in Java only. Not a one-time port.

Note that you would need full source for all accessed third-party JAR files.

A quick look at the CDK suggests openscience/cdk has something like 15,000
methods.  The initial conversion would be relatively easy, provided all the
source there; validation and optimization would be the real chore.

I only have experience with Java2Script. I love it. Anyone have any other
ideas?

BTW I am not volunteering to do this

Bob

Bob
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] owner/operator of online web service for CDK?

[Robert Hanson]

And, here it is!

https://chemapps.stolaf.edu/olcc/examples/js/CDK_image_JS.htm

Very slick! All suggestions welcome at

http://olcc.ccce.divched.org/content/prog-access

by the way...

Bob

On Tue, Aug 30, 2016 at 11:09 PM, Robert Hanson <hans...@stolaf.edu> wrote:

> No, I had not seen that. Fantastic! Just what I need. I will clone this
> for the OLCC course right now!
>
> On Tue, Aug 30, 2016 at 7:22 AM, Egon Willighagen <
> egon.willigha...@gmail.com> wrote:
>
>> On Tue, Aug 30, 2016 at 2:16 PM, Robert Hanson <hans...@stolaf.edu>
>> wrote:
>> > Maybe some of you want to help!
>>
>> Want is one thing... actually have time (read: some good reason to
>> spend project hours on it...), that's another...
>>
>> Bob, you may also be interested in John May's 2D depiction, but I
>> guess you already have seen that:
>> https://cdkdepict-openchem.rhcloud.com/depict.html
>>
>> I may be able to do some proofreading, which I did a bit in the past
>> too... Robert Belford tried to get my support a long time ago, and it
>> has my full moral support, but I don't have any cheminformatics
>> courses I teach right now, so no course material development time :(
>>
>> Egon
>>
>> > On Tue, Aug 30, 2016 at 7:13 AM, Egon Willighagen <
>> egon.willigha...@gmail.com> wrote:
>> >>
>> >>
>> >> Rajarshi, Ola,
>> >>
>> >> where is the code base? Then I can look at updating the code. The QSAR
>> stack has not changed a lot, neither has the SMILES parsing API. I think I
>> can fix it without much trouble, if there is a git repository and build
>> instructions...
>> >>
>> >> Then Ola and I can look at updating the instance in two weeks when I'm
>> visiting his lab.
>> >>
>> >> Egon
>> >>
>> >>
>> >> On Tue, Aug 30, 2016 at 10:21 AM, Ola Spjuth <ola.spj...@farmbio.uu.se>
>> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> Yes, I can confirm that we have been hosting this for some time. We
>> used it in the past, but I dot think we are using it anymore. I would be
>> happy to continue hosting an updated version.
>> >>>
>> >>> Ola
>> >>>
>> >>>
>> >>> On 30 aug. 2016, at 03:04, Rajarshi Guha <rajarshi.g...@gmail.com>
>> wrote:
>> >>>
>> >>> I think Ola Spjuth was/is hosting this.
>> >>>
>> >>> The code is a set of REST services described at http://rest.rguha.net
>> - it hasn't been updated in many years. The JAR file should run and the
>> code should compile (I think it includes the relevant CDK dependencies).
>> >>>
>> >>> But it's many version behind the latest CDK, so I would'nt suggest
>> using this for production
>> >>>
>> >>> On Mon, Aug 29, 2016 at 7:48 PM, Robert Hanson <hans...@stolaf.edu>
>> wrote:
>> >>>>
>> >>>> Does anyone know whom to contact in relation to this site?
>> >>>>
>> >>>> Cross-Origin Request Blocked: The Same Origin Policy disallows
>> reading the remote resource at http://ws1.bmc.uu.se:8182/cdk/
>> descriptor/org.openscience.cdk.qsar.descriptors.molecular.Ru
>> leOfFiveDescriptor/CCCOCOC. (Reason: CORS header
>> 'Access-Control-Allow-Origin' missing).
>> >>>>
>> >>>> It looks like a great site, but (a) I can't find any documentation
>> on it and (b) it isn't accessible by AJAX.
>> >>>>
>> >>>> Bob Hanson
>> >>>>
>> >>>> --
>> >>>> Robert M. Hanson
>> >>>> Larson-Anderson Professor of Chemistry
>> >>>> St. Olaf College
>> >>>> Northfield, MN
>> >>>> http://www.stolaf.edu/people/hansonr
>> >>>>
>> >>>>
>> >>>> If nature does not answer first what we want,
>> >>>> it is better to take what answer we get.
>> >>>>
>> >>>> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>> >>>>
>> >>>>
>> >>>> 
>> --
>> >>>>
>> >>>> ___
>> >>>> Blueobelisk-discuss mailing list
>> >>>> Blueobelisk-discuss@lists.sourceforge.net
>

Re: [BlueObelisk-discuss] owner/operator of online web service for CDK?

[Robert Hanson]

I'd like to showcase this in an on line cheminformatics course.

http://olcc.ccce.divched.org/

Maybe some of you want to help!

Bob

On Tue, Aug 30, 2016 at 7:13 AM, Egon Willighagen <
egon.willigha...@gmail.com> wrote:

>
> Rajarshi, Ola,
>
> where is the code base? Then I can look at updating the code. The QSAR
> stack has not changed a lot, neither has the SMILES parsing API. I think I
> can fix it without much trouble, if there is a git repository and build
> instructions...
>
> Then Ola and I can look at updating the instance in two weeks when I'm
> visiting his lab.
>
> Egon
>
>
> On Tue, Aug 30, 2016 at 10:21 AM, Ola Spjuth <ola.spj...@farmbio.uu.se>
> wrote:
>
>> Hi,
>>
>> Yes, I can confirm that we have been hosting this for some time. We used
>> it in the past, but I dot think we are using it anymore. I would be happy
>> to continue hosting an updated version.
>>
>> Ola
>>
>>
>> On 30 aug. 2016, at 03:04, Rajarshi Guha <rajarshi.g...@gmail.com> wrote:
>>
>> I think Ola Spjuth was/is hosting this.
>>
>> The code is a set of REST services described at http://rest.rguha.net -
>> it hasn't been updated in many years. The JAR file should run and the code
>> should compile (I think it includes the relevant CDK dependencies).
>>
>> But it's many version behind the latest CDK, so I would'nt suggest using
>> this for production
>>
>> On Mon, Aug 29, 2016 at 7:48 PM, Robert Hanson <hans...@stolaf.edu>
>> wrote:
>>
>>> Does anyone know whom to contact in relation to this site?
>>>
>>> Cross-Origin Request Blocked: The Same Origin Policy disallows reading
>>> the remote resource at http://ws1.bmc.uu.se:8182/cdk/
>>> descriptor/org.openscience.cdk.qsar.descriptors.molecular.Ru
>>> leOfFiveDescriptor/CCCOCOC. (Reason: CORS header
>>> 'Access-Control-Allow-Origin' missing).
>>>
>>> It looks like a great site, but (a) I can't find any documentation on it
>>> and (b) it isn't accessible by AJAX.
>>>
>>> Bob Hanson
>>>
>>> --
>>> Robert M. Hanson
>>> Larson-Anderson Professor of Chemistry
>>> St. Olaf College
>>> Northfield, MN
>>> http://www.stolaf.edu/people/hansonr
>>>
>>>
>>> If nature does not answer first what we want,
>>> it is better to take what answer we get.
>>>
>>> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>>>
>>>
>>> 
>>> --
>>>
>>> ___
>>> Blueobelisk-discuss mailing list
>>> Blueobelisk-discuss@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
>>>
>>>
>>
>>
>> --
>> Rajarshi Guha | http://blog.rguha.net
>> NIH Center for Advancing Translational Science
>> 
>> --
>> ___
>> Blueobelisk-discuss mailing list
>> Blueobelisk-discuss@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
>>
>>
>>
>> 
>> --
>>
>> ___
>> Blueobelisk-discuss mailing list
>> Blueobelisk-discuss@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
>>
>>
>
>
> --
> E.L. Willighagen
> Department of Bioinformatics - BiGCaT
> Maastricht University (http://www.bigcat.unimaas.nl/)
> Homepage: http://egonw.github.com/
> LinkedIn: http://se.linkedin.com/in/egonw
> Blog: http://chem-bla-ics.blogspot.com/
> PubList: http://www.citeulike.org/user/egonw/tag/papers
> ORCID: -0001-7542-0286
> ImpactStory: https://impactstory.org/EgonWillighagen
>
> 
> --
>
> ___
> Blueobelisk-discuss mailing list
> Blueobelisk-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
>
>


-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] Fwd: Cahn-Ingold-Prelog rules into Jmol

[Robert Hanson]

OK, so I am reading Chapter 9 now to see the gory details. I didn't know
about the root-distance check, and so now

1-(bicyclo[2.2.2]octan-1-yl)-1-[1,5-dicyclopropyl-3(2-cyclo
propylethyl)-pentan-3-yl]methan-1-ol.mol

is working. So all of this is easy enough. That's probably it for
independent stereochemistry.  Where there is a dependency  of one
stereochemical determination from another -- R/S after E/Z; E/Z after R/S,
E/Z after E/Z, R/S after R/S -- obviously that takes some sort of more
general iteration.

I think I will have to tackle that another day.

Bob





On Sun, Apr 9, 2017 at 11:03 AM, John Mayfield <john.wilkinson...@gmail.com>
wrote:

> Good good,
>
> Fake news before fake news - a paper published in the CCG journal by the
> CCG.
>
> John
>
> On 9 April 2017 at 16:51, Robert Hanson <hans...@stolaf.edu> wrote:
>
>> No, John. Don't worry.  I just happened to look at that page prior to
>> designing my own.
>>
>> On Sun, Apr 9, 2017 at 10:44 AM, John Mayfield <
>> john.wilkinson...@gmail.com> wrote:
>>
>>> Hi Bob,
>>>
>>> On 9 April 2017 at 13:42, Robert Hanson <hans...@stolaf.edu> wrote:
>>>
>>>> [I actually do know it is Cahn; pulled "Cohen" without thinking from
>>>> https://www.chemcomp.com/journal/chiral.htm. Serves me right. Duh!]
>>>>
>>>
>>> Was that the algorithm you implemented because it's not correct - it
>>> doesn't (and can't) handle ghost atoms. Trying to track down the example
>>> but Daniel Lowe constructed a small reproducible example to demonstrate why
>>> this can never work.
>>>
>>> John
>>>
>>>
>>> 
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> Blueobelisk-discuss mailing list
>>> Blueobelisk-discuss@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
>>>
>>>
>>
>>
>> --
>> Robert M. Hanson
>> Larson-Anderson Professor of Chemistry
>> St. Olaf College
>> Northfield, MN
>> http://www.stolaf.edu/people/hansonr
>>
>>
>> If nature does not answer first what we want,
>> it is better to take what answer we get.
>>
>> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>>
>>
>


-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] Fwd: Cahn-Ingold-Prelog rules into Jmol

[Robert Hanson]

No, John. Don't worry.  I just happened to look at that page prior to
designing my own.

On Sun, Apr 9, 2017 at 10:44 AM, John Mayfield <john.wilkinson...@gmail.com>
wrote:

> Hi Bob,
>
> On 9 April 2017 at 13:42, Robert Hanson <hans...@stolaf.edu> wrote:
>
>> [I actually do know it is Cahn; pulled "Cohen" without thinking from
>> https://www.chemcomp.com/journal/chiral.htm. Serves me right. Duh!]
>>
>
> Was that the algorithm you implemented because it's not correct - it
> doesn't (and can't) handle ghost atoms. Trying to track down the example
> but Daniel Lowe constructed a small reproducible example to demonstrate why
> this can never work.
>
> John
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Blueobelisk-discuss mailing list
> Blueobelisk-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
>
>


-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] Fwd: Fwd: Cahn-Ingold-Prelog rules into Jmol

[Robert Hanson]

Brilliant. So I see the logic. This is chemistry not computer science.
Thank you,  John.  I will adjust the algorithm. Pretty easy fix.

On Tue, Apr 11, 2017 at 7:54 AM, John Mayfield 
wrote:

> John, what basis in the IUPAC rules leads you to this reading?
>
>
> That the rules :-) - I did warn you it's madness. Read the original papers
> CIP papers and the IUPAC document carefully.
>
> from IUPAC
>
> The rules are hierarchical, i.e., each rule must be exhaustively applied
>> in the order given until a decision is reached:
>
>
> from Prelog and Helmchen 1982:
>
> Those atoms in the n-th sphere which are of equal rank with respect to
>> those in the (n-1)th sphere to which they are bonded are graded by means of
>> the sequence *rules and these are applied exhaustively in turn: first
>> the entire hierarchical graph is examined by sequence rule 1. If a clear
>> precedence over other ligands can be established, the examination of that
>> particular ligand is concluded. If ligands remain whose rank is not
>> provided by sequence rule **1, **then one uses sequence rule 2, once
>> again exhaustively*, and so forth. While this procedure is in accordance
>> with precepts published earlier“] it now makes clear, we hope, that a rank
>> established for a sphere nearer to the core re- mains valid with respect to
>> atoms in more distant spheres (Fig. 15).
>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] Fwd: Fwd: Cahn-Ingold-Prelog rules into Jmol

[Robert Hanson]

Thank you very much for that very clear tip, John. Thinking *chemically*
was the key to understanding this logic. atomic masses are subtleties that
should not radically change the picture.  Jmol is applying Rules 1 and 2
correctly now based on the suite of structures Mikko gave me. (See
https://sourceforge.net/p/jmol/code/HEAD/tree/trunk/Jmol-datafiles/cip/)

$ load "$CC[C@@](CO)([H])[14CH2]C"
$ print {chirality != ""}.label("%i%[chirality]").join(" ");

3S

$ load
"cip/S/1-(bicyclo[2.2.2]octan-1-yl)-1-[1,5-dicyclopropyl-3(2-cyclopropylethyl)-pentan-3-yl]methan-1-ol-new.mol"
$ print {chirality != ""}.label("%i%[chirality]").join(" ");

7S

$ load "cip/RS/(1S,5R)-bicyclo[3.1.0]hex-2-ene_2D.mol" filter "2D"
$ print {*}.find("SMILES")
$ print {chirality != ""}.label("%i%[chirality]").join(" ");

[C@@H]12[C@H]3C1.C2=CC3
1S 5R

$ load "cip/RS/(1S,5R)-bicyclo[3.1.0]hex-2-ene_2D.mol" filter "2D"
$ @1.element = "13C"
$ print {*}.find("SMILES")
$ print {chirality != ""}.label("%i%[chirality]").join(" ");

[13C@@H]12C3C1.C2=CC3
1S 5R

:)

Time to work on Rule 3

​Bob
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] Fwd: Cahn-Ingold-Prelog rules into Jmol

[Robert Hanson]

On Wed, Apr 12, 2017 at 7:54 AM, Wolf Ihlenfeldt <w...@xemistry.com> wrote:

> On Wed, Apr 12, 2017 at 1:44 PM, Robert Hanson <hans...@stolaf.edu> wrote:
> > (and I wish they had thought of seqR and seqS)
> >
> > In case anyone is interested, here is my pseudocode. The actual methods
> > aren't much longer than this.
> > John, do you agree this is the appropriate approach?
> >
> > Bob
> >
> > https://sourceforge.net/p/jmol/code/HEAD/tree/trunk/
> Jmol/src/org/jmol/symmetry/CIPChirality.java
> >
> >   //
> >   // getChirality(atom) {
> >   //  if (atom.getCovalentBondCount() != 4) exit NO_CHIRALITY
>
> Insufficient. Chiral atoms where a FEP is substituting for a ligand
> are certainly important, in real-life chemistry. But of course that
> heavily depends on the atom type - not every FEP stays locked in
> place. Also geometry matters - you want to treat square planar
> different from tetrahedral, so there needs to be at least some kind of
> VSEPR analysis of prospective chiral centers.
>

"Insufficient" is a relative term. I'm just showing what my algorithm does
in Jmol.

I don't know what "FEP" means.


>
> Also I do not see any iteration here.


This is only for Rules 1-3 right now. One thing at a time...



> Cases where the chirality or
> non-chirality of an atom can only be determined after this has been
> done in its substituent sphere (say, identical substituents but one
> with a stereogenic cis-DB and one with a stereogenic trans-DB, or with
> a R and a S center in the substituents) are important - and can of
> course be nested to any depth, and they can appear in any atom or bond
> order, so there needs to be iteration as long as anything can be
> resolved, which then can lead to a possibility to resolve more
> centers. Furthermode, you need to interweave CIP atomic and bond
> stereodescriptor determination, they cannot be handled independently.
>

I don't  doubt that. Next up is Rules 4 and 5, where this will surely
become an issue.

Revisions to the pseudocode are welcome.

Bob
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] Fwd: Cahn-Ingold-Prelog rules into Jmol

[Robert Hanson]

(and I wish they had thought of seqR and seqS)

In case anyone is interested, here is my pseudocode. The actual methods
aren't much longer than this.
John, do you agree this is the appropriate approach?

Bob

https://sourceforge.net/p/jmol/code/HEAD/tree/trunk/Jmol/src/org/jmol/symmetry/CIPChirality.java

  //
  // getChirality(atom) {
  //  if (atom.getCovalentBondCount() != 4) exit NO_CHIRALITY
  //  for (each Rule){
  //sortSubstituents()
  //if (done) exit getHandedness();
  //  }
  //  exit NO_CHIRALITY
  // }
  //
  // sortSubstituents() {
  //   for (all pairs of substituents a and b) {
  // score = a.compareTo(b, currentRule)
  // if (score == TIED)
  //   score = breakTie(a,b)
  // }
  //
  // breakTie(a,b) {
  //score = compareShallowly(a, b)
  //if (score != TIED) return score
  //a.sortSubstituents(), b.sortSubstituents()
  //return compareDeeply(a, b)
  // }
  //
  // compareShallowly(a, b) {
  //for (each substituent pairing i in a and b) {
  //  score = applyCurrentRule(a_i, b_i)
  //  if (score != TIED) return score
  //}
  //return TIED
  // }
  //
  // compareDeeply(a, b) {
  //for (each substituent pairing i in a and b) {
  //  score = breakTie(a_i, b_i)
  //  if (score != TIED) return score
  //}
  //return TIED
  // }
  //





On Tue, Apr 11, 2017 at 5:17 PM, Bob <hans...@stolaf.edu> wrote:

> Wow.  I love seqcis! Rule 3 was trivial
>
> Robert M. Hanson
> St. Olaf College Chemistry
> from my Windows phone
> ----------
> From: Robert Hanson <hans...@stolaf.edu>
> Sent: ‎4/‎11/‎2017 7:30 AM
> To: BlueObelisk-Discuss <blueobelisk-discuss@lists.sourceforge.net>
> Subject: Fwd: [BlueObelisk-discuss] Fwd: Cahn-Ingold-Prelog rules into
> Jmol
>
> [sorry - forgot that this list requires "reply-all"]
> -- Forwarded message --
> From: Robert Hanson <hans...@stolaf.edu>
> Date: Tue, Apr 11, 2017 at 7:29 AM
> Subject: Re: [BlueObelisk-discuss] Fwd: Cahn-Ingold-Prelog rules into Jmol
> To: John Mayfield <john.wilkinson...@gmail.com>
>
>
>
>
> On Tue, Apr 11, 2017 at 2:37 AM, John Mayfield <
> john.wilkinson...@gmail.com> wrote:
>
>>
>> On 11 April 2017 at 04:37, Robert Hanson <hans...@stolaf.edu> wrote:
>>
>>> 2) What did you get for the other test case, that one checks you have
>>>> the ordering ranking for atomic masses.
>>>>
>>>>> CC[C@@](CO)([H])[14CH2]C
>>>>
>>>>
>>> R.
>>>
>>
>> There you go, that should also be S, ordering is: *CO, *[14CH2]C, *CC,
>> *[H]
>> https://nextmovesoftware.com/blog/2015/01/21/r-or-s-lets-vote/.
>>
>>
> John, what basis in the IUPAC rules leads you to this reading? It suggests
> that atoms in the nth sphere cannot be ranked until atoms in the (n+1)th
> sphere are checked after application of Rule 1, even if they could be
> distinguished by Rule 2. Are you suggesting that after each rule is checked
> (Rule 1a, Rule 1b, Rule 2 -- or is it Rule 1(a and b), Rule 2,...?) one
> must expand to the next sphere before making a decision? That seems to me
> (a) unsupportable by the IUPAC rules and (b) just asking for extremely
> complex code and a whole lot of unnecessary checks.
>
> My understanding is that exhaustive application of all rules are done
> within the sphere first, then the process is repeated at the next sphere.
> What I read is this:
>
>
>
>
>
> *The ranking of each atom in the nth sphere depends in the first place on
> theranking of atoms of the same branch in (n − 1)th sphere, and then by
> theapplication of the Sequence Rules to it; the smaller the number, the
> higher therelative ranking. (Ranking Rule 2).*
> This is certainly my understanding from all the reading I have done. You
> have three atoms connected to an atom. You rank those three atoms based on
> the rules.  Atoms that are tied are taken to  the next sphere, but not
> until that process is completed.
>
> To me that is pretty clear: We apply all rules to rank all atoms in a
> single sphere. Nothing here says, "Atoms in a sphere are compared pairwise,
> and if they are identical, then the comparison of this pair is continued to
> the next sphere. Once this depth-first relative ranking is determined, the
> procedure is repeated with all pairs of the sphere." I can certainly see
> where *that* reading could drive one mad.
>
>
>
>
>
>> Q: Is there software that does a nice job with producing digraphs from
>>> SMILES?
>>
>>
>> I think I added a utility in Centres, however I've barely looked at the
>> code in 5 years - but am planning to brush it off and clean u

Re: [BlueObelisk-discuss] Fwd: Cahn-Ingold-Prelog rules into Jmol

[Robert Hanson]

OK, I don't get the logic of this:


Rule 1 (a) Higher atomic number precedes lower;
(b) A duplicated atom, with its predecessor node having the same label
closer
to the root, ranks higher than a duplicated atom, with its predecessor node
having the same label farther from the root, which ranks higher than any
nonduplicated-atom-node (proposed by Custer, ref. 36)

Rule 2 Higher atomic mass number precedes lower;


Seriously? root distance is checked before isotope. Sure seems odd to me.
Why would that distance check not be after atomic number and mass??

Whatever...

Bob




On Sun, Apr 9, 2017 at 12:11 PM, Robert Hanson <hans...@stolaf.edu> wrote:

> OK, so I am reading Chapter 9 now to see the gory details. I didn't know
> about the root-distance check, and so now
>
> 1-(bicyclo[2.2.2]octan-1-yl)-1-[1,5-dicyclopropyl-3(2-cyclop
> ropylethyl)-pentan-3-yl]methan-1-ol.mol
>
> is working. So all of this is easy enough. That's probably it for
> independent stereochemistry.  Where there is a dependency  of one
> stereochemical determination from another -- R/S after E/Z; E/Z after R/S,
> E/Z after E/Z, R/S after R/S -- obviously that takes some sort of more
> general iteration.
>
> I think I will have to tackle that another day.
>
> Bob
>
>
>
>
>
> On Sun, Apr 9, 2017 at 11:03 AM, John Mayfield <
> john.wilkinson...@gmail.com> wrote:
>
>> Good good,
>>
>> Fake news before fake news - a paper published in the CCG journal by the
>> CCG.
>>
>> John
>>
>> On 9 April 2017 at 16:51, Robert Hanson <hans...@stolaf.edu> wrote:
>>
>>> No, John. Don't worry.  I just happened to look at that page prior to
>>> designing my own.
>>>
>>> On Sun, Apr 9, 2017 at 10:44 AM, John Mayfield <
>>> john.wilkinson...@gmail.com> wrote:
>>>
>>>> Hi Bob,
>>>>
>>>> On 9 April 2017 at 13:42, Robert Hanson <hans...@stolaf.edu> wrote:
>>>>
>>>>> [I actually do know it is Cahn; pulled "Cohen" without thinking from
>>>>> https://www.chemcomp.com/journal/chiral.htm. Serves me right. Duh!]
>>>>>
>>>>
>>>> Was that the algorithm you implemented because it's not correct - it
>>>> doesn't (and can't) handle ghost atoms. Trying to track down the example
>>>> but Daniel Lowe constructed a small reproducible example to demonstrate why
>>>> this can never work.
>>>>
>>>> John
>>>>
>>>>
>>>> 
>>>> --
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> ___
>>>> Blueobelisk-discuss mailing list
>>>> Blueobelisk-discuss@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
>>>>
>>>>
>>>
>>>
>>> --
>>> Robert M. Hanson
>>> Larson-Anderson Professor of Chemistry
>>> St. Olaf College
>>> Northfield, MN
>>> http://www.stolaf.edu/people/hansonr
>>>
>>>
>>> If nature does not answer first what we want,
>>> it is better to take what answer we get.
>>>
>>> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>>>
>>>
>>
>
>
> --
> Robert M. Hanson
> Larson-Anderson Professor of Chemistry
> St. Olaf College
> Northfield, MN
> http://www.stolaf.edu/people/hansonr
>
>
> If nature does not answer first what we want,
> it is better to take what answer we get.
>
> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>
>


-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] Fwd: Cahn-Ingold-Prelog rules into Jmol

[Robert Hanson]

"re" implementing is a great way to find additional bugs and compare
strategies. This (to this point) took me two days. And if I started with a
"libRS" in Java, I would still have to modify it extensively to fit Jmol.
That said, I wouldn't mind taking a look at how other have implemented it.

In the mean time, is it OK for me to continue this discussion without libRS?

Q: What do you say for the stereochemistry of [13CH@@]12C3C1.C2=CC3  ?




On Sun, Apr 9, 2017 at 1:53 PM, Noel O'Boyle <baoille...@gmail.com> wrote:

> We need libRS. Everyone reimplementing these rules is some type of madness.
>
> On 9 Apr 2017 7:05 p.m., "Robert Hanson" <hans...@stolaf.edu> wrote:
>
>> OK, I don't get the logic of this:
>>
>>
>> Rule 1 (a) Higher atomic number precedes lower;
>> (b) A duplicated atom, with its predecessor node having the same label
>> closer
>> to the root, ranks higher than a duplicated atom, with its predecessor
>> node
>> having the same label farther from the root, which ranks higher than any
>> nonduplicated-atom-node (proposed by Custer, ref. 36)
>>
>> Rule 2 Higher atomic mass number precedes lower;
>>
>>
>> Seriously? root distance is checked before isotope. Sure seems odd to me.
>> Why would that distance check not be after atomic number and mass??
>>
>> Whatever...
>>
>> Bob
>>
>>
>>
>>
>> On Sun, Apr 9, 2017 at 12:11 PM, Robert Hanson <hans...@stolaf.edu>
>> wrote:
>>
>>> OK, so I am reading Chapter 9 now to see the gory details. I didn't know
>>> about the root-distance check, and so now
>>>
>>> 1-(bicyclo[2.2.2]octan-1-yl)-1-[1,5-dicyclopropyl-3(2-cyclop
>>> ropylethyl)-pentan-3-yl]methan-1-ol.mol
>>>
>>> is working. So all of this is easy enough. That's probably it for
>>> independent stereochemistry.  Where there is a dependency  of one
>>> stereochemical determination from another -- R/S after E/Z; E/Z after R/S,
>>> E/Z after E/Z, R/S after R/S -- obviously that takes some sort of more
>>> general iteration.
>>>
>>> I think I will have to tackle that another day.
>>>
>>> Bob
>>>
>>>
>>>
>>>
>>>
>>> On Sun, Apr 9, 2017 at 11:03 AM, John Mayfield <
>>> john.wilkinson...@gmail.com> wrote:
>>>
>>>> Good good,
>>>>
>>>> Fake news before fake news - a paper published in the CCG journal by
>>>> the CCG.
>>>>
>>>> John
>>>>
>>>> On 9 April 2017 at 16:51, Robert Hanson <hans...@stolaf.edu> wrote:
>>>>
>>>>> No, John. Don't worry.  I just happened to look at that page prior to
>>>>> designing my own.
>>>>>
>>>>> On Sun, Apr 9, 2017 at 10:44 AM, John Mayfield <
>>>>> john.wilkinson...@gmail.com> wrote:
>>>>>
>>>>>> Hi Bob,
>>>>>>
>>>>>> On 9 April 2017 at 13:42, Robert Hanson <hans...@stolaf.edu> wrote:
>>>>>>
>>>>>>> [I actually do know it is Cahn; pulled "Cohen" without thinking from
>>>>>>> https://www.chemcomp.com/journal/chiral.htm. Serves me right. Duh!]
>>>>>>>
>>>>>>
>>>>>> Was that the algorithm you implemented because it's not correct - it
>>>>>> doesn't (and can't) handle ghost atoms. Trying to track down the example
>>>>>> but Daniel Lowe constructed a small reproducible example to demonstrate 
>>>>>> why
>>>>>> this can never work.
>>>>>>
>>>>>> John
>>>>>>
>>>>>>
>>>>>> 
>>>>>> --
>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>> ___
>>>>>> Blueobelisk-discuss mailing list
>>>>>> Blueobelisk-discuss@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Robert M. Hanson
>>>>> Larson-Anderson Professor of Chemistry
>>>>> St. Olaf College
>>>>> Northfield, MN

Re: [BlueObelisk-discuss] Fwd: Cahn-Ingold-Prelog rules into Jmol

[Robert Hanson]

OK. That's fine. Point me to the algorithm. I'll say no more.

On Mon, Apr 10, 2017 at 7:10 AM, Noel O'Boyle <baoille...@gmail.com> wrote:

> Sorry, but I have to call you out on this, especially as this is the
> Blue Obelisk mailing list.
>
> I've no problem anyone reimplementing anything for fun or profit, but
> I have to disagree with the suggestion that having an N'th
> implementation of the same algorithm is progress, or good for this
> community. At a recent meeting at the EBI, I think there were at least
> 7 attendees who had written versions of this algorithm. The whole goal
> of the Blue Obelisk is to pool our expertise to develop common
> resources, to avoid exactly this situation.
>
> - Noel
>
> On 9 April 2017 at 23:53, Robert Hanson <hans...@stolaf.edu> wrote:
> > "re" implementing is a great way to find additional bugs and compare
> > strategies. This (to this point) took me two days. And if I started with
> a
> > "libRS" in Java, I would still have to modify it extensively to fit Jmol.
> > That said, I wouldn't mind taking a look at how other have implemented
> it.
> >
> > In the mean time, is it OK for me to continue this discussion without
> libRS?
> >
> > Q: What do you say for the stereochemistry of [13CH@@]12C3C1.C2=CC3  ?
> >
> >
> >
> >
> > On Sun, Apr 9, 2017 at 1:53 PM, Noel O'Boyle <baoille...@gmail.com>
> wrote:
> >>
> >> We need libRS. Everyone reimplementing these rules is some type of
> >> madness.
> >>
> >> On 9 Apr 2017 7:05 p.m., "Robert Hanson" <hans...@stolaf.edu> wrote:
> >>>
> >>> OK, I don't get the logic of this:
> >>>
> >>>
> >>> Rule 1 (a) Higher atomic number precedes lower;
> >>> (b) A duplicated atom, with its predecessor node having the same label
> >>> closer
> >>> to the root, ranks higher than a duplicated atom, with its predecessor
> >>> node
> >>> having the same label farther from the root, which ranks higher than
> any
> >>> nonduplicated-atom-node (proposed by Custer, ref. 36)
> >>>
> >>> Rule 2 Higher atomic mass number precedes lower;
> >>>
> >>>
> >>> Seriously? root distance is checked before isotope. Sure seems odd to
> me.
> >>> Why would that distance check not be after atomic number and mass??
> >>>
> >>> Whatever...
> >>>
> >>> Bob
> >>>
> >>>
> >>>
> >>>
> >>> On Sun, Apr 9, 2017 at 12:11 PM, Robert Hanson <hans...@stolaf.edu>
> >>> wrote:
> >>>>
> >>>> OK, so I am reading Chapter 9 now to see the gory details. I didn't
> know
> >>>> about the root-distance check, and so now
> >>>>
> >>>>
> >>>> 1-(bicyclo[2.2.2]octan-1-yl)-1-[1,5-dicyclopropyl-3(2-
> cyclopropylethyl)-pentan-3-yl]methan-1-ol.mol
> >>>>
> >>>> is working. So all of this is easy enough. That's probably it for
> >>>> independent stereochemistry.  Where there is a dependency  of one
> >>>> stereochemical determination from another -- R/S after E/Z; E/Z after
> R/S,
> >>>> E/Z after E/Z, R/S after R/S -- obviously that takes some sort of more
> >>>> general iteration.
> >>>>
> >>>> I think I will have to tackle that another day.
> >>>>
> >>>> Bob
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Sun, Apr 9, 2017 at 11:03 AM, John Mayfield
> >>>> <john.wilkinson...@gmail.com> wrote:
> >>>>>
> >>>>> Good good,
> >>>>>
> >>>>> Fake news before fake news - a paper published in the CCG journal by
> >>>>> the CCG.
> >>>>>
> >>>>> John
> >>>>>
> >>>>> On 9 April 2017 at 16:51, Robert Hanson <hans...@stolaf.edu> wrote:
> >>>>>>
> >>>>>> No, John. Don't worry.  I just happened to look at that page prior
> to
> >>>>>> designing my own.
> >>>>>>
> >>>>>> On Sun, Apr 9, 2017 at 10:44 AM, John Mayfield
> >>>>>> <john.wilkinson...@gmail.com> wrote:
> >>>>>>>
> >>>>>>> Hi Bob,
> >>>>>>>
> >>>>>>> On

[BlueObelisk-discuss] OK, bragging -- CIP

[Robert Hanson]

570 lines; 40 methods.
https://sourceforge.net/p/jmol/code/HEAD/tree/trunk/Jmol/src/org/jmol/symmetry/CIPChirality.java

Limitations:

 no parallel chirality paths (Mata)
 not processing inositols correctly
 no lone-pair business (S, P, imines)
 standard E/Z, R/S, r/s only; no allenes, no planar asymmetry

Tests passed from Mikko's collection:

(2R,3r,4S)-2,3,4-trichloropentane.mol//RrS
(2R,3s,4S)-2,3,4-trichloropentane.mol//RsS
(2R,3r,4R,5s,6R)-2,6-dichloro-3,5-bis[(1S)-1-chloroethyl]heptan-4-ol_2d.sdf
(2R,3r,4R,5s,6R)-2,6-dichloro-3,5-bis[(1S)-1-chloroethyl]heptan-4-ol_3d.sdf
(2R,3s,4S,6R)-2,6-dichloro-5-[(1R)-1-chloroethyl]-3-[(1S)-1-chloroethyl]heptan-4-ol_2d.sdf
(2R,3s,4S,6R)-2,6-dichloro-5-[(1R)-1-chloroethyl]-3-[(1S)-1-chloroethyl]heptan-4-ol_3d.sdf
(2R,3R,4R,5S,6R)-2,3,4,5,6-pentachloroheptanedioic_acid_2d.mol//RSRRR
(2R,3R,4R,5S,6R)-2,3,4,5,6-pentachloroheptanedioic_acid_2d.sdf//RSRRR
(2R,3R,4R,5S,6R)-2,3,4,5,6-pentachloroheptanedioic_acid_3d.sdf//RSRRR
(2R,3R,4S,5S,6R)-2,3,4,5,6-pentachloroheptanedioic_acid_3d.mol//RSSRR
(1s,4s)-1,4-dimethylcyclohexane.mol//ss
(1r,4r)-1,4-dimethylcyclohexane.mol//rr
(1r,4r)-4-bromo-4-methylcyclohexan-1-amine.mol//rr
(1s,4s)-4-bromo-4-methylcyclohexan-1-amine.mol//ss
(1r,3r)-cyclobutane-1,3-diol.mol//rr
(1s,3s)-cyclobutane-1,3-diol.mol//ss
two_pairs_of_enantiomeric_ligands.mol//SRSR
(2R,3r,4S)-2,3,4-trichloropentane.mol//RrS
(2R,3s,4S)-2,3,4-trichloropentane.mol//RsS
(2R,3r,4R,5s,6R)-2,6-dichloro-3,5-bis[(1S)-1-chloroethyl]heptan-4-ol_2d.sdf
(2R,3r,4R,5s,6R)-2,6-dichloro-3,5-bis[(1S)-1-chloroethyl]heptan-4-ol_3d.sdf
(2R,3s,4S,6R)-2,6-dichloro-5-[(1R)-1-chloroethyl]-3-[(1S)-1-chloroethyl]heptan-4-ol_2d.sdf
(2R,3s,4S,6R)-2,6-dichloro-5-[(1R)-1-chloroethyl]-3-[(1S)-1-chloroethyl]heptan-4-ol_3d.sdf
(2R,3R,4R,5S,6R)-2,3,4,5,6-pentachloroheptanedioic_acid_2d.mol//RSRRR
(2R,3R,4R,5S,6R)-2,3,4,5,6-pentachloroheptanedioic_acid_2d.sdf//RSRRR
(2R,3R,4R,5S,6R)-2,3,4,5,6-pentachloroheptanedioic_acid_3d.sdf//RSRRR
(2R,3R,4S,5S,6R)-2,3,4,5,6-pentachloroheptanedioic_acid_3d.mol//RSSRR
(1R,2R)-2-chlorocyclohexanol_2d.mol
(1R,2R)-2-chlorocyclohexanol_2d_noH.mol
(1R,2R)-2-chlorocyclohexanol_3d.mol
(1R,2R)-2-chlorocyclohexanol_3d_noH.mol
(1R,2R,4R,5R)-cyclohexane-1,2,3,4,5-pentol_2d_noH.mol//
(1R,2R,4R,5R)-cyclohexane-1,2,3,4,5-pentol_3d.mol//
(1S,5R)-bicyclo[3.1.0]hex-2-ene_2D.mol//SZZR
(1S,5R)-bicyclo[3.1.0]hex-2-ene_3D.mol//SZZR
(2R,3S,4R,5R,6S)-3-(2-bromoethyl)-1-chloro-2,6,7-trifluoro-5-(2-iodoethyl)heptan-4-ol_2D.mol//SRRSR
(2R,3S,4R,5R,6S)-3-(2-bromoethyl)-1-chloro-2,6,7-trifluoro-5-(2-iodoethyl)heptan-4-ol_3D.mol//SRRSR
(2R,3S,4S,5R,6S)-3-(2-bromoethyl)-1-chloro-2,6,7-trifluoro-5-(2-iodoethyl)heptan-4-ol_2D.mol//SRSSR
(2R,3S,4S,5R,6S)-3-(2-bromoethyl)-1-chloro-2,6,7-trifluoro-5-(2-iodoethyl)heptan-4-ol_3D.mol//SRSSR
(2S,4aS,8aS)-8a-chloro-2-fluoro-decahydronaphthalen-4a-ol.sdf
(4aR,8aS)-8a-methyl-octahydro-1H-2-benzopyran.sdf
one-R-one-S.sdf
_1R,2R_-2-__S_-chloro_fluoro_methyl_cyclohexan-1- ol.sdf
_2R,3R_-3-methylpentan-2-ol.sdf
_2R,3S_-3-methylpentan-2-ol.sdf
beta-eudesmol.sdf
beta-eudesmol_3d.sdf
gibberellin_3D_new.mol//RRRS


-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

[BlueObelisk-discuss] OK, I'm catching on, but...

[Robert Hanson]

Can someone shed some light on how this brilliant statement:

Rule 3. When two ligands differ


*only in that one has an atomor atom-group of higher rank in a cis-position
and theother in a trans-position to the core of the stereogenicunit, *then
preference is given to the former.

[Mata, Lobo, et al., J. Chem. Inf. Comput. Sci. 1994, 34, 491-504]

Got turned into this monster?

Rule 3: ... seqcis = 'Z' precedes seqtrans = 'E'.

In other words, rather than being able to assign priority by the very
clever method of just following the path, one has to actually assign all
the priorities of the double bonds first (from scratch, presumably, not the
currently working process) *then *continue.

Or, maybe what I am saying is, they were so close and yet didn't see that
it could have been so so simple. But no

[I suppose the writer of this rule is on this list, right?]


Bob


-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] another CIP question

[Robert Hanson]

ps, before John jumps on me, I had better add the intermediate l/u business:

left: RSS  (uu)
right: RRS (lu)

l > u, so right wins.

Since it comes down to ordering of the RSS... list, that's what I need
clarification on. We have Ranking Rule #1, which is great and helps in this
case (if John agrees).

John, quick question:  Rule 5 is the place - the only place -- that assigns
"r" and "s". Right?

Bob
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] OK, I'm catching on, but...

[Robert Hanson]

On Fri, Apr 14, 2017 at 3:28 AM, Wolf Ihlenfeldt <w...@xemistry.com> wrote:

> On Fri, Apr 14, 2017 at 1:37 AM, Robert Hanson <hans...@stolaf.edu> wrote:
> > Can someone shed some light on how this brilliant statement:
> >
> > Rule 3. When two ligands differ only in that one has an atom
> > or atom-group of higher rank in a cis-position and the
> > other in a trans-position to the core of the stereogenic
> > unit, then preference is given to the former.
>

OK -- I see that the 2013 final version is much simpler than I thought, in
that one can simply take care of most of the E/Z business by itself in Rule
3. (I hear you, Wolf. Not pretending I have this totally worked out for
more complex cases. I consider that the realm of Rule 4.)

Q: Aren't there cases where you have to know the R/S to get E/Z, but you
also have to know E/Z to get the R/S? How is that trap evaded?

No, not even that is sufficient. You can have of course stereo double

> bonds determining the fate of an atom stereo center which are
> themselves E/Z only by virtue of having substituents which differ only
> in R and S - which then need to be determined first to get the double
> bond descriptor. You cannot determine atom and bond stereochemistry
> independently in the CIP system. This must be a single, repetitive,
> interwoven process.
>
>

> Please keep us posted on your implementation line count ;-)
>
>
>
Rules 1-3 implemented. Tracking multiple stereocenters, but not carrying
out much in the way of Rule 4. All cases that I have that do not involve
auxiliary R/S determination (such as inositol) appear to be working ---
basically anything but Rule 4. No pseudochirality; no axial or other more
sophisticated forms of stereochemistry. At this point I can say, though,
that the algorithm is certainly suitable for most typical cases and holds
up pretty well with the sorts of cases illustrated in Chapter 9. All
methods are relatively simple, with efficient recursion and structural
analysis only on a "need-to-know" basis.

412 lines

Bob
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

[BlueObelisk-discuss] Jmol - CIP update

[Robert Hanson]

Jmol.___JmolVersion="14.15.2" // 4/23/17

- CIPChirality.java 633 lines all except Rule 4b (Mata) and Rule 5 for
those cases.
- adds P, S, As, Se, Sb, Te, Bi, Po trigonal pyramidal and tetrahedral
- validates on 79 known chiral compounds testing a variety of nuances
- still some opportunity for optimization
- multi-path Mata analysis data is collected; just not being parsed.

Pseudocode follows. Actual code is a bit more than this, but this is the
basic idea. It's slightly modified from my original statement in that the
returned score, rather than just 1, 0, or -1, is a number that indicates
both the winner (positive or negative) and the sphere in which that win was
achieved (magnitude). This allows efficient and rapid forward processing
through the spheres.

The idea is to do both a "shallow" (intra-sphere) and a "deep"
(inter-sphere) comparison, iterating as necessary. Extensive use of
auxiliary descriptors is made by cloning atoms on the fly and following
their paths backward rather than forward. Note that the methods
sortSubstituents, breakTie, and compareDeeply are mutually entrant, leading
to the following of the digraph exactly as per IUPAC specifications.

Rules 4 and 5 still need a little fleshing out. All the information needed
is there; I'm just not processing it. I decided to add P and S and lone
pairs today first. One thing at a time!

Wolf and John, you had concerns that a full treatment might explode in some
way, I think. I don't doubt that that might be the case -- I can't prove
otherwise. I would not be surprised if certain combinations of alkenes and
chiral centers could do something like that, but extensive use of auxiliary
descriptors is made here, and I think that removes much of that issue. What
do you think?

The code is designed to fail gracefully by not assigning some centers
rather than assigning them incorrectly. Not saying it is done -- just
saying that I am satisfied that  it is quite manageable for general use.

Continued thanks to all for contributing to this discussion -- especially
the skepticism!

Bob

getChirality(molecule) {
  checkForAlkenes()
  if (haveAlkenes) checkForSmallRings()
  for(all atoms) getChirality(applyRules1-3)
  for(all double bonds) checkEZ()
  for(all atoms still without designations) getChirality(applyRules4and5)
   if (haveAlkenes) removeUnnecessaryEZDesignations()
}

 getChirality(atom) {
  for (each Rule){
sortSubstituents()
if (done) exit checkHandedness();
  }
  exit NO_CHIRALITY
 }

 sortSubstituents() {
   for (all pairs of substituents a and b) {
 score = a.compareTo(b, currentRule)
 if (score == TIED)
   score = breakTie(a,b)
 }

 breakTie(a,b) {
score = compareShallowly(a, b)
if (score != TIED) return score
a.sortSubstituents(), b.sortSubstituents()
return compareDeeply(a, b)
 }

 compareShallowly(a, b) {
for (each substituent pairing i in a and b) {
  score = applyCurrentRule(a_i, b_i)
  if (score != TIED) return score
}
return TIED
 }

 compareDeeply(a, b) {
currentScore = Integer.MAX_VALUE
for (each substituent pairing i in a and b) {
  score = min(currentScore, breakTie(a_i, b_i)
}
return TIED
 }
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

[BlueObelisk-discuss] Cohen-Ingold-Prelog rules into Jmol

[Robert Hanson]

Just thought I would let people know that Jmol/JSmol now can calculate R/S
chirality for any carbon atom. I've been working with Jmol for 10 years and
only yesterday realized it was pretty trivial to write this. Well, better
late than never, right?? And only 100 lines of code. What a deal!

I'm trusting on this erudite group to punch holes in it, of course. What
are the really tricky cases?

See

https://chemapps.stolaf.edu/jmol/jsmol/simple2.htm?load%
20http://www.biotopics.co.uk/jsmol/molecules/taxolH.mol;
label%20%[chirality];background%20labels%20yellow;
set%20antialiasdisplay;set%20echo%20top%20center;echo%20Taxol

You can also experiment with this at https://chemapps.stolaf.edu/
jmol/jsmol/jsmetest2.htm

I'm also not sure exactly how to validate it. Ideas?

Bob


-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

[BlueObelisk-discuss] another CIP question

[Robert Hanson]

OK, on to Rule 4. I am reading Chapter 9 and its associated papers very
closely now. For anyone of the opinion that "this has been done many times
before" I point out that between 1966 and 1982 and 1993 and 2004 and 2013
and between all the different suggestions for revision, it's pretty hard to
believe that anyone (except of course ACD/Labs) has fully implemented and
fully validated code following the IUPAC 2013 Sequence Rules. I'd sure like
to see it if they do.

Here is my esoteric question for the day. I was under the impression that
two branches could be distinguished by direct comparison. That's certainly
true for, say, linear glycerols. But reading Mata (Tetrahedron Asymmetry
vol 4, 1995, p. 657) and more specifically the IUPAC 2013 examples on pages
1193-1205, I am surprised to see that in order to make a characterization
in certain cases, up to three distinct subbranches need to be analyzed in
parallel.

The first example of this I see is on page 1201, Example 5. One cannot
start the analysis without first identifying that there are three branches
for comparison, not two. This is not a problem, as my algorithm will
clearly identify that after Rule 3 we have three same-priority branches.
But it does introduce an entirely new concept. Up to this point branches
are compared two at a time. Now all three subbranches have to be scanned in
parallel prior to determining the "reference" stereochemistry to be R or S.
The example there goes through the process we need to use to sort the
subbranches such as:

C--*S*--S
   /
--C--C--S--S
  \
   C--R--R


OK, I can do that, but it is quite a different concept than comparing in
pairs.


Odder still (shown in Example 4) is that in the case where we have
subbranches of differing priorities, of completely different types (one
starting with O, one with C), now we don't just use the higher-priority
branch as the determinant. We do use it for the reference determination,
but after that we still go through the parallel processing as before, rank
by rank. But since these are now distinctly different structural branches,
the various stereocenters. For example, we could have:

O--*S*--S
   /
--C--C--S--S
  \
   C--R--R

That's fine, too. But these examples are too easy! What if we have:


 O--C--C--C--C--*S*--S--X
/
Y--C--C--S--S--S
\
 C--R--R--S

There could be anything on that oxygen -- X could be a cholesteryl ether
for all we know. Y has to have some symmetry here, I think, because the
goal is still to rank this entire ligand relative to some other evil
diasteriomeric twin somewhere in "Y". (It's not to give this particular
ligand a descriptor at the carbon attached to Y here. That would be trivial
in this case.) Our goal is to analyze a sequence of "like" and "unlike"
pairs within this unit and compare that to a similar set in another unit
somewhere within Y for the purpose of establishing the descriptor for some
*other* atom in Y.

Wolf, Tim, Mikko? Have I go this right so far?

Bob



My reading of the discussion within these elaborations of Rule 4 suggest:

  a) The first S on the highest-ranking branch (O...X) sets the reference
atom for this unit, regardless of how far down the line it is.
  b) The  other two subbranches must be  geometrically identical, or we
wouldn't be here. All the stereochemistry would have been set in a Rule 1
step long ago (just like we already know that we have S and R along the
branch). Someone has already gone through at least Steps 1-3 to do that,
possibly 1-5.



-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] Jmol - CIP update

[Robert Hanson]

Jmol update. Rule 4 is complete. Just 1/80 structures -- Example 6, p. 1208
-- is not validating. But that's just because I have not worked on Rule 5,
and that structure is only resolved there.

Two other structures (Example 4, p. 1200 and O-methyl
(S)-(benzenesulfonothioate), P-93.2.5, page 1216 ) I believe are
incorrectly annotated in the SDF file. In the first case, it looks like an
error in choosing the reference configuration when the two branches have
different Rule-1 priorities; in the second, it looks like S=O is not
properly considered to be a single bond (so no duplicated S on O2). These
seem to me to be easy things to miss and, at least the second one, to fix.
Jmol has no problem now with the reference issue. It is handling all
components of Mata's description of Rule 4b. Again, the code for that is
highly recursive.

So I'm fairly certain that the overall approach I am using exactly
implements IUPAC 2013 Chapter 9 Rules 1-4 for all cases considered,
including S and P with lone pairs (but not imines yet). There are some
great examples there that are really demanding of an algorithm and caught
some rather subtle issues.

Now I'm definitely getting interested in what other algorithms are out
there and how they perform. Very interested in what you find, John. Are you
planning to test these other implementations using a standard validation
suite? I've put mine up at
https://sourceforge.net/p/jmol/code/HEAD/tree/trunk/Jmol-datafiles/cip, but
I think it's missing some key tests.

I'm hoping to finish Rule 5 sometime tomorrow or Thursday.

743 lines.

Bob


On Tue, Apr 25, 2017 at 11:26 AM, Robert Hanson <hans...@stolaf.edu> wrote:

> Basic Mata analysis is in. Still two structures (Examples 4 and 6, pp 1200
> and  1208) are not validating, but I know why. Haven't implemented
> multi-reference like/unlike checking or a final check for complex
> pseudochirality involving Mata analysis. Both should be simple enough.
> We'll see! All other structures are validating. I've asked IUPAC for their
> validation set.
>
> 699 lines.
>
> Bob
> ​
>



-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] Jmol - CIP update

[Robert Hanson]

Rule 5 is done. Fully validating using the first validation set that Mikko
sent me (86 compounds, roughly, some 2D/3D duplicates). I'm sure there are
more cases it needs testing with, though.

My algorithm implementation handles Rules 4 and 5 lexicographically so that
a simple Array.sort(String[]) does the job. Kind of interesting, perhaps.
​
763 lines, Wolf.

Bob
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] Jmol - CIP update

[Robert Hanson]

Basic Mata analysis is in. Still two structures (Examples 4 and 6, pp 1200
and  1208) are not validating, but I know why. Haven't implemented
multi-reference like/unlike checking or a final check for complex
pseudochirality involving Mata analysis. Both should be simple enough.
We'll see! All other structures are validating. I've asked IUPAC for their
validation set.

699 lines.

Bob
​
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] Jmol - CIP update

[Robert Hanson]

Unfortunately,  the wrong answer. At least for now. The problem is with the
mixed mode like/unlike with R/seqCis, R/M, etc. in Rule 4b. I haven't
implemented those at all. When I tried, I got crazy results.

I would like to do some serious cross-checking with a new Rule 4b test
suite. John, sounds like this is something you want to bring up in your
presentation. There's no doubt that if nothing else we need a discussion of
the IUPAC 2013 rules. Maybe an "open" spec, but really to me that means an
IUPAC project. But maybe others aren't interested in that. How do you want
to proceed? You sort of "claimed" this space. I don't want to step on your
toes. Sorry I can't make the fall ACS meeting this year.

Personally, I think we should do better than passing structures back and
forth over this list. But I'm not in a position to be able to run all these
tests on other systems; just Jmol. (And, of course, you don't need me to do
that.) At the very least, we should be using SMILES, not images. While
we're at it, what about this one?

C/1=C\C[CH@](C)C/C=C/C[CH@](C)C\1

Bob

















On Sun, Apr 30, 2017 at 4:38 AM, John Mayfield <john.wilkinson...@gmail.com>
wrote:

>
> On 29 April 2017 at 20:54, Robert Hanson <hans...@stolaf.edu> wrote:
>
>> The algorithm will fail for some more complex nested aspects of Rule 4b.
>> I decided to be satisfied for now with only those examples in IUPAC Blue
>> Book 2013 Chapter 9. My understanding is that even ACD/Labs did not fully
>> implement Rules 4 and 5 much beyond that.
>>
>
> When you say fail, does it give no answer or the wrong answer?
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Blueobelisk-discuss mailing list
> Blueobelisk-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
>
>


-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] Jmol - CIP update

[Robert Hanson]

Final Jmol update for a while. The next release of Jmol will have a CIP
algorithm implementation that passes all the tests I have at this time
(ACD/Labs 236-model test suite + Mikko's 64-model suite). There are many
errors/omissions in the ACD/Labs suite, and I have not had the time to
check every one of them against the actual text of the BB. So all I can
really say is that in every case that I have checked the BB text, Jmol
agrees -- or I have submitted a correction report with a digraph analysis
-- and in every case that it disagrees with the ACD/Labs suite, it is the
ACD/Labs suite that is mistaken, not Jmol.

Thanks again. John for the great test cases. Do keep sending me any tough
cases you might have.

1018 lines completes Rule 4b (for now!)

Bob

On Tue, May 9, 2017 at 10:04 PM, Robert Hanson <hans...@stolaf.edu> wrote:

> yeah! I'll pass on that one -- after all, you said, "if it's a good
> algorithm, this one will blow up."
>
> On Tue, May 9, 2017 at 5:21 PM, John Mayfield <john.wilkinson...@gmail.com
> > wrote:
>
>> And the CHEBI one? :p
>>
>> On 9 May 2017 at 22:43, Robert Hanson <hans...@stolaf.edu> wrote:
>>
>>> Thanks, again, John. That fix is checked in.  I had forgotten to check
>>> for r and s at other than the root atom.
>>>
>>> That reminds me to say that the BB validation suite is missing a lot of
>>> good tests such as this one. So one really great contribution would be to
>>> create an open validation set that would go far beyond the examples in the
>>> BB.
>>>
>>> Bob
>>>
>>>
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Blueobelisk-discuss mailing list
>> Blueobelisk-discuss@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
>>
>>
>
>
> --
> Robert M. Hanson
> Larson-Anderson Professor of Chemistry
> St. Olaf College
> Northfield, MN
> http://www.stolaf.edu/people/hansonr
>
>
> If nature does not answer first what we want,
> it is better to take what answer we get.
>
> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>
>


-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] Jmol - CIP update

[Robert Hanson]

OK, 967 lines. This now includes chiral bridgehead nitrogens and is just
missing a small piece of code for integrating M/P and seqCis/seqTrans into
Rule 4b. The algorithm is solid. No particular issues other than that. Does
not implement atom-number averaging for mancude rings, but does remove
Kekule dependencies for aromatic rings. This last bit required a slight
additional "friendly amendment" to Rule 1b, which I don't think was crafted
with aromatics in mind. Pseudocode is still pretty much the same as
initially described. There are no issues with multi-center dependencies.

Validates on the full 236-compound Chapter 9 validation suite from ACD/Labs
except:

var skip = ({27 229}) || // ignore -- BB has E/Z only; missing chirality
   ({95 96 98 99 100 101 102 103 104 108 109 110 111 112 200}) ||
// trigonal planar, square planar, or hypervalent
   ({32 33})  || // helicene
   ({212 213})|| // chiral conformation 1,4-benzene in a ring
   ({38})  || // ignoring -- Mancude for cyclopentadienyl -- will
require some thought
 ({170}) // failing (mixed Rule 4b)

In the process, I have found four erroneous assignments in IUPAC Blue Book
2013. These are being checked by IUPAC. There's actually quite a large
errata page for that book already.

With regards to an "Open" CIP -- I strongly suggest not going there. If you
are seriously interested in this, join/form an IUPAC project.

Bob


On Sat, Apr 29, 2017 at 2:54 PM, Robert Hanson <hans...@stolaf.edu> wrote:

> OK, final update for a while. (816 lines, Wolf. I have no idea how that
> compares to yours or others' algorithms.)
>
> Open-source, validated IUPAC 2013 preferred IUPAC name (PIN)
> stereochemical designations.
>
> Jmol.___JmolVersion="14.15.2" // 4/29/17
>
>  -- 816 lines
>  -- validation data are at https://sourceforge.net/p/jmol
> /code/HEAD/tree/trunk/Jmol-datafiles/cip/
>  -- validates for 160 structures (some duplicates; both cip_examples.zip
> and stereo_test_cases.sdf)
>  -- validates for all cases considered:
>-- simple R/S and E/Z
>-- small-ring removal of E/Z
>-- parallel-strand Rule 4b and Rule 5 (Mata)
>-- pseudochiral r/s and m/p
>-- odd and even cumulenes
>-- atropisomers
>-- P, S, As, Se, Sb, Te, Bi, Po trigonal pyramidal and tetrahedral
>-- imine and diazine E/Z chirality
>
> The algorithm will fail for some more complex nested aspects of Rule 4b. I
> decided to be satisfied for now with only those examples in IUPAC Blue Book
> 2013 Chapter 9. My understanding is that even ACD/Labs did not fully
> implement Rules 4 and 5 much beyond that.
>
> Working version in JavaScript can be tested at
> https://chemapps.stolaf.edu/jmol/jsmol/jsmetest2.htm
> Binary and source at https://sourceforge.net/projects/jmol/files/Jmol/
>
> A great challenge for April!
>
> Bob
>
>
>
> On Thu, Apr 27, 2017 at 12:21 AM, Robert Hanson <hans...@stolaf.edu>
> wrote:
>
>> Rule 5 is done. Fully validating using the first validation set that
>> Mikko sent me (86 compounds, roughly, some 2D/3D duplicates). I'm sure
>> there are more cases it needs testing with, though.
>>
>> My algorithm implementation handles Rules 4 and 5 lexicographically so
>> that a simple Array.sort(String[]) does the job. Kind of interesting,
>> perhaps.
>> ​
>> 763 lines, Wolf.
>>
>> Bob
>>
>>
>>
>
>
> --
> Robert M. Hanson
> Larson-Anderson Professor of Chemistry
> St. Olaf College
> Northfield, MN
> http://www.stolaf.edu/people/hansonr
>
>
> If nature does not answer first what we want,
> it is better to take what answer we get.
>
> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>
>


-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] Jmol - CIP update

[Robert Hanson]

Thanks, again, John. That fix is checked in.  I had forgotten to check for
r and s at other than the root atom.

That reminds me to say that the BB validation suite is missing a lot of
good tests such as this one. So one really great contribution would be to
create an open validation set that would go far beyond the examples in the
BB.

Bob
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] Jmol - CIP update

[Robert Hanson]

 * 5/17/16 Jmol 14.15.5. adds helicene M/P chirality; 959 lines
 * validated using CCDC
 * structures HEXHEL02 HEXHEL03 HEXHEL04 ODAGOS ODAHAF
 * http://pubs.rsc.org/en/content/articlehtml/2017/CP/C6CP07552E


On Sat, May 13, 2017 at 11:43 PM, Robert Hanson <hans...@stolaf.edu> wrote:

> OK, final (?) report. Always a good sign when code simplifies. I've
> tightened up the algorithm, which passes all pertinent Chapter 9 tests,
> plus several more. After removing unnecessary code, Jmol's CIP
> implementation is now back to 970 lines, even with added (minimal) Kekule
> considerations and full R/S, seqCis/seqTrans, and M/P mixing for Rules 4b
> and 5. It would not take much more to add helicene identification.
>
> I'm happy to report that the following simplified pseudocode is
> sufficient. There is nothing magical here. The successful one-pass use of
> auxiliary descriptors and finite digraphs should put to rest any concerns
> that CIP determination of stereochemical descriptors has any cyclical
> dependencies or routinely blows up. Except, perhaps, due to too many atoms
> and too high symmetry. Every program will have its limits in this regard,
> of course, and I think this algorithm could certainly be made more
> efficient. In any case, the algorithm I have implemented demonstrates that
> this process can be a one-pass process through all eight rules: 1a, 1b, 2,
> 3, 4a, 4b, 4c, and 5; once through does it.
>
> There are some nuances that are problematic -- a dependency on generating
> multiple Kekule models, and a problem with Rule 1b as currently stated
> actually introducing its own Kekule problems. But Rule 4b looks to me now
> to be no major problem. A bit complicated, for sure, but not so bad in the
> end. And I'm sure John will find some issues with what I have here. The
> key, as Peter Murray-Rust mentioned, is the construction of a very good set
> of test structures. There's more testing to do. I don't believe the
> structures that are in papers or in the IUPAC 2013 Blue Book are hardly
> enough to cover the bases. So I have no doubt that I missed something here,
> with the limited number of examples available to me. But I'm confident that
> the overall strategy is sound, and that additional issues will be minor.
>
> Take a look; let me know what you think. Thanks again for all the great
> comments and especially for great test cases.
>
> Bob
>
>   //  getChirality(molecule) {
>   //prefilterAtoms()
>   //checkForAlkenes()
>   //checkForSmallRings()
>   //checkForBridgeheadNitrogens()
>   //checkForKekuleIssues()
>   //checkForAtropisomerism()
>   //for(all filtered atoms) getAtomChirality(atom)
>   //if (haveAlkenes) {
>   //  for(all double bonds) getBondChirality(a1, a2)
>   //  removeUnnecessaryEZDesignations()
>   //}
>   //  }
>   //
>   // getAtomChirality(atom) {
>   //   for (each Rule){
>   // sortSubstituents()
>   // if (done) return checkHandedness();
>   //   }
>   //   return NO_CHIRALITY
>   // }
>   //
>   //  getBondChirality(a1, a2) {
>   //atop = getAlkeneEndTopPriority(a1)
>   //btop = getAlkeneEndTopPriority(a2)
>   //return (atop >= 0 && btop >= 0 ? getEneChirality(atop, a1, a2,
> btop) : NO_CHIRALITY)
>   //  }
>   //
>   // sortSubstituents() {
>   //   for (all pairs of substituents a1 and a2) {
>   // score = a1.compareTo(a2, currentRule)
>   // if (score == TIED)
>   //   score = breakTie(a1,a2)
>   // }
>   //
>   // breakTie(a,b) {
>   //score = compareShallowly(a, b)
>   //if (score != TIED) return score
>   //a.sortSubstituents(), b.sortSubstituents()
>   //return compareDeeply(a, b)
>   // }
>   //
>   // compareShallowly(a, b) {
>   //for (each substituent pairing i in a and b) {
>   //  score = applyCurrentRule(a_i, b_i)
>   //  if (score != TIED) return score
>   //}
>   //return TIED
>   // }
>   //
>   // compareDeeply(a, b) {
>   //bestScore = Integer.MAX_VALUE
>   //for (each substituent pairing i in a and b) {
>   //  bestScore = min(bestScore, breakTie(a_i, b_i)
>   //}
>   //return bestScore
>   // }
>
>
>


-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] Proposed amendment to CIP Rule 1b

[Robert Hanson]

On Wed, May 17, 2017 at 2:20 PM, John Mayfield <john.wilkinson...@gmail.com>
wrote:

>
> On 17 May 2017 at 18:01, Robert Hanson <hans...@stolaf.edu> wrote:
>
>> Oh, that is very cool. So you think this is a failure of Rule 4b in the
>> IUPAC rules? Very impressive. I don't think Jmol is making any mistake
>> here, do you?
>>
>
> It's from a German thesis that found it/proves it, see Handbook of
> Cheminformatics. Yes Jmol is correct.
>
> Thanks for that link. You will find that when you implement 1a fully, you
>> will need to pull it apart from 1b, applying Rule 1a exhaustively before
>> 1b. Otherwise it messes up. Pretty sure that is true with 4a, 4b, and 4c as
>> well. I guess that's obvious to  you; took me a while to catch on to that.
>> Is Centres doing that? 4a and 4b are both in PairRule, right?
>
>
> Yes it already does the hierarchy correctly (I feel like I'm repeating
> myself but see https://nextmovesoftware.com/blog/2015/01/21/r-or-s-lets-
> vote/).
>

You probably are repeating yourself. Sometimes that is necessary with email
threads like this. Thanks.


> I wrote  centres before the IUPAC document was officially published and
> need to adjust/split out some rules. But the pair rule if I remember
> correctly was the like vs unlike but maybe does 4a (I can't remember).
>
> It was only about 50 lines, actually, at least since all I did was for the
>> important cases (6-membered rings). Feel free to utilize it, of course. You
>> will need it anyway for the 1b correction. Or at least, for that you will
>> need some sort of Kekule check. Maybe you already have that somewhere
>> else
>
>
> What do you do for non-periodic atoms? For example
>
> *[C@H](=O)CC
>
>
It's Jmol. I don't think "non-periodic atoims" are part of CIP, are they?
In one of your examples, you have an "R" group. Jmol reads that as an atom
with 0 atom number. So that ends up R < H < C < O.


> If it's a polymer (e.g. carbohydrate) you can cyclise it and then compute
> CIP but this case I decided to handled by making it H < R < He  < .. etc.
>
> Great. I will incorporate those into my test suite. Are the target
>> designations in the files?
>>
>
> Unfortunately not they're in a Java Test class somewhere. I'll update it
> to SMILES (CXSMILES) soon which will make it easier than the CML.
>

OK, I will track those down.

Bob
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] Jmol - CIP update

[Robert Hanson]

OK, final (?) report. Always a good sign when code simplifies. I've
tightened up the algorithm, which passes all pertinent Chapter 9 tests,
plus several more. After removing unnecessary code, Jmol's CIP
implementation is now back to 970 lines, even with added (minimal) Kekule
considerations and full R/S, seqCis/seqTrans, and M/P mixing for Rules 4b
and 5. It would not take much more to add helicene identification.

I'm happy to report that the following simplified pseudocode is sufficient.
There is nothing magical here. The successful one-pass use of auxiliary
descriptors and finite digraphs should put to rest any concerns that CIP
determination of stereochemical descriptors has any cyclical dependencies
or routinely blows up. Except, perhaps, due to too many atoms and too high
symmetry. Every program will have its limits in this regard, of course, and
I think this algorithm could certainly be made more efficient. In any case,
the algorithm I have implemented demonstrates that this process can be a
one-pass process through all eight rules: 1a, 1b, 2, 3, 4a, 4b, 4c, and 5;
once through does it.

There are some nuances that are problematic -- a dependency on generating
multiple Kekule models, and a problem with Rule 1b as currently stated
actually introducing its own Kekule problems. But Rule 4b looks to me now
to be no major problem. A bit complicated, for sure, but not so bad in the
end. And I'm sure John will find some issues with what I have here. The
key, as Peter Murray-Rust mentioned, is the construction of a very good set
of test structures. There's more testing to do. I don't believe the
structures that are in papers or in the IUPAC 2013 Blue Book are hardly
enough to cover the bases. So I have no doubt that I missed something here,
with the limited number of examples available to me. But I'm confident that
the overall strategy is sound, and that additional issues will be minor.

Take a look; let me know what you think. Thanks again for all the great
comments and especially for great test cases.

Bob

  //  getChirality(molecule) {
  //prefilterAtoms()
  //checkForAlkenes()
  //checkForSmallRings()
  //checkForBridgeheadNitrogens()
  //checkForKekuleIssues()
  //checkForAtropisomerism()
  //for(all filtered atoms) getAtomChirality(atom)
  //if (haveAlkenes) {
  //  for(all double bonds) getBondChirality(a1, a2)
  //  removeUnnecessaryEZDesignations()
  //}
  //  }
  //
  // getAtomChirality(atom) {
  //   for (each Rule){
  // sortSubstituents()
  // if (done) return checkHandedness();
  //   }
  //   return NO_CHIRALITY
  // }
  //
  //  getBondChirality(a1, a2) {
  //atop = getAlkeneEndTopPriority(a1)
  //btop = getAlkeneEndTopPriority(a2)
  //return (atop >= 0 && btop >= 0 ? getEneChirality(atop, a1, a2,
btop) : NO_CHIRALITY)
  //  }
  //
  // sortSubstituents() {
  //   for (all pairs of substituents a1 and a2) {
  // score = a1.compareTo(a2, currentRule)
  // if (score == TIED)
  //   score = breakTie(a1,a2)
  // }
  //
  // breakTie(a,b) {
  //score = compareShallowly(a, b)
  //if (score != TIED) return score
  //a.sortSubstituents(), b.sortSubstituents()
  //return compareDeeply(a, b)
  // }
  //
  // compareShallowly(a, b) {
  //for (each substituent pairing i in a and b) {
  //  score = applyCurrentRule(a_i, b_i)
  //  if (score != TIED) return score
  //}
  //return TIED
  // }
  //
  // compareDeeply(a, b) {
  //bestScore = Integer.MAX_VALUE
  //for (each substituent pairing i in a and b) {
  //  bestScore = min(bestScore, breakTie(a_i, b_i)
  //}
  //return bestScore
  // }
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

[BlueObelisk-discuss] Proposed amendment to CIP Rule 1b

[Robert Hanson]

I'm interested in two things. First, feedback on a proposed amendment to
CIP Rule 1b. Second, suggestions for how to officially propose this.

Current Rule 1:


*(1a) higher atomic number precedes lower;*


*(1b) a duplicate atom node whose corresponding nonduplicated atom node is
the root or closer to the root ranks higher than a duplicate atom node
whose corresponding nonduplicated atom node is farther from the root. *Said
differently but with the same meaning:


*(1a) higher atomic number precedes lower;**(1b) in comparing two duplicate
nodes, lower root distance precedes higher root distance, where "root
distance" for a duplicate node is defined as*
* the distance from its corresponding nonduplicated atom node to the root
node.*
Proposed amended rule:


*(1a) higher atomic number precedes lower;*
*(1b) in comparing two duplicate nodes, lower root distance preceded higher
root distance, where "root distance" is defined:  (i) in the case of **a
duplicate atom for which the atomic number is averaged over two or more
atoms in applying Rule 1a, *


*the distance from the duplicate node itself to the root node; and  (ii) in
all other cases, the distance of its corresponding nonduplicated atom node
to the root node.*
If that means nothing to you, ignore this. But it is a critically important
addition for any algorithm if it is to correctly assign the stereochemistry
even for very simple compounds based on CIP rules 1-5. For example, without
that modification, an algorithm following the rules in IUPAC BB 2013 will
arrive at "S" for the descriptor for in this compound:

[image: Inline image 1]
C1=CC=CC(O)=C1[C@H](C2=CC=CC=C2O)O

My second question is, having said that, how do I go about officially
stating this? Publish? Where?


Bob


-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] Jmol - CIP update

[Robert Hanson]

OK, final update for a while. (816 lines, Wolf. I have no idea how that
compares to yours or others' algorithms.)

Open-source, validated IUPAC 2013 preferred IUPAC name (PIN) stereochemical
designations.

Jmol.___JmolVersion="14.15.2" // 4/29/17

 -- 816 lines
 -- validation data are at https://sourceforge.net/p/
jmol/code/HEAD/tree/trunk/Jmol-datafiles/cip/
 -- validates for 160 structures (some duplicates; both cip_examples.zip
and stereo_test_cases.sdf)
 -- validates for all cases considered:
   -- simple R/S and E/Z
   -- small-ring removal of E/Z
   -- parallel-strand Rule 4b and Rule 5 (Mata)
   -- pseudochiral r/s and m/p
   -- odd and even cumulenes
   -- atropisomers
   -- P, S, As, Se, Sb, Te, Bi, Po trigonal pyramidal and tetrahedral
   -- imine and diazine E/Z chirality

The algorithm will fail for some more complex nested aspects of Rule 4b. I
decided to be satisfied for now with only those examples in IUPAC Blue Book
2013 Chapter 9. My understanding is that even ACD/Labs did not fully
implement Rules 4 and 5 much beyond that.

Working version in JavaScript can be tested at https://chemapps.stolaf.edu/
jmol/jsmol/jsmetest2.htm
Binary and source at https://sourceforge.net/projects/jmol/files/Jmol/

A great challenge for April!

Bob



On Thu, Apr 27, 2017 at 12:21 AM, Robert Hanson <hans...@stolaf.edu> wrote:

> Rule 5 is done. Fully validating using the first validation set that Mikko
> sent me (86 compounds, roughly, some 2D/3D duplicates). I'm sure there are
> more cases it needs testing with, though.
>
> My algorithm implementation handles Rules 4 and 5 lexicographically so
> that a simple Array.sort(String[]) does the job. Kind of interesting,
> perhaps.
> ​
> 763 lines, Wolf.
>
> Bob
>
>
>


-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] First BlueObelisk article now OpenAccess

[Robert Hanson via Blueobelisk-discuss]

Great idea!
___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

[BlueObelisk-discuss] Fwd: case #CAS-843334-G6D6X8: PubChem Question - https://pubchem.ncbi.nlm.nih.g... TRACKING:000412000010244

[Robert Hanson via Blueobelisk-discuss]

Does anyone know a way to help PubChem fix/update OECHEM toolkit to
properly create cumulene 3D structures? (allene is planar). Is this just a
version issue?

Bob


-- Forwarded message -
From: NLM Support 
Date: Wed, Jan 19, 2022 at 12:23 PM
Subject: Re: case #CAS-843334-G6D6X8: PubChem Question -
https://pubchem.ncbi.nlm.nih.g... TRACKING:00041210244
To: Robert Hanson 


Hi,

A follow up:

This is an issue with the OEChem toolkit adopted by PubChem workflow to
process chemical structures and to generate 3D coordinates. It has problems
with allenic structures. The team is exploring other toolkits, which will
take time. Another point - currently there is no existing mechanism to do
any manual update due to human resource constraint.

Your patience and understanding will be greatly appreciated!

Regards,

Tao Tao, PhD
NCBI User Services
https://go.usa.gov/x647S

Case Information:
Case #: CAS-843334-G6D6X8
Customer Name: Robert Hanson
Customer Email: hans...@stolaf.edu
Case Created: 1/17/2022, 1:31:27 PM

Summary: PubChem Question -
https://pubchem.ncbi.nlm.nih.gov/compound/12590904

Details:

https://pubchem.ncbi.nlm.nih.gov/compound/12590904

Allene 3d is planar; should be twisted.
___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss

Re: [BlueObelisk-discuss] First BlueObelisk article now OpenAccess

[Robert Hanson via Blueobelisk-discuss]

yeah -- well, Happy New Year 2022!  Seems I picked up and replied to a
message from 2015!!! NO idea how that happened.


On Mon, Jan 17, 2022 at 11:58 PM Egon Willighagen <
egon.willigha...@gmail.com> wrote:

>
>
> On Tue, 18 Jan 2022 at 06:53, Robert Hanson via Blueobelisk-discuss <
> blueobelisk-discuss@lists.sourceforge.net> wrote:
>
>> Great idea!
>>
>
> Okay, no idea where this message is coming from :)
>
> It was indeed a great idea (imho). The first Blue Obelisk paper (
> https://pubs.acs.org/doi/10.1021/ci050400b) has had a CC-BY license for
> almost 7 years now:
> https://sourceforge.net/p/blueobelisk/mailman/message/33816652/ (thx to
> funding by Chris).
>
> Egon
>
> --
> 
> BiGCaT received a NWO Open Science grant to support our research into
> interoperability of biological data and knowledge:
> https://www.nature.com/articles/d41586-021-03418-1 and
> https://www.nwo.nl/en/researchprogrammes/open-science/open-science-fund/open-science-fund-2021-awarded-grants
>
> -
> E.L. Willighagen
> Department of Bioinformatics - BiGCaT
> Maastricht University (http://www.bigcat.unimaas.nl/)
> Twitter/Mastodon: @egonwillighagen <https://twitter.com/egonwillighagen>
>  / @egonw <https://scholar.social/@egonw>
> Homepage: http://egonw.github.io/
> Blog: http://chem-bla-ics.blogspot.com/
> PubList: https://www.zotero.org/egonw
> ORCID: -0001-7542-0286 <http://orcid.org/-0001-7542-0286>
> ImpactStory: https://impactstory.org/u/egonwillighagen
>


-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900

*We stand on the homelands of the Wahpekute Band of the Dakota Nation. We
honor with gratitude the people who have stewarded the land throughout the
generations and their ongoing contributions to this region. We acknowledge
the ongoing injustices that we have committed against the Dakota Nation,
and we wish to interrupt this legacy, beginning with acts of healing and
honest storytelling about this place.*
___
Blueobelisk-discuss mailing list
Blueobelisk-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss