¿Se pueden usar dos programas de modelado diferentes para confirmar los resultados de cada uno?


8

Modelos de computadora

El modelado por computadora se utiliza en varios campos de la ingeniería. Estoy considerando específicamente el análisis estructural o el análisis de elementos finitos (FEA). A veces, los modelos se utilizan para acelerar los cálculos repetitivos que se podrían hacer a mano. A veces, los modelos se utilizan para realizar cálculos que no son fáciles o incluso posibles de hacer a mano.

Comprobación

Existen algunos métodos estándar para verificar los resultados de los modelos de computadora.

  • Ejecute modelos de verificación y confirme que los resultados coincidan con una respuesta calculada previamente.
  • Ejecutar modelos simples que se pueden comprobar mediante cálculos manuales.
  • Prueba de modelos físicos.

El problema con los dos primeros métodos de verificación anteriores es que o bien solo comprueban situaciones específicas o solo las partes simples del programa.

El método del modelo físico puede ser costoso para los modelos de tamaño completo y los modelos a escala no siempre dan los mismos resultados que el tamaño completo.

Esto deja una brecha en lo que los resultados pueden ser revisados. Para cualquier modelo complicado, no hay una manera fácil de verificar que los resultados del programa sean correctos. El ingeniero debe confiar en que el software produjo resultados correctos del modelo.

Comprobación de comparación

El modelo podría ser introducido en dos programas diferentes (hechos por diferentes compañías). El supuesto es que si los resultados de los dos modelos son lo suficientemente similares, entonces los resultados deben ser correctos para el modelo utilizado. Esto no detectaría ningún error en la creación del modelo original, pero detectaría errores en la implementación del software.

  • ¿Se podrían usar dos programas separados para verificar la "corrección" de los resultados del modelo?
  • ¿El uso de este método de comparación de un modelo en dos programas separados proporcionaría el mismo nivel de seguridad en los resultados que cualquiera de los otros métodos de verificación?
  • ¿Cuáles podrían ser las desventajas de usar este procedimiento?

El "Transbordador espacial" se puso en órbita utilizando 5 x computadoras de vuelo. 4 de ellos ejecutaron el mismo programa, verificaron los resultados de cada uno, acordaron entre ellos quién estaba en su sano juicio y eliminaron a cualquier miembro insano. La quinta computadora ejecutó un programa completamente diferente escrito independientemente por un equipo diferente. 'Por si acaso'. No sé si alguna vez fue necesario.
Russell McMahon

Ambos programas de computadora podrían estar equivocados de la misma manera, así que diría que no. Esto no es una buena práctica. Es mejor comparar las soluciones numéricas con los casos en que se conoce una solución, de manera analítica, empírica o mediante investigaciones publicadas.
Paul

@Paul Sí, así es como se verifican las cosas, pero eso solo demuestra que el programa funciona ese problema. Puede suponer si otras configuraciones que utilizan las mismas rutas de código también son correctas, pero siempre habrá un caso de borde. El supuesto incluido en el uso de dos programas separados es que los programadores tienen errores en diferente casos de borde.
hazzey

Respuestas:


7

Sí, obtener una segunda opinión puede ser útil. Esto se hace rutinariamente en el pronóstico del tiempo donde se desconocen las soluciones exactas, y hay algunos juicios sobre cómo aplicar varios factores.

Habrá menos espacio de maniobra en algo así como un análisis de tensión de malla de elementos finitos porque las ecuaciones iterativas para resolverlo serán básicamente las mismas sin importar quién escribió el software. El problema real no es resolver la malla tanto como crear una malla lo suficientemente buena en primer lugar.

Por lo tanto, una forma de obtener múltiples opiniones es variar los parámetros de la malla. Esperemos que todavía obtengas más o menos la misma respuesta. Si haces la malla 2x más fina y obtienes una respuesta significativamente diferente, entonces es una buena pista que la malla original no fue lo suficientemente detallada. Tampoco está seguro de que la próxima malla sea lo suficientemente detallada como para no hacer una más detallada y obtener la misma respuesta.

