Output of bootstrap analysis

[Lars Chatrou]

Dear RAxML users,

I'm a little confused about the output of a RAxML standard bootstrap analysis that I ran on CIPRES.

The output produces ten files with the names RAxML_bootstrap.result.PID.X, where X is between 0 and 9. These files contain trees in Newick format. The majority rule consensus trees of each of the files differ slightly in the (bootstrap) percentages that they produce.

I don't really understand where these ten file come from. Looking into the STDOUT file, there is the following;

ibrun -n 10 --tpp 6 raxmlHPC-HYBRID -T 6 -M -n result -s infile -N 1000 -q part -c 25 -p 12345 -b 12345 -m GTRCAT -o Persea_americana_0484

I assume the ten PID files are resulting from the command "-ibrun -n 10". However, I cannot discover any button in my analysis settings that would have invoked this. 

Could anyone explain what the PID files are?

Thank you, best wishes,

Lars

[Andre J. Aberer]

Hi Lars,

ibrun -n 10 starts 10 MPI processes (each of these starts 6 threads).

Each of the MPI processes has its own output file that contains the
replicate trees computed by this specific process.

You can simply concatenate all 10 output files (e.g., using cat) and
continue with the result.

--
Best regards,
Andre

--
Sent with my mu4e

[Mark Miller]

Hi Lars,

What Andre said is certainly correct, however, the persistence of these ten files at the end of the run is the hallmark of a job that was interrupted before it completed.

Usually it means the job reached its maximum configured wall time before the run was done. Look at the CIPRES file: scheduler_stderr.txt and look for a message that you have reached the maximum wall time.

If it's there, clone the job, open the parameter pane, and increase the amount of time your job may run for. If there is not such message, you can contact me directly, through the cipres bug tracker, or the cipres google group,

send me the contents of the file _jobinfo.txt, and we can sort out the issue.

Best,

Mark

[Lars Chatrou]

Hi Andre and Mark,

Thanks very much for your quick responses. You're right, Mark, there's a message saying that wall time has exceeded the limit. I'll run the analysis longer.

Best wishes,

Lars

Op vrijdag 19 september 2014 13:45:12 UTC+2 schreef Lars Chatrou: