Pesquisa, ferramentas e a verificação dos nossos testes

Nos últimos dias adicionamos Stabileo Research e Stabileo Tools e reforçamos suas verificações. Stabileo é software gratuito e de código aberto para engenharia estrutural com IA, publicado pelo Ergodic Group. LambdaClass é seu braço de desenvolvimento.

Pesquisa que você pode executar

Estamos trazendo artigos publicados de engenharia estrutural e benchmarks clássicos ao navegador, com o visualizador do Stabileo. Cada página informa o que reproduz, como verificamos os resultados e os limites da comparação. Estamos concluindo as páginas que ainda mostram comparações pendentes.

As páginas de artigos disponíveis cobrem fratura por campo de fase de Shauer (2025); redes de molas de Grossman e Boudaoud (2026); otimização topológica de Andreassen et al. (2011); estabilidade do pórtico de Roorda de Ferrari e Sigmund (2025); busca de forma de redes de cabos de Pastrana et al. (2026); arcos com salto de Zmyślony, Khan e Biggins (2026); e cascas reticuladas de Fairclough et al. (2026).

Os clássicos do motor são MacNeal–Harder, o circuito de testes de cascas, a elástica de Mattiasson, Riks/Crisfield, Newmark, CQC, colapso plástico, a placa de Navier, o pórtico de Lee e o arco de DaDeppo–Schmidt. As páginas distinguem cálculo ao vivo de reprodução de resultados gravados e mostram os limites da comparação. A comparação de Koiter de Ferrari está incompleta; Fairclough cobre um exemplo de cinco nós; o salto de equilíbrio do arco não é uma simulação transiente.

Publicamos o escopo e as evidências e os revisamos abertamente. Resultados de pesquisa não são resultados de projeto, e concordância com um benchmark não é certificação.

Os testes também precisam ser verificados

Algumas páginas estavam erradas porque nossos modelos de teste estavam errados. Cada página de benchmark do motor e seu teste de CI agora leem o mesmo arquivo de caso, de modo que corrigir o modelo atualiza ambos. Algumas comparações provisórias continuam explicitamente ignoradas na CI e ainda não bloqueiam integrações; estamos concluindo essas comparações.