Por supuesto, hoy en día la generación de mallas en sí misma es algo automatizada y adaptable. Esto ya no se trata solo de la física de resolver la malla, sino que incluye heurísticas sobre cuándo y cómo subdividir. Diferente software puede variar en este sentido, por lo que ejecutar dos programas diferentes con los mismos datos iniciales puede ser útil.


6

Escribo esto desde la perspectiva de un ingeniero que desarrolla software de simulación.

Creo que la práctica descrita es mala y le recomiendo que no use dos programas diferentes para "confirmar" los resultados.

En general, dos softwares de modelado diferentes no se pueden usar para confirmar mucho más que su similitud. Dos software fácilmente podrían obtener dos respuestas similares pero incorrectas, especialmente si usan modelos similares. Puedo pensar en al menos un caso en el que este es definitivamente el caso, y Trevor Archibald menciona otro. Me sentirían más impresionados con dos softwares que utilizan diferentes técnicas de modelado obteniendo resultados similares.

Este tema se denomina verificación y validación de modelos de computadora, y tiene una literatura bastante vasta. Te ofrezco un boceto de lo básico. La verificación es comparar un modelo con una solución "exacta" (que podría ser un cálculo manual, o algo más complejo), es decir, verificar los cálculos matemáticos del software. Las suposiciones detrás de la solución exacta podrían estar equivocadas, pero al menos querrá asegurarse de que el software obtenga la parte matemática correcta. La validación es comparar un modelo con un experimento. Esto le permite verificar si el modelo que está utilizando es exacto, que es algo que la verificación no puede hacer por usted.

El problema con los dos primeros métodos de verificación anteriores es que, o bien solo comprueban situaciones específicas o solo las partes simples del programa.

Este es un problema real que enfrentan los desarrolladores y usuarios de software. Hay maneras establecidas de manejarlo que son mucho mejores que comparar dos softwares diferentes.

El problema es que nunca se pueden probar todos los casos posibles. Su software puede pasar el caso A, pero el caso A no involucra la física X, Y o Z, y eso lo hace totalmente fuera del caso B. Entonces, lo que usted desearía es una gran cantidad de cheques que cubran al menos todos Las características básicas que desea comprobar. Muchos softwares tienen "V & amp; V suites" que son básicamente eso.

En cuanto a la verificación, existen numerosas opciones. Podrías generar nuevas soluciones exactas para diferentes casos. A veces esto solo es adecuado. Sin embargo, como ha notado, muchas veces lo que puede hacer a mano se limita a casos muy simples. Para los casos más generales, podría utilizar una técnica llamada método de soluciones fabricadas (Google it). Esto requiere programación y puede causar problemas, pero le permite probar básicamente cualquier cosa que se le ocurra. (La parte de desorden se puede manejar a través de una biblioteca como MASA , por cierto.)

Además, me gustaría señalar que, al contrario de lo que sugiere Olin Lathrop, con el método de soluciones fabricadas, puede generar cuáles son, con el propósito de probar, soluciones exactas. No son "exactos" en sentido estricto, porque no satisfacen exactamente las ecuaciones que el software está resolviendo sin modificación. Pero satisfacen ecuaciones que están muy cerca, y la diferencia se tiene en cuenta para hacer que la prueba sea rigurosa. Esta técnica no es muy popular en este momento, pero se ha utilizado para probar cosas que antes se pensaba que eran difíciles de probar.

En términos de validación, puede buscar más datos experimentales o realizar sus propios experimentos.


4

Creo que esta es una buena práctica en general.

Al usar dos softwares diferentes, puede evitar dos tipos de errores: 1) errores que provienen de un software inexacto (que no debe pasarse por alto), 2) errores que provienen de la falta de hábito del usuario con el software (opciones ocultas, configuración predeterminada ...).

