Opened 5 years ago

Last modified 5 years ago

#3619 assigned enhancement

Multi-user sessions for model building

Reported by: Tristan Croll Owned by: Tom Goddard
Priority: normal Milestone:
Component: Core Version:
Keywords: Cc: chimera-staff
Blocked By: Blocking:
Notify when closed: Platform: all
Project: ChimeraX

Description

The following bug report has been submitted:
Platform:        Linux-3.10.0-1127.13.1.el7.x86_64-x86_64-with-centos-7.8.2003-Core
ChimeraX Version: 1.0 (2020-06-04 23:15:07 UTC)
Description
Something I'd like to bring up for discussion (see https://twitter.com/CrollTristan/status/1291786031147163649?s=20), arising from the fact that I'm currently working over 6zm7 (80S ribosome with SARS-CoV-2 NSP1 attached). For huge models like this it would be really useful to have a multi-user collaborative mode. What I'm thinking of is essentially one instance of ChimeraX running as a server (for data-management purposes, not for compute - managing the master set of coordinates, keeping track of which atoms are currently locked because a client is modifying them, pushing changes back to clients). Each client would run a mostly-vanilla ISOLDE instance, still running simulations and graphics on its own local resources, but checks in with the server to acquire a lock on atoms before starting a sim and responds to pushed new coords. Any thoughts? 

OpenGL version: 3.3.0 NVIDIA 450.51.05
OpenGL renderer: TITAN Xp/PCIe/SSE2
OpenGL vendor: NVIDIA Corporation
Manufacturer: Dell Inc.
Model: Precision T5600
OS: CentOS Linux 7 Core
Architecture: 64bit ELF
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        9.2G         43G        170M         10G         52G
	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
PyQt version: 5.12.3
Compiled Qt version: 5.12.4
Runtime Qt version: 5.12.8

Change History (3)

comment:1 by Eric Pettersen, 5 years ago

Cc: chimera-staff added
Component: UnassignedCore
Owner: set to Tom Goddard
Platform: all
Project: ChimeraX
Status: newassigned
Summary: ChimeraX bug report submissionRFE: data server
Type: defectenhancement

comment:2 by Tom Goddard, 5 years ago

Summary: RFE: data serverMulti-user sessions for model building

ChimeraX has the meeting command that attempts to allow two or more instances of ChimeraX to sync with each other. One user starts the session and others can join and will receive the session data from the host automatically. And any command a participant executes is sent to all other participants and run. The meeting command was added for multi-person VR sessions. I don't think this is useful for the requested feature, but is related.

For the requested feature I guess I could see a model that is synced between all builders each running their own ChimeraX. A builder could select part of the model and lock it for themselves, and maybe that changes its color seen by all other builders to a color associated with the person with the lock. Each builder could claim a separate piece, like a separate chain. When they are done modifying they could release their lock on the piece. To implement such a thing in a feasible way I'd imagine the common model everyone sees with is coloring indicating who has locked which pieces is a separate model that actually no-one modifies directly. Instead, once I lock a piece, ChimeraX makes a copy of that piece and I refine that copy. Then when I unlock or when I simply want others to see my progress I push the changes of my working copy to the shared model, or maybe it gets transferred automatically whenever I make a change. During building atoms will get added and some handling might be needed if two builders add the same atoms. Would locks only apply to existing atoms? Or would a lock apply to a whole stretch of sequence which may not yet be built at all? Maybe the latter is better, but the user interface is harder.

Overall, I think this idea would be rarely used, require lots of work, and the tools for one person to do building need so much work that it is a bit crazy to try to allow multiple builders. But it would be novel. So I'd say the main weakness is that it would get very little use since I suspect it will be rare that more than one person is available and sufficiently knowledgable to contribute to a structure. Teams working on any kind of project introduce a lot of inefficiency compared to a single person doing everything, so I think few labs would be able to benefit from this technology.

in reply to:  3 ; comment:3 by Tristan Croll, 5 years ago

Yes - this would only ever make sense for teams working on very large 
models - ribosomes, mitochondrial complexes, that sort of thing - where 
even at a few seconds per residue a single user will need at least a 
week or two of unbroken work to get through it all (which is why at 
present they often don't bother, allowing all sorts of problems to creep 
through). Apparently in such groups "team building" is a real thing, 
using their own ad hoc approaches (one person mentioned they used to 
"lock" a chain by literally taking the print-out of coordinates for that 
chain out of a drawer!). I agree: not high priority, but might be worth 
keeping this future application in mind when looking at any 
client/server style code (such as the proposed ChimeraX-Phenix 
interface).

On 2020-08-13 03:34, ChimeraX wrote:
Note: See TracTickets for help on using tickets.