I have been running some analysis using the
for_each command. The analysis seems to be running well put it has thrown “1 error.” Is there some log file where I can find some indication what the error was? Otherwise debugging is going to be a nightmare
Hello @cbajada ,
There’s a -nocleanup option that will save all the intermediate files inside the folder of your execution. I think we can also have error file inside that folder.
for_each script should print to the terminal both the
stderr contents of only those jobs that did not complete successfully. If that information has since been lost, it’s a little harder, particularly given that the
for_each script doesn’t actually generate a scratch directory with log files as many other MRtrix3 Python scripts do.
@Dave wrote a script specifically for this purpose called
notfound; it’s there in MRtrix3, it just doesn’t appear in the online documentation because it’s written in Bash and therefore doesn’t have the requisite API for automated documentation generation. I had however expected that it would lose its purpose entirely when I ported
for_each from Bash to Python, which enabled the escalation of error messages from invoked commands.
Instead you could probably derive from your original
for_each call something that would test for the presence of expected output files and yield an error just for the input for which the expected file is absent.
for_each doesn’t just work for executing MRtrix3 commands: you can specify anything, as the post-substitution command string gets sent to the shell.
I found out, eventually, that the for_each command prints to the terminal both the
stderr of jobs that did not complete successfully. Unfortunately, I had lots of jobs with very verbose errors so I lost some …
For the future, I’ll redirect the outputs to log files! It would be nice to automatically include some log files for debugging purposes.
I do love the for_each command. I used to use the previous bash version as my go-to for loop! It is more compact than the standard bash syntax, and simpler than gnu parallel.
I think I’ll still be doing the same with the python version as I move forward.