Let's suppose you want to automatize your process of report generation in EnSight. You will do the analysis operations interactively, generate a report, and export the commands that correspond to these steps. For the report generation section, you will get something like:
In this particular example, we are assume that you are setting a new database in the D:/tmp directory.
What these lines are doing is: create a new database in D:/tmp, start a Nexus instance on it, set the default username and password, and finally generate the report by pushing the items created by the sources (in the states) onto the database.
If you now want to repeat the same operation for multiple datasets, you will run the same script against all your datasets. You probably will want to change the D:/tmp directory for each dataset, so that the report items do not overwrite each other.
As long as you run the analysis one after the other (i.e.: first dataset A, then once it's done dataset B, then dataset C, and so on), this will work fine. But if you want to parallelize your postprocessing, you might want to run the script on all the datasets at the same time. You will therefore have dataset A being analyzed at the same time as dataset B and dataset C, with the reports being created at the same time.
This can create some problems. Indeed if you try this approach, you might see that the items generated for the report end up in the wrong database. This is due to the fact that you have left in the command to launch the report server the default:
With this setting, EnSight will query the OS for an open, free port, starting with port 8000. If the OS responds that that port is open, EnSight will launch the Nexus server needed for the report on that port. Unfortunately, there is a time delay between when EnSight first asks the OS for the status of the port, and when the Nexus instance is actually launched. During this time window, the port is not locked down, meaning that it's possible that an other EnSight instance might ask the OS for the status of the same port, and get as answer "open and free" before the first instance manages to launch Nexus on it. Therefore, it is possible that you end up having multiple Nexus instances running on the same port, which will result in confusion (when EnSight generates report items, they end up in a random database between the ones for all the Nexus servers on the same port).
This will happen only if you have multiple sessions of EnSigh trying to generate a report at the same time, each one on a different report server. This is not the most efficient way or running the report structure of EnSight (in this situation, we envision that the user would have one centralized Nexus instance, where all the reports would go to), but it still is a possible configuration. Luckily, there is an easy fix for this. You can manually change the port number to hard-code a specific port, making sure it's different for each EnSight session you run. So, your new script for dataset A will contain something like
to force the usage of port 8000, while for dataset B you might have the following line:
that will force the report to run on port 8001. This will avoid the conflict.