Visualizing Molecular Trajectories and Metastable Conformations
`
`semi-global, and global alignment. The algorithms work both for proteins and
`ribonucleic acids, whereas t-RNA molecules are currently not supported because
`they contain modified bases. This module can be very helpful when used in con-
`junction with the AlignMolecules module.
`
`7.5 Visualizing Molecular Trajectories and
`Metastable Conformations
`
`A MolTrajectory can be visualized via animation of single time steps by attaching
`a Molecule module to the MolTrajectory and then attaching a MoleculeView or
`BondAngleView to the Molecule. The animation is controlled via the Molecule’s
`Time port.
`For MolTrajectories that represent metastable conformations, the modules Mean-
`Molecule, PrecomputeAlignment, and ConfigurationDensity can be used. The
`MeanMolecule module aligns all steps of a trajectory and computes a mean
`molecule by averaging every atomic coordinate over all time steps.
`Instead of
`computing the mean molecule to a reference, as with the MeanMolecule module,
`the PrecomputeAlignment module allows you to find the optimal transformation
`of each time step to minimize the overall sum of squared distances. With the
`RankTimeStep module you can search in a trajectory for a desired time step, using
`different criteria, such as the rmsd value to a given reference.
`The ConfigurationDensity module gives an impression of the fuzziness of the con-
`formation by computing a probability density for the positions of atoms and bonds
`within a molecular trajectory. This density can then be visualized with the Isosur-
`face and Voltex modules.
`
`7.6 Atom Expressions
`
`7.6.1 Overview
`
`Atom expressions are a query language to find and select atoms of certain prop-
`erties in the molecule for further action. The most important application of atom
`expressions in Amira is the highlighting section of the Selection Browser.
`In Amira, a molecule is separated into groups of different levels. Each group con-
`tains a set of attributes. (More details of this concept can be found in the descrip-
`tion of the Attribute Editor). Atom expressions are a simple form of a relational
`
`257
`
`Page 275 of 533
`
`Medivis v. Novarad
`IPR2023-00042
`Ex. 2023
`
`

`

`Chapter 7: Molecular Option Introduction
`
`query language which accesses these attributes.
`The simplest form of an atom expression is an atom specifier. This is a literal
`defining a level, one of its attributes, and a condition for this attribute. For example,
`atoms/atomic number=8 defines all atoms whose atomic number attribute
`equals 8 (i.e., all oxygens).
`Such atom specifiers can be combined with logical operators like AND,
`OR and NOT.
`For
`example,
`atoms/atomic number=8 AND NOT
`atoms/charge=0 will select all charged oxygen atoms.
`There are additional operators like WITHIN, BONDED and GROUP which apply
`certain conditions to coordinates or bond structure. These are explained in section
`on operators.
`
`7.6.2 Grammar
`
`All possible syntaxes of atom expressions are shown in the following grammar.
`The different literals and operators are further explained in the following sections.
`atomExpr →
`( atomExpr )
`| NOT atomExpr
`| atomExpr AND atomExpr
`| atomExpr OR atomExpr
`| WITHIN (atomExpr,float)
`| BONDED (atomExpr[,int])
`| GROUP (groupParts)
`| CS
`| atomSpecifier
`atomSpecifier → hierName/[attrName=]ID
`groupParts →
`groupPart
`| groupPart,groupParts
`groupPart →
`groupSpecifier
`| groupSpecifier [bondOrderSymbolChar] groupSpecifier
`groupSpecifier → [!] elementSymbol index
`
`7.6.3 Literals
`
`As mentioned in the overview, the simplest form of an atom expression is an atom
`specifier. An atom specifier consists of three literals: hierName, the optional attr-
`Name, and ID.
`
`258
`
`Page 276 of 533
`
`Medivis v. Novarad
`IPR2023-00042
`Ex. 2023
`
`

