Solucionadores de ecuaciones no lineales en simuladores SPICE

Tenemos una tarea en la clase de procesamiento paralelo, el objetivo es implementar un solucionador de ecuaciones no lineales en cuda basado en el método de Newton Raphson e interconectar este solucionador con una aplicación que trata con un conjunto de ecuaciones no lineales. Queríamos interconectar nuestro solucionador con simuladores de circuitos . Hemos elegido un simulador de código abierto y cada vez que el simulador realiza una simulación de punto de operación de CC, invocará nuestro código cuda. En este punto, queríamos comparar el rendimiento de nuestro solucionador con los solucionadores implementados en otros simuladores de circuitos como

  • LTspice
  • Ngspice
  • Qucs

Y también otros solucionadores de software, por ejemplo, la caja de herramientas de optimización de Matlab

Hemos probado estos solucionadores contra un circuito [que debería asignarse a un gran conjunto de ecuaciones no lineales].

ingrese la descripción de la imagen aquí

La lista de conexiones del circuito es generada por un script donde se da el número de nodos. Hemos formulado el conjunto de ecuaciones no lineales que gobiernan el circuito anterior como el siguiente

ingrese la descripción de la imagen aquí

Las incógnitas x[i]en este conjunto de ecuaciones son los nodos de tensión y la corriente en cada resistencia.

Hemos logrado escribir esto como una función de matlab para probar este circuito contra los algoritmos de resolución no lineales de matlab que aparecen en la caja de herramientas de optimización.

function F = non_linear_diode(X)
% Len(x) is always even 2*d
d = length(X)/2;
F = zeros(1, d*2);
i = 1e-3;     % Current source magnitude
r = 50;       % Resistors value
c1 = 1e-15;   % Diodes I_s
c2 = 0.0258;  % Diodes N*V_th

F(1) = X(1) - X(2) - i*r;
F(d) = X(d) - X(d+1) - X(2*d)*r;
F(d+1) = i - c1*(exp(X(2)/c2) -1) - X(d+2);

for ii = 2:(d -1)
    F(ii) = X(ii) - X(ii+1) - X(ii+d)*r;
    F(ii+d) = X(ii+d) - c1*(exp(X(ii+1)/c2) -1) - X(ii + d + 1);
end
F(d*2) = X(2*d) - c1*(exp(X(d+1)/c2) -1);
end

También hemos escrito un script para generar una netlist de Spice para este problema.

def gen_ckt(num):
    ret = ""
    for i in range(1, num):
        ret += 'R'+str(i)+" "+str(i)+" "+str(i+1)+" 50\n"
        ret += 'D'+str(i)+" "+str(i+1)+" 0 DI1N4004\n"

¿Dónde DI1N4004está definido nuestro modelo de diodo en la lista de conexiones? Al probar los solucionadores anteriores contra el problema con 70,000nodos, es decir, 140,000ecuaciones e incógnitas

  • Matlab se queda sin memoria
  • Qucs lleva una eternidad
  • Todos los solucionadores basados ​​​​en especias de alguna manera resolvieron este problema en menos de 2 segundos.

En realidad, no tenemos idea de cómo los solucionadores de especias lograron evitar este problema de memoria, e incluso cuando probamos este problema contra un número menor de incógnitas, por ejemplo, 3,000los solucionadores de especias siempre superan a matlab y qucs. Aunque, como se menciona en [1] [2] [3], Spice utiliza el enfoque de Newton-Raphson amortiguado para resolver circuitos con componentes no lineales, que es lo mismo que todos los solucionadores mencionados anteriormente.

  • Matlab Fsolve: método dogleg [Newton + región de confianza + pendiente más pronunciada] [4]
  • Qucs: Newton-Raphson amortiguado [5]

mis preguntas son

  • ¿Cómo se las arregló Spice para resolver un sistema tan grande de ecuaciones no lineales rápidamente y sin quedarse sin memoria? ¿Está explotando la estructura del circuito haciendo uso de los elementos repetidos?
  • ¿Es este ejemplo lo suficientemente justo? Quiero decir, ¿debemos considerar circuitos más prácticos? y si es así, ¿alguien puede dar un ejemplo para un circuito (s) donde la simulación del punto de operación de CC podría ser el cuello de botella del tiempo de simulación?
  • En [6], los autores mencionaron los circuitos de referencia ISCAS85, ¿deberíamos considerar estos circuitos en nuestras pruebas?
  • ¿Es el punto de funcionamiento de CC el tipo de simulación al que deberíamos apuntar? Quiero decir, ¿deberíamos centrarnos en conectar nuestro solucionador con otros tipos de simulaciones, por ejemplo, el análisis transitorio?

Referencias

1: http://www.ni.com/white-paper/5808/en/

2: http://www.ecircuitcenter.com/SpiceTopics/Overview/Overview.htm

3: http://www.electronicdesign.com/boards/take-peek-under-hood-your-spice-circuit-simulation-engine

4: https://www.mathworks.com/help/optim/ug/fsolve.html

5: http://qucs.sourceforge.net/tech/node16.html

6: http://www.mos-ak.org/bucharest/presetnations/Lannutti_MOS-AK_Bucharest.pdf

