Havia sido adicionado anteriormente em função de alguns erros para plotagem no WSL, porém traz muitas dependências, inclusive de Python. Deve ser retirado para manter o pacote julia puro e com o mínimo necessário de deps

O dicionário escrito por SDDP.write_cuts_to_file() inclui um termo chamado "intercept" que, em versões passadas, correspondia ao valor do corte na origem. Isto foi alterado para representar o valor de RHS, ou seja, o ponto em torno do qual o corte é construído, apesar de ter sido mantido o nome. O cálculo dos valores nos cortes foi realizado com a premissa de que este valor era de fato um intercepto e está, portanto, errado, devendo ser corrigido.

Poderia ser implementado para que fossem gerados cenários de demanda

Durante a construção do DataFrame de cortes é escrito um json temporário. Por algum motivo a execução em Windows dá erro nesse ponto pois o julia não possui permissões para apagar um arquivo que ele mesmo escreve na raiz do projeto.
Deve ser trocado para escrita num diretório temporário, sem tentar apagar

Com o uso do paralelismo nativo de Julia, poderia ser configurada a execução paralela (dentre vários modelos existentes para o SDDP), bem como execução em clusteres remotos.

Podem ser utilizadas as novas macros para otimizar a etapa de compilação automática do Julia, que foi melhorada na versão 1.9

Há uma confusão no idioma adotado para dados de entrada, módulos, variáveis e funções. Isto precisa ser uniformizado e padronizado.

A partir da release 1.9 de Julia, o PackageCompiler não tem gerado mais a imagem .so com sucesso.

Atualmente é possível cadastrar um número qualquer de UHEs no modelo, juntamente com as suas gerações de cenários. Todavia, não existe uma ligação entre elas, em termos de recurso hídrico.

Seria necessário incluir um parâmetro de cadastro de "usina a montante/jusante", com algum valor default para casos em que seja usina de início / fim de cascata

Ao executar o cálculo da política em um diretório onde já existe um conjunto de saídas, a execução resulta em erro devido a falta de permissões para sobrescrever arquivos já existentes.

Apesar de possuir modelagem de inflexibilidades, apenas uma UTE exisite no sistema, o que limita os estudos.

Como consequência de não existir mais de um ponto central de demanda, não é possível modelar os efeitos dos intercâmbios na operação

Hoje apenas é modelado um ponto central de demanda, que é atendido por todo o sistema. Isto poderia ser generalizado, inclusive incorporando um desacoplamento entre submercado e barra.

Atualmente assume-se que toda a entrada de dados já está em energia. Todavia, até para avliações futuras da produção de UHEs, seria interessante incorporar, por exemplo, conceitos como duração dos estágios e produtibilidade

Hoje, o config.json permite cadastra um dicionário de UHEs, indexados pelos nomes de cada uma, com um atributo index interno. Isto poderia ser revisto para uma lista com um atributo name.

Atualmente os arquivos de entrada para o programa são em número reduzido, e não são escaláveis para atender à modelagem completa do problema.

Este esquema poderia ser refatorado pensando em adotar uma configuração de entrada com uso de múltiplos arquivos, divididos por componente do programa ou do problema, que se referenciam (algoritmo, modelagem do sistema, cenários, etc.)

Atualmente os cortes de saída do modelo são salvos em alguns arquivos de saída: operacao_hidro.csv, operacao_termo.csv e operacao_sistema.csv, que localizam os cenários nas colunas, o que não é uma boa prática.

Além disso, os arquivos estão crescendo conforme são adicionadas novas variáveis de saída. A proposta é que seja dividida uma variável por arquivo. Por exemplo, para UHEs:

• gh.csv
• earm_inicial.csv
• earm_final.csv
• vert.csv
• ena.csv
• vagua.csv

Com formato, por exemplo:
estagio | cenario | UHE1 | UHE2 | ...

Para UTE:

• gt.csv

Com formato, por exemplo:
estagio | cenario | UTE1 | UTE2 | ...

Para o sistema (futuramente generalizado em submercados):

• deficit.csv
• cmo.csv

Com formato a definir.

Para a simulação como um todo:

• custo_presente.csv
• custo_futuro.csv
• custo_total.csv

Com formato, por exemplo:
estagio | cenario | custo

A leitura das ENAs considerava implicitamente que as UHEs das ENAs declaradas tinha a mesma ordem das UHEs cadastradas no config.json.

Atualmente os cortes de saída do modelo são salvos em um arquivo .csv, que incorpora tanto o estado quanto os coeficientes. Isto poderia ser melhor modelado, incorporando outras informações necessárias.

Antes de realizar uma primeira release do repositório é necessário documentar minimamente as funções, até mesmo pensando em disponibilizar documentação automática futuramente

Atualmente main.jl como script na raiz não pode ser acessado (facilmente) por usuários do pacote em outros ambientes de uso, como por exemplo repos satélite de estudos específicos utilizando o sddp-lab.