`

`Atom Expressions
`
`hierName stands for a name of a hierarchy level (e.g., residues). The following
`abbreviations can be used for the most common levels:
`a=atoms, r=residues, b=bonds, s=secondary structure, c=chains
`attrName
`(e.g.,
`is optional
`and specifies
`the name of
`an attribute
`If it is
`temperature, occupancy, type, ...) of the given level.
`omitted, the ID is assumed to specify the attribute name or index as shown by the
`list command. If an attribute name is given, the ID is assumed to stand for values
`of the attribute.
`To see which hierarchy levels and respective attributes are defined for a given
`molecule, take a look at the Color port which is used in several modules. The right
`pull-down menu will show all available attributes for the level chosen in the left
`pull-down menu.
`ID specifies an identifier of a member of the given level. If an attribute name is
`given, ID specifies a value of this attribute. It may contain wildcards such as * (any
`substring will match) and ? (any single charackter will match). For integer and
`float attributes ranges can be used by delimiting the boundaries with a colon (i.e.
`atoms/index=5:10 selects all atoms with an index within this range). If no attribute
`name is given, the name attribute is used as a default.
`In this case, specifying
`a range will select all atoms whose index is between the index of the selected
`boundaries. (as an example, for a moelcule imported form PDB the residue name
`is the chain identifier plus the residue index, thus r/L1:L5 selects residues 1 to 5 on
`the L chain). An exception to this is the atoms level. Molecules in Amira contain
`an atomic number attribute instead of an element symbol attribute. To select atoms
`via their element symbol you can simply type a/element. Thus the atom specifier
`for all oxygen atoms a/O is equivalent to the atom specifier a/atomic number=8.
`Instead of the ’=’ comparison you can also use the comparison operators (cid:48) <(cid:48),(cid:48) >(cid:48)
`,(cid:48) >=(cid:48) and(cid:48) <=(cid:48). These, however, are only available for index, integer and float
`attributes, not for string attributes.
`Another atom expression form involving several literals is the groupParts expres-
`sion which is used with the GROUP operator. Operators will be explained in the
`next section.
`
`7.6.4 Operators
`Logical Operators
`Several atomSpecifier combinations can be used in one expression by linking them
`logically via the operators AND, OR, and NOT (&, |, and !). Priorities can be speci-
`fied using usual parentheses ( and ).
`
`259
`
`Page 277 of 533
`
`Medivis v. Novarad
`IPR2023-00042
`Ex. 2023
`
`

`

`Chapter 7: Molecular Option Introduction
`
`WITHIN(atomExpr,float)
`This operator selects all atoms which are nearer than float ˚A to any of the atoms
`specified by atomExpr.
`BONDED(atomExpr[,int])
`With this operator, all atoms that are recursively connected to any atoms specified
`by atomExpr will be chosen. You can optionally specify an integer value defining
`the maximal bond steps. If this is omitted, there will be no limit.
`CS
`CS specifies all currently selected (highlighted) atoms.
`GROUP(groupParts)
`The GROUP operator is a powerful tool to find functional groups by searching
`for a certain atom and bond pattern in the molecular graph. To define a graph as
`a search pattern (groupParts), you must divide it into linear pieces of sequential
`atoms (a groupPart). Each atom must be defined by its element symbol and an in-
`dex which distinguishes it from other atoms with the same symbol but other indices
`(groupSpecifier). Thus, C1C2C3 would be a groupPart consisting of three differ-
`ent groupSpecifiers representing a chain of three carbons. This group part can now
`be combined with another group part by using one of its groupSpecifiers as branch
`point (e.g., C2O1H1 for a hydroxyl group branching from the second carbon of
`the chain). At the beginning of each group specifier, there can be an optional ‘!’.
`If it is given, the groupSpecifier is only used for matching, but the correspond-
`ing atoms will not be selected. (Thus !C1O1H1 would find the hydroxyl groups
`without selecting the flanking carbon, which must be given, however, to avoid se-
`lecting structures, such as OH groups in H2O). If the atomSpecifier in question
`appears several times (to define branch points), it is sufficient to mark it with the
`exclamation mark once.
`Consecutive atomSpecifiers in a groupPart are usually not divided from each other.
`This means that there must be a bond of any type between the consecutive atoms.
`If you want to define the bond order further, you can give an optional bondOrder-
`Symbol. (‘-’ for a single, ‘=’ for a double, ‘#’ for a triple and ‘˜’ for an aromatic
`bond).
`Take a carboxyl group as an example. To define the group pattern, the cen-
`tral carbon atom (C2) needs to be connected to three atoms: two oxygens (O1,
`O2), and one other carbon (C1). This can be done in the following way:
`GROUP(!C1C2O1,C2O2H1). Thus, the hydroxyl group (O2H1) is given as a
`branch of the CCO chain. There are, of course, several other ways to split this
`branch into linear pieces which you can easily find yourself. If your molecule con-
`tains the bond type attribute, you can also make use of the double bond. Thus the
`
`260
`
`Page 278 of 533
`
`Medivis v. Novarad
`IPR2023-00042
`Ex. 2023
`
`

