Conversation
Internal functions now have to take dotted keys to work with the output of detect_schema. Allow moving between neighboring jobs of different types by sorting values within each type, then joining these in order of alphabetized type name.
The shadow map will be applied outside this function
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
bdice
approved these changes
Sep 12, 2025
Member
bdice
left a comment
There was a problem hiding this comment.
Thanks for the continued contributions! This is an interesting feature. I haven't evaluated anything for performance but I did a quick read-through for my own curiosity. I left a few small comments but I don't plan to make a second pass of review, so I leave my approval. Feel free to accept or reject my suggestions however you see fit.
By definition, these keys will not distinguish any jobs so will not show up in the neighborlist.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Detect the neighbor list of jobs in a project or neighbors of an individual job. This is useful for navigating in high dimensional signac projects, especially for enabling more intuitive navigation in signac-dashboard.
The idea for abstracting this code developed out of the signac dashboard Navigator module and the need to ignore certain state point parameters when building the neighbor list.
It allows new kinds of analysis based on nearby jobs.
Description
Neighbor detection is based on cache lookups by calculating job ids of possible neighbor jobs. The possible neighbors are found by changing the state point parameters to values listed in the schema.
Ignoring keys changes job ids, so I create a mapping to the related "shadow" project that has these new job ids. This is explained in detail in the docstring for
prepare_shadow_project.It was challenging to work around the conversion between "nested keys" to "dotted keys". The convention is only documented under the query syntax. Schema returns values associated with state point parameters in dotted key format, so I convert state points in the state point caches to dotted keys. However, we have to convert back to nested keys to compute the job id.
The ability to get neighbors of a single job is intended mainly for command line usage.
Motivation and Context
The Navigator module of dashboard has been very helpful, and the general concept of neighbors of jobs could help with analysis like identifying regions of parameter space.
Basic example:
Complex example: show a graph of jobs (above)
Checklist: