Arquivos de resultado

Depois de uma execução, você pode listar e baixar os arquivos produzidos: logs, relatórios dos modelos e resultados para análise. Na API, cada arquivo é um Artifact, identificado por artifact_id. Para ver os resultados em gráficos no Portal, use Resultados do estudo.

Para baixar um resultado, siga três passos:

1. liste os arquivos da execução;
2. escolha o arquivo pelo logical_name (nome) ou pelo semantic_type (tipo);
3. baixe pelo artifact_id.

Todas as rotas desta página exigem executions:read. A autenticação está na visão geral da API.

Listar

curl -sS "$MYRIA_API/api/v1/executions/$EXECUTION_ID/artifacts" \
  -H "Authorization: Bearer $MYRIA_TOKEN"

A listagem reúne a versão mais recente de cada arquivo, com paginação por cursor. GET /executions/{execution_id}/artifacts/{artifact_id} devolve um arquivo só. Cada item informa:

Campo	Significado
artifact_id	Identificador para consultar e baixar o arquivo.
logical_name	Nome do arquivo, como deckoutput.json ou PDO_CMOSIST.DAT.
semantic_type	Tipo de conteúdo, para o seu sistema escolher o arquivo.
media_type	Tipo MIME, como application/json ou text/plain.
size_bytes	Tamanho em bytes.
sha256	Hash para conferir o arquivo depois do download.
availability	available, expired (prazo de retenção encerrado), missing (não encontrado) ou quarantined (isolado por falhar numa verificação de integridade).
download_url	Endereço de download; null quando o arquivo não está disponível.
expires_at	Fim previsto da retenção.
execution_id, leg_id, round_key, attempt_id	De qual execução, etapa, rodada e tentativa veio o arquivo.
manifest_id, revision, outputs_commit_sha	Histórico da coleta, para auditoria. Não são necessários para um download comum.

Para missing, size_bytes, sha256 e outputs_commit_sha podem vir nulos.

Baixar

curl -sS -f -o resultado.bin \
  "$MYRIA_API/api/v1/executions/$EXECUTION_ID/artifacts/$ARTIFACT_ID/download" \
  -H "Authorization: Bearer $MYRIA_TOKEN"

O download não redireciona e nunca expõe repositório, caminho ou ref internos. A resposta é uma destas:

HTTP	Significado
200	Os bytes do arquivo. Content-Disposition traz o logical_name, Content-Length o tamanho e ETag o SHA-256.
409	O arquivo não está disponível: artifact_unavailable (ausente ou isolado), artifact_missing (não encontrado no armazenamento) ou artifact_integrity_mismatch (tamanho ou hash diferente do registrado).
410	artifact_expired: o prazo de retenção terminou. Os metadados continuam disponíveis.
503	artifact_storage_unavailable: o armazenamento não respondeu. Tente de novo mais tarde.

Arquivos armazenados em Git LFS são materializados antes da conferência; o download entrega o conteúdo do resultado. Antes de entregar o arquivo, o Myria confere tamanho e SHA-256 com o registro da coleta. Um arquivo que falha nessa conferência passa a quarantined e deixa de ser servido.

Conjuntos de resultados (Manifest)

Um Manifest é a lista fechada dos arquivos coletados numa tentativa de uma rodada. Na maioria das integrações, você não precisa dele: a listagem de /artifacts já traz a versão mais recente de cada arquivo.

O histórico serve quando uma coleta posterior encontrou um arquivo que antes faltava, quando houve processamento depois do fim da execução ou quando você precisa auditar o que estava disponível numa coleta anterior.

curl -sS "$MYRIA_API/api/v1/executions/$EXECUTION_ID/artifact-manifests" \
  -H "Authorization: Bearer $MYRIA_TOKEN"

Cada coleta traz manifest_id, execution_id, leg_id, round_key, attempt_id, revision, sealed: true, artifact_count e created_at. A listagem de manifestos não embute artefatos. Para ver os arquivos de uma coleta:

curl -sS \
  "$MYRIA_API/api/v1/executions/$EXECUTION_ID/artifact-manifests/$MANIFEST_ID/artifacts" \
  -H "Authorization: Bearer $MYRIA_TOKEN"

