GENERALIDADES

En general, en el proceso de conversión/traducción de un modelo de FEM, se distinguen tres etapas o niveles: una traducción literal, una traducción consistente, y una traducción efectiva [1]. A continuación, al igual que en [1] se explican estos tres niveles de traducción haciendo uso de un símil con una traducción lingüística.

Bien es sabido que en una traducción lingüística entran en juego dos idiomas, el de origen y el objetivo; para la traducción de modelos FEM, ya sea para crash o para cualquier otra finalidad, se tiene algo parecido: el código de origen, el que está construido el modelo a traducir, y el código objetivo, en el que se quiere obtener el modelo. Esta operativa de traducir un modelo de un código a otro presenta los mismos desafíos que la traducción automática de un texto de un idioma a otro. La primera traducción automática entre el lenguaje fuente y el objetivo consiste básicamente en una sustitución de palabras o grupos de palabras por su equivalente, de acuerdo con diccionarios preestablecidos. A este tipo de traducción se le denomina como “traducción literal”; en ella, las frases resultantes casi nunca tienen sentido.

Este caso de traducción literal entre idiomas, extrapolado al campo de la traducción de modelos en elementos finitos, da como resultado un modelo inconsistente en su definición que, en consecuencia, no puede ejecutarse, pues genera errores de código. Para solventar esta situación, las herramientas más avanzadas de traducción automática de modelos FEM, como ENKIDOU, introducen lo que se podría denominar “entornos semánticos”, que, volviendo a la analogía con la traducción entre idiomas, sería el equivalente a los campos semánticos; estos entornos semánticos aportan información extra a la contenida en las bases de datos genéricas que sirven de diccionarios. Como resultado, la introducción basada en campos semánticos permite obtener frases con sentido en el mensaje que se quiere trasmitir de un idioma a otro; para nuestro caso, esto equivale a la obtención de un modelo que ejecutable en el código de destino. Este tipo de traducción se denomina” traducción objetivo consistente”.

Por último, en la línea de la analogía lingüística, puesto que para transmitir un mensaje de un idioma a otro no basta con tener frases con sentido, sino que es preciso que todas las frases estén relacionadas en e l mismo contexto, de tal manera que formen un mensaje que transmita el mismo significado que el que se pretende en el idioma de partida. En el contexto que nos concierne, esto significa que no sólo se persigue un modelo que pueda ejecutarse en el código objetivo -lo cual solo indica que el código entiende las “palabras” en las que está escrito el modelo- sino que es preciso que dicho modelo tenga un comportamiento lo más parecido posible al del modelo de origen, obteniéndose así lo que se denomina una “traducción efectiva”.

3.2.ETAPAS

A continuación, nos adentramos en las peculiaridades de cada una de las etapas arriba definidas, acompañando con ejemplos extraídos del proceso de traducción que se ha llevado a cabo.

3.2.1. TRADUCCIÓN LITERAL:

El primer paso para la conversión de un modelo en elementos finitos es encontrar y asignar, para cada entidad del modelo de origen, una equivalente en e l modelo de destino. Lo que se persigue pues en esta etapa es que el modelo resultante sea sintácticamente correcto, esto es, que el modelo traducido esté compuesto de unas entidades equivalentes de acuerdo con la semántica del código de destino. Por ejemplo, lo que en NASTRAN se conoce como “grids”, en Abaqus debería expresarse como “nodes”, pues ambas entidades hacen referencia a una misma clase de entidad: nodos. Lo mismo pasa al definir un sistema de coordenadas local, lo que en la sintaxis de NASTRAN se escribiría como” CORD”, en la sintaxis de PAM-CRASH se ha de expresar como “FRAME”.

Atendiendo a este criterio, según [1], se tienen 3 tipos de traducción literal:

• Conversión elemento-elemento: en estos casos, cada entidad del código de origen

sólo puede ser asignada a una y solo una entidad del código de destino; es el caso de conversión más simple, aunque no exento de errores; por ejemplo, a la hora de traducir las “cartas” de opciones de LS-DYNA, utilizadas para almacenar información extra de las entidades, al realizar una conversión de este tipo, la información extra almacenada en las opciones no se traduce como una entidad, pues no lo es, y, en consecuencia, la entidad a la que se hacía referencia se traducirá a la correspondiente según la información contenida en la carta principal de la entidad; este ha sido un caso frecuente en la realización de este proyecto, el cual se ha solventado con la redefinición de la entidad traducida según la información opcional cambiando a veces la entidad equivalente asignada en al principio. Un ejemplo de ello es lo ocurrido en la traducción de la fuerza de gravedad, definida en LS-DYNA como “LOAD-BODY” -cargas externas que actúan sobre un cuerpo- se tradujo primeramente como una

