Generating executable simulations with OPNET (and why)

First of all, why generating OPNET static executables? There are a lot of possible reasons, first of all for distributing simulations, but in my experience the most interesting one is that you can run memory debuggers (such as valgrind) or debuggers such as gdb against static OPNET executables, thus easily spotting many common bugs.
These notes refer to OPNET version 11.5 (I still have to upgrade to the latest version), on linux.

The procedure:

1. open the scenario you want to compile
2. click on "run simulation", this will open the simulation dialog, click on "simulation set info"
3. here you will find the command opnet will execute to launch your simulations (something like op_runsim ...) - copy it, paste it in a text editor, delete all carriage returns so that it is on a single line
4. in the command, substitute the word op_runsim with op_mksim
5. open a shell (bash in linux, cmd in windows), go to your project's directory, and execute the command you obtained (to give an example, op_mksim -opnet_user_home . -net_name sample -noprompt -kernel_type development could be such a command)
   
6. opnet will start compiling and linking your simulations, in the last lines of output it will tell you the name of the produced executable (e.g., something like op_mksim: Simulation (./op_models/sample.dev32.i1.sim) Produced)
   
7. to execute it, substitute its name to "op_mksim" and start the simulation (example: ./op_models/sample.dev32.i1.sim -opnet_user_home . -net_name sample -noprompt -ef sample)
   

Everything should go fine. In my case, the executable complains and I have to add the option "-opnet_dir /opt/opnet", although it shouldn't be as this variable is set in my opnet preferences. If you have the same problem, substitute /opt/opnet with your opnet installation path.
Next time I'll also show some example of how to use valgrind against opnet executables, although that is quite straightforward.

Script: monitoring processes on multiple hosts

Today I'm posting a simple script, very useful when you have multiple machines accessible via ssh and you want to know if these machines are busy, and what are the most CPU-intensive processes at a given moment.

Simply set the variable $HOSTS_TO_MONITOR to the list of hosts you want to monitor, this way:

export HOSTS_TO_MONITOR="host1 host2 host3 host4"

and call the script.

The script uses ssh to log into each host. I strongly suggest you to use password-less authentication for this purpose, so that you don't have to type the password for any given host.

Download the script from here