Si los softwares son lo suficientemente diferentes, las probabilidades de obtener dos veces los mismos resultados erróneos son bajas.

Sin embargo, los errores que provienen de una mala elección de modelado no se pueden evitar de esta manera. Así que diría que la principal desventaja es confiar demasiado en los resultados porque han sido confirmados por dos softwares.

Creo que es mejor dominar un software, ejecutando todo tipo de casos de prueba (comparación con resultados académicos, por ejemplo), que usar varios programas y tener un conocimiento promedio. Además, creo que es mejor conocer los conceptos básicos del análisis FEM, y usar solo dos programas informáticos de "un solo clic para ejecutar" es una mala práctica porque es probable que los usuarios reproduzcan errores de modelado.

PD: Estoy escribiendo como usuario de electromagnetismo / análisis térmico de FEM (no hay otros dominios).


2

Respuesta desde el punto de vista de un ingeniero de diseño.

La comparación de los resultados de un programa con respecto a otro le dará cierto nivel de certeza de que los resultados son correctos. Es poco probable que le brinde un 100% de certeza, pero entonces ese nivel de certeza es difícil de alcanzar.

Un gran problema que veo es poder transferir el modelo de una pieza de software a otra. Aunque la mayoría de las compañías de software están mejorando la importación / exportación de modelos (debido a BIM), no esperaría que todas las características de un modelo sean exportables. La geometría es relativamente fácil de importar / exportar, ya que el archivo de intercambio solo necesita contener coordenadas. Pero por ejemplo es probable que las versiones finales de los miembros se almacenen de manera muy diferente según el software, por lo que, a menos que / hasta que se acepte un formato de intercambio de archivos universal, sospecho que se requerirá un gran esfuerzo para reconstruir completamente un modelo en el segundo programa de software.

Según mi propia experiencia, es mucho más probable que los errores en los resultados provengan de una entrada incorrecta de datos o suposiciones incorrectas que de un software mal escrito. El tiempo y el esfuerzo en usar software independiente para verificar una respuesta, por lo tanto, probablemente no sea un buen uso de su tiempo.

Respuesta desde el punto de vista de un ingeniero de software

La verificación del software contra otro software no se toma como justificación de que su software es correcto. Es mucho mejor encontrar datos / resultados publicados que puedan usarse para verificar que el software da las respuestas correctas. Imagine una reunión de ventas donde una compañía de software está tratando de vender su software a una compañía de ingeniería:

Ingeniero: ¿Cómo sabemos que su software es correcto?

Vendedor de software: Bueno, lo comparamos con el software de nuestro competidor y obtuvimos la misma respuesta.

Ingeniero: Entonces, ¿está diciendo que su competidor es lo suficientemente mejor que usted que su software es el criterio con el que mide su software? Parece que deberíamos comprar su software en su lugar!


1
Espero que el ingeniero de software no lo haga. anunciar que el software se compara con otro programa, incluso si es el caso en el laboratorio. También pensaría que un ingeniero de software apreciaría que podría haber casos extremos que no se hayan cubierto completamente con las pruebas unitarias.
hazzey

2

Coincido con las otras respuestas aquí, que esto en general puede ser una buena idea y ayudará a garantizar la precisión de los resultados de la simulación. En cuanto a lo bueno que es en relación con los otros métodos de verificación, diría que los resultados conocidos y las pruebas físicas son mejores opciones si es posible, pero los cálculos manuales pueden requerir una simplificación excesiva si el modelo es lo suficientemente complejo.

Lo que realmente quiero señalar es algo que no se ha abordado en el punto final: las debilidades potenciales de esta práctica. El uso de dos paquetes FEA diferentes puede detectar una peculiaridad de un paquete que provoca un error, siempre que pueda identificar qué análisis es correcto y cuál está desactivado. Sin embargo, hay algunas limitaciones generales para FEA en general, independientemente del método o la implementación. Las esquinas afiladas y otros concentradores de tensión que causan singularidades en el modelo no son algo que cambie mucho de un paquete a otro, estos siempre serán puntos débiles. Aquí es donde se requieren conocimientos de ingeniería e intuición.

