You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
(8) |
May
(7) |
Jun
(9) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(1) |
Feb
(1) |
Mar
(4) |
Apr
(6) |
May
(17) |
Jun
(1) |
Jul
(2) |
Aug
(2) |
Sep
(3) |
Oct
(21) |
Nov
(6) |
Dec
(4) |
2003 |
Jan
(2) |
Feb
(5) |
Mar
|
Apr
(6) |
May
(21) |
Jun
(27) |
Jul
(14) |
Aug
(13) |
Sep
(30) |
Oct
(71) |
Nov
(188) |
Dec
(108) |
2004 |
Jan
(74) |
Feb
(341) |
Mar
(307) |
Apr
(64) |
May
(98) |
Jun
(185) |
Jul
(37) |
Aug
(175) |
Sep
(196) |
Oct
(206) |
Nov
(174) |
Dec
(399) |
2005 |
Jan
(136) |
Feb
(217) |
Mar
(265) |
Apr
(227) |
May
(198) |
Jun
(178) |
Jul
(239) |
Aug
(245) |
Sep
(290) |
Oct
(145) |
Nov
(120) |
Dec
(103) |
2006 |
Jan
(107) |
Feb
(276) |
Mar
(332) |
Apr
(255) |
May
(326) |
Jun
(121) |
Jul
(75) |
Aug
(236) |
Sep
(289) |
Oct
(337) |
Nov
(131) |
Dec
(90) |
2007 |
Jan
(64) |
Feb
(169) |
Mar
(233) |
Apr
(128) |
May
(409) |
Jun
(151) |
Jul
(82) |
Aug
(201) |
Sep
(150) |
Oct
(243) |
Nov
(117) |
Dec
(175) |
2008 |
Jan
(127) |
Feb
(155) |
Mar
(120) |
Apr
(260) |
May
(123) |
Jun
(108) |
Jul
(128) |
Aug
(253) |
Sep
(229) |
Oct
(224) |
Nov
(214) |
Dec
(127) |
2009 |
Jan
(77) |
Feb
(153) |
Mar
(89) |
Apr
(192) |
May
(182) |
Jun
(168) |
Jul
(84) |
Aug
(94) |
Sep
(126) |
Oct
(164) |
Nov
(143) |
Dec
(191) |
2010 |
Jan
(236) |
Feb
(249) |
Mar
(212) |
Apr
(286) |
May
(198) |
Jun
(208) |
Jul
(446) |
Aug
(291) |
Sep
(241) |
Oct
(217) |
Nov
(286) |
Dec
(120) |
2011 |
Jan
(141) |
Feb
(127) |
Mar
(247) |
Apr
(182) |
May
(159) |
Jun
(124) |
Jul
(193) |
Aug
(161) |
Sep
(267) |
Oct
(171) |
Nov
(205) |
Dec
(85) |
2012 |
Jan
(135) |
Feb
(72) |
Mar
(128) |
Apr
(202) |
May
(144) |
Jun
(219) |
Jul
(169) |
Aug
(71) |
Sep
(99) |
Oct
(118) |
Nov
(306) |
Dec
(140) |
2013 |
Jan
(220) |
Feb
(220) |
Mar
(305) |
Apr
(123) |
May
(189) |
Jun
(135) |
Jul
(81) |
Aug
(187) |
Sep
(281) |
Oct
(150) |
Nov
(332) |
Dec
(179) |
2014 |
Jan
(274) |
Feb
(253) |
Mar
(164) |
Apr
(196) |
May
(111) |
Jun
(237) |
Jul
(146) |
Aug
(120) |
Sep
(263) |
Oct
(151) |
Nov
(109) |
Dec
(87) |
2015 |
Jan
(202) |
Feb
(121) |
Mar
(101) |
Apr
(77) |
May
(91) |
Jun
(124) |
Jul
(71) |
Aug
(206) |
Sep
(140) |
Oct
(147) |
Nov
(119) |
Dec
(164) |
2016 |
Jan
(175) |
Feb
(77) |
Mar
(162) |
Apr
(104) |
May
(137) |
Jun
(126) |
Jul
(102) |
Aug
(55) |
Sep
(53) |
Oct
(63) |
Nov
(8) |
Dec
(41) |
2017 |
Jan
(40) |
Feb
(20) |
Mar
(53) |
Apr
(98) |
May
(34) |
Jun
(61) |
Jul
(74) |
Aug
(15) |
Sep
(96) |
Oct
(42) |
Nov
(54) |
Dec
(43) |
2018 |
Jan
(48) |
Feb
(81) |
Mar
(72) |
Apr
(36) |
May
(87) |
Jun
(49) |
Jul
(13) |
Aug
(26) |
Sep
(29) |
Oct
(24) |
Nov
(37) |
Dec
(15) |
2019 |
Jan
(28) |
Feb
(33) |
Mar
(61) |
Apr
(73) |
May
(52) |
Jun
(28) |
Jul
(53) |
Aug
(63) |
Sep
(38) |
Oct
(88) |
Nov
(63) |
Dec
(63) |
2020 |
Jan
(24) |
Feb
(5) |
Mar
(18) |
Apr
(9) |
May
(35) |
Jun
(42) |
Jul
(56) |
Aug
(95) |
Sep
(155) |
Oct
(215) |
Nov
(103) |
Dec
(65) |
2021 |
Jan
(173) |
Feb
(88) |
Mar
(35) |
Apr
(60) |
May
(31) |
Jun
(40) |
Jul
(76) |
Aug
(60) |
Sep
(32) |
Oct
(46) |
Nov
(82) |
Dec
(52) |
2022 |
Jan
(176) |
Feb
(163) |
Mar
(86) |
Apr
(82) |
May
(38) |
Jun
(28) |
Jul
(52) |
Aug
(87) |
Sep
(46) |
Oct
(103) |
Nov
(21) |
Dec
(36) |
2023 |
Jan
(24) |
Feb
(49) |
Mar
(22) |
Apr
(14) |
May
(28) |
Jun
(38) |
Jul
(71) |
Aug
(47) |
Sep
(58) |
Oct
(52) |
Nov
(18) |
Dec
(18) |
2024 |
Jan
(39) |
Feb
(67) |
Mar
(50) |
Apr
(65) |
May
(13) |
Jun
(24) |
Jul
(59) |
Aug
(58) |
Sep
(53) |
Oct
(9) |
Nov
|
Dec
|
From: Robert H. <ha...@st...> - 2024-10-11 14:49:18
|
more tweaks *Looking for the latest version? * Download Jmol-16.2.37-binary.zip (68.5 MB) <https://sourceforge.net/projects/jmol/files/latest/download> Jmol.___JmolVersion="16.2.37" // (legacy) also 16.2.38 (swingJS) bug fix: various issues with subgroups path description for expanded cell routes bug fix: switching SHOW SPACEGROUP DIAGRAM to University College London hypertextbook site -- now making calls to http://img.chem.ucl.ac.uk/sgp/large/sgp.htm -- ITA wiley site has been placed behind a paywall bug fix: various fixes relating to new subperiodic group features bug fix: unitcell and DRAW UNITCELL for subperiodic and plane groups -- modification to more clearly indicate nonperiodic axes test: test/script/16.2 passing 72 tests -- Robert M. Hanson Professor of Chemistry, Emeritus 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.* |
From: Robert H. <ha...@st...> - 2024-10-09 16:50:08
|
Keith, it looks like MP has gone to an API that requires logging in and creating an API key. I've sent a message to them asking if there is any way Jmol users can access their site directly. Guessing the answer is no. On Mon, Oct 7, 2024 at 8:35 AM Keith Refson <kr...@gm...> wrote: > Dear All, > > The documented syntax > > load =mp/24972 > > does not appear to work, yielding an error > > fetching https://www.materialsproject.org/materials/mp-24972/cif#_DOCACHE_ > script ERROR: unrecognized file format for filehttps://www.materialsproject.org/materials/mp-24972/cif#_DOCACHE_ > > Is this a known issue with the Materials Project retrieval? > > Keith Refson > > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users > -- Robert M. Hanson Professor of Chemistry, Emeritus 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.* |
From: Robert H. <ha...@st...> - 2024-10-09 16:13:35
|
Ah, FYI SPIN and CAPTURE ROCK/SPIN are broken in this version; this due to a but I created implementing the COMPARE ... MORPH feature. I will get the next version out today. |
From: Robert H. <ha...@st...> - 2024-10-09 01:57:11
|
A busy few weeks.... *Looking for the latest version? * Download Jmol-16.2.33-binary.zip (92.6 MB) <https://sourceforge.net/projects/jmol/files/latest/download> The 2024 Latin American Crystallography Association meeting Sept. 23-26 <https://www.laca2024.pedeciba.edu.uy/> was a huge success, with lots of good ideas for Jmol generated by participants. This release introduces many of these ideas, including the expansion of Jmol's capabilities beyond crystallographic space groups, supporting plane groups, layer groups, rod groups, and frieze groups with novel ways of modeling symmetry elements, generating Wyckoff positions, and changing settings. Plenty of more work to be done on these, but it's a start. More generally, the "element key" idea has been expanded as a "label key" idea, allowing the production of a key on the right side of the window to describe atoms based on their label (such as atom Wyckoff positions) in a simple format. [image: image.png] modelkit zap spacegroup 46 draw spacegroup all modelkit add wyckoff all packed label %[wyckoffm]; label hide set labelKey TRUE Any label can be listed, provided that there is a 1:1 correlation between atom color and label. It doesn't have to have anything to do with crystallography. The full list of 14 new features and one bug fix follows. Bob Jmol.___JmolVersion="16.2.33" // (legacy) also 16.2.34 (swingJS) NOTE: LACA2024 refers to ideas generated from the Latin American Crystallographic Association meeting, Sept 23-26, 2024 new feature: (LACA2024) MOVETO PLANE [1 0 0] -- reorients a crystal structure along the given crystallographic direction -- "PLANE" here means "plane perpendicular to the axis {1 0 0/1}" -- uses quaternion differences to calculate the needed direct rotation new feature: (LACA2024) set labelKey TRUE/FALSE -- when set TRUE, adds a key on the right -- removes any key created with set elementKey -- removed if set elementkey is issued -- key indicates atom color correspondence with atom labels (alphabetically) -- key is disabled when: -- a color corresponds to more than one label -- a given label corresponds to more than one atom color -- note that LABEL HIDE can still be used -- particularly useful for showing wyckoff positions -- example: modelkit spacegroup 62 modelkit add wyckoff all packed label %[wyckoffm] set labelkey label hide set picking dragatom modelkit draw spacegroup 47 modelkit add wyckoff all packed label %[wyckoff] label hide set labelkey new feature: (LACA2024) set mode2d (experimental) -- when set TRUE, disables mouse rotation new feature: (LACA2024) using set dragAtom with symmetry, a "collision" with a symmetry element results in a red warning halo around all equivalent atoms. new feature: (LACA2024) modelkit unitcell {0 1 0} -- retains space group as long as this is a unit lattice shift new feature: (LACA2024) modelkit unitcell {0 1 0} packed -- retains space group as long as this is a unit lattice shift -- packs the new unit cell -- CONNECT is not executed; if bonding is required, follow by the CONNECT command new feature: (LACA2024) MODELKIT ADD <element> <position> Wyckoff ALL PACKED -- adds a full set of atoms for each Wyckoff position -- uses the list "Al B C D Fe F Ga He I Ge K Li Mg N Os P Ca Rh S T U V W Xe Yb Zn Am" to provide 27 different colors and sizes (Space Group 47 uses all of these) -- Aluminum for "a", Boron for "b", etc. -- <element> is an element symbol to be used to specify the general position -- default is "O" (which is not on this list already) -- <position> is an optional fractional position and defaults to {0.53, 0.20, 0.16} -- PACKED is optional -- for example: modelkit draw spacegroup 47 modelkit add wyckoff all packed label %[wyckoffm]; labels hide set labelKey modelkit zap spacegroup 148 modelkit add O {0.1 0.11 0.15} wyckoff all packed spacefill 0.3 new feature: (LACA2024) x = plane([u v w]) -- u v w are fractional coordinates, generally integers -- do not use "1/2" here -- generates the plane perpendicular to the given direct space fractional vector {u v w/1} new feature: (LACA2024) x = {*}.plane([u v w]) -- u v w are fractional coordinates, generally integers -- do not use "1/2" here -- generates an array of coordinates that are the projection onto the plane perpendicular to the given direct space fractional vector {u v w/1} new feature: (LACA2024) compare <atoms> <coordinates> MORPH -- smoothly and linearly converts atom coordinates to the specified list of coordinates. -- example projecting all atoms onto a plane in a crystal structure compare {*} @{{*).plane([1 1 1])} MORPH new feature: (LACA2024) SHOW WYCKOFF -- lists Wyckoff positions without multiplicities new feature: (LACA2024) SHOW WYCKOFFM -- lists Wyckoff positions with multiplicities new feature: (LACA2024) DRAW VECTOR NOHEAD pt1 v1 -- uses point and vector, but displays just the cylinder without an arrow head -- introduced in Jmol 11.5.40 (June 2008!) but undocumented and broken new feature: (LACA2024) adds support for plane, layer, rod, and frieze groups. -- CLEG designations add prefixes p/ l/ r/ f/ -- full support for adding atoms, designating Wyckoff positioning, and moving atoms around -- introduces a new way to show nonperiodic dimensions using "open-ended" unit cells -- prefixes also work with Hermann-Mauguin names. (this was necessary because there is cross-over between names among the group types) -- subgroups are not supported yet -- for example: modelkit draw spacegroup p/15; modelkit add wyckoff all packed; modelkit draw spacegroup l/p6/mmm; modelkit add wyckoff all packed; set picking dragatom; bug fix: RESET should restore crystal structure to "center unitcell" |
From: Robert H. <ha...@st...> - 2024-10-07 18:07:45
|
Probably just freezer burn. I will check. On Mon, Oct 7, 2024 at 8:35 AM Keith Refson <kr...@gm...> wrote: > Dear All, > > The documented syntax > > load =mp/24972 > > does not appear to work, yielding an error > > fetching https://www.materialsproject.org/materials/mp-24972/cif#_DOCACHE_ > script ERROR: unrecognized file format for filehttps://www.materialsproject.org/materials/mp-24972/cif#_DOCACHE_ > > Is this a known issue with the Materials Project retrieval? > > Keith Refson > > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users > -- Robert M. Hanson Professor of Chemistry, Emeritus 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.* |
From: Keith R. <kr...@gm...> - 2024-10-07 13:35:33
|
Dear All, The documented syntax load =mp/24972 does not appear to work, yielding an error fetchinghttps://www.materialsproject.org/materials/mp-24972/cif#_DOCACHE_ script ERROR: unrecognized file format for file https://www.materialsproject.org/materials/mp-24972/cif#_DOCACHE_ Is this a known issue with the Materials Project retrieval? Keith Refson |
From: Angel H. <ang...@ua...> - 2024-10-07 11:08:37
|
That solved it. Thanks Dr. Angel Herráez Biochemistry and Molecular Biology, Dept. of Systems Biology, University of Alcalá E-28805 Alcalá de Henares (Madrid), Spain ________________________________ De: Jaime Prilusky <jai...@we...> Enviado: lunes, 7 de octubre de 2024 11:07 Para: m0lviz--- via Jmol-users <jmo...@li...> Asunto: Re: [Jmol-users] help - How to unlock MacOS security for running Jmol.jar (URGENT) ATENCIÓN: Este correo electrónico se envió desde fuera de la UAH. No haga clic en enlaces ni abra archivos adjuntos a menos que reconozca al remitente y sepa que el contenido es seguro. If the error is the one on the screenshot below [cid:cae8620c-643c-4736-b757-82f93170672c@EURP191.PROD.OUTLOOK.COM] Then right-click on Jmol.jar (or Ctrl-left-click) and on the menu that opens click Open. It will ask you if your’e sure to open, as in the screenshot below. Simply click [Open] [cid:49670785-1b7a-4399-93f0-67ee36e2d2ac@EURP191.PROD.OUTLOOK.COM] Jaim > On 7 Oct 2024, at 11:55, Angel Herráez <ang...@ua...> wrote: > > Caution: External Sender. Do not click on links or open attachments unless you recognize the sender. > > Please, can any Mac user tell me how to allow running Jmol.jar in MacOS? > > I am running a course this morning and the students with Mac laptops cannot run Jmol to due to Java security policy. > > All information I find on the web speaks of exceptions in URLs, none on local files. > > Thanks > > -- > · > Dr. Angel Herráez > Biochemistry and Molecular Biology, > Dept. of Systems Biology, University of Alcalá > E-28805 Alcalá de Henares (Madrid), Spain > https://biomodel.uah.es/ > > > > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users |
From: Jaime P. <jai...@we...> - 2024-10-07 09:23:44
|
If the error is the one on the screenshot below [cid:cae8620c-643c-4736-b757-82f93170672c@EURP191.PROD.OUTLOOK.COM] Then right-click on Jmol.jar (or Ctrl-left-click) and on the menu that opens click Open. It will ask you if your’e sure to open, as in the screenshot below. Simply click [Open] [cid:49670785-1b7a-4399-93f0-67ee36e2d2ac@EURP191.PROD.OUTLOOK.COM] Jaim > On 7 Oct 2024, at 11:55, Angel Herráez <ang...@ua...> wrote: > > Caution: External Sender. Do not click on links or open attachments unless you recognize the sender. > > Please, can any Mac user tell me how to allow running Jmol.jar in MacOS? > > I am running a course this morning and the students with Mac laptops cannot run Jmol to due to Java security policy. > > All information I find on the web speaks of exceptions in URLs, none on local files. > > Thanks > > -- > · > Dr. Angel Herráez > Biochemistry and Molecular Biology, > Dept. of Systems Biology, University of Alcalá > E-28805 Alcalá de Henares (Madrid), Spain > https://biomodel.uah.es/ > > > > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users |
From: Angel H. <ang...@ua...> - 2024-10-07 08:55:34
|
Please, can any Mac user tell me how to allow running Jmol.jar in MacOS? I am running a course this morning and the students with Mac laptops cannot run Jmol to due to Java security policy. All information I find on the web speaks of exceptions in URLs, none on local files. Thanks -- · Dr. Angel Herráez Biochemistry and Molecular Biology, Dept. of Systems Biology, University of Alcalá E-28805 Alcalá de Henares (Madrid), Spain https://biomodel.uah.es/ |
From: Randall H. <ran...@do...> - 2024-09-26 23:15:39
|
Hi Bob, did you get a chance to look at this file? Randy Randall Hall (he/him/his) Emeritus Professor of Chemistry Dominican University of California ran...@do... 220 Science Center Phone: 415-482-1911 Fax: 415-482-1972 > On Aug 28, 2024, at 6:49 PM, Randall Hall <ran...@do...> wrote: > > Hi Bob, > Thanks for taking a look. The file is attached. My version of jmol (and other info is) > > Jmol Version: 16.1.63 2024-03-04 14:40 > java.vendor: Java: Oracle Corporation > java.version: Java 1.8.0_421 > os.name: Mac OS X > > > Randy > <syn-1.zn.2h2o.relax.out> > > Randall Hall (he/him/his) > Emeritus Professor of Chemistry > Dominican University of California > ran...@do... > 220 Science Center > Phone: 415-482-1911 > Fax: 415-482-1972 > > > > >> On Aug 28, 2024, at 4:40 PM, Robert Hanson via Jmol-users <jmo...@li...> wrote: >> >> Send me the offending file, please. >> _______________________________________________ >> Jmol-users mailing list >> Jmo...@li... >> https://lists.sourceforge.net/lists/listinfo/jmol-users > |
From: Norwid B. <nb...@ya...> - 2024-09-26 16:26:13
|
After amending my knowledge about .sdf files, the issue was resolved. The Wikipedia article[1] about .sdf and Jmol wiki[2] outline Jmol can read the absolute configuration from the bound block's fourth column of a .mol file (V2000). This place is used for instance by MarvinJS, ChemDraw/ChemDrawJS. According to Biovia's documentation (appendix A, page 99, [3]) the stereogenic center is identified, the closest atoms are arranged by their id number in the file (`%i` in Jmol) in increasing order; if one of them is an atom of hydrogen, then hydrogen is assigned with the highest number. If inspected along the axis of the atom of highest ID and atom of the center, the sequence of increasing IDs of the remaining atoms either turns anticlockwise (up -> label `1`), or clockwise (down -> label `6`). At present, neither the Wikipedia article, nor Jmol wiki share that the atom block equally can provide this information in column 7 (three columns past the element symbol) with either - `0` absence of stereochemistry - `1` odd parity (the sequence mentioned above is anticlockwise) - `2` even parity (the sequence mentioned above is clockwise) - `3` either or unmarked stereo center .mol files written by OpenBabel, or the ones fetched with Jmol from NIH cactus servers follow this pattern. For the export of a .mol (V2000) with explicit stereo information in the bound block (i.e., first pattern) as a new .mol file, Jmol uses the second pattern. By now (Jmol version 16.2.21) this can yield multiple carbon atoms with a newly assigned label `1` or `2` instead of the anticipated continued use of `0`. I didn't identify a cause for this. But Jmol still assigned on such a file the same CIP label, and OpenBabel's generation of a SMILES string was not affected by the change either. My "take home message" is i) that a parity label in column 7 (atom block) other than `0` alone is not a necessity in a .mol (V2000) file to describe a stereogenic center. And ii) a bound block of three columns needn't be incomplete, either. Indeed, Biovia Draw 2024 uses both column 7 (atom block) and column 4 (bound block) to describe fructose. Best regards, Norwid [1] https://en.wikipedia.org/wiki/Chemical_table_file#SDF, edit 10 March 2024 [2] https://wiki.jmol.org/index.php/Support_for_stereochemistry, 21 May 2010 [3] https://web.archive.org/web/20210219065450/https://discover.3ds.com/sites/default/files/2020-08/biovia_ctfileformats_2020.pdf |
From: Robert H. <ha...@st...> - 2024-09-25 21:21:01
|
Thanks, Mike. Let me know if you need anything. |
From: Mike C. <mik...@uc...> - 2024-09-25 11:18:17
|
Thanks Bob, I've read your paper and can now see how to fix my scripts, as well as a number of possibilities that I hadn't recognised previously. Problems involving drawing isomers were already top of my to-do list, hopefully they will be available sometime next month. I'm retired now and developing ChemInteractive is great for keeping my brain active. I've looked at some of the other Cheminformatics packages out there, but keep coming back to Jmol because of it's power and ease of implementation - all thanks to your superb work. Best regards, Mike On Tue, 24 Sept 2024 at 23:18, Robert Hanson via Jmol-users < jmo...@li...> wrote: > Super, Mike > This is exactly what it is designed for. Whether the app is visible or > not you can use it to answer all sorts of questions about the student work. > Note that it can distinguish isomer types. > > > Enjoy. > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users > |
From: Robert H. <ha...@st...> - 2024-09-24 22:18:34
|
Super, Mike This is exactly what it is designed for. Whether the app is visible or not you can use it to answer all sorts of questions about the student work. Note that it can distinguish isomer types. Enjoy. |
From: Mike C. <mik...@uc...> - 2024-09-24 20:49:52
|
Thank you Otis, that's what I was working on prior to Bob's replies. Enjoy the walk with Linus (interesting name). Many thanks Bob, I had completely overlooked those subtleties. I will study your paper and try again. I want to use SMARTS searches too and I need to get the details of your work clear. Those features in JSmol are great! FWIW, my project is cheminteractive.ie. Mike On Tue, 24 Sept 2024 at 21:37, Robert Hanson via Jmol-users < jmo...@li...> wrote: > https://jcheminf.biomedcentral.com/articles/10.1186/s13321-016-0160-4 > > > *Finally, by allowing for double bonds between aromatic atoms, we can > specify that double bonds in the pattern must also be present in the model > or SMILES string being compared. That is, a successful match requires a > specified Kekulé form of an aromatic system. It can be used to check to see > if models from two different sources have the same Kekulé form. For > example, 2-methylpyridine models retrieved from NCI/CADD and PubChem have > different Kekulé forms. We need aromaticity models to compare them, but we > still might want to distinguish them. The Jmol SMILES string [n]1ccccc1(C) > will match both, but [n]1=cc=cc=c1(C) will match only the one from PubChem. > * > > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users > |
From: Robert H. <ha...@st...> - 2024-09-24 20:37:37
|
https://jcheminf.biomedcentral.com/articles/10.1186/s13321-016-0160-4 *Finally, by allowing for double bonds between aromatic atoms, we can specify that double bonds in the pattern must also be present in the model or SMILES string being compared. That is, a successful match requires a specified Kekulé form of an aromatic system. It can be used to check to see if models from two different sources have the same Kekulé form. For example, 2-methylpyridine models retrieved from NCI/CADD and PubChem have different Kekulé forms. We need aromaticity models to compare them, but we still might want to distinguish them. The Jmol SMILES string [n]1ccccc1(C) will match both, but [n]1=cc=cc=c1(C) will match only the one from PubChem. * |
From: Robert H. <ha...@st...> - 2024-09-24 20:27:14
|
Has to do with using aromatic designations. The algorithm is designed to be asynchronous in this regard. note that if(smiles1.find("SMILES", smiles2) > 0) { print "These are the same." } Does report that they are the same. Why is that? smiles1 = "C1=C(NC(=O)C)C=CC(=C1)O" smiles2 = "CC(=O)Nc1ccc(O)cc1" if(smiles2.find("SMILES", smiles1) > 0) { print "These are the same." } NOT smiles1 = "CC(=O)Nc1ccc(O)cc1" smiles2 = "C1=C(NC(=O)C)C=CC(=C1)O" if(smiles2.find("SMILES", smiles1) > 0) { print "These are the same." } ARE the same. In the first case, you are asking if an aromatic designation "equals" a Kekulé structure. This is designed to return false. Bob |
From: Otie R. <oti...@gm...> - 2024-09-24 20:04:30
|
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Mike,<div><br></div><div>I don't know the details, but Bob and Peter Ertl put significant effort into making JSME and JSmol "talk" to each other. I did not pay much attention because I have run both applets in the same HTML page for years. It may be that Bob's JSME/JSmol work has a procedure for doing what you want to do - i.e. convert a JSME SMILES to a JSmol SMILES. Alternatively, a hidden JSmol applet might work. I'm assuming that your web app has both JSmol and JSME.</div><div><br></div><div>If you have both JSME and JSmol in you web page app, you could also write script that does the following:</div><div><br></div><div>1) Save the current JSmol model.</div><div>2) Load the JSME model.</div><div>3) Get the new SMILES.</div><div>4) Load the original (1 above) model.</div><div><br></div><div>I am absolutely sure that Bob has a better approach! I just thought I'd make the suggestion before I take my dog Linus for a walk!</div><div><br></div><div><br id="lineBreakAtBeginningOfSignature"><div dir="ltr">--<div><div>Otis Rothenberger</div><div>oti...@gm...</div><div>https://chemagic.org</div></div></div><div dir="ltr"><br><blockquote type="cite">On Sep 24, 2024, at 2:12 PM, Mike Casey <mik...@uc...> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">Hi Otis,</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">Thank you for the suggestions.</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">I'm not sure about your analysis is the first response, I think (based on the JSmol interactive documentation) that the comparison should give a match regardless of the origins of the SMILES strings, and it does seem to work for all the non-aromatic examples that I have tried, but I'm not at all sure of that. When (non-canonical) SMILES strings are generated in JSmol using the "noaromatic" qualifier, the comparisons with strings from other sources seem to work OK.</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">Irrespective of the origin of the issue, I agree that loading the structures into JSmol is a good bet for tackling the problem and I'm exploring that now.</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">Many thanks,</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><br></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div><div><div>Mike </div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 24 Sept 2024 at 18:11, Otie Rothenberger <<a href="mailto:oti...@gm...">oti...@gm...</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Mike,<div><br></div><div><p style="margin:0px;font-stretch:normal;line-height:normal;font-size-adjust:none;font-kerning:auto;font-variant-alternates:normal;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-east-asian:normal;font-feature-settings:normal"><span style="font-family:UICTFontTextStyleBody">After my usual wordy email, I think the problem is as simple as this: The JSmol SMILES comparison models must have exactly the same JSmol characters! I'm not sure how to handle this with JSME other than actually loading the JSME SMILES into JSmol.</span></p><p style="margin:0px;font-stretch:normal;line-height:normal;font-size-adjust:none;font-kerning:auto;font-variant-alternates:normal;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-east-asian:normal;font-feature-settings:normal"><span style="font-family:UICTFontTextStyleBody"><br></span></p><div dir="ltr">--<div><div>Otis Rothenberger</div><div><a href="mailto:oti...@gm..." target="_blank">oti...@gm...</a></div><div><a href="https://chemagic.org" target="_blank">https://chemagic.org</a></div></div></div><div dir="ltr"><br><blockquote type="cite">On Sep 24, 2024, at 11:05 AM, Otie Rothenberger <<a href="mailto:oti...@gm..." target="_blank">oti...@gm...</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">Mike,<div><br></div><div><p style="margin:0px;font-stretch:normal;line-height:normal;font-size-adjust:none;font-kerning:auto;font-variant-alternates:normal;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-east-asian:normal;font-feature-settings:normal"><span style="font-family:UICTFontTextStyleBody">This is a wild guess on my part, but since I use both JSmol and JSME in my CheMagic app, I'll offer the guess.</span></p><p style="margin:0px;font-stretch:normal;line-height:normal;font-size-adjust:none;font-kerning:auto;font-variant-alternates:normal;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-east-asian:normal;font-feature-settings:normal;min-height:34px"><span style="font-family:UICTFontTextStyleBody"></span><br></p><p style="margin:0px;font-stretch:normal;line-height:normal;font-size-adjust:none;font-kerning:auto;font-variant-alternates:normal;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-east-asian:normal;font-feature-settings:normal"><span style="font-family:UICTFontTextStyleBody">JSmol SMILES are not canonical; JSME SMILES are canonical. IF two model SMILES, are created in JSmol, then the comparison will work independent of atom drawing order in the two models. This comparison will not work comparing JSME canonical and JSmol non-canonical SMILES.</span></p><p style="margin:0px;font-stretch:normal;line-height:normal;font-size-adjust:none;font-kerning:auto;font-variant-alternates:normal;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-east-asian:normal;font-feature-settings:normal;min-height:34px"><span style="font-family:UICTFontTextStyleBody"></span><br></p><p style="margin:0px;font-stretch:normal;line-height:normal;font-size-adjust:none;font-kerning:auto;font-variant-alternates:normal;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-east-asian:normal;font-feature-settings:normal"><span style="font-family:UICTFontTextStyleBody">As to the solution to your problem, I have to think about that. I know that Bob has included JSME/JSmol communication into JSmol. I do not use this because JSmol and JSME are combined in my app, and they talk to each othe. It seems to me that this should work by changing the aromatic "c" to "C", but that case change gets very tricky in general for obvious reasons. </span></p><p style="margin:0px;font-stretch:normal;line-height:normal;font-size-adjust:none;font-kerning:auto;font-variant-alternates:normal;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-east-asian:normal;font-feature-settings:normal"><span style="font-family:UICTFontTextStyleBody"><br></span></p><p style="margin:0px;font-stretch:normal;line-height:normal;font-size-adjust:none;font-kerning:auto;font-variant-alternates:normal;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-east-asian:normal;font-feature-settings:normal"><span style="font-family:UICTFontTextStyleBody"><br></span></p><div dir="ltr">--<div><div>Otis Rothenberger</div><div><a href="mailto:oti...@gm..." target="_blank">oti...@gm...</a></div><div><a href="https://chemagic.org" target="_blank">https://chemagic.org</a></div></div></div><div dir="ltr"><br><blockquote type="cite">On Sep 24, 2024, at 9:55 AM, Mike Casey <<a href="mailto:mik...@uc..." target="_blank">mik...@uc...</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small">Hi All,</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><br></div><div class="gmail_default"><font face="arial, sans-serif">Working with </font><b style="font-family:Arial,Helvetica,sans-serif;font-size:small">Jmol 16.2.17 2024-06-07</b>, I found a curious issue with the extremely useful ".find" SMILES/SMARTS feature.</div><div class="gmail_default"><br></div><div class="gmail_default">Taking the example from the interactive scripting documentation page, the following script which compares the SMILES for acetaminophen from two different sources works as expected:</div><div class="gmail_default"><br></div>smiles1 = "C1=C(NC(=O)C)C=CC(=C1)O"<br>smiles2 = "CC(=O)NC1=CC=C(C=C1)O"<br>if(smiles2.find("SMILES", smiles1) > 0) {<br>print "These are the same."<br>}<div class="gmail_default"><br></div><div class="gmail_default">However, using the SMILES string from JSME, as follows, does not give a match:</div><div class="gmail_default"><br></div>smiles1 = "C1=C(NC(=O)C)C=CC(=C1)O"<br>smiles2 = "CC(=O)Nc1ccc(O)cc1"<br>if(smiles2.find("SMILES", smiles1) > 0) {<br>print "These are the same."<br>}<div class="gmail_default"><span style="color:rgb(0,0,0);font-family:helvetica;font-size:14.6667px;background-color:rgb(229,229,229)"><br></span></div><span class="gmail_default" style="font-family:arial,sans-serif;font-size:small"></span>C<span class="gmail_default" style="font-family:arial,sans-serif;font-size:small">omparing </span>"CC(=O)Nc1ccc(O)cc1"<span style="color:rgb(0,0,0);font-family:helvetica;font-size:14.6667px;background-color:rgb(229,229,229)"><span class="gmail_default" style="font-family:arial,sans-serif;font-size:small"></span></span> <span class="gmail_default" style="font-family:arial,sans-serif;font-size:small">with itself also fails to give a match! A bit more experimentation suggests that the problem arises quite commonly with SMILES strings containing lowercase element symbols used to indicate aromatic structures.</span></div><div dir="ltr"><span class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><br></span></div><div dir="ltr"><font face="arial, sans-serif"><span class="gmail_default" style="font-family:arial,sans-serif;font-size:small">Have I overlooked something or is this a bug?</span></font></div><div dir="ltr"><font face="arial, sans-serif"><br></font></div><div dir="ltr"><font face="arial, sans-serif"><span class="gmail_default" style="font-family:arial,sans-serif;font-size:small"></span></font>Mike Casey<div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div> <span>_______________________________________________</span><br><span>Jmol-users mailing list</span><br><span><a href="mailto:Jmo...@li..." target="_blank">Jmo...@li...</a></span><br><span><a href="https://lists.sourceforge.net/lists/listinfo/jmol-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/jmol-users</a></span><br></div></blockquote></div></div></blockquote></div></div>_______________________________________________<br> Jmol-users mailing list<br> <a href="mailto:Jmo...@li..." target="_blank">Jmo...@li...</a><br> <a href="https://lists.sourceforge.net/lists/listinfo/jmol-users" rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/jmol-users</a><br> </blockquote></div> <span>_______________________________________________</span><br><span>Jmol-users mailing list</span><br><span>Jmo...@li...</span><br><span>https://lists.sourceforge.net/lists/listinfo/jmol-users</span><br></div></blockquote></div></body></html> |
From: Mike C. <mik...@uc...> - 2024-09-24 19:10:50
|
Hi Otis, Thank you for the suggestions. I'm not sure about your analysis is the first response, I think (based on the JSmol interactive documentation) that the comparison should give a match regardless of the origins of the SMILES strings, and it does seem to work for all the non-aromatic examples that I have tried, but I'm not at all sure of that. When (non-canonical) SMILES strings are generated in JSmol using the "noaromatic" qualifier, the comparisons with strings from other sources seem to work OK. Irrespective of the origin of the issue, I agree that loading the structures into JSmol is a good bet for tackling the problem and I'm exploring that now. Many thanks, Mike On Tue, 24 Sept 2024 at 18:11, Otie Rothenberger < oti...@gm...> wrote: > Mike, > > After my usual wordy email, I think the problem is as simple as this: The > JSmol SMILES comparison models must have exactly the same JSmol > characters! I'm not sure how to handle this with JSME other than actually > loading the JSME SMILES into JSmol. > > > -- > Otis Rothenberger > oti...@gm... > https://chemagic.org > > On Sep 24, 2024, at 11:05 AM, Otie Rothenberger < > oti...@gm...> wrote: > > Mike, > > This is a wild guess on my part, but since I use both JSmol and JSME in my > CheMagic app, I'll offer the guess. > > > JSmol SMILES are not canonical; JSME SMILES are canonical. IF two model > SMILES, are created in JSmol, then the comparison will work independent of > atom drawing order in the two models. This comparison will not work > comparing JSME canonical and JSmol non-canonical SMILES. > > > As to the solution to your problem, I have to think about that. I know > that Bob has included JSME/JSmol communication into JSmol. I do not use > this because JSmol and JSME are combined in my app, and they talk to each > othe. It seems to me that this should work by changing the aromatic "c" to > "C", but that case change gets very tricky in general for obvious reasons. > > > > -- > Otis Rothenberger > oti...@gm... > https://chemagic.org > > On Sep 24, 2024, at 9:55 AM, Mike Casey <mik...@uc...> wrote: > > > Hi All, > > Working with *Jmol 16.2.17 2024-06-07*, I found a curious issue with the > extremely useful ".find" SMILES/SMARTS feature. > > Taking the example from the interactive scripting documentation page, the > following script which compares the SMILES for acetaminophen from two > different sources works as expected: > > smiles1 = "C1=C(NC(=O)C)C=CC(=C1)O" > smiles2 = "CC(=O)NC1=CC=C(C=C1)O" > if(smiles2.find("SMILES", smiles1) > 0) { > print "These are the same." > } > > However, using the SMILES string from JSME, as follows, does not give a > match: > > smiles1 = "C1=C(NC(=O)C)C=CC(=C1)O" > smiles2 = "CC(=O)Nc1ccc(O)cc1" > if(smiles2.find("SMILES", smiles1) > 0) { > print "These are the same." > } > > Comparing "CC(=O)Nc1ccc(O)cc1" with itself also fails to give a match! A > bit more experimentation suggests that the problem arises quite commonly > with SMILES strings containing lowercase element symbols used to indicate > aromatic structures. > > Have I overlooked something or is this a bug? > > Mike Casey > > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users > > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users > |
From: Otie R. <oti...@gm...> - 2024-09-24 17:11:00
|
Mike, After my usual wordy email, I think the problem is as simple as this: The JSmol SMILES comparison models must have exactly the same JSmol characters! I'm not sure how to handle this with JSME other than actually loading the JSME SMILES into JSmol. -- Otis Rothenberger oti...@gm... https://chemagic.org > On Sep 24, 2024, at 11:05 AM, Otie Rothenberger <oti...@gm...> wrote: > > Mike, > > This is a wild guess on my part, but since I use both JSmol and JSME in my CheMagic app, I'll offer the guess. > > JSmol SMILES are not canonical; JSME SMILES are canonical. IF two model SMILES, are created in JSmol, then the comparison will work independent of atom drawing order in the two models. This comparison will not work comparing JSME canonical and JSmol non-canonical SMILES. > > As to the solution to your problem, I have to think about that. I know that Bob has included JSME/JSmol communication into JSmol. I do not use this because JSmol and JSME are combined in my app, and they talk to each othe. It seems to me that this should work by changing the aromatic "c" to "C", but that case change gets very tricky in general for obvious reasons. > > > -- > Otis Rothenberger > oti...@gm... > https://chemagic.org > >>> On Sep 24, 2024, at 9:55 AM, Mike Casey <mik...@uc...> wrote: >>> >> >> Hi All, >> >> Working with Jmol 16.2.17 2024-06-07, I found a curious issue with the extremely useful ".find" SMILES/SMARTS feature. >> >> Taking the example from the interactive scripting documentation page, the following script which compares the SMILES for acetaminophen from two different sources works as expected: >> >> smiles1 = "C1=C(NC(=O)C)C=CC(=C1)O" >> smiles2 = "CC(=O)NC1=CC=C(C=C1)O" >> if(smiles2.find("SMILES", smiles1) > 0) { >> print "These are the same." >> } >> >> However, using the SMILES string from JSME, as follows, does not give a match: >> >> smiles1 = "C1=C(NC(=O)C)C=CC(=C1)O" >> smiles2 = "CC(=O)Nc1ccc(O)cc1" >> if(smiles2.find("SMILES", smiles1) > 0) { >> print "These are the same." >> } >> >> Comparing "CC(=O)Nc1ccc(O)cc1" with itself also fails to give a match! A bit more experimentation suggests that the problem arises quite commonly with SMILES strings containing lowercase element symbols used to indicate aromatic structures. >> >> Have I overlooked something or is this a bug? >> >> Mike Casey >> >> _______________________________________________ >> Jmol-users mailing list >> Jmo...@li... >> https://lists.sourceforge.net/lists/listinfo/jmol-users |
From: Otie R. <oti...@gm...> - 2024-09-24 16:05:13
|
Mike, This is a wild guess on my part, but since I use both JSmol and JSME in my CheMagic app, I'll offer the guess. JSmol SMILES are not canonical; JSME SMILES are canonical. IF two model SMILES, are created in JSmol, then the comparison will work independent of atom drawing order in the two models. This comparison will not work comparing JSME canonical and JSmol non-canonical SMILES. As to the solution to your problem, I have to think about that. I know that Bob has included JSME/JSmol communication into JSmol. I do not use this because JSmol and JSME are combined in my app, and they talk to each othe. It seems to me that this should work by changing the aromatic "c" to "C", but that case change gets very tricky in general for obvious reasons. -- Otis Rothenberger oti...@gm... https://chemagic.org > On Sep 24, 2024, at 9:55 AM, Mike Casey <mik...@uc...> wrote: > > > Hi All, > > Working with Jmol 16.2.17 2024-06-07, I found a curious issue with the extremely useful ".find" SMILES/SMARTS feature. > > Taking the example from the interactive scripting documentation page, the following script which compares the SMILES for acetaminophen from two different sources works as expected: > > smiles1 = "C1=C(NC(=O)C)C=CC(=C1)O" > smiles2 = "CC(=O)NC1=CC=C(C=C1)O" > if(smiles2.find("SMILES", smiles1) > 0) { > print "These are the same." > } > > However, using the SMILES string from JSME, as follows, does not give a match: > > smiles1 = "C1=C(NC(=O)C)C=CC(=C1)O" > smiles2 = "CC(=O)Nc1ccc(O)cc1" > if(smiles2.find("SMILES", smiles1) > 0) { > print "These are the same." > } > > Comparing "CC(=O)Nc1ccc(O)cc1" with itself also fails to give a match! A bit more experimentation suggests that the problem arises quite commonly with SMILES strings containing lowercase element symbols used to indicate aromatic structures. > > Have I overlooked something or is this a bug? > > Mike Casey > > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users |
From: Mike C. <mik...@uc...> - 2024-09-24 14:55:24
|
Hi All, Working with *Jmol 16.2.17 2024-06-07*, I found a curious issue with the extremely useful ".find" SMILES/SMARTS feature. Taking the example from the interactive scripting documentation page, the following script which compares the SMILES for acetaminophen from two different sources works as expected: smiles1 = "C1=C(NC(=O)C)C=CC(=C1)O" smiles2 = "CC(=O)NC1=CC=C(C=C1)O" if(smiles2.find("SMILES", smiles1) > 0) { print "These are the same." } However, using the SMILES string from JSME, as follows, does not give a match: smiles1 = "C1=C(NC(=O)C)C=CC(=C1)O" smiles2 = "CC(=O)Nc1ccc(O)cc1" if(smiles2.find("SMILES", smiles1) > 0) { print "These are the same." } Comparing "CC(=O)Nc1ccc(O)cc1" with itself also fails to give a match! A bit more experimentation suggests that the problem arises quite commonly with SMILES strings containing lowercase element symbols used to indicate aromatic structures. Have I overlooked something or is this a bug? Mike Casey |
From: <m0...@ya...> - 2024-09-22 17:37:58
|
Dear Bob, YES! Barak Yariv, the person working on the current upgrade to ConSurfDB, also figured out the fix of using http instead of https for the PDB file at consurfdb. My site martzpots.org is not "secure". If you enter simply "martzpots.org" into the browser address line, it first tries https, then http, with success. However, if you enter "https://martzpots.org", the browser never finds the site, eventually reporting ERR_TIMED_OUT. Curiously, https seems to work for consurfDB. Both of these work in Chrome: https://consurfdb.tau.ac.il https://consurfdb.tau.ac.il/DB_NEW/2VAAA/2VAAA_consurf_firstglance.pdb If the latter is pasted into the address line, you can see that the browser seems not to be changing https to http. Changing jsmol.php's _&query= value to http works for ConSurfDBhttps://chemapps.stolaf.edu/jmol/jsmol/php/jsmol.php?call=getRawDataFromDatabase&database=_&query=http%3A%2F%2Fconsurfdb.tau.ac.il And using http for the PDB file works for FirstGlance (which is using the StOlaf jsmol.php)http://firstglance.jmol.org/fg.htm?mol=http://consurfdb.tau.ac.il/DB_NEW/2VAAA/2VAAA_consurf_firstglance.pdb (jmol.org is not secure, so neither is firstglance.jmol.org) But this strategy does not work for the case we struggled with in August:https://bioinformatics.org/firstglance/fgij/jsmol/php/jsmol.php?call=getRawDataFromDatabase&database=_&query=http%3A%2F%2Fproteopedia.org I worked around that problem by using the jsmol.php at StOlaf instead of within jsmol/php within FirstGlance. In conclusion, the problem with ConSurfDB linking to FirstGlance seems to be solved. -Eric On Sunday, September 22, 2024 at 01:05:47 PM EDT, Robert Hanson <ha...@st...> wrote: Eric, the problem appears to be that the consurfdb is delivering only http:// not https://. I suppose the browser somehow figures that out; maybe it tries https and then tries http, I don't know. https://chemapps.stolaf.edu/jmol/jsmol/php/jsmol.php?call=getRawDataFromDatabase&database=_&query=http://consurfdb.tau.ac.il/DB_NEW/2VAAA/2VAAA_consurf_firstglance.pdb works So I would contact ConSurfDB and ask them to implement https://, not http://. And, in the meantime, drop the s. Bob |
From: Robert H. <ha...@st...> - 2024-09-22 17:05:55
|
Eric, the problem appears to be that the consurfdb is delivering only http:// not https://. I suppose the browser somehow figures that out; maybe it tries https and then tries http, I don't know. https://chemapps.stolaf.edu/jmol/jsmol/php/jsmol.php?call=getRawDataFromDatabase&database=_&query=http://consurfdb.tau.ac.il/DB_NEW/2VAAA/2VAAA_consurf_firstglance.pdb works So I would contact ConSurfDB and ask them to implement https://, not http://. And, in the meantime, drop the s. Bob |
From: <m0...@ya...> - 2024-09-21 21:33:04
|
In mid-August, we had a long discussion about the failure of jsmol.php to work between certain servers. In August, the problem was that jsmol.php on bioinformatics.org could not fetch a PDB file from proteopedia.org. I don't think the reason was ever clearly understood. I released FirstGlance 4.31 in August using jsmol.php at stolaf.edu because that worked around the problem seen at the time. Now there is a problem having jsmol.php on stolaf.edu fetch a PDB file from consurfdb.tau.ac.il. Strangely, it CAN fetch from consurf.tau.ac.il (not the DB). It is highly desirable that links in the ConSurf Database show results in FirstGlance, but at the moment, that does not work due to this problem. Here are the key test links: stolaf works from consurf.tau.ac.il (displays text in browser) https://chemapps.stolaf.edu/jmol/jsmol/php/jsmol.php?call=getRawDataFromDatabase&database=_&query=https%3A%2F%2Fconsurf.tau.ac.il stolaf FAILS from consurfDB.tau.ac.il (blank page in browser)https://chemapps.stolaf.edu/jmol/jsmol/php/jsmol.php?call=getRawDataFromDatabase&database=_&query=https%3A%2F%2Fconsurfdb.tau.ac.il The above 2 links demonstrate the problem. Below is the context where the problem was discovered, but what follows is unnecessary to demonstrate the problem. Here is the actual link that needs to work, where FirstGlance on the FAST proteopedia.org server uses jsmol.php from stolaf to get the PDB file from consurfdb. JSmol says java.io.EOFException https://proteopedia.org/wiki/fgij/fg.htm?mol=https://consurfdb.tau.ac.il//DB_NEW/2VAAA/2VAAA_consurf_firstglance.pdb (That link is on this page "view ConSurf-DB results with FirstGlance":https://consurfdb.tau.ac.il/main_output_new.php?pdb_ID=2VAA&view_chain=A&unique_chain=2VAAA ) Here is the ConSurf Server link that works:https://proteopedia.org/wiki/fgij/fg.htm?mol=https%3A//consurf.tau.ac.il/results/1726951478/2vaa_A_consurf_firstglance.pdb (That link is on this page "view ConSurf results with FirstGlance"https://consurf.tau.ac.il/barak/final_output.php?number=1726951478&model=0&cbs=0 ) -Eric |