“BODY FORCE” -campo de fuerza externo que actúa sobre e volumen del cuerpo que aplica; no obstante, la información extra de la definición de load-body, esta vez como una configuración por defecto asumida por el solver, ha ayudado a traducir la gravedad de manera apropiada en el código de destino, eso es: Acceleration Field.

• División de entidades o conversión por entidades: este tipo de conversión se tiene

cuando una entidad de origen puede traducirse a dos o más entidades en el código objetivo. Este caso es más frecuente cuando en código objetivo es LS-DYNA, en donde existe un tipo de material y un tipo de elemento para cada tipo de propiedad, complementado así la definición de la entidad correspondiente mediante la combinación de las distintas entradas que hacer referencia a ella; esto implica que, una propiedad de PAM-CRASH, por ejemplo, dará lugar a la creación en LS-DYNA de no sólo una propiedad equivalente sino también de un elemento y de un material, puesto que son argumentos necesarios para la definición de una propiedad. Para el caso que nos aplica, al ser LS- DYNA el código de origen, la situación se ha presentado al revés.

• Colapso de entidades: este tipo de conversión se caracteriza por no sólo la pérdida

de información sino también de entidades: entidades del modelo visibles en el código de origen que no se traducen o no se muestran en el código de destino; es el caso contrario al anterior. Uno de los ejemplos más relevantes de este tipo en esta conversión ha sido con la modelización de los muelles y amortiguadores, definidos en LS-DYNA como elementos discretos, modelizándose por separado, pero que en PAM-CRASH no encuentran ninguna entidad equivalente de manera automática, debido a su formulación en origen, por lo que, en este caso, se ha tenido que reconstruir dichos elementos.

Como se ha podido observar, varias son las causas que pueden interferir en una traducción literal, pero se resaltan dos factores que la hacen especialmente complicada [1]:

• Primero, no siempre existe una entidad equivalente, ya sea por su formulación

intrínseca en el código de origen o porque la física a modelizar en uno y otro código es distinta; generalmente es el caso cuando se tratan no linealidades, por ejemplo, no se tendrá elementos equivalentes para contactos o para materiales plásticos si el código de destino es un código lineal estático y partimos de un modelo de comportamiento dinámico no lineal, un modelo crash por ejemplo. Y, en otros casos, aunque la física sea la misma, algunas entidades pueden no tener un equivalente directo debido simplemente a que se modelizan de forma distinta en uno u otro código. Este último caso es más frecuente con los materiales, pues cada código define sus modelos de materiales atendiendo a enfoques distintos; un ejemplo de esto último se ha dado con el MAT7 de LS-DYNA, el cual modeliza un material de base polimérica pero utilizando una formulación concreta -modelo constitutivo de Blatz-Ko para materiales de tipo goma espumada- que permite

modelizar un comportamiento elástico no lineal e isótropo de un sólido altamente compresible; este material no tiene un equivalente directo en PAM-CRASH debido a dos razones principales: la primera es que se usan otros modelos constitutivos para materiales poliméricos , y la segunda es la diferente formulación utilizada para la construcción de los modelos de los materiales.

Se podría decir que los materiales en LS-DYNA buscan representar comportamientos tipo y, por tanto, los inputs requeridos para su definición son los parámetros que aparecen en la ecuación de la ley de comportamiento correspondiente que modeliza el comportamiento que se quiere representar, mientras que en PAM-CRASH la modelización de materiales persigue representar la respuesta estructural detallada del material en cuestión, por lo que los inputs requeridos para definir dicho material son parámetros físicos medibles mediante ensayos reales.

Como consecuencia de lo anterior, la mayoría de los materiales en PAM-CRASH admiten más datos en su definición, mientras que en LS-DYNA es más habitual el uso de simplificaciones derivadas del comportamiento tipo que se quiere modelizar. Ejemplo de ello se tiene con el mismo caso mencionado, para el MAT7 en LS-DYNA se asume un valor del coeficiente de poisson para el que el modelo constitutivo empleado se comporta de una determinada manera y, por consiguiente, dicho parámetro no aparece como input en la carta de definición de dicho material, pues ya va implícito en su definición y así lo asume el solver. Esta es la información extra que se pierde a la hora de hacer una traducción literal.

