Então você usa o SWMM?
Hum, algumas notícias para você:
Ele também tem bugs. Então não confie totalmente.
Estou implementando o suporte a ele no SOLIDOS.
Até aí, você já sabia, né? Bom, acontece que o SOLIDOS exporta o arquivo INP e também lê o arquivo. Isso é meio que óbvio que deveria acontecer.
Acontece que a API do SWMM, ao menos o código fonte “padrão” dele, não tem tudo o que precisa. Então usei o programa SWMM padrão para criar algumas centenas de arquivos INP para entender o que ele escreve… Bem. Digamos que não é exatamente o que está na API. Enfim.
Aí começou a dar um erro besta durante o cálculo:
Ele “pensa” que a palavra YES deveria ser o nome de um nó???
Bem, vamos lá no código fonte descobrir do que se trada:
Aqui, na linha 110, o SWMM está tentando identificar qual a posição da palavra numa array de palavras, no caso, ele está lendo esta linha do INP:
A Array de palavras em questão, é:
Muito bem, na contagem, “NODESTATS” é de índice 7 enquanto que a palavra “NODE” é a de índice 5
findmatch(“NODE”, ReportWords), retorna 5. como esperado
findmatch(“NODESTATS”, ReportWords), retorna 5 também!!!
Qual a consequência disso?
Bem, talvez tu tenha reparado que se o INP estiver um pouco fora de ordem nas seções (aquelas palavras que tem []) , simplesmente não lê.
Talvez, tenha reparado que mesmo seguindo a API, o programa SWMM padrão não entende o seu arquivo INP
Adivinha porque…. porque ele confunde palavras parecidas!!!
No caso, NODESTATS é confundido com NODE, pois ambras começam com NODE………
Mano… isso é no mínimo PERIGOSO.
A função findmatch é usada várias vezes no código…. Já imaginou você ligar o nó “PV” ao tubo “tubo1” e então ligar o tubo ao “PV2” ? Vai que o SWMM use findmatch para comparar “PV” com “PV1″… durma com esse barulho….
Eu dei minha contribuição já algumas vezes, aqui: