Some kind of id for run instances

[jimboid]

When working on the domain specific side (ie in the launcher method) it might be helpful if there is some sort of instance identifier passed in that we could use for generating files with names that match a parameter sweep instance.

This could in future also be used in the results processing so that the returned information can be tagged against the correct set of parameters (I'm just thinking about passing data around here). Basically this is probably more about readability so one doesn't have to go digging around in input/log files to find the one they might be interested in.

Further down the line if things such as asynchronous execution and perhaps even a pretty front end become a desired feature then these id's will form a decent basis for keeping data together.

I have implemented a kinda rough way of doing this in the gromacs example where I simply generate a random string of numbers as and identifier which I then tack onto file names (to retain raw outputs, as in some programs useful hints come out in the logs) I then append this id back into the results data which I guess can then be used downstream in any results processing.

The problem with the method I have implemented is that there is an off chance that the same random string gets generated twice thus overwriting a set of files, I could prevent this with more checking and further regens. But my feeling is that this is cumbersome to code with lots of reinventing the same wheel when we could provide this through melody itself.

Would this be a massive change? Does this make sense?

[rupertford]

yes this should be relatively easy to do. One question I have is whether a particular type of key would be useful. The two obvious options are 1) an integer 2) a unique id string from uuid, unless you can think of an alternative.

[jimboid]

I suppose it doesn't really matter as long as it is unique. It might be easier to simply pass an integer that corresponds to the index a particular instance is in the list, you can't currently get at this from the launch method.

I can't see a need for including specific information like uuid's or even if any particular ordering is required, possibly just being unique is the only thing that matters so guess it doesn't matter how this really happens inside melody core.

Might be worth running this by @arporter see if he can see a situation where information such as uuid might be helpful in his implementation.

[rupertford]

I could pass list indices but in this case there would be one for each parameter, so for 3 parameters you would get [0, 0, 0], [0, 0, 1] etc. (in some agreed structure).

[rupertford]

Or, I could create an internal counter of course.

[arporter]

I think an internal counter would be fine. I can't see any need for anything more complex than that at the moment. If some need does arise in the future then it should be a simple change. Maybe we should pass in a 'label' (i.e. a string) rather than an integer identifier to facilitate any future changes.

[jimboid]

Yes, I think that is probably the best way to do it (with a string). It should give the most flexibility should further needs arise with other applications.

[rupertford]

OK, we're coming to a consensus. Unless there are any objections I'll go with strings "1", "2" etc but these are just unique identifiers and the values could change in the future e.g. we might decide to go with a uuid(), so user code should not attach any meaning to the strings. I'll make this clear in the documentation that is ... err ... coming.