Opened 4 years ago
Last modified 6 months ago
#4871 assigned task
Scenes in mmCIF
| Reported by: | Tristan Croll | Owned by: | Zach Pearson |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Depiction | Version: | |
| Keywords: | Cc: | chimera-staff | |
| Blocked By: | Blocking: | ||
| Notify when closed: | Platform: | all | |
| Project: | ChimeraX |
Description (last modified by )
The following bug report has been submitted:
Platform: Linux-3.10.0-1160.25.1.el7.x86_64-x86_64-with-glibc2.14
ChimeraX Version: 1.3.dev202106210544 (2021-06-21 05:44:33 UTC)
Description
There's some talk brewing about getting interested developers together to hash out an extension to the mmCIF dictionary allowing specification of molecular scenes. How detailed is yet to be determined, but the basic idea is to provide a way for authors to define scenes corresponding to individual figures in their manuscript in such a way that readers can easily replicate them in their viewer of choice. Incorporating the scenes into the mmCIF file itself seems the most logical approach to ensuring maximum portability. Anyway, let me know if you're interested in taking part in any discussions that come up, and I'll add you to the loop if/when something more formal develops.
OpenGL version: 3.3.0 NVIDIA 465.19.01
OpenGL renderer: NVIDIA TITAN Xp/PCIe/SSE2
OpenGL vendor: NVIDIA Corporation
Manufacturer: Dell Inc.
Model: Precision T5600
OS: CentOS Linux 7 Core
Architecture: 64bit ELF
Virutal Machine: none
CPU: 32 Intel(R) Xeon(R) CPU E5-2687W 0 @ 3.10GHz
Cache Size: 20480 KB
Memory:
total used free shared buff/cache available
Mem: 62G 12G 37G 281M 12G 49G
Swap: 4.9G 0B 4.9G
Graphics:
03:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP102 [TITAN Xp] [10de:1b02] (rev a1)
Subsystem: NVIDIA Corporation Device [10de:11df]
Kernel driver in use: nvidia
Locale: ('en_GB', 'UTF-8')
PyQt5 5.15.2, Qt 5.15.2
Installed Packages:
alabaster: 0.7.12
appdirs: 1.4.4
Babel: 2.9.1
backcall: 0.2.0
blockdiag: 2.0.1
certifi: 2021.5.30
cftime: 1.5.0
chardet: 4.0.0
ChimeraX-AddCharge: 1.1.4
ChimeraX-AddH: 2.1.7
ChimeraX-AlignmentAlgorithms: 2.0
ChimeraX-AlignmentHdrs: 3.2
ChimeraX-AlignmentMatrices: 2.0
ChimeraX-Alignments: 2.1
ChimeraX-AmberInfo: 1.0
ChimeraX-Arrays: 1.0
ChimeraX-Atomic: 1.23
ChimeraX-AtomicLibrary: 3.3
ChimeraX-AtomSearch: 2.0
ChimeraX-AtomSearchLibrary: 1.0
ChimeraX-AxesPlanes: 2.0
ChimeraX-BasicActions: 1.1
ChimeraX-BILD: 1.0
ChimeraX-BlastProtein: 1.1.1
ChimeraX-BondRot: 2.0
ChimeraX-BugReporter: 1.0
ChimeraX-BuildStructure: 2.5.2
ChimeraX-Bumps: 1.0
ChimeraX-BundleBuilder: 1.1
ChimeraX-ButtonPanel: 1.0
ChimeraX-CageBuilder: 1.0
ChimeraX-CellPack: 1.0
ChimeraX-Centroids: 1.1
ChimeraX-ChemGroup: 2.0
ChimeraX-Clashes: 2.1
ChimeraX-Clipper: 0.17.0
ChimeraX-ColorActions: 1.0
ChimeraX-ColorGlobe: 1.0
ChimeraX-ColorKey: 1.3.2
ChimeraX-CommandLine: 1.1.4
ChimeraX-ConnectStructure: 2.0
ChimeraX-Contacts: 1.0
ChimeraX-Core: 1.3.dev202106210544
ChimeraX-CoreFormats: 1.0
ChimeraX-coulombic: 1.3
ChimeraX-Crosslinks: 1.0
ChimeraX-Crystal: 1.0
ChimeraX-CrystalContacts: 1.0
ChimeraX-DataFormats: 1.2
ChimeraX-Dicom: 1.0
ChimeraX-DistMonitor: 1.1.4
ChimeraX-DistUI: 1.0
ChimeraX-Dssp: 2.0
ChimeraX-EMDB-SFF: 1.0
ChimeraX-ExperimentalCommands: 1.0
ChimeraX-FileHistory: 1.0
ChimeraX-FunctionKey: 1.0
ChimeraX-Geometry: 1.1
ChimeraX-gltf: 1.0
ChimeraX-Graphics: 1.1
ChimeraX-Hbonds: 2.1
ChimeraX-Help: 1.1
ChimeraX-HKCage: 1.3
ChimeraX-IHM: 1.1
ChimeraX-ImageFormats: 1.1
ChimeraX-IMOD: 1.0
ChimeraX-IO: 1.0.1
ChimeraX-ISOLDE: 1.3.dev18
ChimeraX-ItemsInspection: 1.0
ChimeraX-Label: 1.1
ChimeraX-LinuxSupport: 1.0
ChimeraX-ListInfo: 1.1.1
ChimeraX-Log: 1.1.4
ChimeraX-LookingGlass: 1.1
ChimeraX-Maestro: 1.8.1
ChimeraX-Map: 1.1
ChimeraX-MapData: 2.0
ChimeraX-MapEraser: 1.0
ChimeraX-MapFilter: 2.0
ChimeraX-MapFit: 2.0
ChimeraX-MapSeries: 2.1
ChimeraX-Markers: 1.0
ChimeraX-Mask: 1.0
ChimeraX-MatchMaker: 1.2.1
ChimeraX-MDcrds: 2.3
ChimeraX-MedicalToolbar: 1.0.1
ChimeraX-Meeting: 1.0
ChimeraX-MLP: 1.1
ChimeraX-mmCIF: 2.3
ChimeraX-MMTF: 2.1
ChimeraX-Modeller: 1.0.2
ChimeraX-ModelPanel: 1.1
ChimeraX-ModelSeries: 1.0
ChimeraX-Mol2: 2.0
ChimeraX-Morph: 1.0
ChimeraX-MouseModes: 1.1
ChimeraX-Movie: 1.0
ChimeraX-Neuron: 1.0
ChimeraX-Nucleotides: 2.0.2
ChimeraX-OpenCommand: 1.6
ChimeraX-PDB: 2.4.2
ChimeraX-PDBBio: 1.0
ChimeraX-PDBLibrary: 1.0.1
ChimeraX-PDBMatrices: 1.0
ChimeraX-PickBlobs: 1.0
ChimeraX-Positions: 1.0
ChimeraX-PresetMgr: 1.0.1
ChimeraX-PubChem: 2.1
ChimeraX-ReadPbonds: 1.0
ChimeraX-Registration: 1.1
ChimeraX-RemoteControl: 1.0
ChimeraX-ResidueFit: 1.0
ChimeraX-RestServer: 1.1
ChimeraX-RNALayout: 1.0
ChimeraX-RotamerLibMgr: 2.0
ChimeraX-RotamerLibsDunbrack: 2.0
ChimeraX-RotamerLibsDynameomics: 2.0
ChimeraX-RotamerLibsRichardson: 2.0
ChimeraX-Sample: 0.1
ChimeraX-SaveCommand: 1.4
ChimeraX-SchemeMgr: 1.0
ChimeraX-SDF: 2.0
ChimeraX-Segger: 1.0
ChimeraX-Segment: 1.0
ChimeraX-SelInspector: 1.0
ChimeraX-SeqView: 2.4.1
ChimeraX-Shape: 1.0.1
ChimeraX-Shell: 1.0
ChimeraX-Shortcuts: 1.1
ChimeraX-ShowAttr: 1.0
ChimeraX-ShowSequences: 1.0
ChimeraX-SideView: 1.0
ChimeraX-Smiles: 2.1
ChimeraX-SmoothLines: 1.0
ChimeraX-SpaceNavigator: 1.0
ChimeraX-StdCommands: 1.6
ChimeraX-STL: 1.0
ChimeraX-Storm: 1.0
ChimeraX-Struts: 1.0
ChimeraX-Surface: 1.0
ChimeraX-SwapAA: 2.0
ChimeraX-SwapRes: 2.1
ChimeraX-TapeMeasure: 1.0
ChimeraX-Test: 1.0
ChimeraX-Toolbar: 1.1
ChimeraX-ToolshedUtils: 1.2
ChimeraX-Tug: 1.0
ChimeraX-UI: 1.10
ChimeraX-uniprot: 2.1
ChimeraX-UnitCell: 1.0
ChimeraX-ViewDockX: 1.0.1
ChimeraX-Vive: 1.1
ChimeraX-VolumeMenu: 1.0
ChimeraX-Voyager: 0.1
ChimeraX-VTK: 1.0
ChimeraX-WavefrontOBJ: 1.0
ChimeraX-WebCam: 1.0
ChimeraX-WebServices: 1.0
ChimeraX-Zone: 1.0
colorama: 0.4.4
comtypes: 1.1.10
cxservices: 1.0
cycler: 0.10.0
Cython: 0.29.23
decorator: 4.4.2
distlib: 0.3.1
distro: 1.5.0
docutils: 0.17.1
filelock: 3.0.12
funcparserlib: 0.3.6
grako: 3.16.5
h5py: 3.2.1
html2text: 2020.1.16
idna: 2.10
ihm: 0.20
imagecodecs: 2021.4.28
imagesize: 1.2.0
ipykernel: 5.5.5
ipython: 7.23.1
ipython-genutils: 0.2.0
jedi: 0.18.0
Jinja2: 2.11.3
jupyter-client: 6.1.12
jupyter-core: 4.7.1
kiwisolver: 1.3.1
line-profiler: 3.3.0
lxml: 4.6.3
lz4: 3.1.3
MarkupSafe: 1.1.1
matplotlib: 3.4.2
matplotlib-inline: 0.1.2
msgpack: 1.0.2
netCDF4: 1.5.6
networkx: 2.5.1
numexpr: 2.7.3
numpy: 1.20.3
numpydoc: 1.1.0
openvr: 1.16.801
packaging: 20.9
ParmEd: 3.2.0
parso: 0.8.2
pexpect: 4.8.0
pickleshare: 0.7.5
Pillow: 8.2.0
pip: 21.1.1
pkginfo: 1.7.0
prompt-toolkit: 3.0.19
psutil: 5.8.0
ptyprocess: 0.7.0
pycollada: 0.7.1
pydicom: 2.1.2
Pygments: 2.9.0
PyOpenGL: 3.1.5
PyOpenGL-accelerate: 3.1.5
pyparsing: 2.4.7
PyQt5-commercial: 5.15.2
PyQt5-sip: 12.8.1
PyQtWebEngine-commercial: 5.15.2
python-dateutil: 2.8.1
pytz: 2021.1
pyzmq: 22.1.0
qtconsole: 5.1.0
QtPy: 1.9.0
RandomWords: 0.3.0
requests: 2.25.1
scipy: 1.6.3
setuptools: 57.0.0
sfftk-rw: 0.7.0.post1
six: 1.16.0
snowballstemmer: 2.1.0
sortedcontainers: 2.4.0
Sphinx: 4.0.1
sphinxcontrib-applehelp: 1.0.2
sphinxcontrib-blockdiag: 2.0.0
sphinxcontrib-devhelp: 1.0.2
sphinxcontrib-htmlhelp: 2.0.0
sphinxcontrib-jsmath: 1.0.1
sphinxcontrib-qthelp: 1.0.3
sphinxcontrib-serializinghtml: 1.1.5
suds-jurko: 0.6
tables: 3.6.1
tifffile: 2021.4.8
tinyarray: 1.2.3
tornado: 6.1
traitlets: 5.0.5
urllib3: 1.26.5
wcwidth: 0.2.5
webcolors: 1.11.1
wheel: 0.36.2
wheel-filename: 1.3.0
Change History (11)
comment:1 by , 4 years ago
| Cc: | added |
|---|---|
| Component: | Unassigned → Depiction |
| Owner: | set to |
| Platform: | → all |
| Project: | → ChimeraX |
| Status: | new → assigned |
| Summary: | ChimeraX bug report submission → Scenes in mmCIF |
| Type: | defect → task |
comment:2 by , 4 years ago
follow-up: 3 comment:3 by , 4 years ago
The way things are at the moment, people are doing things like including PyMol sessions as supplementary data. That's an obviously inferior solution - often huge file size, non-portable, completely dependent on PyMol remaining available long-term. Some generic protocol definitely seems the way to go... the next questions then are (a) what form that protocol should take, and (b) how much detail would the scene specification need to go into to make it useful to a moderately-savvy user? All early days...
________________________________
From: ChimeraX <ChimeraX-bugs-admin@cgl.ucsf.edu>
Sent: 07 July 2021 19:22
Cc: chimera-staff@cgl.ucsf.edu <chimera-staff@cgl.ucsf.edu>; gregc@cgl.ucsf.edu <gregc@cgl.ucsf.edu>; Tristan Croll <tic20@cam.ac.uk>
Subject: Re: [ChimeraX] #4871: Scenes in mmCIF
#4871: Scenes in mmCIF
------------------------------------+------------------------
Reporter: Tristan Croll | Owner: Greg Couch
Type: task | Status: assigned
Priority: normal | Milestone:
Component: Depiction | Version:
Resolution: | Keywords:
Blocked By: | Blocking:
Notify when closed: | Platform: all
Project: ChimeraX |
------------------------------------+------------------------
Comment (by Tom Goddard):
Sounds likely to fail. There is a lot scene information, would double the
mmCIF file size. Camera view, which residues are shown as ribbon, which
atoms are shown, ribbon colors, atom colors, atom styles, which residues
and atoms are labeled (could give up on that), surface visibility / color
/ transparency (could give up on that), other 2D labels (could give up on
that). You could encode the very basic molecule view of a figure but
leave out all the details that make the figure really useful (like
labeling, arrows, ...).
I think the PDB is unlikely to include this information. They will say it
belongs with the journal publication, not with the archived data. If it
is not archived by the PDB then it is not clear mmCIF is a good format.
It is pretty hard to parse. But one might expect all molecular viewers to
read mmCIF for the coordinate data so maybe it is the best choice.
As with many projects I think this goal is pretty trivial to implement and
more or less impossible to get the relevant parties like the PDB and
software developers to support it to the extent needed to make it
worthwhile. The PDB and software developers are so busy they handle only
pressing needs, and this is unlikely to be a pressing need.
--
Ticket URL: <https://www.rbvi.ucsf.edu/trac/ChimeraX/ticket/4871#comment:2>
ChimeraX <https://www.rbvi.ucsf.edu/chimerax/>
ChimeraX Issue Tracker
follow-up: 4 comment:4 by , 4 years ago
Yes, I've seen publications that include Chimera sessions in supplementary data too. Not that many, maybe once or twice a year.
comment:5 by , 4 years ago
I agree the current situation is poor, all sharing of science data is really in bad shape, and the PDB is a remarkable exception. A basic obstacle to this generic scene format and providing machine-readable figures is who really cares enough about it to work on it? Most researchers who would want to see the 3D view of a figure know PyMol or ChimeraX or VMD and if they have the data they can get the same view. It wastes their time to reproduce the view. No doubt having a machine-readable version available that works in their preferred software would be handy. But is it handy enough that everyone will come together and implement it? The software developers, the PDB, maybe hardest of all getting the researchers to make these machine-readable figure files. The researchers won't even deposit their data unless forced to. So while the goal is admirable. It seems to me the need for it balanced against the difficulty of getting everyone to implement it and use it make it very unlikely to succeed. Personally I would be much more motivated to get researchers to deposit their data in an archive. I'd say about 80% of the data I read about that I want to look at is not available -- with crippling effect on science. After that I am highly motivated to change the standards of publishing so that most of science is not held behind paywalls. These are examples of science communication problems that I think are much more important to work on and have strong community support than machine-readable figures.
Despite my negative comments I am in favor of machine-readable figures. I make these comments because I think it is important to think carefully to avoid wasting effort on projects that will not succeed.
comment:6 by , 4 years ago
I agree that complete scene information would be too much and too constricting. But a limited amount of information would be useful, but exactly what is part of the discussion with the other developers. For example, for each view/image, only the center, radius, and objects (atoms/bonds) to highlight could be recorded, and the molecular viewer could choose how to do that.
follow-up: 7 comment:7 by , 4 years ago
Tom: I had a feeling your response would be along those lines. :)
Current discussion started at https://twitter.com/kaczmarski_joe/status/1410821248569921542?s=21 and got reasonably lively. At least a few developers chimed in... the folks behind Mol* were particularly keen on the mmCIF idea, and they have at least some influence with PDBe given their status as the web-based viewer of choice.
On 7 Jul 2021, at 20:05, ChimeraX <ChimeraX-bugs-admin@cgl.ucsf.edu<mailto:ChimeraX-bugs-admin@cgl.ucsf.edu>> wrote:
#4871: Scenes in mmCIF
------------------------------------+------------------------
Reporter: Tristan Croll | Owner: Greg Couch
Type: task | Status: assigned
Priority: normal | Milestone:
Component: Depiction | Version:
Resolution: | Keywords:
Blocked By: | Blocking:
Notify when closed: | Platform: all
Project: ChimeraX |
------------------------------------+------------------------
Comment (by Greg Couch):
I agree that complete scene information would be too much and too
constricting. But a limited amount of information would be useful, but
exactly what is part of the discussion with the other developers. For
example, for each view/image, only the center, radius, and objects
(atoms/bonds) to highlight could be recorded, and the molecular viewer
could choose how to do that.
--
Ticket URL: <https://www.rbvi.ucsf.edu/trac/ChimeraX/ticket/4871#comment:6>
ChimeraX <https://www.rbvi.ucsf.edu/chimerax/>
ChimeraX Issue Tracker
comment:8 by , 4 years ago
I think I am just in a grumpy mood! Successes in data distribution and community standards have been very few. And a success in that area would be immensely valuable. So I am very interested in why these kinds of efforts fail and how to make them succeed.
follow-up: 9 comment:9 by , 4 years ago
I think the trick is to convince a bunch of tenured folk with already-well-padded CVs that it’ll get them some kudos if they take charge...
comment:10 by , 13 months ago
| Description: | modified (diff) |
|---|---|
| Owner: | changed from to |
Our summer intern has done some initial scene work.
Sounds likely to fail. There is a lot scene information, would double the mmCIF file size. Camera view, which residues are shown as ribbon, which atoms are shown, ribbon colors, atom colors, atom styles, which residues and atoms are labeled (could give up on that), surface visibility / color / transparency (could give up on that), other 2D labels (could give up on that). You could encode the very basic molecule view of a figure but leave out all the details that make the figure really useful (like labeling, arrows, ...).
I think the PDB is unlikely to include this information. They will say it belongs with the journal publication, not with the archived data. If it is not archived by the PDB then it is not clear mmCIF is a good format. It is pretty hard to parse. But one might expect all molecular viewers to read mmCIF for the coordinate data so maybe it is the best choice.
As with many projects I think this goal is pretty trivial to implement and more or less impossible to get the relevant parties like the PDB and software developers to support it to the extent needed to make it worthwhile. The PDB and software developers are so busy they handle only pressing needs, and this is unlikely to be a pressing need.