`

`Atom Expressions
`
`expression becomes GROUP(!C1-C2=O1,C2-O2-H1).
`Notice: The keywords do not need to be in capital letters. Lower case letters, even
`a combination of lower and upper case letters, works as well.
`
`7.6.5 Shortcuts
`Molecular Option also provides pre-defined shortcuts that have been assembled
`using the previously mentioned syntactical elements. The shortcuts can be found in
`your local Amira directory in share/molecules/atomExpr.cfg, and can
`be edited and supplemented.
`The standard aliases included in the current Amira release are listed in Table 7.1.
`
`7.6.6 Further Examples
`• all
`selects all atoms.
`• atoms/5-8
`all atoms whose index is in the range 5 to 8, inclusive.
`• atoms/atomic_number>1
`all atoms, except hydrogens
`• s/type=helix AND NOT (a/C OR a/N)
`all atoms which belong to helices, except C and N atoms.
`• r/type=A*
`all atoms which belong to residues whose type name begins with the letter
`A.
`• BONDED(a/4 OR a/100,6)
`all atoms which are connected via at most 6 steps to the two specified atoms
`• WITHIN(r/A11,3.1) AND C
`all carbon atoms which are not away further than 3.1 angtroms from atoms
`of residue 11 on chain A
`• GROUP(C1C2C3C4C5C6C1)
`all cycles consisting of 6 carbons (e.g., cyclohexane).
`• acidic AND helix
`all atoms of acidic amino acids which belong to helices
`
`261
`
`Page 279 of 533
`
`Medivis v. Novarad
`IPR2023-00042
`Ex. 2023
`
`

`

`Chapter 7: Molecular Option Introduction
`
`acidic
`acyclic
`aliphatic
`alkali
`alkaliearth
`all
`amino
`aromatic
`at
`backbone
`basic
`buried
`cg
`charged
`cyclic
`h2o
`helix
`halfmetallic
`halogens
`hetero
`hydrophobic
`ions
`metallic
`neutral
`noblegas
`nonmetallic
`nucleic
`nucleicbackbone
`polar
`proteinbackbone
`purine
`pyrimidine
`sheet
`sidechain
`site
`surface
`turn
`
`acidic amino acids
`acyclic amino acids
`aliphatic amino acids
`atoms which are alkali metals
`atoms which are alkali earth metals
`selects everything
`amino acids
`aromatic amino acids
`adenine or thymine
`atoms of protein or DNA/RNA
`basic amino acids
`amino acids usually found inside the protein
`cytosine or guanine
`charged amino acids
`cyclic amino acids
`water molecules
`helices
`atoms which have half metallic properties
`halogenic atoms
`heterogenic atoms
`hydrophobic amino acids
`charged heterogenic atoms
`atoms which have metallic properties
`neutral amino acids
`atoms which have noble gas properties
`atoms which have nonmetallic properties
`nucleic acids
`backbone atoms of RNA/DNA
`polar amino acids
`backbone of a polypeptide
`adenine or guanine
`cytosine or thymine
`sheets
`atoms not belonging to the backbone
`
`amino acids usually to be found on the surface
`
`Table 7.1: Predefined expressions for selecting parts of molecules in Amira.
`
`262
`
`Page 280 of 533
`
`Medivis v. Novarad
`IPR2023-00042
`Ex. 2023
`
`