No tengo tiempo en este momento para responder, pero este libro puede darle una buena idea de cómo los simuladores de circuitos hacen su magia, lo recomiendo mucho: amazon.com/Circuit-Simulation-Farid-N-Najm/dp/ 0470538716/…
Podría considerar hacer (¿un subconjunto?) de esta pregunta sobre ciencia computacional
Esta no es realmente una pregunta de electrónica... SPICE ni siquiera se limita a la electrónica AFAIK. ¿No debería estar en Math.SE o SciComp.SE o CS.SE o algo más?
@Mehrdad, estoy totalmente de acuerdo con ThePhoton, solo una parte de la pregunta debe hacerse en cse.se, pero teniendo en cuenta el resto de las preguntas, creo que este es el mejor lugar para hacerlas.

Respuestas (1)

¿Cómo se las arregló Spice para resolver un sistema tan grande de ecuaciones no lineales rápidamente y sin quedarse sin memoria?

Solucionador de matrices dispersas de Google .

Es muy probable que un buen SPICE use por defecto (o sepa cuándo cambiar a) un solucionador de matrices dispersas, ya que los circuitos grandes generalmente producen matrices dispersas (cada nodo se conecta solo a una pequeña fracción de las ramas), sería una optimización obvia para usar (o tener disponible) un solucionador de matriz dispersa en un SPICE. Incluso el informe original de Nagel de 1975 (¿Tesis?) sobre SPICE analiza el uso de métodos de matrices dispersas.

Matlab ciertamente tiene disponible un solucionador de matrices dispersas, pero probablemente deba invocarlo explícitamente.

Qucs puede no tener esta capacidad, o puede que no se implemente particularmente bien, porque es un proyecto de código abierto relativamente crudo y es posible que sus desarrolladores no hayan llegado al punto de probarlo en algo más grande que un problema de juguete.

(Sugerencia para @jonk por el enlace al informe Nagel)

¿Es este ejemplo lo suficientemente justo? Quiero decir, ¿debemos considerar circuitos más prácticos?

Pensaría que desea demostrar su solucionador en una amplia variedad de diferentes tipos de circuitos. Probablemente desee considerar circuitos que se sabe que producen matrices mal condicionadas . Los circuitos de retroalimentación positiva también suelen producir dificultades para los solucionadores no lineales.

y si es así, ¿alguien puede dar un ejemplo para un circuito (s) donde la simulación del punto de operación de CC podría ser el cuello de botella del tiempo de simulación?

Esperaría que esto sea común en cualquier circuito mal acondicionado al configurar una simulación de CA.

¿Es el punto de funcionamiento de CC el tipo de simulación al que deberíamos apuntar? Quiero decir, ¿deberíamos centrarnos en conectar nuestro solucionador con otros tipos de simulaciones, por ejemplo, el análisis transitorio?

Los otros tipos principales de simulación (CA y transitorios) solo requieren solucionadores lineales. La simulación de CA trata explícitamente de pequeñas variaciones sobre el punto de operación, por lo que el circuito puede considerarse lineal por la teoría de la perturbación. El solucionador de transitorios linealiza el circuito en cada paso de tiempo, pero vuelve a calcular el circuito equivalente lineal local para cada paso de tiempo. Entonces, si está tratando de demostrar un solucionador no lineal, el solucionador DC es el que debe demostrar.

Le devuelvo mi agradecimiento por encontrar una versión en línea del artículo de Nagel. (Creo que fue una tesis, pero luego se transformó en un memorando del departamento de algún tipo).
@jonk, creo que me diste el enlace hace un par de semanas (¿meses?).
Creo que di la referencia en sí, porque tengo una copia completa en papel que obtuve de Berkeley, directamente, hace más de una década. Tal vez no fuiste tú quien encontró el enlace. Pero definitivamente recuerdo que no sabía de la versión web hasta que la vi publicada aquí el 20 de junio de este año. (Lo agarré, por supuesto, ya que me gusta poder buscar palabras).
Actualmente, los solucionadores dispersos se utilizan para casi todo, incluidas las matrices densas. Pero mirando el diagrama de circuito del OP, las matrices del sistema probablemente tengan un ancho de banda muy pequeño, incluso podría ser tridiagonal. Si ignoraste ese hecho en tu código de Matlab, podrías esperar factores de aceleración de 1000 o más con muy poco esfuerzo, incluso usando algoritmos numéricos de la década de 1960, ¡no los modernos que son más difíciles de entender!
@alephzero, hasta donde yo sé, LTSpice se basa en SPICE3, que es una base de código de 1980. Matlab también está basado en una base de código bastante antigua y, como dije en la respuesta, probablemente hará que solicite explícitamente una matriz dispersa si eso es lo que desea.
Muchas gracias por esta gran respuesta, resulta que incluso el simulador ckt de código abierto que estamos usando trata la matriz MNA como una matriz dispersa cuando es demasiado grande. También tuvimos casi el mismo rendimiento cuando le dijimos explícitamente a matlab fsolveque este es un sistema disperso. Nuevamente muchas gracias por tu respuesta y por tu tiempo.
@Elbehery, para obtener un mejor rendimiento de Matlab, es posible que deba tener mucho cuidado de nunca hacer que almacene la matriz como una matriz densa, o hacer que se convierta entre representaciones densas y dispersas. Desafortunadamente, no sé lo suficiente sobre Matlab para dar consejos más detallados.
"El solucionador de transitorios linealiza el circuito en cada paso de tiempo, pero vuelve a calcular el circuito equivalente lineal local para cada paso de tiempo" es solo una parte de la historia. SPICE ajusta los parámetros de sesgo del dispositivo para los nuevos puntos operativos ligeramente diferentes encontrados por el solucionador lineal. Luego (parcialmente) se linealiza nuevamente y se repite hasta que los errores están dentro de los límites especificados.