If you’ve ever found yourself puzzled by why a property model node appears selected (or not) inside SAMSON, you’re not alone. Understanding the difference between the selected attribute and the selectionFlag attribute can save time and confusion—especially when building automation scripts, NSL queries, or debugging complex models. In this post, we’ll take a closer look at selection-related attributes for property model nodes in SAMSON.
Why selection information matters
When you’re working on building or analyzing molecular systems, it’s essential to accurately define which elements are selected—especially when these selections act as filters for simulations, visualizations, or scripting. But SAMSON’s node system differentiates between visible selections, user selections, and backend flags used to power the software.
selected vs. selectionFlag: What’s the difference?
In the context of the Node Specification Language (NSL), the propertyModel attribute space (pm) inherits the selected and selectionFlag attributes from the general node space. But it’s important to note how they behave differently:
pm.selected: This indicates whether the node is currently selected from the user’s point of view. It’s what is displayed in the selection outline and considered actively picked in the UI.pm.sf(short forselectionFlag): This is more of a backend attribute. It may represent intermediate selections or scenarios where a node is logically marked for something, without being displayed as selected. It’s usually used by the software for processing selection-related logic.
Because selectionFlag has a short name (sf), it’s very convenient for filtering in scripts. For instance, you can write:
|
1 |
pm.sf false |
to find all property model nodes that are not flagged as selected internally, regardless of what the UI displays.
Common use cases where this matters
- Scripting repetitive analysis: When using NSL to select only truly finalized selections,
pm.selectedis more reliable thanpm.sf. - Debugging automation: Sometimes your script interacts with nodes not actually selected in the interface. Filtering with
pm.sfhelps track this. - Custom extensions: If you’re developing an extension that reacts to nodes marked for processing,
selectionFlaglets you work behind the scenes without interfering with the UI.
Hands-on examples
Let’s say you want to select all property model nodes currently selected by the user:
|
1 |
pm.selected |
Want to ignore any node selected by internal processing?
|
1 |
not pm.sf |
Looking for nodes that aren’t explicitly selected (visually), but may still carry selection logic internally?
|
1 |
pm.sf and not pm.selected |
Why this distinction is often overlooked
Most users think that a selected node is simply… selected. But advanced operations, especially those involving hierarchy traversal, simulations, or graphical representations, often rely on deeper logic. SAMSON’s transparency in exposing both selected and selectionFlag helps users express more complex logic in filters and automation pipelines.
Conclusion
Next time your script isn’t behaving as expected, don’t forget that selected and selectionFlag may yield different result sets. Knowing which attribute aligns with your operation context will help you get more accurate and efficient results.
To learn more, visit the original documentation page: https://documentation.samson-connect.net/users/latest/nsl/propertyModel/
SAMSON and all SAMSON Extensions are free for non-commercial use. You can get SAMSON at https://www.samson-connect.net.