Skip to main content
U.S. flag

An official website of the United States government

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Secure .gov websites use HTTPS
A lock ( ) or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

Server Local Data and Configuration

Server Data

The NICE server is installed on a number of machines around the building.  This includes actual instruments, VMs and developer desktops.  Each of these instances is referred to as an installation.

Each installation references/depends on data from two broad categories:

  • Local Data
  • Instrument Configuration

Local data is only applicable to that particular installation and is not stored in the NICE code repository.  Local data includes:

  • The latest value of nodes
  • Experiment data
  • Logs
  • The state of any simulated hardware
  • Which instrument configuration to use (ie. is this "spin echo" or "magik")?

Instrument Configuration is applicable to ALL instruments of this type.  A simulation of Spin Echo, running on a developer's desktop will have many things in common with the real Spin Echo machine.  This type of data is stored in the NICE the repository and includes:

  • A reference the startup script (a piece of code run whenever the server starts)
  • Device/Communications configurations
  • Writer setup
  • Suggested device hierarchy as displayed in the device panel
  • Information about special persistent config keys for this instrument

Resetting Installation Data

As a convenience to developers, it is useful to reset the local installation's data folder to a previously defined state.  This state will typically represent an existing instrument in a reasonable state.  However, any number of states can be created to restart the server in any useful state you'd like to repeatedly go to.

To start the server in a given state, start with the argument: --resetdata <state>

States are defined in the folder reset_server_data.  When the --resetdata argument is used, the server:

  1. deletes server_data (or whatever folder was configured to be used for local machine state)

  2. copies reset_server_data/base --> server_data (contains boilerplate data which has to exist)

  3. copies reset_server_data/<state> --> server_data (any conflicting files are overwritten)

Important: Reset would be dangerous if used on a real instrument!  As a result, reset fails unless:

 

The file server_data/testing_machine exists and contains the string testing_machine.  Conveniently, the reset_server_data/base folder already contains a file like this!

Important: When setting up a new instrument for the 1st time, you must change the Testing_machine file to mark the instrument as REAL!  This has several effects, which including preventing an accidental and CATASTROPHIC reset!

On a new real instrument installation, edit server_data/testing_machine so that it contains the string real_machine.

Making a Reset State

To create a new reset state from your current state:

  • Get the server to  state you like
  • Shutdown the server
  • Copy the server_data folder, as it exists, to the reset_server_data folder and rename it appropriately.
  • Modify the copied state to minimize its size:
    • Delete the logs sub-folder
    • Remove all files, which are already present in the reset_server_data/base folder
    • Reduce the persist_config folder:
      • Delete everything EXCEPT: 
        • the latest full_state.xxx
        • integrity.0
      • Rename full_state.xxx to full_state.0
      • Open the full_state.0 file and copy the 1st number (a time stamp)
      • Edit integrity.0 and change the number, preceding :valid, to the number you copied

 

Created September 17, 2018