Demonstrando que o tamanho da etapa de tempo é pequeno o suficiente em um código com seleção automática de tamanho da etapa

Recentemente, herdei um grande corpo de código legado que resolve um problema muito rígido e transitório. Eu gostaria de demonstrar que os tamanhos de etapas espaciais e temporais são pequenos o suficiente para que a natureza qualitativa da solução computada não seja alterada se forem diminuídas. Em outras palavras, eu gostaria de mostrar que a solução é "convergida" em um sentido qualitativo. Como eu posso definir explicitamente o tamanho da malha espacial, essa parte é simples. No entanto, como o código usa o controle automático do tamanho do intervalo de tempo, não posso definir o tamanho do intervalo de tempo diretamente.

O algoritmo altera o intervalo de tempo entre dois limites, com base no número de iterações jacobianas necessárias para atingir uma tolerância a erros durante os últimos passos. O fato de usar iteração jacobiana me deixa bastante certo de que é algum tipo de esquema implícito, mas não posso estar absolutamente certo. Ele não leva em consideração o erro que está vendo na etapa de tempo atual, o que a leva a atingir o limite de iteração de vez em quando (talvez uma dúzia de vezes ao longo de vários milhares de etapas de tempo, quase sempre durante as partes mais dinâmicas do simulação). As corridas atuais que estou concluindo, estou definindo os limites do intervalo de tempo em duas ordens e meia de magnitude ( a ). $n$$10^{-13}$$5 \cdot 10^{-11}$

Nas corridas, eu tenho controle sobre os limites do intervalo de tempo, o número de intervalos de tempo passados ​​em que ele olha para escolher o intervalo de tempo atual, a alteração máxima no intervalo de tempo (proporções), o número alvo de iterações jacobianas, o número máximo de iterações e o erro associado. Eu gostaria que alguém pudesse me colocar no caminho certo para analisar a independência no tempo, ou pelo menos descobrir qual algoritmo é usado.

O objetivo da estimativa automática de erros e do controle do tamanho da etapa é libertá-lo do problema de determinar manualmente qual é a dimensão da etapa suficientemente pequena. Portanto, sua pergunta é como perguntar "alguém me deu esse carro de transmissão automática; como posso saber em que equipamento estou?" O ponto é que você não precisa saber. Obviamente, se a transmissão estiver com defeito, talvez seja necessário desmontá-la e corrigi-la, mas esse é um problema muito maior.

No seu caso, normalmente a abordagem correta é determinar que tipo de erro é aceitável e impor isso através do controle automático do tamanho da etapa. É imperfeito, porque o controle de erros, nesse sentido, geralmente é apenas o controle de erros local ; portanto, você não controla diretamente o erro global, o que provavelmente lhe interessa.

Uma coisa que você poderia facilmente fazer em caso de dúvida é executar a simulação com uma sequência de tolerâncias de erro cada vez mais rígidas (ou seja, pequenas). Quando a solução parecer insensível (independentemente da sua métrica) para diminuir a tolerância, você poderá parar.

Adendo : Quanto ao problema do limite máximo de iteração sendo atingido (o que leva a um erro local que excede a tolerância especificada), sugiro o seguinte.

Aparentemente, o código pensa que, se exceder o número máximo de iterações, a coisa certa a fazer é aceitar a etapa. Eu diria que é a coisa errada. Uma abordagem melhor é rejeitar a etapa e iniciá-la novamente com um tamanho reduzido. Obviamente, existe o risco de a etapa ser reduzida abaixo do tamanho mínimo da etapa. Nesse caso, a coisa certa é abortar a simulação. Mas se você acredita que uma solução errada é melhor do que nenhuma solução, você pode simplesmente aceitar a etapa e continuar se ambas as condições forem atendidas: o tamanho mínimo da etapa é atingido e o número máximo de iterações é excedido.

Em um código bem projetado, fazer esses tipos de alterações é trivial, mas em um código arbitrário pode ser arbitrariamente difícil.