Uma coleta fechada nunca muda. Se novos arquivos aparecerem, o Myria cria outra revisão, com novos manifest_id e artifact_id; a anterior continua consultável. Uma coleta pode ter artifact_count: 0 quando a execução falhou ou foi parada antes de produzir arquivos.

Arquivos incompletos e novas coletas

Enquanto os resultados são coletados, a rodada continua em running, mesmo que o modelo já tenha terminado. Uma falha temporária nessa etapa repete a coleta sem executar o modelo de novo.

A execução só termina com sucesso quando os resultados obrigatórios foram coletados e conferidos. Se faltar um arquivo obrigatório, a execução pode ir para attention_required e emitir o evento execution.attention_required. Uma coleta posterior pode completar os arquivos sem executar o modelo de novo.

Uma execução parada guarda os resultados já produzidos, então pode ter um conjunto parcial de arquivos, ou nenhum, se ainda não tinha começado.

Se o DESSEM falhar antes de produzir resultados, os recibos do processo e o diagnóstico do erro podem aparecer na listagem de arquivos. Essa coleta registra a falha; os diagnósticos não são resultados do modelo nem permitem executar o dia seguinte como se a rodada tivesse concluído.

deckoutput.json e earm_control_report.json são arquivos derivados e opcionais. Se um deles não puder ser gerado, a coleta o registra com availability: missing, sem bloquear os demais arquivos nem o fim da execução.

Conteúdo por modelo

NEWAVE e DECOMP. deckoutput.json traz os dados de saída do DECOMP numa árvore JSON. Quando a rodada usa ajuste de EARM, earm_control_report.json registra o ajuste aplicado, a EARM de referência do modelo e os hashes das fontes usadas; leia o campo schema_version do relatório para interpretar o conteúdo.

Os relatórios deck_rules/preflight_report.json e deck_rules/post_roll_report.json descrevem as alterações feitas pelos Cards. Neles, cada diferença aponta para a sua origem por provenance_ref: N, que é a posição (a partir de zero) em report.provenance_table.

DESSEM de preço. A coleta publica os arquivos de saída do formato de resultados da CCEE, como DES_LOG_RELATO.DAT, PDO_CMOSIST.DAT, PDO_SIST.DAT, PDO_SUMAOPER.DAT e PDO_OPERACAO.DAT. A falta de um deles impede concluir a coleta. O estado horário PDO_OPER_R11_HORARIO.DAT, quando produzido, também é publicado com integridade e classificado como dessem_state. Ele permite reconstruir COTASR11 no dia seguinte; uma rolagem que precise desse estado continua bloqueada se ele estiver ausente ou inválido. PLD_CCEE_ITER.txt é opcional: quando o modelo o gera, ele é preservado; o Myria não o cria. O CMO vem de PDO_CMOSIST.DAT e não é o PLD regulado.

Arquivos de diagnóstico, como dessem.out, dessem.err, DES_LOG_MENSAGENS.DAT e dessem-recovery.json, ficam em _diagnostics/, entre os arquivos da tentativa. dessem-recovery.json registra cada tentativa de tratamento de inviabilidade: a restrição violada, o limite ou a taxa antes e depois do ajuste, unidades, períodos, os trechos dos relatórios usados como evidência e os hashes dos arquivos alterados. Conforme o tipo de restrição, inclui também o cadastro usado nas conversões de cota e volume, os componentes e fatores das restrições elétricas compostas, os conjuntos de máquinas e a geração por unidade, o balanço hídrico conferido nos déficits de retirada, a janela e os pesos dos limites por média diária ou semanal e o limite diário único de R11. Folgas da função de produção hidrelétrica aparecem como FPHA, com orientação para conferir cadastro, volume, turbinamento, vertimento e cortes. Também registra, conforme o caso, as janelas e endpoints das rampas pontuais T3, os componentes das composições de volume e cota, as projeções para períodos futuros (scope=projected_period), as provas de carga dos cortes de LPP e das tabelas TABSEG, a geração por unidade dos limites térmicos e o registro de reserva de potência alterado. Folgas mantidas sem ajuste aparecem em blocked com o motivo, por exemplo restricao_fisica_nao_flexibilizavel. Esses ajustes valem só para a execução e não alteram o deck no Git. Uma rodada que processou tudo mas não convergiu fica nonconverged: os resultados existem, mas não comprovam uma política viável. O número de tentativas é configurado na rodada.

