Menu
▾
▴
Re: [Jmol-users] proposed default change for 12.2 CIF files
|
From: Michael E. <ev...@il...> - 2010-12-08 16:13:20
|
Bob—an official vote from from labmate who uses Jmol to display crystal
structures for this one. Any chance it could get placed in the next release
of 12.0?
Cheers, Mike
On Tue, Dec 7, 2010 at 8:58 AM, Robert Hanson <ha...@st...> wrote:
> Brian, yes, in fact I did notice that one. Odd that the CIF doesn't include
> GEOM_BOND for that disordered set. But I notice that Mercury displays these
> as little crosses, so I too think it's probably OK. And lots of cases show
> full molecules. Don't know why that particular one shows only the bonds to
> the first disorder group. Seems to me it's better that Jmol show what's
> actually in the file than to start guessing what is and what is not a bond
> after processing the in-file bond information. Jmol doesn't do that with
> other file types -- well, except PDB.
>
> Any CIF file... Hard to say. The problem arises with network/ionic solids.
> In that case, where they don't generally add GEOM_BOND records Jmol has to
> guess at what a molecule is. Of course, that's more an inorganic problem. I
> haven't been terribly satisfied with how those "molecules" look, and I don't
> think people really want to see them that way. Can you think of any easy way
> to differentiate these two types of files? Has to be VERY easy to describe
> and implement, or it's not worth it.
>
> Right now the default is only for files containing GEOM_BOND records, based
> on the assumption that with all other file types Jmol respects what the file
> says for what a bond is.
>
> The GEOM_BOND record is ignored when loading with an explicit lattice such
> as {1 1 1}, as before. The only changes I made were that (1) you can now
> force any CIF (other than mmCIF) to this mode using FILTER "molecular" and
> (2) when the GEOM_BOND record is present, then specifically when the lattice
> is not present, as in simple drag/drop, the default is FILTER "molecular".
>
> There was a bug in the way Jmol read and applied the bonding information in
> earlier versions, so we don't want that to be an option. I guess the way you
> would do it now that would be closest to the same as before for default
> loading of files that contain bond information would be:
>
> set forceAutoBond; load xxxx.cif {1 1 1};delete symop > 1
>
> The {1 1 1} prevents the molecular business from being carried out, the
> forceAutoBond goes back to the way Jmol used to fill in the blanks with its
> own bond creation (without the bug), and the delete symop > 1 takes out the
> extra symmetry-derived atoms.
>
> It seems to me that's not particularly useful. Lots of time it would give
> fractions of molecules, as is the case in earlier versions.
>
> I did get the local symmetry business set up. Looks great! Try it with some
> molecules you have that have disorder at special positions and tell me what
> you think. My only comment is that in the CIF documentation the type for
> _atom_site_disorder_group should not be "char". It should be something like
> "signed char" -- a character with or without a preceding "-" sign. Crazy!
>
> Bob
>
>
> On Tue, Dec 7, 2010 at 5:11 AM, Brian McMahon <bm...@iu...> wrote:
>
>> Bob
>>
>> I think this is a sensible default. One effect is that in your example
>> 04369a half the atoms in the disordered trifluoromethy groups appear
>> as "free-floating", which looks odd - but then, a heptavalent carbon also
>> looks odd. In this mode you're accurately reflecting the reported physical
>> bonds - in the Acta enhanced figure toolkit we can make it easy for
>> authors
>> to draw in the additional bonds if they actually want to display them.
>>
>> So would it be safe to load any CIF with the
>> FILTER "molecular"
>> command if one wants to guarantee this behaviour? And is there a
>> corresponding FILTER command to force Jmol to ignore the GEOM_BOND
>> records if they are present?
>>
>> Cheers
>> Brian
>>
>> On Sun, Dec 05, 2010 at 08:52:11PM -0600, Robert Hanson wrote:
>> > With the help of Kris Radacki, I've finally learned how to properly read
>> the
>> > GEOM_BOND records in CIF files. These aren't in all CIF files, and Jmol
>> (as
>> > well as Mercury) generally ignores these, but in the special case when
>> you
>> > load a CIF file just using "load xxx.cif" without the "packed" keyword
>> and
>> > without a lattice parameter such as {1 1 1}, Jmol has had a bug that
>> allowed
>> > misreading these as it attempted to use them to generate bonds.
>> >
>> > Jmol now reads these properly. In fixing this bug, it seemed to me that
>> a
>> > reasonable default would be to have Jmol open CIF files of this type
>> > (small-molecule molecular solids, mostly, I think) as follows:
>> >
>> > -- properly connect the molecules
>> > -- include only the following atoms:
>> > -- symop=1 {x,y,z} atoms
>> > -- additional atoms only as needed to complete molecules
>> > -- do no autobonding
>> > -- load models similarly to non-CIF models - Cartesian coordinates,
>> with no
>> > unit cell
>> >
>> > You can try this out at
>> > http://chemapps.stolaf.edu/jmol/docs/examples-11/jcse/explore.htm The
>> first
>> > five models are loaded this way. In the case of the CCDC file AgFUPMOS,
>> > which does not contain GEOM_BOND records but is still a molecular solid,
>> the
>> > file was loaded using:
>> >
>> > load AgFUPMOS.cif FILTER "molecular"
>> >
>> > to force the generation of a molecular model.
>> >
>> > So the questions are these:
>> >
>> > Q: Does this seem like an appropriate improvement?
>> >
>> > Q: Does it work as expected?
>> >
>> > Q: Will this default loading create problems with anyone? (Once again,
>> the
>> > only change is if you load a CIF file, say, by dragging it into Jmol or
>> for
>> > whatever other reason load it with no lattice indicated.)
>> >
>> > Q: Is there something I haven't thought of that we should be doing in
>> > relation to this?
>> >
>> > Thanks,
>> >
>> >
>> > 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
>> _________________________________________________________________________
>> Brian McMahon tel: +44 1244 342878
>> Research and Development Officer fax: +44 1244 314888
>> International Union of Crystallography e-mail: bm...@iu...
>> 5 Abbey Square, Chester CH1 2HU, England
>>
>>
>> ------------------------------------------------------------------------------
>> What happens now with your Lotus Notes apps - do you make another costly
>> upgrade, or settle for being marooned without product support? Time to
>> move
>> off Lotus Notes and onto the cloud with Force.com, apps are easier to
>> build,
>> use, and manage than apps on traditional platforms. Sign up for the Lotus
>> Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
>> _______________________________________________
>> Jmol-users mailing list
>> Jmo...@li...
>> https://lists.sourceforge.net/lists/listinfo/jmol-users
>>
>
>
>
> --
> 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
>
>
> ------------------------------------------------------------------------------
> What happens now with your Lotus Notes apps - do you make another costly
> upgrade, or settle for being marooned without product support? Time to move
> off Lotus Notes and onto the cloud with Force.com, apps are easier to
> build,
> use, and manage than apps on traditional platforms. Sign up for the Lotus
> Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
> _______________________________________________
> Jmol-users mailing list
> Jmo...@li...
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>
--
Mike Evans
Organic Chemistry Graduate Student
Moore Group
University of Illinois, Urbana-Champaign
|
