As ROOT:

1) Unpack xvnmr_dir.tar.Z to a sensible directory. E.g.,

place xvnmr_dir.tar.Z in /export/home

	uncompress xvnmr_dir.tar.Z
        tar xvf xvnmr_dir.tar

2) create a link to the xvnmr_dir in /xvnmr_dir, something like:

	ln -s YOUR_PATHNAME/xvnmr_dir /xvnmr_dir

where YOUR_PATHNAME is the absolute pathname of where you have put the
xvnmr_dir directory (/export/home in the example above)

3a) You then need to link various files in the xvnmr_dir directory to
the system vnmrsys directories:

	cd /xvnmr_dir/bin
	run create_global_xvnmr_links

3b) You also need to link in our supported sequences to the psglib etc.
directories:

	cd /xvnmr_dir/supported_sequences
	run create_new_links

This step should compile the sequences as well, so check for warning
messages as it tries to compile them.

4) The xvnmr.config file needs to be set up correctly so that xvnmr knows
where various support and log files are, and a directory where data will
be saved. Do the following:

	cd /xvnmr_dir/vnmr-tk
	vi xvnmr.config  

Set the correct fields. Note that main_save_dir can be set to an absolute
pathname, e.g. /scratch or a relative pathname (with respect to the users'
home directory), e.g., data. Note also that if you use an absolute directory
name (such as /scrtach as we do) then the software will want to create a
sub-directory for each user called /scratch/$user where $user is the user
name of the operator. If users don't have permission to create a sub-
directory under the main_save_dir path then root may need to do this for
them. For the case of main_save_dir being /scratch this could be done by
performing (e.g. for user vnmr1):

mkdir /scratch/vnmr1
chown vnmr1 /scratch/vnmr1

etc. for all users.

Various log files are written to by the xvnmr code. These need to be
"created" when xvnmr is installed. To do this:

	cd /xvnmr_dir/log_files (or wherever was specified for the 
				patient log directory)
	touch patient_log.doc
	chmod ugo+rw patient_log.doc
	touch last_study_log
	chmod ugo+rw last_study_log

5) Log off as root and login as a particular user

For a new user to start using xvnmr there are a couple of things they
need to do the first time they run the code:

Firstly they need a link in their home directory to the master xvnmr_dir
directory. This is most easlily done with teh following:

	cd 	(to get to the user's home directory)
	ln -s /xvnmr_dir xvnmr_dir

Next, run xvnmr from the new menubar within Vnmr (a new xvnmr button
should appear automatically in the main Vnmr menu).  On the first time any
user runs xvnmr, various global parameters are created, using the
macro create_image_pars.  Some of these will need to be set to
sensible values (e.g. the EPI tweaker tep) and grise should be set
to the rise time of the gradients (or to a larger value if you
want to back off the slew rate). If you have more than one gradient
set, make sure grise gets correctly updated when you change coils.

A basic (and a bit out-dated) description of using xvnmr is given in
http://www.fmrib.ox.ac.uk/~peterj/xvnmr_docs/xvnmr_scanning.html

Additional notes to the installer:

1) The patient information page has two features that are used here at
   FMRIB, but may not be useful for other users.  When a study is
   finished a file called .archive is written which contains the user
   name of the investigator.  A separate program (not included here) 
   periodically searches for these files and automatically archives 
   the data to disk and copies it to the user's home directory on 
   our main server (independent from the scanner workstation).  A 
   list of valid users needs to be included in the file
   /xvnmr_dir/log_files/valid_user_list.doc.  Also it is required 
   that a study has a project number associated.  This is a requirement 
   in our lab, and scanning cannot proceed without one.  The valid
   study numbers are in /xvnmr_dir/log_files/db.txt and are colon
   separated lists of the form

   Investigators : Study name : Project number

Both these features are easy to disable in the file
/xvnmr_dir/vnmr-tk/xvnmr (search for the string FMRIB).

2) Note that you may run into a problem with the main menu not
   showing up the "start xvnmr" button. Most of our macros
   have names which should not conflict with Varian macros/menus, but
   the "main" menu is one that we could not avoid giving the same name
   as the Varian version. Since the menu will already exist it is
   possible that our link in /vnmr/menulib didn't update to the xvnmr
   version. So have a look at /vnmr/menulib/main and see if it is a
   file or a pointer. If it's still the default (Varian) file, then
   you could do the following (as root or vnmr1):

   cd /vnmr/menulib
   rm main
   ln -s /xvnmr_dir/menulib/main main

   With this accomplished you should be running our version of the main
   menu.

3) Note that the rfcoils need to have default calibration values 
   entered into a file in /xvnmr_dir/vnmr-tk called rfcoils.config
   Basically this needs to look pretty much like the pulsecal file,
   although it is a bit different. When xvnmr runs a new study it writes
   a fresh pulsecal file in ~/vnmrsys with the default settings from
   the rfcoils.config file. It then searches around these values for
   a decent transmit gain setting (you may also need to optimise the
   procpar file used as part of the RF calibration for your system.

   An example of a valid rfcoils.config file (from our human system) 
   should be in your xvnmr_dir/vnmr-tk directory. You'll need to edit
   this to reflect the coils you have. 

   Also, note that if you have a prized version of ~/vnmrsys/pulsecal
   then you should back it up, since xvnmr will treat it as a scratch file.

4) Some parameters may need to be changed for every sequence that we
   have included.  An example of this is 'ticks' which may need to be
   set to 0 (zero) on your system, and is generally set to 1 on ours.
   There are also possibly some mis-set parameters if you have more
   than one RF channel (we only have one). Since it is pretty irritating
   to change the same parameter in hundreds of procpar files we have
   written a macro so that you can do this for all of our files. To 
   change a parameter for every sequence edit the skeleton text and
   run the macro 'update_supported_sequences' inside vnmr 
   (before running xvnmr).

5) We have a few sequences that use more real time variables than Varian
   provide as standard (and have made a few other mods too to the psg
   libraries). Assuming you are running Vnmr6.1c the easiest way to
   incorporate these changes is to copy the latest psg routines from
   our directory and then re-compile the psg libraries. This can be
   done by:

   (as vnmr1)
   cp /xvnmr_dir/vnmr_6.1C_patches/sc_code_18jul01/* /vnmr/psg
   then run "fixpsg" as vnmr1

6) On our system there is a timing issue between the clocks on the waveform
   board and the clock on the acquire board. This introduces a beating
   between the clocks that shows up as an instability on the EPI data
   (particularly). We have had to solve this by gating the acquires from
   the gradient waveform boards. For info on how to do this you can look
   at the write up on: 

   http://www.fmrib.ox.ac.uk/~peterj/misc_images/index_misc.html

7) Finally, note that users can customise their config files by putting
   them in a sub directory called ~/personal_xvnmr (this is particularly
   useful for the files sequences.config and rfcoils.confif, that users
   may wish to add new fields). The code will look in ~/personal_xvnmr
   first and then will look in /xvnmr_dir/vnmr-tk if it isn't found.

If you have difficulty then email us. It will likely take a couple of
rounds of emails to get it sorted, since we don't have this installed
in many places.

Good luck!

Stuart Clare and Peter Jezzard