Selección del solucionador: NonlinearBlockGS vs NewtonSolver

Aug 22 2020

Tengo dos grupos openmdao con dependencia cíclica entre los grupos. Calculo las derivadas usando paso complejo. Tengo un solucionador no lineal para la dependencia y uso SLSQP para optimizar mi función objetivo. El problema está en la elección del solucionador no lineal. Cuando uso NonlinearBlockGSla optimización es exitosa en 12 iteraciones. Pero cuando uso NewtonSolverwith Directsolvero ScipyKrylovla optimización falla (se excedió el límite de iteración), incluso con maxiter=2000. Las conexiones cíclicas convergen, pero es solo que las variables de diseño no alcanzan los valores óptimos. La diferencia entre las variables de diseño en iteraciones consecutivas es del orden 1e-5. Y esto aumenta las iteraciones necesarias. Además, cuando cambio la suposición inicial a un valor más cercano al valor óptimo, funciona.

Para verificar más, convertí el modelo en IDF (al crear copias de las variables de acoplamiento y las restricciones de consistencia), eliminando así la necesidad de un solucionador. Ahora la optimización es exitosa en 5 iteraciones y los resultados son similares a los resultados cuando NonlinearBlockGSse usa.

¿Por qué pasó esto? ¿Me estoy perdiendo de algo? ¿Cuándo debo usar NewtonSolversobre otros? Sé que es difícil responder sin ver el código. Pero es solo que mi código es largo con múltiples componentes y no pude recrear el problema con un modelo de juguete. Así que cualquier idea general es muy apreciada.

Respuestas

2 JustinGray Aug 22 2020 at 08:57

Sin ver el código, tienes razón en que es difícil dar detalles.

En términos muy generales, Newton a veces puede tener muchos más problemas para converger que NLBGS (Nota: esto no es absolutamente cierto, pero es una buena regla general). Entonces, lo que supongo que está sucediendo es que en su primera o segunda iteración, el solucionador de Newton en realidad no está convergiendo. Puede verificar esto configurando newton.options['iprint']=2y mirando el historial de iteraciones a medida que el optimizador itera.

Cuando tiene un solucionador en su optimización, es fundamental que también se asegure de configurarlo para que arroje un error en la no convergencia. Algunos optimizadores pueden manejar este error y retrocederán en la búsqueda de línea. Otros simplemente morirán. De cualquier manera, es importante. De lo contrario, termina dando al optimizador un caso no convergente que no sabe que no es convergente.

Esto es malo por dos razones. En primer lugar, ¡los valores de objetivos y restricciones que obtenga serán incorrectos! En segundo lugar, y quizás lo más importante, ¡las derivadas que calcula serán incorrectas! Puede leer los detalles [en el manual de teoría] pero, en resumen, los métodos analíticos derivados que utiliza OpenMDAO asumen que los residuos se han ido a 0. Si ese no es el caso, las matemáticas fallan. Incluso si estuviera haciendo un modelo completo de diferencias finitas, los modelos no convergentes son un problema. Obtendrá basura ruidosa cuando intente FD. 2

Entonces, suponiendo que haya configurado su modelo correctamente y que tenga los problemas de configuración de los solucionadores lineales (suena como si los tuviera, ya que funciona con NLBGS), entonces lo más probable es que el solucionador de newton no esté convergiendo. Utilice iprint, posiblemente combinado con la impresión de depuración del controlador , para comprobarlo usted mismo. Si ese es el caso, debe descubrir cómo hacer que Newton se comporte mejor.

Aquí hay algunos consejos que son bastante generales. También puede intentar usar la búsqueda de línea armijo , que a menudo puede estabilizar una resolución de newton a costa de cierta velocidad.

Finalmente... Newton no es la mejor respuesta en todas las situaciones. Si NLBGS es más estable y computacionalmente más barato, debe usarlo. Aplaudo su deseo de que funcione con Newton. Definitivamente debería averiguar por qué no es así, pero si resulta que Newton simplemente no puede resolver su problema acoplado de manera confiable, ¡también está bien!