• Segundo: en algunos casos, sí que puede haber una entidad funcionalmente

equivalente entre el código de origen y el código objetivo, pero que no esté permitido en el código de destino, es decir, que exista un elemento en el código objetivo que cumple con las mismas funciones que el equivalente de origen pero que no sea posible una correlación directa por incompatibilidad. Un ejemplo de ello se tiene en la conversión de las restricciones y condiciones de contorno en modelos de crash, las cuales dependen mucho de cómo se combinan dichas restricciones internamente en cada código, por lo que algunas combinaciones no son compatibles. Aquí se tiene el ejemplo de lo ocurrido con las entidades “CONSTRAINED_EXTRA_NODES_SET”, “CONSTRAINED_RIGID_BODIES” y todas restricciones cinemáticas –“JOINST” de LS-DYNA, las cuales, a pesar de tener sus entidades equivalentes en PAM-CRASH, la forma en que se combinan entre sí para contribuir en los g.d.l. de los elementos a los que restringen, y a la dinámica del modelo, es incompatible con las combinaciones de sus equivalentes.

En conclusión, una traducción literal, tal como se ha explicado, puede no ser “entendida” por el código objetivo, aun cuando se ha conseguido el objetivo que en ella se persigue, que es que todas las entidades estén sintácticamente bien definidas, produciendo errores a la hora de ser ejecutad0.

Por esta razón, el modelo resultante de esta primera etapa no se considera un modelo traducido, técnicamente hablando, pues no es funcional, ya que no es más que la representación de la discretización del dominio físico objeto de estudio.

3.2.2. TRADUCCIÓN CONSISTENTE

Como ya se indicó, una traducción consistente o una traducción objetivo consistente es aquella que se puede ejecutar en el código objetivo sin errores de código [1], es decir, que e l cálculo converge y se obtiene un resultado, independientemente de la calidad de dicho resultado. En este nivel conversión ya se puede elegir qué equivalente es el más adecuado en el código de destino para una entidad dada del modelo de origen. Durante el proceso de conversión del modelo objeto de estudio, este nivel de traducción se ha obtenido sólo después de una detallada revisión de la traducción literal, pues era necesario reasignar la equivalencia adecuada a las entidades del modelo de origen que se correspondían con varios equivalentes en el código de destino, consiguiendo así un modelo traducido consistente con la física que se desea simular.

No obstante a lo anterior, en vista de los objetivos perseguidos en un proceso de traducción de un modelo FEM, y particularmente en el contexto de los modelos de crash, un modelo consistente no es suficiente como para considerarse “modelo traducido”, pues, a pesar de que pueda ejecutarse y llegar a la convergencia, el cálculo puede no ser estable; este fenómeno se puede observar muy bien en el contexto en el que estamos en el caso de las suspensiones, por ejemplo, que el coche puede no llegar a estabilizarse después del contacto con el suelo, en un cálculo a velocidad cero, donde la fuerza de la gravedad es la única que se ejerce sobre el modelo. Otro ejemplo de convergencia sin estabilidad es el que muestra en la figura 2, donde una combinación inconsistente de parámetros en el contacto ruedas-suelo conlleva a un pico de fuerza en el instante inicial debido a penetraciones iniciales en dicho contacto. En la figura 3 se puede observar el resultado del mismo cálculo, convergido y estable. Lo que se observa es el equilibrio o no de la energía cinética, la energía interna y la energía total del sistema. Dichos resultados corresponden al modelo que se muestra en la figura 4.

También puede darse el caso de que, convergido el cálculo y estabilizado el modelo, los resultados obtenidos no re correlacionen con los del modelo original, ya no sólo por particularidades del cálculo sino también por alguna inconsistencia en los parámetros de control o como consecuencia

Figura 2: Diagrama de energías de un cálculo inestable convergido.

de alguna simplificación adoptada o algún dato intrínseco del software de origen que no se posible asigna al elemento correspondiente en código objetivo. Otro ejemplo de convergencia y estabilidad, pero de resultados diferentes al que se he hecho frente durante el presente proyecto se hadado con los contactos con la pared rígida y con el suelo, donde tras la ejecución del cálculo, se observa que no hay impacto del vehículo con la pared ni contacto con el suelo. Hay que indicar aquí que estos contactos no se han obtenido de la traducción literal, es decir, no se han traducido de forma automática, ya que en el modelo inicial estaban definidos de manera implícita en la restricción “RIGID_WALL” y esta no está permitida en PAM-CR. Un análisis posterior del caso del fallo de contacto revela una insuficiencia de rigidez en el modelo como la causa de la rotura del contacto, puesto que sí que existe una presión de contacto entre el coche y la pared, y sin embargo este acaba atravesando la pared.