Para LPP sobre RE, family=network_lpp e scope=single_lpp_cut_for_horizon indicam que o intercepto é compartilhado. reported_periods identifica a origem das folgas e affected_periods informa todo o alcance da mudança. lpp identifica a função, enquanto equation identifica a RE controlada, que também aparece no nome da violação nativa. A auditoria guarda uma mudança por corte com as provas de todos os períodos. cut_kind distingue o corte constante do afim de carga; slope registra o coeficiente preservado e parameter_evidence comprova a carga por período e por submercado, com os hashes das fontes e dos relatórios.

Para TABSEG sobre RE, family=electrical_table e scope=single_table_cell_for_horizon identificam um ajuste compartilhado de uma célula. table identifica a tabela e equation a RE controlada. reported_periods registra as folgas e affected_periods todos os períodos que selecionam essa célula. A prova inclui a carga DP, os relatórios de carga e tabela e a composição elétrica. Em period_evidence, load_evidence identifica a carga do submercado ou do SIN e registra cada componente, sua declaração, sua linha nativa e os hashes das fontes. Quando um limite LU mais restritivo explica a folga, o ajuste continua pertencendo à família de limites elétricos.

Para limites térmicos UT, family=thermal_limit, scope=reported_period e plant identificam o ajuste operacional. limit_kind distingue mínimo e máximo. A auditoria registra o limite nominal derivado da folga, a geração reconstruída, sua incerteza de impressão, os limites inferior e superior usados no arredondamento e as capacidades cadastrais. A ampliação do máximo é limitada pela capacidade comprovada. Os hashes de OPERUT, TERMDAT e RAMPAS comprovam a preservação dos dados físicos; as linhas UT mantêm seus demais campos e períodos.

Retenção

Os arquivos ficam disponíveis por 30 dias. Execuções em andamento e outras proteções podem adiar a expiração. Depois do prazo, metadados, manifestos e hashes continuam consultáveis, mas o download retorna 410 artifact_expired.

Folgas nativas INF_LIM_TERM e SUP_LIM_TERM aparecem como family=thermal_limit, com o período, a magnitude e a unidade originais. O diagnóstico orienta conferir o limite agregado da usina, a geração e o compromisso de cada unidade. Essa classificação não altera automaticamente os limites térmicos, a capacidade ou os estados de partida e parada; sem prova de uma flexibilização operacional válida, a folga permanece bloqueada.

Para LPP com vários cortes da mesma região, scope=piecewise_lpp_cuts_for_horizon indica a prova conjunta do envelope. cut identifica cada corte alterado e envelope_evidence registra o corte ativo, todos os limites por período e a reconstrução pela folga final. Cada intercepto tem seu antes/depois; os coeficientes permanecem preservados.

Para regiões LPP selecionadas pela carga, scope=regional_lpp_cuts_for_horizon, region e region_evidence identificam a região e sua seleção comprovada por período. affected_periods cobre somente os períodos que usam essa região; regiões sem ajuste são preservadas.

Recuperacao de coleta e publicacao

Se a coleta perder temporariamente a permissao de leitura ou a publicacao no Git ficar sem confirmacao, o sistema preserva a tentativa e os resultados remotos e retoma a publicacao com um numero limitado de novas tentativas. Antes de reenviar os arquivos, o sistema confere se o Git ja concluiu a publicacao, para evitar duplicacoes. Essa recuperacao nao executa novamente o modelo. Se o problema persistir alem do limite, a execucao exige atencao.

Os diagnósticos de resultados DECOMP usam referências ao deck, sem caminhos locais temporários. Repetir a coleta dos mesmos insumos e resultados conserva os bytes do arquivo analítico e permite retomar a publicação idempotente.

Se os resultados DECOMP ficarem temporariamente inacessíveis durante a verificação do término, o sistema repete a verificação antes de classificar a execução. A falta de acesso aos arquivos não significa falha do modelo.