Corrigimos as referências de Mattiasson e o tratamento do alongamento axial (#845), um pórtico de nós rígidos comparado com uma fórmula de treliça puramente axial (#846) e modelos incorretos de apoios e cargas em cascas (#810). Estamos mudando como os benchmarks são construídos para que essa classe de erro não volte a passar. A primeira parte já está incorporada: cada benchmark é uma especificação com duas referências independentes que devem concordar e verificações automáticas de carga aplicada, equilíbrio das reações e simetria, incluindo comparações entre meio modelo e modelo completo. Estamos adicionando convergência em três ou mais malhas, um teste com erro de sinal que comprova que cada benchmark pode falhar e a aprovação de um engenheiro para o conjunto principal.

Também estamos incorporando unidades ao sistema de tipos (#864), para detectar confusões entre kN/N ou m/mm na compilação. A primeira parte, para o caminho de materiais e seções dos pórticos 2D, foi integrada em 3 de novembro.

Segunda rodada: todas as páginas revisadas de novo

Depois, cada página de pesquisa publicada passou por uma segunda revisão, feita por três modelos de IA em sequência (Kimi, depois Codex, depois Claude), e cada achado que conseguimos verificar foi corrigido. Quinze páginas foram revisadas juntas e publicadas em 4 de novembro (#1068): seis artigos (Shauer, Pastrana, Ferrari, Zmyślony, Grossman e Fairclough) e nove benchmarks do motor (Newmark, Riks/Crisfield, Navier, Lee, MacNeal–Harder, DaDeppo–Schmidt, o exemplo de colapso plástico segundo Horne, SRSS/CQC e Mattiasson, que teve uma terceira rodada). Nenhuma tolerância foi afrouxada e nenhum teste foi removido. A revisão por engenheiros em atividade ainda está por vir.

• MacNeal–Harder comparava valores absolutos, então um resultado com o sinal errado teria passado. As referências agora trazem seu sinal, e um teste rejeita uma resposta invertida em todos os casos.
• Riks/Crisfield podia informar um ponto limite sem queda de carga. Agora um ponto limite exige uma queda entre passos convergidos; a página diz que o cálculo passa pelo ponto limite superior em vez de “traces the snap-through”, e suas tolerâncias foram de 5 % para valores entre 5e-3 e 1e-5.
• Navier explicava o erro do MITC4 em vez de medi-lo. Agora ele é comparado com uma série de Reissner–Mindlin independente, e o erro do MITC4 com apoio simples duro cai de −1,951 % em 4×4 para −0,036 % em 32×32, com convergência de segunda ordem.
• As páginas dizem com o que são comparadas. Newmark é verificado contra soluções exatas em forma fechada, não contra “the author’s code”; SRSS/CQC é uma ilustração do método, não uma reprodução do edifício do artigo; os limites de colapso plástico são deduções nossas feitas à mão, não uma citação; a referência de 1,83 kN do pórtico de Lee é uma leitura de uma figura publicada, por isso só afirmamos diferenças em porcentagens inteiras.

Em celulares e tablets

Pelo que medimos no site publicado, as páginas de pesquisa não transbordavam num celular, mas o experimento ficava abaixo do artigo inteiro, o visualizador ficava apertado (356×189 px para uma placa quadrada) e cada página tinha de 25 a 40 controles com menos de 32 px e de 14 a 20 trechos de texto com menos de 12 px. Agora o experimento vem logo depois do título, o visualizador é dimensionado conforme o modelo, os controles têm pelo menos 44 px e o texto pelo menos 12 px (#831).

Uma verificação permanente renderiza a galeria e cada página executável em 360, 390, 844×390 e 810 px, em espanhol, inglês e português, e falha com transbordamento horizontal, controles pequenos, texto pequeno ou um visualizador ausente, pequeno demais ou baixo demais na página. Suas primeiras execuções encontraram erros reais, e os layouts foram corrigidos, não a verificação: o visualizador de Mattiasson tinha 187 px de altura com o celular na horizontal e agora tem 280 px, e um gráfico de convergência mostrava seus rótulos com 9 px. Um teste de refluxo descobriu que as abas de Shauer transbordavam em português e em turco com 360 px.

Oito calculadoras, com acesso ao editor

Stabileo Tools tem calculadoras gratuitas para vigas biapoiadas, balanços, flambagem elástica de pilares, vigas contínuas, pórticos de um vão, treliças planas, linhas de influência de cargas móveis e frequências de flexão de vigas. Usam o motor de produção, mostram comparações clássicas independentes e declaram suas hipóteses. Cada uma abre seu modelo no editor completo. São ferramentas de análise, não verificações normativas completas.

Conter resultados errados

Estamos contendo todos os problemas conhecidos de resultados incorretos: as recusas ou os avisos do motor incluem o identificador do problema, em vez de retornar um número sem verificação (#807, integrado em 5 de novembro). Cada recusa é testada, incluindo modelos dinâmicos não suportados com excentricidades de barras ou cascas.

Os testes metamórficos revelaram erros de invariância: modelos equivalentes podiam ser recusados após rotação, espelhamento ou mudança de escala das unidades. Agora executamos a suíte metamórfica a cada alteração para detectar essas regressões. Estamos adicionando uma execução noturna de modelos aleatórios que agrupa os achados por causa raiz e abre uma issue por causa raiz.

Desde então: de 1 a 3 de novembro

• O modo de análise do PRO está concluído. Corrigimos resultados que estavam errados sem nenhum aviso: o gerador de cargas não carrega mais os beirais de um galpão como se fossem um piso, e o peso sísmico de cada nível agora inclui as lajes e paredes desenhadas como cascas, que ficavam de fora (#1076).
• As exportações funcionam em edifícios reais. As planilhas grandes do Excel são escritas linha por linha, e o memorial de um edifício de seis andares leva cerca de dez segundos em vez de quatro minutos. “Verificar um relatório exportado” agora compara os números impressos, não só as impressões digitais (#1076).
• O PRO ganhou ajuda em linha que pode ser desligada, um estado de salvamento no cabeçalho, um memorial depois da análise, resultados de placas e um visualizador somente leitura para modelos compartilhados com “Duplicar e editar” (#1077, #1078).
• Um fator de flambagem acima do seu limite superior certificado de forma independente agora é recusado, em 2D e em 3D (#817, versão de resultados 6). Refaça a certificação antes de confiar num certificado de flambagem anterior.
• Links compartilhados com números não finitos, ou com barras, apoios ou cargas que apontam para algo inexistente, são recusados em vez de abertos (#1058).
• A suíte de invariância agora verifica seis análises prioritárias sob rotação, espelhamento e superposição, e quatro delas sob escala uniforme da rigidez (#1060).

Verificações que respondem em vinte minutos

Antes de chegar à main, toda alteração no Stabileo passa pelas verificações que pode afetar, e uma alteração no motor passa por todas: testes do motor, testes unitários da web, builds de produção, testes de ponta a ponta num navegador, os snapshots de resultados e a verificação de determinismo. Uma correção de um resultado errado não chega mais rápido do que essas verificações, por isso em 4 de novembro trabalhamos na velocidade delas. Primeiro medimos. Numa execução limpa da fila de merge de 44 a 47 minutos, os testes do motor e os unitários terminavam de 8 a 15 minutos antes do fim, então adicionar mais deles em paralelo não teria ganhado nada. O tempo ia para compilar os pacotes de pesquisa um depois do outro e para o fragmento de ponta a ponta mais lento. Depois que esses ficaram mais curtos, o fragmento mais lento era lento por causa da preparação: numa execução, gastou 7,2 dos seus 16 minutos em testes e seis e meio baixando pacotes de navegadores de um espelho lento.

• Compilar uma vez, testar o que foi compilado. Os testes dos builds de produção faziam mais cinco builds próprios, quatro deles da mesma árvore que a CI tinha acabado de compilar; esses quatro agora leem aquele build (#1411). Cada build leva um selo de tudo a partir do que foi compilado, e um teste falha, nunca é pulado, se o selo não corresponder à árvore em que roda.
• Cache por entradas. Cada pacote de pesquisa é guardado em cache sob uma chave das suas próprias entradas, incluindo o motor que todo pacote vincula, de modo que uma alteração num artigo recompila só esse artigo e uma alteração no motor recompila todos. Um pull request reutiliza os pacotes que a fila de merge já compilou a partir das mesmas entradas, depois de verificar cada arquivo contra seu checksum, e pode ler esse cache, mas nunca escrever nele (#1395). Os pacotes de navegadores também vêm de um cache, em vez do espelho (#1413).
• Executar só o que uma alteração pode afetar. Uma alteração na documentação não compila nada e termina em um ou dois minutos, em vez de uma execução completa. Uma alteração só no site pula os jobs do motor, mas mantém todos os fragmentos de ponta a ponta, porque 59 das 281 specs leem texto na tela (#1381). Na fila, o escopo de cada entrada é definido pelo seu próprio diff em relação à entrada à frente dela, o que é válido porque uma entrada só é integrada se todas as entradas à frente dela passaram; quando o diff está ausente ou não está claro, tudo é executado (#1400).
• Equilibrar o caminho mais lento. Os testes de ponta a ponta rodam em 14 fragmentos em vez de 10, equilibrados por tempos medidos (#1382). A tabela de tempos antiga previa 41,5 minutos de testes onde uma execução levou 69,8.

Uma verificação vermelha que não é culpa da alteração

Uma falha causada pela rede ou por uma máquina perdida é ruído, mas também é uma verificação vermelha que alguém precisa olhar, e o hábito de reexecutar verificações vermelhas é como uma falha real acaba sendo deixada passar. Por isso os jobs que falharam num pull request são reexecutados uma vez, automaticamente, só quando cada job que falhou traz evidência positiva de uma falha de infraestrutura: um timeout numa etapa de download, uma máquina de CI perdida no meio do trabalho, um erro de rede que encerra a última tentativa de um download (#1380). Qualquer coisa que pareça uma falha de teste em qualquer parte do log bloqueia a reexecução, assim como qualquer coisa que o classificador não reconheça. Isso a mantém conservadora: reexecuta no máximo uma vez e nunca depois de uma etapa de testes com falha. Não é uma garantia: uma falha intermitente que o classificador interprete mal como de infraestrutura poderia passar na reexecução, e por isso qualquer coisa que ele não reconheça bloqueia a reexecução.

Duas outras correções eliminaram alarmes falsos. Uma execução de pull request cancelada porque uma execução mais nova no mesmo commit a substituiu mostrava uma verificação obrigatória vermelha; agora ela pula essa verificação, mas só depois de confirmar que a execução mais nova existe e não falhou, porque uma verificação obrigatória pulada conta como aprovada (#1397). E um download travado podia deixar um processo segurando o lock do gerenciador de pacotes, então a nova tentativa falhava no lock e não no download; agora uma tentativa só conta como travada depois de minutos sem saída, é interrompida junto com tudo o que iniciou, e a nova tentativa espera pelo lock (#1408).

O que vem a seguir

Estamos concluindo as comparações pendentes e acelerando o site e o solver. Os próximos itens do roteiro são um pacote Python (pip install stabileo) e um manual público de verificação gerado a partir dos benchmarks.