This is part 3 in my series of blog posts on RTI RID configuration tips. Each of these tips, unless otherwise noted, works in HLA 1.3, HLA 1516-2000, or HLA Evolved. Check out the previous posts in this series, and stay tuned for more to come.

Part 1 – RTI RID Configuration Tips: Consistency Checking

Part 2 – RTI RID Configuration Tips: the Advantages of MTL

Lookup environment variables within your RID

If you’ve followed me through parts 1 and 2 in this series, you may have noticed a theme: managing multiple RID files is a pain. Whether it’s ensuring consistency between the various RID files involved in a single federation, or maintaining separate configurations to be used in different federations, whenever you’re managing multiple RID files you’re bound to run into the occasional hiccup. The goal of these posts is to help you reduce these hiccups and help you identify them when they occur.

One of the best ways to eliminate consistency issues is to only use one RID file. If everyone uses the same file, there can’t be any inconsistency. I’ve talked to a lot of customers who do just that. Some throw the RID on some shared drive on their network that all federates have access to. Others manually distribute the RID file before exercises. And a few of the larger exercises I’ve talked to actually have a means of automatically distributing a central RID file to every machine in the federation at exercise start up. No matter how you do it, the problem is that not all RID parameters are meant to be used federation-wide. Many parameters are designed to be adjustable for each federate in your federation. After all, we can’t really expect a logger, a PVD, an IG, and any other federate you’re running to have the same needs. Some may want to run a separate IO thread, some may need larger socket buffers, some may have multiple NIC cards to choose between. How can you account for these small differences without maintaining multiple RIDs? Most of the parameters are the same!

One way is to use environment variables. Every federate can run in a different environment with the same RID. So just tell the RTI to read the environment variable when the RID is processed.

(setqb RTI_networkInterfaceAddr (getenv (quote RTI_NETWORK_IF)))

Or, for a numerical parameter rather than a string:

(setqb RTI_processingModel (string->number (getenv (quote RTI_PROC_MODEL))))

Or maybe you want a way to quickly enable logging for individual federates. Even better, you want to enable logging, but ensure that two federates in the same directory don’t try logging to the same file (a common problem). While we’re at it, let’s forget about putting the logs in the federate working directories: let’s have an environment variable for the log directory as well. Run each federate in a different environment (maybe from a script) with different settings for an environment variable called RTI_LOG. You can set the RTI_LOG_DIR environment variable a global one, shared by all federates on the machine, or you can tailor it for individual federates as well. Then just set the following in your RID:

(setq logFile (getenv (quote RTI_LOG)))

(setq logDir (getenv (quote RTI_LOG_DIR)))

(if (not (null? logFile))

(sequence (setqb RTI_logFileName (string-append logDir logFile))

  (setqb RTI_notifyLevel 3)))

That will turn the notify level up to verbose and enable logging to the filename of your choice, in the directory of your choice, but only if you set RTI_LOG. Otherwise the notify level stays at the default and no log file is generated.

We could also revise our example from the last post in this series. Rather than having siteConfiguration be a RID parameter that needs to be updated when you want to run with another site, make it an environment variable.

(setq siteConfiguration (getenv (quote SITE_CONFIGURATION)))

These are just a few examples, but I think you get the idea. You can do a lot more in RID files than just simple setqb statements.