Opened 5 years ago

Last modified 4 years ago

#4499 accepted enhancement

RFE: coulombic coloring of surface caps to automatically update

Reported by: Elaine Meng Owned by: pett
Priority: moderate Milestone:
Component: Depiction Version:
Keywords: Cc: Tom Goddard
Blocked By: Blocking:
Notify when closed: Platform: all
Project: ChimeraX

Description

This might require having a map "under the hood," however, even if there is no volume model explicitly created.

Tom G: The mlp command computes the volume even when you don't use option "map true". The volume is not shown as an opened model but should be used to update the coloring of a cap automatically as the clip cap is moved.
Coulombic does not need to compute a map in order for automatic coloring updates to happen when a surface changes. You use Drawing.auto_recolor_vertices to get a callback when the surface changes and have an instance that know all the settings redo the coloring.

Eric: It would be sluggish without a map, wouldn't it?

Tom G: It might be in some cases. I'd guess the cap surface might have 10,000 vertices and maybe you have 10,000 atoms so 100 million terms to calculate -- might take 1 second in C++. If most of the atoms have 0 charge and those are not summed, so you only have 1000 atoms then ten times faster. Would require timing to know how fast it is. Of course map interpolation will be plenty fast, but the initial map calculation could be quite slow depending on how fine the grid spacing is.

Change History (9)

comment:1 by pett, 5 years ago

Status: assignedaccepted

comment:2 by pett, 4 years ago

Cc: Tom Goddard added

Coulombic doesn't even color a cap initially. Tom, how do you find out if a surface is capped, and how do you refer to / use a cap?

in reply to:  3 ; comment:3 by goddard@…, 4 years ago

A surface cap is a child model of the surface and is itself a surface.  So in a command you would usually get the cap if the parent surface was specified, for example, if #1 was a structure and #1.1 a surface, and #1.1.1 a surface cap, then specifier #1.1 would also include the cap.  The clip cap model type ClipCap is defined in chimerax.surface.cap and has an attribute "is_clip_cap = True", so if you want to test if a surface model m is a cap you could use getattr(m, 'is_clip_cap', False).

comment:4 by pett, 4 years ago

Okay, I made it so that an existing cap is colored and updated correctly. New caps don't work though. How do I find out when a cap gets created for a surface?

in reply to:  5 ; comment:5 by goddard@…, 4 years ago

Currently we don't have any special mechanism for watching when a clip cap gets created, and to my knowledge no current code does this.  Of course you could just use a model opened trigger and check if it is a clip cap of a surface of interest.  I vaguely think the current simplistic behavior where coloring does not magically apply to new models created after the coloring was done is best.  It would be nice and smart if clip caps got colored but it is too magical (and hence fragile) I feel.  The issue is that the cap is not part of the surface, it is a separate model.  The idea that you colored the surface therefore the cap made later should also be colored makes sense if the cap is part of the surface.  The cap looks like part of the surface to the user.  But the implementation is not that way, the cap is a separate model.  Different models that are coupled are really complex to implement, like molecular surfaces coupled to atomic structures, and I don't think we can maintain that level of complexity when we have so much functionality and so few programmers.  My two cents.

comment:6 by pett, 4 years ago

Well, I don't think any user is really going to think of a surface and its cap as two models conceptually. And the fact that the coloring for these "two models" works if they are both there initially but not if one is created later is slightly crazy. Nonetheless, I grok your argument about the practical issues. Despite that, at some point I will probably assail getting a later-created cap to be colored also.

in reply to:  7 ; comment:7 by goddard@…, 4 years ago

Yeah, the current behavior is definitely not the best for the user.  It is a limit of the implementation.  You can make cap coloring nicer for ESP, but there are lots of other colorings which won't work right, so it is going to be pretty disappointing to the user that some coloring works with later caps and some doesn't.  So to maintain consistency in the program behavior can be more work than we have time for.

in reply to:  8 ; comment:8 by Elaine Meng, 4 years ago

One complication with Coulombic surface coloring (or maybe it's not really much of a complication if you're using two commands internally) is that I recommend using 1.4 offset for the "real" surface and 0.0 offset for the cap since other molecules cannot access that space, and users are probably expecting the color to represent the potential at that location.

comment:9 by pett, 4 years ago

Good point. Have now changed the offset for caps to zero.

Note: See TracTickets for help on using tickets.