Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Scripts: New -continue implementation #713
As first mentioned in #672.
The current implementation of the
It may now be possible to provide a more robust solution:
Another little thing that could be added here would be to write the current MRtrix3 version to a text file in the temporary directory, and warn the user if the script is resumed with a mismatched version of MRtrix3.
It would be useful if
Yes, the fundamental assumption with the current implementation of
I presume by this that you mean overriding command-line options set in the initial execution of the script with new ones? I think that should be possible. It would however make comparison of command strings with the contents of the prior command log error-prone.
This could potentially be dealt with by introducing some sort of pause mechanism rather than splitting up scripts? In the case of running on an HPC, the pause would instead disable cleanup and terminate, with the second half being triggered using the continue mechanism. The disadvantage of the continue mechanism (both current and future) is that it's only based on
I don't quite see how checking the results of the first half would then cause you to change parameter options that only influence the second half...?
That should be fine if no python command overwrites a file and if we resort to repeating the last successful runCommand() to make sure the following python code is also rerun.
If one wants to only run the linear registration to check the output or manually overwrite a linear transformation file that could be done with i.e.
It would work if the parameter affects only runCommand(): Just continue at the first runCommand() with the updated parameter that does not match the log. But you are right, I did not think of the case where the parameter change affects the python code that might be well before the last matching runCommand(). This could be solved by adding lines to the log that indicate independent sections of the script and re-running everything since the last unaffected section. Not sure if it is worth the trouble, though.