`

`Part III
`
`Virtual Reality Option User’s
`Guide
`
`263
`
`Page 281 of 533
`
`Medivis v. Novarad
`IPR2023-00042
`Ex. 2023
`
`

`

`Page 282 of 533
`
`Medivis v. Novarad
`IPR2023-00042
`Ex. 2023
`
`Page 282 of 533
`
`Medivis v. Novarad
`IPR2023-00042
`Ex. 2023
`
`

`

`8 Virtual Reality Option User’s
`Guide
`
`The Virtual Reality Option is an Amira extension providing support for large tiled
`displays like screen arrays as well as immersive multi-wall displays like CAVEs
`and Holobenches, with applications ranging from extended resolution displays to
`true immersive virtual reality. For performance use of multiple screens or projec-
`tors, Virtual Reality Option supports either:
`• parallel multi-threaded rendering on multi-pipe machines, which are hosting
`multiple graphics boards,
`• parallel distributed rendering on graphics clusters, which are interconnected
`PCs equipped with graphics board (not to be confused with compute clus-
`ters).
`For enhanced interaction and immersion, VR configurations can support active
`and passive stereo modes, soft edge blending, head tracking and advanced 3D user
`interaction. Any VRCO trackd-compatible tracking system and control devices
`can be used together with Virtual Reality Option. Existing Amira modules can be
`directly used in an immersive environment by means of 3D menus. Scripts can
`be used for customization.
`In addition, a simple API is provided, allowing an
`Developer Option programmer to add display modules with a specific interaction
`behaviour.
`The documentation of Virtual Reality Option configurations is separated into the
`following parts:
`Configuration and startup
`• Virtual Reality Option essentials
`• Using a multi-pipe system
`• Using a cluster system
`• Flat screen configurations
`• Immersive configurations
`
`265
`
`Page 283 of 533
`
`Medivis v. Novarad
`IPR2023-00042
`Ex. 2023
`
`

`

`Chapter 8: Virtual Reality Option User’s Guide
`
`• Calibrating the tracking system
`Working with Virtual Reality Option:
`• 3D user interaction, including the 3D menu
`• Writing Virtual Reality Option custom modules
`Reference sections
`• Config file reference
`• The AmiraVR control module
`• The ShowConfig module
`• The tracker emulator
`
`8.1 Virtual Reality Option Essentials
`
`8.1.1 Virtual Reality Option configurations
`
`differ-
`in many
`configured
`be
`can
`Option
`Reality
`Virtual
`in
`a
`described
`is
`configuration
`A particular
`ent ways.
`or
`under
`file
`config
`$AMIRA ROOT/share/config/vr
`$AMIRA LOCAL/share/config/vr.
`The config file contains things
`like the layout or physical extent of the screens of the display system, information
`about the display sources such as the X display or the parts of the desktop mapped
`onto the screens, as well as optional calibration data for the tracking system.
`When Virtual Reality Option is installed the Amira main window provides an ad-
`ditional menu labelled VR. This menu lists all config files found in the config
`directory. Once a particular configuration is selected, the AmiraVR module is cre-
`ated - if one does not already exists. Depending on the particular configuration the
`AmiraVR module allows the user to connect to the tracking system, to calibrate the
`tracking system, or to activate additional options.
`Configurations are detailed in further sections.
`
`8.1.2 Immersive interaction and the trackd daemon
`
`For immersive displays with head tracking or interaction with 3D input devices,
`Virtual Reality Option makes use of the VRCO trackd software in order to access
`
`266
`
`Page 284 of 533
`
`Medivis v. Novarad
`IPR2023-00042
`Ex. 2023
`
`

`

`Using Virtual Reality Option on a multi-pipe system
`
`the tracking system and controller devices. Trackd itself is not part of Virtual Re-
`ality Option. For more information about purchasing and installing trackd, please
`refer to www.vrco.com or 3dviz.mc.com.
`Before a tracking system can be used in Virtual Reality Option the trackd daemon
`(and possibly a trackd server) has to be started. The trackd daemon connects to the
`tracking system and controller device and provides the actual tracker and controller
`data in two shared memory segments, which are read by Amira.
`
`8.1.3 Multiple displays and parallel rendering
`Virtual Reality Option can use simple configurations driven by a single graphics
`board, possibly using several video outputs (e.g. dual-head). It also supports con-
`figurations requiring more outputs than available from a single board (tiled or arbi-
`trary multi-displays). Having a single screen or projector per graphics board may
`also be preferred for performance. This can be achieved either by using a multi-
`pipe computer hosting multiple graphics boards (section 8.2), or using a cluster of
`computers (section 8.3).
`Virtual Reality Option manages application synchronization and OpenGL frame
`buffer swap synchronization for all displays, so that the same content can rendered
`simultaneously on each display, yet possibly with a different viewpoint.
`A type of stereoscopic displays relies on active shutter glasses synchronized with
`the display, where the left and right eye images are rendered alternatively (OpenGL
`quadbuffered stereo). Active stereo requires synchronizing the video signals of the
`whole graphics boards. This can be achieved for instance with hardware frame-
`lock/genlock as provided by NVidia ’G’ cards. Passive stereoscopy, for instance
`using polarizing filter glasses, does not require video frame synchronization.
`
`8.2 Using Virtual Reality Option on a multi-pipe
`system
`
`8.2.1 Configuration
`Effective rendering on a multi-pipe system requires parallel rendering, i.e. send-
`ing data to the graphics engines from several threads running in parallel. Note that
`for all common current graphics architectures it makes no sense to render multiple
`windows on the same pipe in parallel. Typically, this even implies a significant per-
`formance decrease. Virtual Reality Option configurations allows to define display
`
`267
`
`Page 285 of 533
`
`Medivis v. Novarad
`IPR2023-00042
`Ex. 2023
`
`

`

`Chapter 8: Virtual Reality Option User’s Guide
`
`thread groups for multi-pipe rendering (more about configuration with examples
`in next sections).
`
`8.2.2 Starting Amira
`
`After Virtual Reality Option has been installed Amira can be started as usual. How-
`ever, in order to activate parallel rendering of screens assigned to different thread
`groups, Amira should be started with the -mt command line options. This option
`enables multi-threading. In order to permanently activate multi-threading, the en-
`vironment variable AMIRA MULTITHREAD can be set. In order to disable multi-
`threading when AMIRA MULTITHREAD is set, Amira can also be started with the
`-st command line option (single-threaded mode).
`Note: On some graphics engines such as SGI Onyx systems there are known
`problems with the OpenGL driver related to the use of texture objects in differ-
`ent OpenGL contexts. If you are rendering more than one screen on a single pipe,
`you may define the environment variable AMIRA NO CONTEXT SHARING as a
`workaround. This may be fixed by some OS or driver update.
`
`8.3 Using Virtual Reality Option on a cluster
`
`8.3.1 Overview
`
`A graphics cluster consists of multiple computers cluster nodes) connected via
`a network. Each computer controls one or more screens of a tiled or multi-wall
`display system. Virtual Reality Option synchronizes the different cluster nodes,
`ensuring that the same scene is rendered simultaneously from different viewpoints.
`This cluster support enables distributed parallel rendering. It does not speed up
`ordinary computations by distributing them across multiple nodes of the cluster.
`Instead, on each cluster node a separate instance of Amira is running, with the
`complete modules network and all data being replicated in cluster’s node memory.
`Changes of Amira modules made on a master node will be propagated to the slave
`nodes as lightweight command messages and executed synchronously: therefore
`the master and the slaves nodes execute the same processing steps. A special
`daemon running on slave nodes is responsible for starting the Amira instance upon
`requests of the master, once a cluster configuration is selected. The 2D mouse or a
`3D input device can be used to interact with the application on the master node.
`
`268
`
`Page 286 of 533
`
`Medivis v. Novarad
`IPR2023-00042
`Ex. 2023
`
`

`

`Using Virtual Reality Option on a cluster
`
`8.3.2 Requirements
`• All nodes of the cluster should be of the same type. If different hardware is
`used, it is possible that the cluster will run out-of-sync for instance because
`of round-off errors.
`• Rendering speed is limited by the slowest node of the cluster, including the
`master node. Therefore it is recommended that all cluster nodes including
`the master node have the same type of graphics board.
`• All nodes of the graphics cluster must be able to communicate with each
`other via a TCP/IP connection. A standard 10 Mbit ethernet connection
`may be fast enough, since only synchronization commands are exchanged,
`rather than images or raw data blocks.
`• For active stereoscopy, the graphics cards of the different cluster nodes must
`be genlocked with a genlock cable. Currently only a small number of graph-
`ics cards (such as WildCat, SUN Zulu, NVidia ’G’ boards) provide genlock-
`ing. Genlocking ensures that the video refresh cycles are synchronized. Vir-
`tual Reality Option itself only synchronizes OpenGL buffer swaps. Passive
`stereoscopy does not require genlocking.
`• Installation path and data location.
`When Amira loads scripts or data below its installation directory, the rel-
`ative path on the master is ’rooted’ to Amira installation directory on
`slaves. For instance, /master-path/Amira/data/xxx is translated
`into /slave-path/Amira/data/xxx. However it is highly recom-
`mended that all data files and scripts have the same absolute file path on
`all nodes of the cluster. Likewise, Amira should be installed at the same lo-
`cation on all nodes. For convenience, it is recommended to run Amira from
`a shared mounted file system. This ensures that the same scripts and config
`files will be used on all cluster nodes.
`• On a Linux or UNIX cluster, it is recommended to have a shared home direc-
`tory. This ensures that some modules have consistent access to preferences
`settings stored in .AmiraRegistry.
`
`8.3.3 Preparing cluster slave nodes
`
`Amira requires a daemon process to run on each slave node. This sections explains
`how this can be achieved automatically or manually.
`
`269
`
`Page 287 of 533
`
`Medivis v. Novarad
`IPR2023-00042
`Ex. 2023
`
`

`

`Chapter 8: Virtual Reality Option User’s Guide
`
`Using the Amira service
`
`Amira can manage services for automatic start-up of daemon processes such as the
`Virtual Reality Option daemon. You may request installation of services during
`Amira installation, or you can control the services with a dedicated utility program
`provided with Amira.
`Note: To manage the Amira services, you must have administrator privileges
`(Windows) or root privileges (UNIX/Linux).
`
`Figure 8.1: The Amira service configurator.
`
`Just launch ”bin\arch-...-Optimize\hxservicemanager.exe” on
`Windows, and ”bin/start -servicemanager” on Linux. This tool man-
`ages the execution of Virtual Reality Option services. Indeed, instead of the user
`launching the Virtual Reality Option daemon manually, a service can be installed
`on the system so that it automatically starts these processes at system start-up.
`
`270
`
`Page 288 of 533
`
`Medivis v. Novarad
`IPR2023-00042
`Ex. 2023
`
`

`

`Using Virtual Reality Option on a cluster
`
`In order to install and start a service, click on the Start button. Then, clicking on
`the Stop button will stop and uninstall the service.
`
`Platform-dependent notes
`• On Windows platforms:
`Once installed, services can be started or stopped from the services manager
`of the system that can be launched via the Control Panel (select Administra-
`tive tools, then Services) or with the command: services.msc /s.
`• To start an Amira service, select it in the list (”hxvrdaemon”), then
`select Start from the Action menu.
`• To restart the service, select it in the list, then select Restart from the
`Action menu.
`• To stop the service, select it in the list, then select Stop from the Ac-
`tion menu.
`
`Warning about virtual drives: Amira services do not support
`log-
`ical or network volumes.
`Indeed, such virtual drives do not exist
`in the service execution context. You must specify full paths con-
`structed according to the universal naming convention (UNC), such as
`”\\remotemachine\directory”.
`For example, to install the service from a virtual drive S: targeting a
`distant mount point ”\\remotemachine\directory”, do not launch
`the installer from S:, but from ”\\remotemachine\directory”.
`Then, for the same reason, the user should not load data from virtual drives
`because Amira slaves cannot resolve virtual paths unless they are below
`%AMIRA ROOT%, in which case data paths are re-interpreted on slaves with
`the local %AMIRA ROOT%.
`• On Unix/Linux platforms:
`started from the
`Amira services
`are
`implemented as daemons,
`”/etc/init.d” directory. Once installed, services can be manu-
`ally started or stopped using the appropriate script. For example, type
`”/etc/init.d/hxvrdaemon stop” to stop the Virtual Reality
`Option daemon. Note that this will not uninstall the daemon, that will
`be launched on next system start-up (or next ”init 5” mode switch in
`
`271
`
`Page 289 of 533
`
`Medivis v. Novarad
`IPR2023-00042
`Ex. 2023
`
`

`

`Chapter 8: Virtual Reality Option User’s Guide
`
`particular).
`One specific feature of Amira services on Linux platforms is that they can
`be executed as a given user, other than root. To do so, just type a valid login
`in the user field, then restart the service to take the change into account.
`One other specific feature is that Virtual Reality Option daemons can be
`installed on remote nodes of a cluster from the master node, provided the
`fact that %AMIRA ROOT% is the same on every machine. Just type the list
`of the nodes hostnames separated by space chars. Make sure that ssh is
`installed on all machines and configured to use RSA authentication protocol
`(public and private key files) so that you will not be prompted for password
`on any operation.
`
`Running the daemon
`
`If the Amira service cannot be used for some reason, one can use manual start-
`up. On Linux start Amira with command line option -clusterdaemon, on
`Windows start hxvrdaemon.exe
`On Windows, to start the daemon automatically after the computer is booted, a
`shortcut to the daemon executable can be added to the Start/Programs/Startup
`folder.
`
`8.3.4 Running Virtual Reality Option on cluster
`The following steps are required to use cluster configurations:
`
`1. Install Virtual Reality Option on every node of the graphics cluster under the
`same absolute path name, or better yet, create a mounted file system with
`the same absolute path name on every node.
`2. Create a standard Virtual Reality Option config file describing the geometry
`of your display system (see the next sections about configurations). Then
`add a field hostname in each screen section. This field indicates on which
`node the screen will be rendered. The config file must be stored on all nodes
`in the directory $AMIRA ROOT/share/config/vr.
`3. Choose one node as the master node. After Amira installation, a daemon is
`started on the slave nodes, by a service on Windows systems or by inetd on
`Unix/Linux systems. Start Virtual Reality Option on the master and select
`your cluster configuration from the config menu. Slave instances of Virtual
`Reality Option should now be started on all nodes specified in the config file.
`
`272
`
`Page 290 of 533
`
`Medivis v. Novarad
`IPR2023-00042
`Ex. 2023
`
`

`

`Using Virtual Reality Option on a cluster
`
`To use the -clusterdaemon option, stop the daemon (see 8.3.3 service man-
`agement) and replace step 3 by the following steps:
`
`1. Choose one node as the master node. On all other nodes start Amira with the
`command line option -clusterdaemon. With this option a little daemon
`is started, to which the master process can talk. The daemon automatically
`starts a slave instance of the real Amira if necessary.
`2. Start Virtual Reality Option on the master node. Then select your cluster
`configuration from the config menu. Slave instances of Virtual Reality Op-
`tion should now be started on all nodes specified in the config file.
`3. Next you can load any standard Amira network script. For example, open
`the online help browser on the master node and choose one of the standard
`Virtual Reality Option tracking demos. The particular script will be loaded
`on all slaves as well. Once a script has been loaded, all standard Virtual
`Reality Option interaction modes are available in cluster mode too.
`
`8.3.5 Limitations
`• The primary focus of the Virtual Reality Option cluster version is on work-
`ing in a VR environment. Consequently all manipulations performed in VR
`mode, e.g., via the 3D menu, will be properly synchronized. On the other
`hand, currently not all manipulations made on the master node via the con-
`ventional 2D user interface will be synchronized.
`• Any kind of 2D mouse interaction in a 3D viewer window also will not be
`synchronized in cluster mode. Thus you cannot draw a lasso area with the
`2D mouse. Mouse manipulation and interaction are entirely disabled on
`slaves nodes.
`• Transform editors and clip planes are synchronized in cluster mode, while
`other editors may be grayed out and not accessible.
`• When loading a new cluster configuration file, Amira attempts to send the
`current network to slaves nodes for reloading after they are restarted. Data
`should be duplicated or shared in order to have the same path relative to
`script. This may also fail if default directory for temporary files are not the
`same path on master and slaves. You may check TMPDIR, TEMP or TMP
`environment variable depending on your system.
`
`273
`
`Page 291 of 533
`
`Medivis v. Novarad
`IPR2023-00042
`Ex. 2023
`
`

`

`Chapter 8: Virtual Reality Option User’s Guide
`
`8.3.6 Troubleshooting cluster configurations
`• Check that cluster
`slaves can be reached from master.
`ping
`<slave-hostname> or ping <slave-IP-adress> You can
`change hostnames with IP adresses in the configuration file.
`• Check that cluster master can be reached from slave with master hostname
`with ping <master-hostname>. Otherwise, on the master node you
`can set the environment variable AMIRA HOSTNAME to the master host-
`name or IP address that can be used from slaves to reach the master.
`• Check that Amira runs properly on each slaves. You may need to switch
`keyboard and mouse to each slave nodes for checking. You may first try
`hint below.
`• In order to show and check console output on slaves, you can reduce the
`channel size in SoScreen, and add in the configuration file:
`
`SoVRProperty {
`showSlaveConsole TRUE
`showSlaveGUI TRUE
`showSlaveCursor TRUE
`
`}
`
`showSlaveCursor should be set if you wish to use a mouse connected to a
`slave node.
`• It is recommended to have one and only one screen defined for the master
`in the configuration file (SoScreen without specified hostname). Use SoVR-
`Property with keepMasterViewerInsideGUI field for convenience.
`• Do not mix flat and immersive screen definitions.
`• Make sure that no firewall limits communication within the cluster (port
`17234 and dynamic port are used).
`
`8.4 Flat Screen Configurations
`
`A flat screen configuration consists of usually two or more screens forming a big-
`ger 2D virtual graphics window commonly called a tiled display or power wall.
`Users can interact with the ordinary 2D mouse, i.e., mouse events in the differ-
`ent windows are translated and interpreted in the 2D virtual window. There is
`
`274
`
`Page 292 of 533
`
`Medivis v. Novarad
`IPR2023-00042
`Ex. 2023
`
`

`

`Flat Screen Configurations
`
`no need for a tracking system in case of a flat screen configuration. For such a
`configuration the only options provided by the AmiraVR control module are for
`controlling stereo viewing. Besides standard OpenGL active stereo modes, pas-
`sive stereo modes can also be configured. In the most simple case this is done by
`defining two full screen windows on two different channels, one for the left eye
`view and one for the right eye view. This particular configuration is illustrated in
`Figure 8.2. Other passive stereo configurations are possible too, e.g., a super-wide
`tiled passive stereo configuration with four channels (left side left eye, left side
`right eye, right side left eye, right side right eye), possibly with an overlap region
`for soft-edge blending.
`The main advantage of a flat screen configuration is its ease of use. There is no
`need for a tracking system. Flat screen configurations are well suited for presen-
`tations targeted to a larger audience, e.g. presentations in a seminar room or in a
`lecture hall.
`In the following we describe some common flat screen configurations in more
`detail, namely a standard-resolution two-projector passive stereo configuration, a
`super-wide two-projector mono configuration with soft-edge blending, and a tiled
`2x2 four-channel monitor configuration. For some cases also hardware solutions
`are available, namely special-purpose video splitters converting an interlaced ac-
`tive stereo signal into separat