por que este processo paralelo não grava a saída nos arquivos, mas sim a impressão no console?

1

Isenção de responsabilidade: Esta é uma pergunta mais geral sobre a pergunta que fiz no site biostars.org sobre o assunto e escrever para arquivo.

Quando executo um programa ( obisplit do obitools package ) sequencialmente, ele lê um arquivo e cria um número de arquivos com base em algum critério (não importante aqui) no arquivo original:

input_file.fastq
     |____ output_01.fastq
     |____ output_02.fastq
     |____ output_03.fastq

No entanto, quando eu dividir o arquivo de entrada e executá-los em paralelo (versão do repositório do ubuntu: 20141022),

find . * | grep -P "^input_file" | parallel -j+3 obisplit -p output_{/.}_ -t variable_to_split_on {/}

Espero obter arquivos

input_file_a.fastq
     |____ output_input_file_a_01.fastq
     |____ output_input_file_a_02.fastq
     |____ output_input_file_a_03.fastq
input_file_b.fastq
     |____ output_input_file_b_01.fastq
     |____ output_input_file_b_02.fastq
     |____ output_input_file_b_03.fastq
input_file_c.fastq
     |____ output_input_file_c_01.fastq
     |____ output_input_file_c_02.fastq
     |____ output_input_file_c_03.fastq

mas a saída é impressa apenas no console.

Existe algo inerente em parallel que faz com que essa impressão seja consolada ou pode ser a maneira como o obisplit está se comportando por algum motivo? Existe uma maneira de convencer cada núcleo comandado por parallel a imprimir em um arquivo específico em vez do console?

    
por Roman Luštrik 25.05.2017 / 13:16

1 resposta

1

Soa como se obisplit se comportasse de maneira diferente se a saída fosse redirecionada.

Você pode pedir ao GNU Parallel para enviar para arquivos:

seq 10 | parallel --results output_{} echo this is input {} >/dev/null

(ou se sua versão for mais antiga:

seq 10 | parallel echo this is input {} '>' output_{}

Ele criará output_# , output_#.err , output_#.seq .

    
por 26.05.2017 / 00:37