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 , 5 years ago
| Cc: | added |
|---|---|
| Component: | Unassigned → Core |
| Owner: | set to |
| Platform: | → all |
| Project: | → ChimeraX |
| Status: | new → assigned |
| Summary: | ChimeraX bug report submission → RFE: data server |
| Type: | defect → enhancement |
comment:2 by , 5 years ago
| Summary: | RFE: data server → Multi-user sessions for model building |
|---|
follow-up: 3 comment:3 by , 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.
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.