Figura 4: Modelo simplificado de camioneta. VPS Education Package. Fuente: [10]

Figura 3: Diagrama de energías de cálculo estable convergido. Fuente: [10]

3.2.3. TRADUCCIÓN EFECTIVA

Por todos los ejemplos ya mencionados en las anteriores etapas, se concluye que es necesario un nivel más de conversión, para pasar de un modelo consiste a un modelo totalmente funcional que sea capaz de reproducir de la manera más parecida posible el comportamiento del modelo original. Coincidiendo con [1], se considera que dos modelos son cualitativamente equivalentes cuando las distintas entidades del modelo traducido se comportan, en el código de destino, de la misma manera que sus correspondientes equivalentes del modelo original en el código de o rigen. En otras palabras, con una traducción efectiva no se pretende conseguir los mismos resultados numéricos, sino que el modelo, en su conjunto, funcione correctamente y se comporte igual que el modelo de origen.

3.3.HERRAMIENTAS

En este subapartado se hablará de la utilidad que han aportado las herramientas utilizadas. Siguiendo las líneas del alcance del proyecto, queda fuera de la competencia de este la descripción del funcionamiento de dichas herramientas, información disponible en los correspondientes manuales de usuario.

La principal herramienta utilizada para la traducción del modelo en todas las etapas de dicha operación ha sido el preprocesador ANSA® -Versión 18.1.1-, de la plataforma de BETA-CAE SYSTEMS©, acompañada del pre-postsprocesador LS-PrePost® -versión4.5.22- de LIVERMORE SOFTWARE TECHNOLOGY CORPORATION (LSTC), propio de LS-DYNA. En primera instancia, tras examinar el modelo en su visor propio, donde todas propiedades y características se muestran con todos los argumentos y metadatos, pues es el entorno en el que han sido definidos, se ha examinado después en ANSA -en la correspondiente pestaña de LS-DYNA-, comprobando primero que se mantienen todos los elementos, propiedades y características del modelo, y segundo, que estos mantienen su correcta definición y se expresan de forma correcta. En la figura 6se tiene una vista comparativa del listado de los elementos del modelo visto en LS-PrePost y visto en ANSA. Las figuras 7 y 8 muestran la visualización del modelo competo en ambos entornos.

El uso ANSA como preprocesador principal para llevar a cabo la operativa de conversión del modelo, en lugar de realizarse en el preprocesador propio de PAM-CRASH, Visual Viewer, en combinación con el LS-PrePost, responde a una cuestión de eficacia y de ahorro de tiempo – y ahorro también recursos, computacionales y económicos, de desde una visión más global sobre la gestión de herramientas- y se justifica con las tres ventajas destacables que han sido de gran utilidad para la realización de este trabajo.

La primera ventaja por mencionar es su compatibilidad con los ficheros tipo de la gran mayoría de los softwares comerciales de simulación numérica; este potencial está alimentado por la información contenida en las bases de datos internas del software, mediante las cuales puede gestionar adecuadamente cada tipo de archivo. Entre estos códigos compatibles se tiene: Nastran, Pam-crash, Ls-Dyna, Abaqus, Radioss, Ansys, Fluent, Open-Foam…etc.,permitiendo no sólo importar sino también modificar y exportar en los formatos propios de cada código.

Lo que resulta de ello es un software versátil y multidisciplinar que ofrece al usuario, bajo una misma ventana de aplicación, una interfaz gráfica -Graphical User Interface, GUI- acomodada a los elementos, parámetros y configuraciones de cada código comercial compatible, pudiendo visualizar un mismo modelo en varios códigos con sólo cambiar de pestaña, como se puede observar en la figura 5.

Otra de las grandes facilidades de ANSA, basada en este concepto “multi-gui”, es que todos estos entornos gráficos, a pesar de mostrar unos comandos u otros en función del código seleccionado, están ordenados de la misma forma, es decir, los bloques de comandos y funciones específicas de cada código encajan en un mismo esquema, lo cual facilita enormemente el control de los elementos al pasar de una pestaña a otra. Esta es la segunda ventaja que destacar.

La tercera y gran ventaja que cabe señalar aquí deriva directamente de las dos anteriores, y es que, lo que se consigue con el cambio de pestaña