Fix XML name for results output file

[stiber]

Right now, this is called "stateOutputFileName"; it should be something like "resultsFileName".

What is affected by this?

simulator

[stiber]

Depends on issue UWB-Biocomputing/BrainGrid#208

[stevecl5]

The configfiles in the Graphitti repo seem to use resultFileName for the tag name. They also appear to prepend the output path and append -out to the name of the results file. For example:

test-small.xml (config file) contains

<resultFileName name="resultFileName">../Output/Results/test-small-out.xml</resultFileName>

@stiber Do we want to use this same convention for Workbench (not necessarily with the same output path)? Also, do you have a preference between resultsFileName (from your comment) and resultFileName?

Edit: Upon reflection, using result (singular) is probably more clear. Specifically, it implies a one-to-one relationship between a simulation and a result (i.e. the results of many simulations vs. the result of a simulation).

[stiber]

I think we should come up with a Workbench directory structure for both the remote machine (well, machine on which the simulation runs, be it local or remote) and the local metadata directory structure (basically, all of the Workbench files, be they global or per-simulation). Let's have this drive the Graphitti result file location and naming). We can go over the investigator workflow with @king-shak, propose ideas, and decide on what we like best.

[king-shak]

I think we should come up with a Workbench directory structure for both the remote machine (well, machine on which the simulation runs, be it local or remote) and the local metadata directory structure (basically, all of the Workbench files, be they global or per-simulation). Let's have this drive the Graphitti result file location and naming). We can go over the investigator workflow with @king-shak, propose ideas, and decide on what we like best.

I agree! I was thinking of putting everything in the user's home directory. On Linux, user programs like Workbench are usually installed to /usr/local. The problem with storing anything else here is that you most likely are going to need to admin rights. This is why it is common for most applications to create their own folder in the users's home folder, where they can do whatever they want (usually named something like .ApplicationName, with the . in front so its hidden. e.g., you could have something like /home/user/.Workbench). Most users also have a .local folder in there home directory, with some or all of their application folders there (e.g. /home/user/.local/Workbench), the idea being to keep your home directory less cluttered, but either method works. Windows has something similar too (instead of .local its something among the lines of .ApplicationData).

Within there, you can have a directory for each simulation (or experiment...a project in Workbench only runs a single simulation, so that's something we need to work out). This way you would just have the user specify the name of the project, and leave it up to Workbench to figure out the rest.

[stevecl5]

Currently blocked due to stateOutputFileName being the required XML tag in BrainGrid. The tag is updated to resultFileName in Graphitti. This should be changed over to the new name when the other features of Workbench are able to work with Graphitti. Doing so will also make Workbench incompatible with BrainGrid unless it is updated to work with the new tag name.

[stiber]

OK, at some point, we will decide that it is time to switch Workbench from BrainGrid to Graphitti. There will be a number of mods needed at that point. I suppose the silver lining of the fact that WB isn't currently in active production use is that this won't break or orphan any critical work. We should generate a final BG-connected release before starting the switch.