He hecho simulaciones en partes que conozco que resisten fácilmente ciertas tensiones, y el modelo muestra que la tensión interna es 10 veces más fuerte que la resistencia; esto es obviamente incorrecto, porque está en un patrón de spline involuto y al software FEA no le gusta eso.

Por último, debería ser obvio que el cambio de software no elimina el error del usuario. Si comete un error en el modelo o los parámetros, ese error lo arruinará sin importar lo que use para analizarlo.


No tengo idea de lo que es un "patrón de spline involuto", por lo que este comentario puede no ser relevante, pero si está obteniendo un estrés interno con un rendimiento de 10x, ¿quizás sería bueno modelar con un material no lineal? Eso eliminaría concentraciones extremas de estrés local.
AndyT

En este punto, no recuerdo si usé una respuesta de material elástico lineal o algo más básico, pero no quería que la simulación se ejecutara para siempre, y este es un uso temprano de FEA para nosotros. Fue esencialmente un rediseño de una parte existente para la cual conocemos el modo de falla, y la forma en que tuvimos que configurar el modelo impuso algunas restricciones difíciles en la spline (una spline involuta es la forma de la mayoría de los dientes de engranaje). Si estuviera haciendo un análisis más completo, podría intentar arreglarlo, pero esto era más una prueba de concepto, en comparación con la parte existente.
Trevor Archibald

1

Las condiciones de contorno y la técnica de modelado influirán enormemente en los resultados. Lo que sugiero es ejecutar una versión simplificada / idealizada (como planar o axisimétrica) y una completa y comparar las dos.

El problema con dos programas FEA diferentes es que bajo el capó, los solucionadores serán prácticamente iguales. Las diferencias observadas serían desde diferentes criterios de convergencia, o desde diferentes supuestos sobre cómo se aplican las condiciones de frontera. No está comprobando el modelo, pero la capacidad de cada solucionador de saber que ha alcanzado una solución.

Creo que los resultados de FEA deben validarse primero con sentido común y cálculos manuales, luego con modelos similares pero diferentes (sólidos en lugar de vigas, por ejemplo) y, finalmente, mediante pruebas físicas para ver si las piezas fallan dónde y cómo la FEA predice. los cuando una pieza fallará es más difícil porque está influenciada por los procesos de fabricación, las variaciones de materiales y las tensiones residuales.


No todas las disciplinas de ingeniería tienen el lujo de poder hacer una prueba de destrucción física. En ingeniería civil y estructural, la gran mayoría de los proyectos están construyendo artículos únicos únicos: ¡construir uno completamente separado solo para probarlo y destruirlo sería prohibitivamente costoso!
AndyT

Punto a favor. Todavía es una buena idea validar los resultados de FEA con pruebas, incluso si se trata de piezas de muestra o de escala.
ja72

Puedo ver tu punto ... pero en mis seis años de diseño de puentes nunca escuché que se hiciera una prueba física en una escala de un puente.
AndyT

Entonces, ¿qué puentes debo evitar entonces? Bromeando Por lo tanto, debe haber suficientes márgenes de seguridad para tener en cuenta lo que no se modela con FEA. No existe un modelo FEA 100% preciso.
ja72

De hecho, tenemos factores de seguridad en todas partes! El Estándar Británico BS5400 (ahora bastante difunto) incluía un factor de 1.1, llamado gammaf3, que era "un factor que tiene en cuenta la evaluación inexacta de los efectos de la carga, la distribución imprevista de la tensión en la estructura y las variaciones en la precisión dimensional lograda en la construcción . " es decir, sea lo que sea que su análisis de FE le diga que el estrés es, multiplíquelo por 1.1 en caso de que sea un valor no conservador.
AndyT
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.