You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The raxml-ng docs describes the --nofiles action as do not create any output files, print results to the terminal only
However, the results printed to the terminal seem to be only the model parameters, as usual, but not any additional information that is normally written to files, such as the trees. Would it be possible to have this option also print the contents of .bestTree to the terminal? Or to have some option to do this?
In terms of a use case for this, I suspect that when I'm parallelizing hundreds of small raxml runs at the same time it is likely being slowed by I/O limits from writing so many tiny tmp files simultaneously. This could be alleviated somewhat by capturing the trees from STDOUT.
Thanks
The text was updated successfully, but these errors were encountered:
I guess what you need is --nofiles interim option:
NOTE: You can suppress generation of all intermediate files (excl. checkpoints) with the --nofiles interim switch. Typically, the overhead of writing the intermediate files in negligible, but under certain conditions (lots of small trees, many coarse-parallel searches) disabling it can accelerate inference by a few percent.
Hi Team,
The raxml-ng docs describes the
--nofiles
action asdo not create any output files, print results to the terminal only
However, the results printed to the terminal seem to be only the model parameters, as usual, but not any additional information that is normally written to files, such as the trees. Would it be possible to have this option also print the contents of
.bestTree
to the terminal? Or to have some option to do this?In terms of a use case for this, I suspect that when I'm parallelizing hundreds of small raxml runs at the same time it is likely being slowed by I/O limits from writing so many tiny tmp files simultaneously. This could be alleviated somewhat by capturing the trees from STDOUT.
Thanks
The text was updated successfully, but these errors were encountered: