soniaApplySettings {rSoNIA} | R Documentation |
SoNIA Layout Apply Settings
Description
Parameter settings object that controls which layout algorithm should be applied, its
parameters and any additonal transformations
Usage
data(soniaApplySettings)
Format
The format is:
- settings.class
- "SettingsClass" "sonia.settings.ApplySettings"
- apply.all
- "APPLY_REMAINING" "false"
- stop.error
- "STOP_ON_ERROR" "false"
- rescale.layout
- "RESCALE_LAYOUT" "none"
- isolate.position
- "ISOLATE_POSITION" "ignore isolates"
- transform.isolate.exclude
- "TRANSFORM_ISOLATE_EXCLUDE" "false"
- transform.recenter
- "RECENTER_TRANSFORM" "false"
- start.coords.type
- "STARTING_COORDS" "use random positions"
- repaint.n
- "LAYOUT_REPAINT_N" "0"
- alg.name
- "Algorithm_Name" "Multiple component Kamada-Kawai layout"
- alg.prop.keys
- "ALG_PROP_KEYS" "springConst,min epsilon,optimum dist,cool factor,max passes,comp connect value"
- kk.opt.dist
- "optimum dist" "50"
- kk.target.epsilon
- "min epsilon" "1"
- kk.cool.factor
- "cool factor" "0.25"
- kk.spring.constant
- "springConst" "1"
- kk.comp.connect
- "comp connect value" "0"
- attr(*, "class")= chr "sonia.settings"
Details
SoNIA reads its control paramters as sets of grouped key=value pairs that are
included in a batch file or passed in from the command line. Objects of class
sonia.settings
are used to store the values in R so they can be configured if
needed. Do not modify the key (first value) or SoNIA will not recognize the
parameter. The value will either be a numeric string or one of a set of options
givin here or in the SoNIA documentation.
- settings.class
- gives the name of this parameter group. DO NOT CHANGE
- apply.all
- if true, the layout will be applied to all the slices in the
network (in batch mode this will be set to true internally after the first layout)
- stop.error
- if true, the layout processes will halt if any of the layouts
fail to converge in the specified number of iterations.
- rescale.layout
- controls if and how the node coordinates should be rescaled
to fit the layout window. Options are 'none', 'rescale layout to fit window'
rescaling is generally not a good idea when exporting a movie because it is not
possible to compare edges lengths in successive frames.
- isolate.position
- controls how isolated nodes should be treated.
- ignore isolates
- eave 'em where the layout puts 'em
- pin to bottom edge
- lines the nodes up along the bottom
- pin to circle
- puts isolates in a circle around the layout
- pin to file coords
- use coordinates passed in as original coords
- pin to previous position
- use the coordinates from the previous slice
in order to chain the layouts.
- transform.isolate.exclude
- if true, isolates are ignored during transforms
- transform.recenter
- should the layout be recentered?
- none
- don't recenter
- barycenter after layout
- center on the center of gravity
- rescale layout to fit window
- scale the coords to fit within bounds
- recenter during layout
- apply after each iteration, only usefull in gui mode.
- start.coords.type
- specifies where to get the initial node coords to feed
into the layout algorithm.
- from orginal file
- use coords passed in with nodes
- use circular
- rrange nodes in a circle
- use random positions
- give random initial positions
- use current positions
- use current screen positions (useful for continuing a layout)
- from previous slice
- use the results of the previous timestep,
good option for creating a movie.
- repaint.n
- option to redraw the screen every Nth iteration while calculating
the layout for visual debugging, only useful in gui mode.
- alg.name
- the name of the layout algorithm that the remaining keys apply to
CHANGING THIS PARAM WILL NOT CHANGE THE LAYOUT ALG USED. To change layout,
see
soniaLayoutSettings
.
- alg.prop.keys
- names of additional paramters used by the currently
selected layout.
- max.passes
- maximum number of iterations a layout will be allowed Acts as a guaranteed stopping criteria if the energy minimization target is not reached.
- kk.opt.dist
- desired distance (pixels) between nodes connected by a an
edge of weight 1 (after distance transformation)
- kk.target.epsilon
- desired minimum energy (stoping criteria) for kk
Newton-Raphson optimization. Applied to each component individually. Decreasing this value will probably improve the "quality" and stress measurement of the layout and increase the number of iterations it will take to converge. Most layouts can never achieve zero epsilon.
- kk.cool.factor
- fraction by which the temporary target energy should
be reduced at each stage until reaching target epsilon. Unlike the original KK algorithm, SoNIA's variant does not immediately try to reach the target epsilon (min epsilon) each time a node is selected for positioning. Instead it starts with target equal to the energy of the graph, optimizes until it is exceeded, reduces this target by the cool factor, and repeats until the min epsilon is reached or max. passes is exceeded. This 'pseudo-annealing' approach seems to give better resultsand get stuck less. Setting this to a larger value may give the layout more time to reach an optima at each stage, but will probably increase the number of iterations needed.
- kk.spring.constant
- how 'springy' the springs are, indirectly controls
the overall energy of the graph, impact on layout unclear. Sometimes it is useful to tweak this a little bit if the layout is getting stuck.
- kk.comp.connect
- if non-zero, used as a replacement value to create
phantom edges between nodes in disconnected components and isolates.
Can be used to force positioning of isolates and components, at some cost to
overall layout accuracy, since the isolates are now being positioned, they tend to bounce around a lot more. At the moment, this unfortunately also breaks the isolate positioning post processing options. Also interacts a lot with the opt dist parameter, you will need to tweak both a bit to get it to work. Try an initial connect value of 15 for opt dist 20. Note: using this option will make the network acts as a single giant component, which means it will probably run much slower. But it can look nice, sometimes it is worth it.
Source
see javadoc for SoNIA at http://sonia.stanford.edu/
References
Bender-deMoll, S and McFarland, D.A. (2006) 'The Art and Science of Dynamic Network Visualization' Journal of Social Structure. Volume 7, Number 2. http://www.cmu.edu/joss/content/articles/volume7/deMollMcFarland
Examples
## set initial node coords to a circle before starting algorithm
soniaApplySettings$start.coords.type[2] <- "use circular";
[Package
rSoNIA version 0.0-4
Index]