Command Line Interface
VisIt has a command line interface, intended to be driven by Python scripts.
To run VisIt via the CLI, use the -cli command line option, usually along with -s to name a script file. For example:
/path/to/visit -cli -s /your/python/script.py
VisIt is (almost?) completely controllable via the command line interface. Here is just about the simplest of scripts which still does something useful:
db = "/path/to/your/checkout/trunk/data/multi_curv3d.silo" OpenDatabase(db) AddPlot("Pseudocolor", "u") DrawPlots() DeleteAllPlots() CloseDatabase(db)
Which opens a data file provided in the subversion repository and creates a pseudocolor plot of the u field. You can find more detail in the Python Interface Manual.
The CLI normally has more than 2 threads of execution running. Thread 1 starts the Python interpreter, automatically loading the VisIt module. Python maintains control of thread 1, calling into the VisIt module whenever it wants to interact with VisIt. The VisIt python module starts thread 2 on load. Thread 2 exists solely to read the viewer's socket and update state based on what the viewer sends. The synchronization is implemented by sending a message from thread 1 to the viewer. Thread 1 then blocks. The viewer is expected to reply to the CLI, which thread 2 will pick up via its read loop. Then, thread 1 is free to come back to life, allowing whatever visit_* function was executing to exit back to the Python interpreter.
The alternative implementation is to simply poll for data from the viewer's socket whenever we enter into the C implementation of the Python module. This is undesirable because we don't know when (if ever) the C implementation will be called next. If a state change comes in while we are executing Python code, it could sit in the operating system's socket buffers for a long period of time. Particularly if a lot of state changes occurred while we were `stuck' in python, the OS could start dropping later state changes, refusing to allocate more buffers.
Client methods are RPCs in spirit which are implemented by clients of the viewer. Clients give a list of such methods to the viewer when they connect. The viewer will forward the whole list to all connected clients. This essentially allows an intermediary by which disparate components of VisIt can request actions for one another. For example, a user can enter Python code in the GUI, which then sends an `interpret' command with the Python code via a client method. The viewer forwards the command to the CLI, which will execute the Python code. Thus the GUI can cause Python code to run without ever communicating with the CLI directly.