Demostrar que el tamaño del paso del tiempo es lo suficientemente pequeño en un código con selección automática del tamaño del paso

Recientemente heredé un gran cuerpo de código heredado que resuelve un problema muy rígido y transitorio. Me gustaría demostrar que los tamaños de paso espacial y temporal son lo suficientemente pequeños como para que la naturaleza cualitativa de la solución calculada no cambie si se redujeran. En otras palabras, me gustaría mostrar que la solución está "convergida" en un sentido cualitativo. Como puedo establecer explícitamente el tamaño de la malla espacial, esa parte es sencilla. Sin embargo, como el código usa el control automático del tamaño del paso de tiempo, no puedo establecer el tamaño del paso de tiempo directamente.

El algoritmo cambia el paso de tiempo entre dos límites en función del número de iteraciones jacobianas necesarias para alcanzar una tolerancia de error durante los últimos pasos de tiempo. El hecho de que use la iteración jacobiana me hace estar bastante seguro de que es algún tipo de esquema implícito, pero no puedo estar absolutamente seguro. No tiene en cuenta el error que está viendo en el paso de tiempo actual, lo que ocasiona que se encuentre con el límite de iteración en ocasiones (tal vez una docena de veces en el transcurso de varios miles de pasos de tiempo, casi siempre durante las partes más dinámicas del simulación). Las ejecuciones actuales que estoy completando estoy estableciendo los límites de tiempo en dos órdenes de magnitud y media ( a ). 10 - 13 5 ⋅ 10 - $n$$10^{-13}$$5 \cdot 10^{-11}$

En las corridas, tengo control sobre los límites de los pasos de tiempo, el número de pasos de tiempo pasados ​​que mira para elegir el paso de tiempo actual, el cambio máximo en el paso de tiempo (proporciones), el número objetivo de iteraciones jacobianas, el número máximo de iteraciones, y el error vinculado. Me gustaría que alguien me pusiera en el camino correcto para analizar la independencia del paso del tiempo, o al menos averiguar qué algoritmo se utiliza.

El propósito de la estimación automática de errores y el control del tamaño del paso es liberarlo del problema de determinar manualmente qué es un tamaño de paso suficientemente pequeño. Entonces su pregunta es un poco como preguntar "alguien me dio este auto de transmisión automática; ¿cómo puedo saber en qué equipo estoy?" El punto es que no deberías saberlo. Por supuesto, si la transmisión es defectuosa, es posible que deba desmontarla y arreglarla, pero ese es un problema mucho mayor.

En su caso, generalmente el enfoque correcto es determinar qué tipo de error es aceptable e imponerlo a través del control automático del tamaño del paso. Es imperfecto porque el control de errores en este sentido generalmente es solo control de errores local , por lo que no controla directamente el error global, que es lo que probablemente le interese.

Una cosa que podría hacer fácilmente si tiene dudas es ejecutar la simulación con una secuencia de tolerancias de error cada vez más estrictas (es decir, pequeñas). Una vez que la solución parece insensible (sea cual sea su métrica) para disminuir la tolerancia, puede detenerse.

Anexo : Con respecto a la cuestión del límite máximo de iteración alcanzado (que conduce a un error local que excede la tolerancia especificada), sugiero lo siguiente.

Aparentemente, el código piensa que si excede el número máximo de iteraciones, lo correcto es aceptar el paso. Yo diría que eso es lo incorrecto. Un mejor enfoque es rechazar el paso y comenzar ese paso nuevamente con un tamaño de paso reducido. Por supuesto, existe el peligro de que el escalón se reduzca por debajo del tamaño mínimo del escalón. En ese caso, lo correcto es abortar la simulación. Pero si cree que una solución incorrecta es mejor que ninguna, puede aceptar el paso y continuar si se cumplen ambas condiciones: se alcanza el tamaño mínimo del paso y se excede el número máximo de iteraciones.

En un código bien diseñado, hacer este tipo de cambios es trivial, pero en un código arbitrario puede ser arbitrariamente difícil.