Administering SMTK

Previous sections covered the concepts and tools for using SMTK. This section is for system administrators who wish to make SMTK available to users

  • as a Python module and command-line utilities for end users of SMTK,

  • as a library for people developing SMTK-based applications, and/or

  • as a remote model and mesh server for end users and applications.

End-user tool installation

This type of installation should be as simple as downloading a binary package of SMTK and clicking install.

Todo

Expand on details of installation and configuration.

Developer installation

In addition to the binary installer, there should also be a development package that contains header and configuration files needed to build C++ applications using SMTK. Install this the same way you installed the binary above.

You can also download the source code from the git repostory and follow the instructions for building and installing SMTK in the toplevel ReadMe.md file.

Todo

Expand on details of installation and configuration.

Configuration as a modeling and meshing server

SMTK uses Remus to start model and mesh workers. In order for SMTK to discover available workers, you must place Remus worker files somewhere that SMTK is configured to search for them. These worker files identify the executable to run when a user requests a modeling or meshing operation to be performed. Their format is covered further below, but first we focus on how the files are discovered.

Worker file search paths

The default locations that SMTK searches for these worker files varies by operating system:

Linux

SMTK searches the current working directory of the process, followed by the var/smtk/workers subdirectory of the toplevel installation directory. For example, if SMTK is installed into /usr with the worker at /usr/bin/smtk-model-worker, then it will search /usr/var/smtk/workers.

If the SMTK_WORKER_DIR environment variable is set to a valid path, then it is searched as well.

Mac OS X

SMTK searches the current working directory of the process, followed by the var/workers subdirectory of the toplevel installation directory if SMTK is not part of a bundle. For example, if SMTK is installed into /usr with the worker at /usr/bin/smtk-model-worker, then it will search /usr/var/smtk/workers.

If an application built with SMTK is part of a bundle (such as an app), then SMTK will search the Contents/Resources/workers directory of the bundle.

If the SMTK_WORKER_DIR environment variable is set to a valid path, then it is searched as well.

Windows

SMTK searches the current working directory of the process followed by the directory containing the process executable (when provided to SMTK by the application).

If the SMTK_WORKER_DIR environment variable is set to a valid path, then it is searched as well.

Creating a Remus worker file for solid modeling

When SMTK is built with Remus support enabled, it will include a command-line utility named smtk-model-worker. This program can be run manually or directly by SMTK in order to perform modeling operations in a different process. It is also the program you can run to generate a worker file that makes it discoverable to SMTK for direct use. You can run

smtk-model-worker -help

to obtain reference information on the command-line arguments. It will also print a list of available modeling kernels.

Each model worker exposes a single modeling kernel (via smtk::session::remote::Session on the client, which talks to a RemusRPCWorker in the worker process). Normally, the model worker executable expects to be given the following command-line arguments:

  • A Remus server to connect to as its first argument, formatted as a URL (e.g., tcp://cadserver.kitware.com:50510).

  • A solid modeling kernel to advertise (e.g., -kernel=cgm).

  • A default modeling engine for the kernel to use (e.g., -engine=OpenCascade).

  • A Remus worker file to read (when invoked without -generate) or write (when invoked with -generate).

  • A directory in the filesystem to make available to users for reading and writing CAD model files (e.g., -root=/usr/local/var/smtk/data). The root directory is not made available to end users for security purposes; all paths are relative to the root directory. SMTK does not currently prevent access to other portions of the filesystem but it will in the future.

  • A “site name” describing the combination of host and/or filesystem made available to SMTK by the model worker. This label is presented to end users by applications so that users can differentiate between workers providing the same modeling kernels but on different machines.

  • A Remus worker file to read or write (e.g., -rwfile=/usr/local/var/smtk/workers/cgm-OCC.rw).

If you pass the -generate option to the model worker, then it will generate a model worker file which you can then customize. When you generate a model worker file, two files are normally written: the first, specified by the -rwfile argument is the actual Remus worker file and is formatted as a JSON object. The second has the same filename with a .requirements suffix appended and is formatted as an XML attribute resource describing the modeling operations available.

You should generate a separate Remus worker file for each combination of modeling kernel, engine, and root directory you wish to make available. Once these files have been generated, you can edit the worker file and change them to suit your site’s needs. You may specifically wish to change the WorkerName setting to be more descriptive. Be careful when editing the Tag data as it is used by SMTK to decide which engine and kernel combination may load a given file.