MXPA02003699A - Un metodo y un sistema para generar un codigo de software utilizando un traductor de lenguaje simbolico. - Google Patents

Abstract

Se expone un metodo y un sistema mejorados para crear en una computadora uno de los operadores nativos y un archivo de codigo de prueba para que un simulador de Elementos Finitos modele el flujo fluido en un medio poroso. El metodo de la presente invencion incluye los pasos de ingresar en un traductor de lenguaje simbolico ecuaciones y parametros que describan el modelo que sera creado por el simulador y generar uno o mas objetos del modelo a partir de las ecuaciones y parametros. El metodo de la presente invencion tambien incluye los pasos de generar una representacion simbolica de los operadores de matriz residual y tangencial de los objetos modelo y generar reglas de optimizacion para cualesquiera cantidades constantes geometricas. El codigo de nucleo numerico y la estructura de datos que inicializa el codigo nucleo se generan para el simulador en un lenguaje de programacion de alto nivel a partir del lenguaje del traductor de lenguaje simbolico. El codigo de nucleo numerico se formatea y se optimiza. La presente invencion genera los operadores nativos y el archivo de codigo de prueba al procesar el archivo de empalme a traves del traductor de lenguaje simbolico.

Description

MÉTODO Y SISTEMA PARA GENERAR UN CÓDIGO DE SOFTWARE QUE UTILIZA UN TRADUCTOR DE LENGUAJE SIMBÓLICO CAMPO TÉCNICO DE LA INVENCIÓN Está invención en general se relaciona con métodos y sistemas para modelar sistemas físicos utilizando un análisis de problemas de Elemento Finito y, más específicamente, con los métodos y sistemas para crear un simulador de Elementos Finitos para modelar el flujo fluido en medios porosos. Incluso de manera más particular, esta invención se relaciona con los métodos y sistemas para generar un código de software utilizando un traductor de lenguaje simbólico.

ANTECEDENTES DE LA INVENCIÓN Los modelos matemáticos para simular el comportamiento de los sistemas físicos pueden ser tanto consumidores de tiempo como complejos para crearse. En particular, los problemas de Elementos Finitos en múltiples dimensiones (por ejemplo, las cuatro dimensiones de espacio y tiempo) son casi imposibles de resolver por seres humanos. Estos tipos de problemas son tan complejos que el análisis se hace demasiado difícil para, que los humanos lo realicen sin errores. A medida que aumenta el número de dimensiones que abarca el problema, el problema en si mismo se vuelve casi exponencialmente más difícil en los términos tanto de los cálculos actuales como de la dificultad de los cálculos que se deben realizar. Un método para abordar el problema de la dificultad para resolver los problemas de Elementos Finitos de múltiples dimensiones es la manipulación simbólica. La manipulación simbólica implica la traducción de fórmulas Mathematicas en una representación simbólica que se pueda utilizar para generar un código de programación para utilizarse en un simulador para modelar un sistema físico. Sin embargo, los métodos de manipulación simbólica existentes actualmente tienen la tendencia de producir errores debido a su dependencia de una formulación humana de las ecuaciones Mathematicas necesarias y la traducción de esas ecuaciones en el código de programación. Los errores humanos se pueden presentar en al menos dos áreas. Un área es la de los cálculos algebraicos, en donde se pueden presentar errores tales como por ejemplo, derivación de signos o errores de trasc ipción. Otra área en donde se puede presentar un error humano es en la traducción del álgebra en el código en un lenguaje de programación tal como por ejemplo, Fortran, C++, o algún otro lenguaje de programación de alto nivel. Además, incluso asumiendo que la persona que realiza la traducción de las fórmulas algebraicas en el código de lenguaje de programación realiza la traducción correctamente al 100%, el código resultante puede no ser todavía tan eficiente o conciso como se desee. Por ejemplo, el código puede ser lento, puede ser demasiado grande y complejo, o puede contener más operaciones de comas flotantes que las necesarias- De manera más importante, los métodos y sistemas existentes en la actualidad para crear simuladores y modelar sistemas físicos requieren de una gran cantidad de capital humano en la forma de analistas experimentados que deben estar familiarizados tanto con Mathematicas de alto nivel para generar las ecuaciones complejas necesarias, y que sean también programadores expertos para generar el código necesario a partir de las formulaciones Mathematicas. Alternativamente, se podrían tomar grupos de matemáticos y programadores especializados para analizar los problemas, formular las ecuaciones Mathematicas y escribir el código correspondiente. Es tanto caro como consumidor de tiempo encontrar gente que sea experta en estos aspectos o en tener que aumentar el número del personal necesario para resolver estos problemas al tener analistas y programadores por separado. De manera similar, la investigación en el área de análisis del problema de Elementos Finitos ha sido tanto difícil como lento, debido a que se lleva meses o incluso años adoptar un nuevo método de Elementos Finitos o una nueva física y realizar todo el trabajo necesario para probar que el método o la física son viables. Como resultado, esto ha sido muy caro y no siempre es factible en una cantidad de tiempo económicamente viable para generar nuevos simuladores para modelar sistemas físicos.

SUMARIO DE LA INVENCIÓN Por lo tanto, existe una necesidad por un método y un sistema para generar un código de software utilizando un traductor de lenguaje simbólico que pueda resolver de manera eficiente los problemas de Elementos Finitos mult i-dimens ionales que son muy difíciles de resolver por humanos, tales como por ejemplo, la generación de simuladores para modelar un flujo fluido en medios porosos, y que reduzca el tiempo exhaustivo de computadora necesario para resolver estos problemas . Además existe la necesidad por un método y un sistema para generar un código de software utilizando un traductor de lenguaje simbólico que reduzca o elimine significativamente la propensión a errores humanos inherentes a la manipulación de fórmulas Mathematicas complejas y a la traducción de aquellas fórmulas Mathematicas en un código de lenguaje de programación. Todavía, adicionalmente existe una necesidad por un método y un sistema para generar un código de software utilizando un traductor de lenguaje simbólico que mejore significativamente el desempeño del código de programación generado a partir de la traducción simbólica de la fórmula athematica que se resuelvan para crear un modelo de un sistema físico. El desempeño del código generado a partir de este método y este sistema puede tener una velocidad aumentada, menos complejidad y un menor número de operaciones de comas flotantes. Incluso existe una necesidad adicional por un método y un sistema para generar un código de software utilizando un traductor de lenguaje simbólico que se proporcione para una rápida construcción y refinamiento de prototipos al mejorar el proceso de desarrollo para un simulador y generar un modelo matemático de un sistema físico/ tal como por ejemplo, el flujo fluido en un medio poroso. Este método y este sistema podrían hacer posible generar el simulado en una cantidad de tiempo económicamente viable. Incluso adicionalmente, existe una necesidad por un método y un sistema para generar un código de software utilizando un traductor de lenguaje simbólico que reduzca significativamente la dependencia de los sistemas anteriores con respecto al personal especializado tales como por ejemplo, analistas/programadores que hayan estado versados en las Mathematicas del proceso de modelación física y que tengan la experiencia de programación necesaria para traducir las Mathematicas en códigos de programación . Todavía adicionalmente, existe una necesidad por un método y un sistema para generar un código de software utilizando un traductor de lenguaje simbólico que proporcione la capacidad de disminuir la demora en la investigación al proporcionar un medio para generar un nuevo simulador a partir de ya sea un nuevo método de Elementos Finitos o utilizando una nueva física en un periodo de tiempo más corto que los métodos y sistemas actuales. De acuerdo con la presente invención, se proporciona un método y un sistema para generar un código de software utilizando un traductor de lenguaje simbólico que elimine o reduzca sustancialmente las desventajas y problemas asociados con estos sistemas y métodos desarrollados anteriormente. En particular, la presente invención proporciona un método y un sistema mejorado para crear en una computadora uno de los operadores nativos y un archivo de código de prueba para un simulador de Elementos Finitos para modelar el flujo fluido en medios porosos. El método de la presente invención incluye los pasos de ingresar las ecuaciones y parámetros en el traductor de lenguaje simbólico que describen el modelo que será creado por el simulador y. generar uno o más objetos modelo a partir de las ecuaciones y parámetros. El método de la presente invención incluye además los pasos de generar una representación simbólica de los operadores de matriz residual y tangencial de los objetos modelo y generar reglas de optimización para cualesquiera cantidades de constantes geométricas. El código de núcleo numérico y la estructura de datos que inicializan el código de núcleo se generan para el simulador en un lenguaje de programación de alto nivel a partir del lenguaje del traductor de lenguaje simbólico. El código de núcleo numérico se formatea y se optimiza y se genera un archivo que contenga el código de núcleo numérico formateado y optimizado y la estructura de datos que inicializa el código de núcleo . La presente invención proporciona una ventaja técnica importante al generar un código de software, utilizando un traductor de lenguaje simbólico, que pueda resolver de manera eficiente los problemas de Elementos Finitos multi-dimensionales que son muy difíciles de resolver por humanos, tal como por ejemplo, generar simuladores para modelar el flujo fluido en medios porosos y que reduzca el tiempo excesivo de computadora necesario para resolver estos problemas. La presente invención proporciona otra ventaja técnica al generar un código de software que utiliza un traductor de lenguaje simbólico que reduce o elimina significati amente la propensión de errores humanos inherentes a la manipulación de las fórmulas Mathematicas complejas y a la traducción de estas fórmulas Mathematicas en un código de lenguaje de progr mación . La presente invención proporciona todavía otra ventaja técnica al generar un código de software utilizando un traductor de lenguaje simbólico que mejore significativamente el desempeño del código de programación generado a partir de la. traducción simbólica de fórmulas Mathematicas que se resuelven para crear un modelo de un sistema físico. El desempeño del código generado a partir de este método y sistema puede proporcionar una velocidad aumentada, menos complejidad y un número menor de operaciones de comas flotantes. La presente invención proporciona todavía otra ventaja técnica al generar un código de software utilizando un traductor de lenguaje simbólico que se proporciona para una rápida construcción y refinación de prototipos al mejorar el proceso de desarrollo para un simulador y generar un modelo matemático de un sistema físico, tal como por ejemplo, el flujo fluido en un medio poroso. Este método y sistema podrían hacer posible generar el simulador en una cantidad de tiempo económicamente viable. La presente invención proporciona todavía otra ventaja técnica al generar un código de software utilizando un traductor de lenguaje simbólico que reduzca significativamente la dependencia de los sistemas anteriores con respecto al personal especializado tal como por ejemplo, analistas/programadores que deban estar versados en las Mathematicas del proceso de modelación física y que tengan la experiencia en programación necesaria para traducir las Mathematicas en un código de programación. La presente invención proporciona todavía otra ventaja técnica al generar un código de software que utiliza un traductor de lenguaje simbólico que proporciona la capacidad de disminuir la demora de investigación al proporcionar un medio para ' generar un nuevo simulador a partir de cualquier método de Elementos Finitos o utilizar una nueva física en un periodo de tiempo más corto que los métodos y sistemas actuales.

BREVE DESCRIPCIÓN DE LOS DIBUJOS Una comprensión más completa de la presente invención y las ventajas de la misma se puede adquirir al hacer referencia a la siguiente descripción, tomada en conjunto con los dibujos acompañantes en los cuales los números de referencia similares indican características similares y en donde: La Figura 1 muestra una ecuación Mathematica típica que se puede utilizar como entrada para la presente invención; la Figura 2 es un ejemplo de una representación residual simbólica de la ecuación de la Figura 1 ; las Figuras 3A y 3B muestran un ejemplo del código fuente generado por la presente invención a partir de la representación simbólica de la Figura 2 ; la Figura 4 es una descarga en pantalla de la paleta de notación de la interfaz mejorada del usuario de Mathematica de la presente invención; la Figura 5 es un diagrama de flujo de datos que muestra la interrelación y operación de los diferentes módulos de la presente invención; la Figura 6 muestra una digitalización del modelo de la técnica anterior; la Figura 7 muestra una solución de Elementos Finitos del mismo modelo mostrado en la Figura 6; y la Figura 8 muestra una vista general de un simulador discreto completo.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN Las modalidades preferidas de la presente invención se ilustran en las Figuras, números similares se utilizan para referirse a partes similares y correspondientes de los diversos dibujos. La presente invención proporciona un método y un sistema para generar un código de software que utiliza un traductor de lenguaje simbólico que es más flexible, más eficiente, menos propenso a errores y mucho menos dependiente de las personas con un conjunto de expertos muy especializados que cualquier método y sistema de la técnica anterior. La presente invención resuelve la dificultad para resolver problemas de Elementos Finitos multi-dimensionales al proporcionar una interfaz individual para ingresar las ecuaciones athematicas que describen el sistema físico y proporcionar una traducción simbólica automatizada, mejorada, y la generación de código que será modelada. De manera similar, la presente invención elimina la propensión de errores humanos en la traducción de las ecuaciones algebraicas al automatizar la función de entrada de la ecuación algebraica. Adicionalmente , al proporcionar una traducción simbólica, automática, mejorada a partir de ecuaciones algebraicas para el código de programación, el método y el sistema de la presente invención mejora significativamente el desempeño del código y líneas de corriente resultantes del proceso de desarrollo de los simuladores para modelar sistemas físicos. Por lo 'tanto, es posible generar en una cantidad de tiempo económicamente viable nuevos simuladores para nuevas físicas y modelar estos sistemas físicos. El método y el sistema de la presente invención de esta forma proporcionan una rápida construcción y refinamiento de prototipos para los nuevos métodos de Elementos Finitos o nuevas físicas que se puedan utilizar para crear nuevos simuladores para modelar sistemas físicos. La presente invención proporciona una interfaz individual para ingresar las formulaciones Mathematicas que describen las físicas que serán resueltas por un simulador para modelar un sistema físico, tal como por ejemplo, un simulador de Elementos Finitos para modelar el flujo fluido en medio poroso. La presente invención depende de la Mathematica de lenguaje de programación, según se describe en S. 'Wolfram, "The Mathematica Book, " 3* Edición (Wolfram Media, Cambridge Univ. Press 1996) . El programa Mathematica se incorpora en la presente invención como un medio para efectuar la manipulación simbólica de las fórmulas algebraicas en el código generado en un lenguaje de programación tal como por ejemplo, JAVA, C++ o Fortran. La Figura 1 muestra una ecuación Mathematica típica, muy similar a las ecuaciones que se puedan observar en un texto matemático típico. Las ecuaciones Mathematicas tales como aquellas mostradas en la Figura 1 comprenden las entradas generadas por un analista típico que luego se pueden ingresar en el programa Mathematica. La Figura 2 es un ejemplo de la representación residual simbólica que corresponde a la ecuación mostrada en la Figura 1. Con el fin de aplicar un método de Elementos Finitos a las ecuaciones Mathemat icas , tales como las mostradas en la Figura 1, las representaciones simbólicas mostradas en la Figura 2 se generan por lo general manualmente por parte del analista que generó las ecuaciones Mat ematicas correspondientes. En los métodos y sistemas de traducción simbólica de la técnica anterior, se requiere un experto con bastante experiencia para efectuar tanto la generación de las formulaciones Mathematicas iniciales como las representaciones simbólicas mostradas en la Figura 1 de aquellas formulaciones Mathematicas mostradas en la Figura 2. Las representaciones simbólicas de la Figura 2 representan una salida típica del programa Mathematica. Las Figuras 3A y 3B muestran un ejemplo del código fuente generado por el programa Mathematica a partir de las representaciones simbólicas (Figura 2) de las formulaciones Mathematicas mostradas en la Figura 1. En los sistemas de traducción simbólica de la técnica anterior, las tres etapas representadas por las Figuras 1, 2 y 3 se realizan utilizando altos niveles de interacción humana, con la propensión inherente de errores. La presente invención realiza la mayoría de estas funciones de manera automática. En particular, la traducción en representaciones simbólicas de las formulaciones Mathematicas generadas por un analista y la generación de códigos correspondientes se realizan automáticamente mediante paquetes Mathematica (módulos de código) de la presente invención escritos específicamente para ese fin. La presente invención también proporciona un sistema notacional que permite que un analista genere formulaciones Mathematicas iniciales para ingresar la notación Mathematica exactamente en el formato en que el analista de otra manera podría escribir aquellas notaciones. El analista simplemente puede hacer click sobre los botones de la interfaz gráfica del usuario (GUI, por sus siglas en inglés) sobre la pantalla de la computadora para ingresar las derivadas, integrales y otra simbología Mathematica. Aunque la interfaz de la presente invención no se acciona completamente por botones, el analista está libre de las rest icciones de sintaxis que Mathematica de otra manera requiere sin los módulos de código adicionales de la presente invención. En otras palabras, el analista no sólo está libre de tener que ser un experto programador en el lenguaje en el cual el código generado por último se extraerá, aunque también está libre de tener que ser un experto programador de Mathematica. La presente invención de esta forma proporciona una interfaz familiar para ingresar formulaciones Mathematicas en el programa Mathematica mismo. La Figura 4 es una descarga de pantalla de la paleta de notación 10 de la interfaz mejorada del usuario de athematica de la presente invención. La sintaxis de Mathematica se ha extendido para incluir la notación del cálculo de variación ampliamente utilizado. La paleta de notación 10 proporciona al usuario un método de "punto y click" de ingresar una notación Mathematica complicada, de tal forma que el usuario no tenga que ser un experto en Mathematica para utilizar el sistema. Obsérvese que, en general, las paletas son una característica de programación incorporada de Mathematica. Sin embargo, la paleta de notación 10 mejorada de la Figura 4 es un módulo programado habitual que mejora la funcionalidad de Mathematica más allá de su estado actual. La paleta de notación 10 de la Figura 4 proporciona a un analista la capacidad de ingresar fácilmente formulaciones Mathematicas complejas en la misma forma en que se podrían escribir manualmente o se podrían observar normalmente en un libro de texto. De esta forma, el analista tiene la comodidad y familiaridad adicionales mientras que trabaja con fórmulas Mathematicas complejas. Los analistas están libres también de tener que ser expertos programadores para, generar de manera eficiente un simulador, sin la ayuda de un programador, para un modelo de un sistema físico. La presente invención de esta forma proporciona una mejor interfaz para un analista para el programa Mathematica. Por ejemplo, la paleta de notación 10 incluye los botones 12 en los que un analista puede hacer click para ingresar notaciones complicadas similares ' a signos de integral y derivadas, operaciones especiales, etc. Estas notaciones complejas ya no tienen que ser tipeadas manualmente por parte del analista. El método y el sistema para generar un código de software que utiliza un traductor de lenguaje simbólico de la presente invención se efectúa en el código Mathematica y depende de Mathematica para su funcionalidad subyacente, aunque únicamente al grado de que cualquier código de programación dependa del lenguaje de programación en el cual se escribe. Para los fines de la presente invención, Mathematica es simplemente un lenguaje de programación que realiza la manipulación simbólica de la presente invención. De esta forma, se puede generar una descripción Mathematica de alto nivel, un análisis de método finito aplicado a esa descripción Mathematica de alto nivel y un código de programación resultante generado . El método y el sistema para generar un código de software que utiliza un traductor de lenguaje simbólico de la presente invención incluye varios paquetes de software únicos (módulos de código) escritos en el lenguaje Mathematica. Estos módulos únicos se interconec tan con diversos módulos de Mathematica ya existentes para realizar la manipulación simbólica necesaria para . crear un simulador para la modelación de, por ejemplo, un flujo fluido en un medio poroso. El código de programación utilizado en la presente invención es modular e incluye diferentes archivos de Mathematica que contienen piezas ortogonales de funcionalidad. La Figura 5 es un diagrama de flujo de datos que muestra la interrelación y operación de los diferentes módulos de Mathematica de la presente invención, tanto aquellos que son únicos para la presente invención como aquellos que ya existen dentro de Mathematica. El módulo Notación 16, el módulo Modelo 20, el módulo Modelmaker 24, el módulo Operador 28, el módulo CodeGen 32, el módulo Simplex 34, el módulo MatrixOps 36, el módulo RuleSort 38, el módulo Util 42 y el módulo de prueba 44 son algunos de los aspectos novedosos de la presente invención. Las Ecuaciones 14 y parámetros modelo 18 de la Figura 5 son las entradas proporcionadas por el usuario (el analista) . Las ecuaciones 14 y los parámetros modelo 18 representan las variables que el analista tiene por resolver. Un ejemplo de las ecuaciones 14 se muestra en la Figura 1. El módulo Notación 16 es un elemento funcional de la presente invención (el código subyacente para la paleta de notación 10 de la Figura 4) que permite que el analista ingrese sus ecuaciones y los parámetros de modelo en una computadora en la simbo logi Mathematica adecuada con menos esfuerzo significativamente que los sistemas de la técnica anterior. El analista lleva a cabo esto a través del uso de la paleta de notación 10, descrita anteriormente como parte de la Figura 4. El módulo Notación 16 permite al analista ingresar las ecuaciones 14 en el programa Mathematica. El módulo Modelo (paquete) 20 proporciona una clase de función de preparación. El módulo Modelo 20 crea objetos denominados modelos fuera de los parámetros y ecuaciones del analista. Un modelo es una colección de variables, ecuaciones y otra información necesaria para construir operadores de matriz residual y tangencial para las ecuaciones 14 determinadas. Todo lo que el código generado resultante aborda se proporciona en los términos de ios modelos de grandes objetos. Adicionalmente, el módulo Modelmaker 24 proporciona una salida de la solución a otros posibles subsistemas que .consisten de ecuaciones que el analista podría necesitar para estimar el error en la solución eventual de las ecuaciones 14. El módulo Modelmaker 24 puede incluir una función denominada "crear un modelo Lagrange" que toma como una entrada un objeto modelo 22 y sale como otro modelo, la condición de límite Diricnlet 26 para el modelo original. De manera similar, el módulo Modelmaker 24 puede incluir una función denominada "crear modelos de error" que toma como una entrada un objeto modelo 22 y da salida a otros nuevos objetos modelo 27 que estiman el error en el modelo original. Estas funciones se realizan automáticamente con una llamada de función individual; el analista no requiere codificar todos los modelos diferentes. Por lo tanto, una vez que el analista ha construido un modelo principal, la presente invención puede crear automáticamente otros modelos requeridos.

Estructura del módulo modelo 20 Diversos objetivos de diseño para el módulo 20 para modelación de Elementos Finitos de la Figura 5 han conducido a esta estructura. Es conveniente permitir que el analista observe resultados legibles por humanos, intermedios, del proceso de modelación antes de que se lleve a cabo la generación del código de lenguaje compilado. La presente invención permite al analista observar los resultados intermedios del proceso en la forma de los objetos modelo 22, 26 y 27. Adicionalmente, el archivo de empalme Mathematica también se puede referir a estos resultados intermedios, para seguridad de eficiencia. El archivo de empalme se analiza adicionalmente más adelante. Para llevar a cabo estos objetivos, parecería que ciertos resultados se deben mantener en variables globales. Sin embargo, esto podría hacer que se trabaje sobre más de un modelo individual en un tiempo excesi amente difícil y una propensión de error. Por lo tanto, el método y el sistema de la presente invención aislan el conjunto de variables para cada modelo. Esto se puede realizar al almacenar uno de los valores modelo como Valores Descendentes (funciones de construcción dentro de Mathematica) , por ejemplo, model[R], model [ PU] , etc. Los símbolos especiales R, PU, etc. se protegen en Mathematica y no se pueden ajustar por parte del usuario. Un intento para ajustar R=5, por ejemplo, dará por resultado en $Model [R] que se ajusta a 5, en donde $Model es el modelo actual . Existen dos ventajas adicionales para este diseño dentro de Mathematica. En primer lugar, el Block [{ $Model=othermodel }, expression] de construcción cambia de manera efectiva el modelo actual, únicamente durante la duración del Block. Esta construcción se utiliza por ei paquete "Operador" de Elementos Finitos (analizado con más detalle más adelante) para realizar les cálculos con las variables modelo. En segundo lugar, interceptar todos los intentos para ajustar las variables modelo permite que la verificación de errores se realice muy fácilmente en el proceso para la construcción del modelo .

Variables modelo Las siguientes variables modelo se almacenan con cada modelo: Entradas R es el sistema de ecuaciones diferenciales parciales para un modelo de. Elementos Finitos. PU es una lista de elementos desconocidos primarios para un modelo de Elementos Finitos. El modelo debe tener un SystemSpaceOb] ect (SYS) antes de que se pueda ajustar el PU. SU es una lista de elementos desconocidos secundarios, con dependencias explícitas, para un modelo de Elementos Finitos. El modelo debe tener un SystemSpaceObj ect (SYS) antes de que se ajuste el SU. EA es una lista de variables de grupo promediadas por elementos, con dependencias explícitas, para un modelo de Elementos Finitos. CF es una lista de campos constantes para un modelo de Elementos Finitos. El modelo debe tener un SystemSpaceObj ect (SYS) antes de que se ajuste el CF. K es una lista de reglas de inicial i zación de constantes globales para un modelo de Elementos Finitos . GC es una lista de coordinados globales para un modelo de Elementos Finitos. Es una variable modelo de sólo lectura (utilizar MakeSystemSpace para ajustar GC indi ectamente) . PHY es ¦ na cadena que identifica el tipo de física para un modelo de Elementos Finitos. ' Es una variable de modelo de sólo lectura (utilizar MakeNodeSpace para ajustar PHY indirectamente) . SYS es el SystemSpaceObj ect para un modelo de Elementos Finitos. TOPDIM es la dimensión topológica del Simplex para un modelo de Elementos Finitos. OP es una cadena que identifica el nombre del operador para un modelo de Elementos Finitos. Se determina el nombre del directorio generado del operador . OPTYPE ' se debe ajustar para ya sea Oplnterior u OpBoundary (omisión: Oplnterior) . Se utiliza por el módulo CodeGen 32 para seleccionar un archivo de empalme. Oplnterior y OpBoundary son valores posibles para la variable modelo OPTYPE. EQ es una lista de identi f icadores de ecuación (símbolos o símbolos suscritos) de las ecuaciones en el residuo para un modelo de Elementos Finitos . OBJ es una lista de Obj ect [ typename , ob ect ame, baseclass] para los objetos Java que aparecen en las reglas con dependencia en SU. Object[t, o, "be"; especifica un objeto Java del tipo t (el nombre de la interfaz generada) derivado de la clase base be (una cadena que contiene una trayectoria de clase completa) en la variable modelo OBJ. Objectft, o, "be", "init"] inicializa el objeto utilizando el código de lenguaje compilado encontrado en init (omisión: "nulo"). MAP es una lista de reglas de la forma global_coordinate? [point_Coordinates ] . Los coordinados puntuales se especifican como PointfO], Pointfl], etc. Estas son las omisiones para el mapa SystemSpace del modelo. INITCF, INITPU, FINCF, FINPU y UPDATE contienen una lista de llamadas de métodos y/o reglas de asignación para la inicialización, actualización o finalización de objetos externos. BUILDER -especifica los argumentos para un constructor de condición para el modelo. Debe ser una cadena o una lista de cadenas (posiblemente incorporadas), 'todas a la misma profundidad. Los ejemplos incluyen: "Operator", "WellPostCondition", { ( "DirichletCondition" } , { strings ... } } . El valor por omisión es (constructor sin condición). GPGEN especifica a los operadores qué código generar. Puede ser una lista de cero o más de las contraseñas ResidualVector, TangentMatr x , TangentAdjointMatrix, Tangentlmage y TangentAdj oint Image , o la contraseña All. Es la omisión para All. ResidualVector, TangentMatrix, TangentAdjointMatrix, Tangentlmage y TangentAdj oint Image son contraseñas del operador.

CACHE es una variable modelo que especifica el número máximo de cantidades geométricas por elementos para ocultarse en cada objeto EiementSystem. CACHE se puede ajustar a cualquier número entero no negativo o al símbolo Infinito.

Salidas SSU es una lista de elementos desconocidos secundarios y derivados de elementos desconocidos secundarios que se almacenan en el NodeSpace. Esta es una variable modelo de sólo lectura. CSU es una lista de elementos desconocidos secundarios calculados (elementos desconocidos secundarios o derivados de elementos desconocidos secundarios que NO se almacenan en el NodeSpace) . Esta es una variable modelo de sólo lectura. ZSU es una lista de elementos desconocidos secundarios (o sus derivados) que son idénticamente cero. Esta es una variable modelo de sólo lectura. RI es el valor escondido del componente interior del residuo discreto. Esta es una variable modelo de sólo lectura. RB es el valor escondido del componente límite del residuo discreto. Esta es una variable modelo de sólo lectura. TI es el valor escondido del componente interior de la tange te disc eta. Esta es una variable modelo de sólo lectura. TI se pone a cero cada vez que se llama a Residual []. Si TI es indefinido en el tiempo de generación de código, no se genera ningún operador tangencial. TB es el valor escondido del componente limite de la tangente discreta. Esta una variable modelo de sólo lectura. TB se pone a ceros cada vez que se llama a Residual [] . Si TB es indefinido en el tiempo de generación de código, no se genera ningún operador tangencial. DIM[model] regresa la dimensión espacial de un modelo de Elementos Finitos. DIM[] es equivalente a DIM[$Model] . NS es el NodeSpaceOb ect para un modelo de Elementos Finitos. Esta es una variable modelo de sólo lectura, determinada indirectamente por SYS. Obj ectTypes [ ] regresa una lista de tipos de objetos externos referenciados por el modelo de Elementos Finitos actual. Obj ect Ins tances [ pa t ern ] regresa una lista de ejemplos de todos les objetos externos en el modelo de Elementos Finitos cuyo nombre de clase coincide con el patrón.

Funciones para crear, destruir y solicitar las propiedades de los modelos BeginModel [modei ] hace modelar al modelo activo, de tal forma que las referencias a model[R], model[PU], etc. se puedan abreviar R, PU, etc. Esto regresa el conjunto de valores modelo para el modelo recientemente activo. EndModel [] desactiva el modelo activo, reactiva el modelo activo anteriormente y regresa el conjunto de valores modelo para el modelo recientemente activo. Todavía se puede tener acceso a los valores del modelo desactivado utilizando la sintaxis model [R] , model [PU], etc. $Model evalúa para el modelo activo. DefaultModel es el modelo de Elementos Finitos por omisión, activo cuando no hay un modelo activo definido por el usuario. ClearModel [model ] regresa todos los valores del modelo a sus valores por omisión. CopyModel [model 1 , model2 ] suprime model2, copia las entradas de modell en model2 y ajusta el modelo actual a model2. $ModelStack regresa la pila modelo. ModelValues [model ] regresa los valores definidos para un modelo, expresados como una lista de reglas. ModelValues [ 1 regresa los valores para el modelo activo. ModelQ[x] .regresa a True si x es un modelo de Elementos Finitos, False de otra manera. ModelValueQ [x] . regresa a True si x es una variable modelo y se ha asignado un valor a x en el modelo activo. Regresando ahora a la Figura 5, los objetos modelo 22, objeto modelo Dirichlet BC 26 y objeto modelo Error 27 (todos los modelos) se envían al módulo Operador 28, que realiza la mayoría de las manipulaciones Mathematicas . El módulo Operador 28 toma como una entrada un objeto modelo (ya sea el objeto modelo 22, el objeto modelo Dirichlet BC 26, u objeto modelo Error 27) y da salida a un cálculo simbólico de los operadores de matriz residual y tangencial, los operadores residuales y tangenciales simbólicos 30. Para dar salida a los operadores residuales y tangenciales simbólicos 30, el módulo Operador 28 en un nivel básico calcula las integrales de las ecuaciones Matemáticas 14, que pueden ser funciones de diversas variables. El programa Mathematica mismo tiene una función "integrar" incorporada que puede integrar una . ecuación . Sin embargo, un problema de análisis de Elementos Finitos de múltiples dimensiones puede estar a un nivel de complejidad que Mathematica puede no ser capaz de obtener una solución en una cantidad de tiempo bastante corta para un sentido económico. Adicionalmente, es posible realizar diversas simplificaciones en los términos de qué porciones de las expresiones Mathematicas ingresar en Mathematica. Si se realiza esta simplificación, es posible obtener una solución para las ecuaciones sin utilizar la función "integrar" de Mathematica. Para realizar esta simplificación de ecuación, aquellos elementos de las ecuaciones que son constantes se eliminan de aquellos elementos que no son constantes. El cálculo luego se realiza a diferentes niveles de instrucción. Las diferentes propiedades de las expresiones Mathematicas de esta forma se pueden utilizar para obtener la respuesta de una forma diferente. El módulo Operador 28 de esta forma se puede utilizar como un medio para evitar la integración explícita. El módulo Operador 28 de Elementos Finitos construye una solución para un sistema de ecuaciones diferenciales parciales (PDEs, por sus siglas en inglés) con respecto a un dominio al dividir el dominio en elementos Simplex y combinar las soluciones para el sistema en cada uno de los elementos Simplex indi iduales.

Simplex Un Simplex es un elemento espacial geométrico Euclídeo que tiene el número mínimo de puntos límite, tal como por ejemplo, un segmento lineal en un espacio uni-dimens ional (ID), un triángulo en un espacio 2D, o un tetraedro en un espacio 3D. De esta forma, un Simplex de dimensión n tiene n+1 vértices, marcados vértice 1,..., vértice n+1. El vértice de lado opuesto i se marca lado i. Cada lado de un Simplex nD es un Simplex (n-I)D.

Elemento maestro de las funciones base Las funciones base forman un sistema coordinado para especificar cualquier punto en un Simplex como sigue: la función base i-ésima, NL, especifica la distancia del punto del lado i-ésimo del Simplex, a lo largo de una linea del lado i-ésimo al vértice i-ésimo. Existen n+1 funciones base para un Simplex de dimensión n. Ni se define para ser 1 en el vértice i y 0 en cualquier punto del lado i. El elemento maestro en nD se define como el Simplex nD con un vértice en el origen de un sistema de coordenadas Cartesianas y los otros vértices n en los puntos Cartesianos ( 1 , 0, 0...0) , (0,1,0...0), ... ( 0 , 0 , 0...1 ) . Por ejemplo, en 2D el elemento maestro (un triángulo) tiene los vértices en (0,0), (1,0) y (0,1) . Marcar los vértices en una forma levógira puede iniciar con el vértice I en el punto (x=l, y=0), luego el lado 1 en la linea x=0, el lado 2 en la linea y=0, el lado 3 en la linea x+y=l . Para este elemento, las funciones base son como sigue: N-. (x, y) = x N (x, y) = y Ecuación (1) N2 (x, y) = 1-x-y Cualquier punto dentro del Simplex se puede especificar en los términos de funciones base. Por ejemplo, el centroide de un triángulo está en el punto (NL, Nv, N. ) = (l/3, 1/3, 1/3) .

Método de Elementos Finitos Se asume que las variables en un sistema de ecuaciones diferenciales parciales varían linealmente con respecto al lapso de cada Simplex individual. En otras palabras, sobre un Simplx nD particular, una variable p(x,y, ...) se puede rescribir como: p(x,y,...) = PiNi(x,y,...) Ecuación (2) i-l donde pi es el valor de p en el vértice i del Simplex. La totalización del lado derecho de la Ecuación (2! se refiere como la forma digitalizada o digitalización de la variable del lado izquierdo. Los pi se denominan los componentes de p. El problema · se presenta como una o más ecuaciones de la forma: ?? = 0 Ecuación (3 La integral del lado izquierdo de la Ecuación (3) se denomina el residuo continuo. El objetivo es resolver los valores de p, q, ... (los elementos desconocidos primarios) que hacen al valor residual igual a 0. Existen dos formas de calcular el valor del residuo: 1. Cuadratura numérica. Esta técnica aproxima el valor de la integral en cada Simplex con una suma ponderada del integrando evaluado en ios puntos seleccionados cuidadosamente sobre el Simplex. La desventaja de este método es la necesidad de calcular el valor del integrando en demasiados puntos de cuadratura para obtener la precisión numérica deseada. 2. Integración simbólica exacta. Una vez que la integral se ha calculado simbólicamente, el costo de evaluar numéricamente la integral puede ser mucho menor que si se estuviera utilizando una cuadratura. Sin embargo, el cálculo simbólico implicado en la integración exacta de la Ecuación (3) sobre los Simplex dimensionales mayores es difícil de resolver cuando se realiza manualmente. El fin del módulo "Operador" de Elementos Finitos 28 es realizar este cálculo simbólico.

Cálculo del residuo discreto El residuo discreto se obtiene al digitalizar cada uno de los elementos desconocidos en la Ecuación (3) utilizando la relación de la Ecuación (2) . Esto se puede llevar a cabo en Mathematica al utilizar la función incorporada ReplaceAll. Esto transforma el lado izquierdo de la Ecuación (3) en: 3Ni 3V, Ecuación (4) Teó icamente, esta integral se puede evaluar al reemplazar las funciones base con sus expresiones equivalentes en los términos de las coordenadas Cartesianas (como en la Ecuación (1), pero para dimensiones arbitrarias), y realizar una transformación de las variables para que las coordenadas Cartesianas proporcionen: { - f*** Ecuación (5) en donde 3 es el simplex Jacobiano. Sin embargo, para problemas incluso de dimensión modesta, la evaluación de la Ecuación (5) mediante un sistema algebraico por computadora en una estación de trabajo con computadoras modernas requiere de días de tiempo de cálculo y de cientos a miles de megabytes de memoria de acceso aleatorio. El módulo Operador 28 de la presente invención aprovecha un enfoque diferente. Debido a que los componentes p,, q,, etc. y los derivados de las funciones, base son constantes con respecto a cualquier Simplex particular, la Ecuación (4) se puede rescribir como: *· ·"·5·¾·····)?0 ? W,(x,y.~))'' & Ecuación (6) Esta transformación virtualmente es imposible de realizar sin una computadora, pero incluso para grandes problemas en cuatro dimensiones, un sistema algebraico de computadora que corre en una estación de trabajo moderna puede realizarla sólo en unos cuantos minutos. Utilizando el método de la presente invención, esta transformación se puede realizar utilizando la función incorporada ExpandAll, seguida por diversas aplicaciones de la función incorporada Collect para simplificar la expresión resul tante . Las integrales de la Ecuación (6) se pueden evaluar de manera eficiente utilizando la fórmula: Ecuación (7) sustituyendo la Ecuación (7) en la Ecuación (6) se proporciona una fórmula para la integral exacta de la aproximación discreta para el residuo continuo con respecto a un Simplex, denominado el residuo discreto . Obsérvese que el valor de la Ecuación (7) es constante con respecto a la permutación de los exponentes sobre las funciones base; por lo tanto, cada una de las integrales en la Ecuación (6) se puede reemplazar por una integral equivalente cuyos exponentes aparecen en orden clasificado. Esto reduce en gran medida el número de evaluaciones de la Ecuación (7) que se requieren. Cuando el residuo continuo contiene una integral con respecto al límite de un Simplex, entonces un residuo continuo individual da surgimiento a residuos discretos n+1, uno para cada lado del Simplex. El hecho de que Ni es cero en el lado i proporciona la oportunidad de simplificar los residuos discretos del lado especifico.

Clase de operaciones soportadas y operandos dentro del módulo Operador 28 El módulo Operador 28 de Elementos Finitos permite que los residuos continuos se expresen en los términos de cualquiera o todos los siguientes: 1. Elementos desconocidos primarios, elementos desconocidos secundarios (es decir, funciones de elementos desconocidos primarios) , y campos constantes, los cuales se asumen para que tengan valores definidos en cada uno de los vértices de un Simplex y se puedan expandir utilizando la Ecuación (2) . Estas cantidades se pueden definir por parte del usuario. 2. Elementos desconocidos promediados por elementos, que representan una función de cualquiera de las cantidades listadas en 1 anterior, evaluadas en el centroide del Simplex. Estas cantidades se pueden definir por parte del usuario. 3. Coordenadas Cartesianas x, y, ... Éstas se pueden ¦ definir por el usuario. 4. Primero y segundo derivados de elementos desconocidos primarios, secundarios, o de elementos promedio, con respecto a cualquiera de las coordenadas Cartesianas. Debido a que los operadores diferenciales en Mathematica, en general, se evalúan inmediatamente, es necesario implementar operadores análogos que representen estos operadores, pero que no se evalúen, de tal forma que se puedan manipular mediante transformaciones de alto nivel tales como por ejemplo el Teorema de Divergencia de Gauss. La función Dh se define par representar estos derivados. 5. Otros operadores diferenciales con base coordinada de los elementos desconocidos, tales como por ejemplo Divergencia y Gradiente. Los mismos comentarios se aplican a estos operadores según se aplican en el punto 4 anterior. Las funciones GradS, GradST, Gradh, DivS, DivST y Divh representan estas operaciones . 6. Variación de una expresión con respecto a una variable arbitraria o conjunto de variables. La función Variationh representa esta operación. 7. Funciones base y derivados de funciones base con respecto a las coordenadas Cartesianas. Las funciones BasisFunction y BasisDerivative representan estas cantidades. 8. El vector normal de cualquier lado del Simplex. La función FaceNormal representa estas cantidades . 9. La integración con respecto al interior del limite de un Simplex. Las funciones Integratelnterior e Integrateboundary representan estas operaciones. 10. La aplicación del Teorema de Divergencia de Gauss para las integrales que contienen los operadores diferenciales. La función GDT representa esta operación. Aunque cualquiera de las cantidades y operaciones listadas en los puntos 4-9 anteriores se pueden ingresar directamente por parte del usuario, por ejemplo, Integrateinterior [Variationh[w*Dh [p, x] , w] ] , esta no es una forma natural de ingresar estas cantidades para los usuarios blanco de esta invención. La sintaxis especial para ingresar los puntos 4-9 que es familiar para los usuarios blanco (por ejemplo, para el ejemplo recién proporcionado) se pueden implementar utilizando el módulo Notación 16, analizado anteriormente.

Optimización do operadora» discretos para cálculo numérico Aunque en teoría, la sustitución de la Ecuación (7) en la Ecuación (6) proporciona una fórmula para el residuo discreto, en la práctica, no se realiza esta sustitución hasta después de que la Ecuación (7) se haya evaluado numéricamente (una vez para cada conjunto único clasificado de exponentes) en el código generado. Esto reduce al mínimo el número de veces que la Ecuación (7) necesita ser evaluada, haciendo que el código generado sea mucho más eficiente. Otras expresiones que aparecen comúnmente que se optimizan de esta forma son los derivados de las funciones base y vectores normales de los lados Simplex. Estas cantidades se calculan mediante el módulo 34 Simplex de Elementos Finitos, como se muestra en la Figura 5. Estos cálculos incluyen los determinantes matriz y la inversión de las matrices simétricas, las dos contienen un alto grado de redundancia. Con el fin de identificar el número máximo posible de subexpresiones comunes, los cálculos matriz se realizan mediante el módulo 36 MatrixOps de Elementos Finitos en lugar de utilizar las funciones de Mathematica incorporadas tales como Det e Inverse. Además, los valores de los elementos desconocidos secundarios o los elementos desconocidos promediados por elementos, y sus derivados, no se sustituyen hasta que la evaluación numérica se realice en el código generado. El usuario especifica únicamente las formas funcionales de estos elementos desconocidos y el módulo Operador 28 automáticamente calcula cualesquiera derivados de estas formas funcionales que surgen durante los cálculos del operador. La función IntegralRules del módulo Operador 28 explora una expresión del operador para los acontecimientos de estos tipos de expresiones y construye los objetos Rule que contienen sus valores simbólicos. IntegralRules se llama mediante el módulo 32 CodeGen de Elementos Finitos, en donde las reglas se convierten en las asignaciones generadas para variables temporales, y mediante el módulo de prueba 44 para Elementos Finitos, en donde las reglas se utilizan junto con la función ReplaceAll Mathemat ica para evaluar numéricamente el operador. Regresando ahora a la Figura 5, los operadores residuales y tangenciales simbólicos 30 que salen del módulo operador 28 se dirigen al módulo CodeGen 32. El Módulo CodeGen 32 puede realizar la traducción de las ecuaciones 14 y los parámetros modelo 18 del lenguaje de Mathemat ica en el código de programa en JAVA, C++ o Fortran, o algún otro lenguaje de computadora de alto nivel. Además, el módulo Simplex 34, el módulo MatrixOps 36 y el módulo RuleSort 38 están disponibles para calcular las reglas de optimización para diversas cantidades que son constantes excepto para la geometría. En otras palabras, dadas las coordenadas de, por ejemplo, un triángulo, el módulo Simplex 34, el módulo MatrixOps 36 y el módulo RuleSort 38 juntos pueden calcular las diversas cantidades geométricas similares al volumen, diversas velocidades de cambio a través del lado de la construcción, etc. Estas clasificaciones de las cantidades se presentan repe idamente y pueden dar por resultado en tiempo y potencia computacional aumentados. Para evitar esto, el método y el sistema para generar un código de software que utilice un traductor de lenguaje simbólico de la presente invención calcula previamente estos diversos parámetros, como se analizó anteriormente, de tal forma que una vez que se genere el código, cada uno de los mismos necesite ser calculado sólo una vez. El módulo CodeGen 32 de Elementos Finitos de la Figura 5 define un número de funciones que producen "recortes" del código generado, que no constituyen en si mismos un módulo de programa compilable. En lugar de esto, estas porciones del código se insertan en un archivo de texto que contiene todas las declaraciones circundantes necesarias, sintaxis, etc., para formar un módulo de programa compilable. Esto se lleva a cabo utilizando el comando Mathematica Splice y varios de los archivos externos denominados archivos de empalme. Como se explicó en la documentación de Mathematica: " Spl ice [ " fi le " ] empalma la salida de Mathematica en un archivo externo. Toma el texto encerrado entre <* and *> en el archivo, evalúa el texto como una entrada de Mathematica, y reemplaza el texto con la salida de Mathematica resultante. El texto en el archive de entrada que no está encerrado entre <* and *>, se copia sin cambiar el archivo de salida. Splice [ " file " ] toma los archivos con los nombres de la forma name.mx y escribe la salida en los archivos con los nombres name.x." Por ejemplo, un archivo de empalme de lenguaje Java simple aparece como sigue: public class SpliceExample { public static void main ( String [] args ) { System . out . println ( "El coseno de la raíz cuadrada de 2 es" + < * Cos [Sqrt[2. ]]*>);} }; Si a este archivo se le proporciona el nombre SpliceExample .m ava y el comando Spl ice [ Spl iceExample . mj ava" ] se proporciona a Mathematica, entonces el archivo SpliceExamplej ava se creará, cuyos contenidos se muestran enseguida: public class Spl iceExample { public static void main ( String [ ] args) ( System. out .println ("El coseno de la raíz cuadrada de 2 es". + 0.155944);}}; Este archivo se puede compilar mediante un compilador de código de byte Java para producir un archivo de la clase Java ejecutable.

Los paquetes para formater y optimizar (técnica anterior) El módulo formatear 46 con Mathematica y el módulo optimizar 47, como se muestran en la Figura 5 están disponibles en la Red Mundial como el siguiente URLS : htt : / /ww .mathsource.com/Content/Enhancements / Interfacing/Other/0205-254 ht t : / /www .mathsource. com/Content /Enhancements/ Language/0206-592 el módulo formatear 46 traduce una clase limitada de expresiones de Mathematica en C, Fortran, o Maple (una pequeña cantidad de procesamiento posterior hace girar la salida C de la función CAssign del módulo formatear en el código Java sintácticamente correcto). La clase de expresiones que el módulo formatear 46 maneja son operaciones aritméticas, la mayoría de las funciones elementales y las asignaciones para las variables. Las limitaciones principales del módulo formatear 46 son que el mismo no genera declaraciones variables o exposiciones para control de flujo (por ejemplo, las exposiciones if-then-else bucles, etc.). El módulo optimizar 47 intenta eliminar las sub-expresiones comunes de una expresión Mathematica mediante examen sintáctico. Él módulo optimizar 47 y el módulo formatear 46 trabajan juntos de tal forma que el código generado por FormatCAssign contenga asignaciones para variables de optimización que se calculen por el módulo optimizar 47. Un ejemplo simple es como sigue: CAssign [x, Cos[a+b] + Sin[a+b], AssignOptimize-> True] 01=a+b; x=cos (ol ) +sin (ol ) ; Como se mencionó, FormatCAssign no genera las declaraciones para estas variables de optimización . El siguiente ejemplo ilustra una limitación importante de optimizar: CAssign [x, Cos[a+b] + Sin[a+b+c], AssignOptimize-> True x=cos (a+b) +sin (a+b+c) ; Aunque a+b es una sub-expresión de a+b+c, el módulo optimizar 47 no descubre esto. El problema no es una limitación de la implementación particular del módulo optimizar 47, pero de preferencia es una limitación fundamental de la optimización de la expresión accionada, por sintaxis. Existen cuatro diferentes sub-expres iones no triviales de a+b+c: a+b, a+c, b+c, a+b+c. para cualquier operador asociativo con n argumentos (por ejemplo, suma, multiplicación), existen 2r:-n-l sub-expresiones posibles, sin tomar en cuenta las sub-expresiones triviales que consisten de un argumento individual . El número de sub-expres iones de esta forma se vuelve difícil de resolver para valores incluso modestos de n .

Módulo CodeGen 32 La presente invención utiliza el modulo formatear 46 para traducir un cálculo numérico secuencial sin ramificar, tal como por ejemplo un operador residual discreto. También utiliza este módulo para generar un código para reglas de optimización que se calculan mediante la función IntegralRules del módulo operador 28. En los dos casos, el código generado consiste simplemente de una lista de declaraciones de asignación con operaciones aritméticas simples o sus lados derechos. El módulo CodeGen 32 agrega las declaraciones para las variables temporales adecuadas para el código generado . Por contraste a esta generación de código de optimización, la presente invención también puede generar un código "a partir de supresión" para inicializar una variedad de estructuras de datos que se utilicen por el motor de simulación y la interfaz de usuario del simulador. También se pueden generar códigos para permitir que ios operadores generados soliciten funciones en otros módulos de código escritos manualmente.

Generación del operador del módulo CodeGen 32 Como se mencionó anteriormente, los operadores de matriz residual y tangencial discretos contienen muchas sub-expresiones comunes que sean conocidas de antemano, tales como por ejemplo, constantes geométricas (volúmenes Simplex, derivados de función base, integrales de función base, vectores normales para los lados Simplex) y elementos desconocidos definidos por un usuario (elementos desconocidos secundarios, elementos desconocidos promediados por elemento) . El módulo CodeGen 32 solicita que la función Integral ules del módulo Operador 28 cree una lista de reglas de optimización para las constantes geométricas. Opcionalmente , se calcula el costo de calcular estas sub-expresiones, y se generan las reglas para ocultar las sub-expresiones más caras en una estructura de datos. El módulo CodeGen 32 puede calcular el conjunto de elementos desconocidos definidos por un usuario, y sus derivados, que son necesarios para evaluar al operador que está en consideración. Estos dos conjuntos de reglas se combinan y se corren a través del módulo optimizar 47 para realizar una optimización de usos generales. El módulo formatear 46 se utiliza par generar el código para evaluar las reglas de optimización y el operador mismo. Por último, las declaraciones adecuadas de las variables temporales se pretenden para el código y el código se' empalma en el archivo de empalme 50 para crear el archivo de salida 52. Existen ciertas sub-expres iones comunes que surgen durante el proceso de cálculo de derivados de elementos desconocidos definidos por un usuario que el optimizador es' incapaz de detectar. Como se analizó anteriormente, esto es un limite fundamental de optimización para expresión activada por sintaxis. Afortunadamente, al conocer algo acerca de las propiedades de las derivadas, se pueden optimizar estas expresiones. Estas expresiones surgen cuando un producto de varios términos se diferencia utilizando la regla de cadena bien conocida. En una expresión tal como por ejemplo: WmgW(x,y)) m a b g(y) Xíy)f.(x) + a bf(x)g{y)h (x,y) Ecuación (8) d(ab x)g(y) xty)) s abñ xM(y) +abf m™ fc» dy se sabe que antes de que se calculen las derivadas, la sub-expres ión ab se presentará en cada término de cada derivada, debido a que es independiente de todas las variables; que abf(x) se presentará en cada término de cada una de las derivadas con respecto a y, debido a que es independiente de y; etc. De esta forma, las expresiones en -ios lados derechos de la Ecuación (8) se pueden optimizar mediante examen de las expresiones mucho más simples en los lados izquierdos. Éste es un ejemplo de semántica, en oposición a la optimización sintáctica para depender de las semánticas del operador de diferenciación. Si se hace posible una generación de código de prueba, el módulo CodeGen 32 puede crear varios conjuntos dé valores de entrada de prueba para el operador (algunos predeterminados y algunos aleatorios) , y llamar el módulo de prueba 44 de Elementos Finitos para calcular los valores numéricos para el operador con base en estos valores de entrada. Tanto los valores de entrada como los valores de salida calculados se empalman en otra parte del archivo de empalme 50. El código actual que realiza la prueba es una porción estática (sin cambio) del archivo de empalme 50. Cuando el archivo generado 52 se compila y se corre/ el código de prueba estática alimenta los valores de entrada generados en el código de operador generado para calcular las salidas y compara aquellos con los valores de salida generados. El módulo Util 42 de la Figura 5 traduce lo que constituye un nombre de símbolo en Mathematica en nombres de símbolo válidos en el lenguaje de programación de computadora en el cual el código se generará, tal como por ejemplo, JAVA, C+ + o Fortran. Las convenciones para las cuales se hace un nombre simbólico válido en Mathematica pueden ser convenciones diferentes a partir de lo que hace un nombre simbólico válido en un lenguaje de programación tal como por ejemplo JAVA o C++. Un módulo Util 42 traduce entre Mathematica y el lenguaje de programación de producto final y regresa aquellos nombres de símbolo para el módulo CodeGen 32. Como se analizó con más detalle anteriormente, después el módulo CodeGen 32, el módulo formatear 46 y el módulo optimizar 47 realizan una porción de la traducción de códigos. El módulo formatear 46 y el módulo optimizar 47 son módulos de la técnica anterior escritos por Mark Sofroniou, como se analizó anteriormente. Una porción del código generado por el módulo CodeGen 32 no pasará a través del módulo formatear 46 o el módulo optimizar 47. En su lugar, pasa a través del archivo de empalme 50. La porción del código saliente del módulo CodeGen 32 y que va al interior del archivo de empalme 50 se representa por la flecha 62. El código 62 se genera para inicializar diversos géneros de estructuras de datos, en oposición para hacer el cálculo numérico real. De esta forma, como se analizó anteriormente, el código numérico se puede generar mediante el módulo formatear 46 y el módulo optimizar 47 y el código para inicializar la estructura de datos se puede generar directamente mediante el módulo CodeGen 32. La salida del módulo CodeGen 32 también se puede hacer pasar al módulo de prueba 44. El módulo de prueba 44 puede tomar un operador simbólico y un conjunto de entradas para que ese operador calcule cuáles salidas deben ser para ese operador. Tanto las entradas como las salidas se escriben en el código de lenguaje de programación final como se analizó anteriormente. El módulo de prueba 44 recibe el código desde el módulo CodeGen 32 que le da instrucciones para hacer una llamada a un operador, establecer una conexión en una entrada particular, observar si las entradas coinciden con la entrada esperada, y si no es asi, imprimir un mensaje de error. El módulo de prueba 44 puede servir como un aparato de prueba para el método y el sistema para generar un código de software que utiliza un traductor de lenguaje simbólico de esta invención. El archivo de Empalme 50 es una entrada para el mecanismo de Empalme creado por los diseñadores de Mathematica. Su función se ha descrito anteriormente en una porción anterior de este documento. El resultado de correr el archivo de Empalme 50 a través del programa Mathematica es un archivo que contiene el mismo nombre de archivo, pero sin la adición "m" al sufijo. Este archivo se muestra en la Figura 5 como los operadores nativos y el código de prueba 52. Los operadores nativos y el código de prueba 52 representan el código de programación final generado por el método y el sistema para generar un código de software utilizando un traductor de lenguaje simbólico de esta invención. Regresando ahora a los módulos Simplex, Matr'ixOps y RuleSort 34 , 36 y 38, estos módulos se basan en una construcción Mathematica de un Simplex, como se describió anteriormente. Se pueden realizar diversas clases de operaciones matriz para calcular las variables geométricas de una construcción tal como por ejemplo, un tetraedro. La salida proveniente del módulo Simplex 34 y el módulo MatrixOps 36 son ecuaciones para calcular los volúmenes, etc. de la construcción geométrica. Estas ecuaciones se clasifican de tal forma que cuando se escriban en el código resultante y el programa se corra, se evalúen en el orden correcto. Por ejemplo, si el código contiene una ecuación tal como por ejemplo, A=B+C y luego más tarde una ecuación D=A2, estas ecuaciones deben presentarse en el orden correcto. Esta función se realiza mediante el módulo RuleSort 38. El módulo RuleSort 38 puede incorporar un algoritmo denominado "clasificación topológica" que es bien conocido en la literatura. El módulo CodeGen 32 de la Figura 5 también puede generar un código para evaluar los operadores ingresados en el sistema. Las estructuras de datos que se generaron como parte del método de la presente invención se utilizan para efectuar la generación del código mediante el módulo CodeGen 32 que luego se envía al módulo formatear 46 y al módulo optimizar 47. El módulo CodeGen 32 toma un residuo simbólico de entrada y los operadores tangenciales 30 y genera el código para evaluar aquellos operadores. Para hacer esto, el módulo CodeGen 32 solicita que el módulo Simplex 34, el módulo MatrixOps 36 y el módulo RuleSort 38 pre-optimicen las cantidades que aparecen repetidamente en el residuo simbólico y los operadores tangenciales. En este sentido, el módulo CodeGen 32 también puede servir como un administrador de tráfico entre los diferentes módulos del método y el sistema para generar un código de software utilizando un traductor de lenguaje simbólico de la presente invención. Adicionalmente, el módulo CodeGen 32 puede ajustar diversas graduaciones para el módulo formatear 46 y el módulo optimizar 47. En el módulo formatear 46 y el módulo optimizar 47, las cantidades de optimización se pueden oscurecer en el curso de otras manipulaciones algebraicas. Ésta es la razón por la cual la pre-opt imi zación se realiza por el módulo CodeGen 32 en cooperación con el módulo Simplex 34, el módulo MatrixOps 36 y el módulo RuleSort 38. Los operadores nativos y el código de prueba 52 de la Figura 5 representan la salida del método y el sistema para generar un código de software que utiliza un traductor de lenguaje simbólico de la presente invención. Este es el código que puede utilizar un segundo conjunto de analistas para crear un modelo de un sistema físico tal como por ejemplo un flujo fluido a través de medios porosos. Los operadores nativos y el código de prueba 52 de la Figura 5 se muestran como un archivo individual, sin embargo, se pueden generar múltiples archivos para comprender un bastidor más grande de, por ejemplo, hasta 500 archivos Java o más, que tomados juntos se pueden utilizar para simular el flujo fluido en un medio poroso tal como por ejemplo un depósito para petróleo. Los operadores nativos y el archivo de código 52 se pueden utilizar junto con la interfaz de usuario de esta invención y un archivo adicional denominado un solucionador para crear modelos de sistemas físicos. Los operadores nativos y el código de prueba 52 representan un código de solución para fines generales para un sistema de álgebra lineal muy grande utilizado para representar y modelar el flujo fluido a través del medio poroso (o algún otro sistema físico) . Esta solución para fines generales, sin embargo, se puede utilizar para obtener una aproximación cada vez mejor a través del uso de un solucionador iterativo. Al reevaluar continuamente los operadores en el último estimado mejor, los nuevos estimados de la solución se pueden realizar y retroalimentar en cada solución anterior de tal forma que se puedan aproximar mejor otros valores. Estos nuevos valores se pueden retroalimentar entonces en los operadores para generar nuevas soluciones las cuales, a su vez, se pueden retroalimentar nuevamente. Los operadores nativos y el archivo de código de prueba 52 de esta forma se puede apreciar como un código núcleo que se puede volver a evaluar continuamente mediante un solucionador iterativo para obtener una aproximación cada vez más cercana a la solución verdadera para un modelo de un sistema físico. De esta forma, se podría presentar un producto final para un analista futuro que consiste de código de núcleo generado y un archivo solucionador que utiliza el código de núcleo generado. Adicionalmente, una interfaz de usuario se puede utilizar para tener acceso al solucionador y al código de núcleo generado. Juntos forman un simulador para crear modelos de sistemas físicos. El método y el sistema para generar un código de software utilizando un traductor de lenguaje simbólico de esta invención por lo tanto proporciona a un analista con las herramientas para crear un simulador del método de Elementos Finitos para modelar un sistema físico, tal como por ejemplo un flujo fluido a través de un medio poroso, de una forma más eficiente, sin errores y automática. Los errores algebraicos y los errores de traducción se reducen a través del uso de la paleta notacional que permite una entrada notacional fácil en el programa Mathematica. Adicionalmente, al proporcionar un modo muy simplificado e intuitivo de ingresar formulaciones Mathematicas complejas, no se requiere un analista que sea experto en la técnica de programación. El método y el sistema para generar un código de software utilizando un traductor de lenguaje simbólico de esta invención se puede utilizar para resolver el problema físico de moldear un depósito de petróleo. Esto es un problema cuatridimensional debido a que son necesarias tres dimensiones espaciales y una dimensión de tiempo para describir completamente un depósito de petróleo. Un depósito de petróleo es un ejemplo del mundo real de un problema cuatridimensional en el cual las ecuaciones diferenciales parciales utilizadas para describir el sistema son tan complicadas que se vuelve gigantesca la probabilidad de un error o equivocación. El método y el sistema para generar un código de software utilizando un traductor de lenguaje simbólico de esta invención permite la creación de un simulador para modelar este tipo de sistema en una cantidad de tiempo económicamente viable. Una capacidad del depósito de petróleo de esta forma se puede aprovechar de manera más eficiente debido a que una ' compañía que está extrayendo petróleo del depósito de petróleo puede crear más rápida y económicamente un simulador para modelar de manera más precisa el flujo fluido del depósito . El método y el sistema para generar un código de software utilizando un traductor de lenguaje simbólico de esta invención proporciona que un analista sea tipicamente un experto en dinámicas de fluido, cuyo trabajo es generar un simulador para modelar un sistema físico, con un modelo de trabajo de las físicas particulares, es decir, ese conjunto particular de ecuaciones que el analista desea modelar. De esta forma, el analista tiene a su disposición un simulador discreto de trabajo. Un simulador discreto de trabajo incluye una interfaz de usuario, un solucionador (un sistema que resuelve un conjunto de ecuaciones para un modelo discreto, un modelo de coincidencia o un modelo del tipo digitalización) y operadores nativos y el código de prueba 52 de la presente invención. Por ejemplo, la Figura 6 muestra una digitalización modelo de la técnica anterior. El modelo mostrado en la Figura 6 es un modelo 3D de una fase de una cavidad en el centro de un depósito circular. La Figura 7 muestra una solución de Elementos Finitos de la misma cavidad utilizando el método y el sistema para generar un código de software utilizando un traductor de lenguaje simbólico. El modelo de la Figura 7 asimismo es un modelo digitalizado y existe un valor para cada uno de los nodos de los triángulos que constituyen el modelo . El método y el sistema para generar un código de software utilizando un traductor de lenguaje simbólico de la presente invención permite que un analista individual genere a partir de la descripción de ecuación diferencial parcial y las físicas, la descripción que deseen modelar, un simulador discreto para resolver el conjunto de ecuaciones para un modelo discreto particular del sistema físico aquí descrito. Este simulador discreto entonces se puede utilizar por un segundo analista, por ejemplo, una compañía geoquímica, que no está interesada en la creación del simulador mismo, pero que está interesada en crear un modelo utilizando el simulador y que conoce la forma de utilizar el simulador. Este segundo analista podría ser un grupo de analistas de flujo fluido e ingenieros que trabajan en el mismo para resolver un problema modelo específico utilizando ese simulador. El analista del segundo usuario final en este caso esta interesado en recibir una variedad de físicas en el simulador proporcionadas a los mismos por el método y el sistema para generar un código de software utilizando un traductor de lenguaje simbólico de esta invención. Por ejemplo, estos analistas pueden desear físicas que puedan manipular el flujo a través de medios porosos o mixtos. Es decir, donde el gasto y dificultad entra en los sistemas de la técnica anterior para crear un simulador debido a que cada una de estas físicas adicionales es un ciclo de desarrollo novedoso completo y un nuevo lote completo de código que debe ser generado. Los sistemas de la técnica anterior requieren la generación de este nuevo código en gran parte manualmente, con analistas expertos y programadores que ingresan y traducen los datos. El método y el sistema para generar un código de software que útiliza un traductor de lenguaje simbólico de esta invención automatiza este proceso y hace económicamente viable la generación de las físicas de seguimiento para suministrar el simulador discreto al analista del usuario final. De esta forma, las nuevas físicas se pueden agregar rápidamente y se puede crear un nuevo modelo simulador. En este sentido, el título de esta invención es una clasificación del sistema de generación del producto. El usuario final del método y el sistema para generar un código de software utilizando un traductor de lenguaje simbólico de esta invención puede cambiar los parámetros de las ecuaciones utilizadas por el simulador para modelar, por ejemplo el depósito de petróleo. Asimismo, el usuario final puede describir Mathematicamente las cavidades que bombearan petróleo desde el depósito y aplicar una condición limite a las ecuaciones diferenciales parciales como las que describe el sistema y resolver las ecuaciones utilizando el simulador. El método y el sistema para generar un código de software utilizando un traductor de lenguaje simbólico de esta invención proporciona un simulador para ajustar la ecuación particular que permita que un analista de usuario final modele un sistema físico particular al ingresar los limites de ese sistema físico en el simulador. El método y el sistema para generar un código de software utilizando un traductor de lenguaje simbólico de esta invención de esta forma proporciona un método mejorado y un sistema para generar un simulador de problemas de Elementos Finitos para modelar un sistema físico tal como por ejemplo, el flujo fluido dentro de medios porosos. La Figura 8 proporciona una vista general de un simulador completo que se puede crear utilizando el método y el sistema para generar un código de software utilizando un traductor de lenguaje simbólico de esta invención. El PDE y la descripción de físicas 70 de la Figura 8 es la entrada del analista que debe resolverse para modelar un sistema físico en el simulador 76. El sistema 72 para generación de físicas de athemat ica toma el PDE y la descripción de físicas como una entrada y da salida a las físicas 52 generadas (véase la Figura 5), como se describió anteriormente. Las físicas 52 generadas pueden ser múltiples sistemas físicos 52 generados y se pueden insertar en el simulador 76 como se muestra en la Figura 5. Las físicas 52 generadas pueden estar dinámicamente disponibles para los analistas del usuario final para que los utilicen en la modelación (no para la entrada de datos) . La Figura 8 muestra, por ejemplo, tres físicas 52 generadas que proporcionan a los analistas de usuario final una selección de físicas a partir de las cuales seleccionar. De esta forma, se puede utilizar un simulador 76 individual con diferentes físicas 52 generadas insertadas. Al proporcionar físicas 52 generadas múltiples para que sean utilizadas en el simulador 76, es posible un cambio de posición más eficiente y rápido que una cantidad de tiempo económicamente viable cuando en un sistema físico se requiere la generación de una nueva descripción. De esta forma, por ejemplo, si se encuentra un depósito que todavía no se haya contemplado, se pueden crear unas nuevas físicas generadas en una cantidad de tiempo relativamente corto. Un usuario final puede proporcionar las ecuaciones diferenciales que necesitan ser modeladas y luego se pueden insertar en el sistema 72 para generación de físicas de Mathematica para generar rápidamente un simulador que será utilizado para modelar aquellas ecuaciones.

Aunque' la presente invención se ha descrito en detalle en la presente con referencia a las modalidades ilustrativas, se debe entender que la descripción se presenta únicamente a manera de ejemplo y no se debe considerar en un sentido limitante. Por lo tanto, se debe entender adicionalmente que muchos cambios en los detalles de las modalidades de esta invención y las modalidades adicionales de esta invención serán evidentes y se pueden realizar por aquellas personas con experiencia normal en la técnica que hagan referencia a esta descripción. Se contempla que todos estos cambios y modalidades adicionales están dentro del espíritu y alcance verdadero de esta invención como se reivindica más adelante.

Claims (1)

1. NOVEDAD DE LA INVENCIÓN Habiendo descrito el presente invento, se considera como "una novedad y, por lo tanto, se reclama como propiedad lo contenido en las siguientes REIVINDICACIONES : 1. Un método para crear en una computadora uno de los operadores nativos y un archivo de código de prueba para un simulador de Elementos Finitos para modelar el flujo fluido en un medio, que comprende los pasos de: ingresar en un traductor de lenguaje simbólico una o más ecuaciones y parámetros que describen el modelo que será creado por el simulador; generar uno o más objetos modelo a partir de una o más ecuaciones y parámetros; generar una representación simbólica para uno o más operadores de matriz residual y tangencial de uno o más objetos modelo; generar reglas de optimización para cantidades constantes geométricas de los operadores de matriz residual y tangencial; generar el código de núcleo numérico y la estructura de datos que inicializa el código" de núcleo en un lenguaje de programación predeterminado a partir del lenguaje del traductor de lenguaje simbólico; formatear y optimizar el código de núcleo numérico utilizando el traductor de lenguaje simbólico; generar los operadores nativos y el archivo de código de prueba al procesar el archivo de empalme a través del traductor de lenguaje simbólico para proporcionar los operadores nativos y el archivo de código de prueba. 2. El método según la reivindicación 1, en donde el paso para ingresar comprende ingresar la una o más ecuaciones y parámetros utilizando una interfaz gráfica de usuario para el traductor de lenguaje simbólico, la interfaz gráfica de usuario comprende una paleta notacional para ingresar símbolos matemáticos . 3. El método según la reivindicación 1, en donde el medio poroso comprende un depósito de petróleo . 4. El método según la reivindicación 1, que comprende además el paso de generar uno o más objetos modelo de error y objetos modelo de condición límite Dirichlet a partir de uno o más objetos modelo para estimar el error en la una o más ecuaciones, y en donde la generación de un paso de representación simbólica comprende además generar la representación simbólica utilizando el uno o más objetos modelo de error. 5. El método según la reivindicación 4, en donde los objetos modelo y los objetos modelo de error son objetos intermedios que se pueden observar 12. El método según la reivindicación 11, que comprende además el paso de resolver la una o más ecuaciones sin utilizar la función Intégrate de Mathematica . 13. El método según la reivindicación 1, en donde la una o más ecuaciones son ecuaciones diferenciales parciales. 14. El método según la reivindicación 13, en donde la una o más ecuaciones describen un sistema físico cuatr idimensional . 15. El método según la reivindicación 1, en donde el paso de ingresar se realiza por parte de un ser humano y todos los otros pasos se realizan automáticamente por la computadora. 16. El método según la reivindicación 1, en donde el simulador comprende un solucionador , una interfaz de usuario y los operadores nativos y el archivo de código de prueba. 17. Un sistema para crear en una computadora uno de los operadores nativos y el archivo de código de prueba para un simulador de elementos finitos para modelar el flujo fluido en medio poroso, que comprende : un medio para ingresar en un traductor de lenguaje simbólico una o más ecuaciones y parámetros que describen el modelo que será creado por el simulador; las instrucciones para generar uno o más objetos modelo a partir de la una o más ecuaciones y parámetros las instrucciones para generar una representación simbólica para uno o más operadores de matriz residual y tangencial del uno o más objetos modelo ; las inst ucciones para generar reglas de optimización para cantidades constantes geométricas de los operadores de matriz residual y tangencial; las instrucciones para generar el código de núcleo numérico y la estructura de datos que inicializa el código de núcleo en un lenguaje de programación de alto nivel a partir del lenguaje del traductor de lenguaje simbólico; las instrucciones para formatear y optimizar el código de núcleo numérico utilizando el traductor de lenguaje simbólico; y las instrucciones para generar los operadores nativos y el archivo de código de prueba al procesar el archivo de empalme a través del traductor de lenguaje simbólico para proporcionar los operadores nativos y el archivo de código de prueba. 18. El sistema según la reivindicación' 17, en donde las instrucciones de ingreso comprenden además instrucciones para ingresar la una o más ecuaciones y los parámetros que utilizan una interfaz gráfica de usuario para el traductor de lenguaje simbólico, la interfaz gráfica de usuario comprende una paleta notacional para ingresar símbolos matemáticos . 19. El sistema según la reivindicación 17, en donde el medio poroso comprende un depósito de petróleo. 20. El sistema según la rei indicación 17, que comprende además instrucciones para generar uno o más objetos modelo de error a partir de uno o más objetos modelo para estimar el error en la una o más ecuaciones, y en donde las instrucciones para generar una representación simbólica comprenden además instrucciones para generar la representación simbólica utilizando el uno o más objetos modelo de error . 21. El sistema según la reivindicación 20, en donde los objetos modelo y los objetos modelo de error son objetos intermedios que se pueden observar por el usuario y que se pueden utilizar para verificar el progreso. 22. El sistema según la reivindicación 17, en donde las instrucciones para generar las reglas de optimización comprenden calcular previamente las cantidades constantes geométricas. 23. El sistema según la reivindicación 22, en donde el cálculo previo comprende utilizar un método Simplex y operaciones matriz para calcular las cantidades constantes geométricas y clasificar una o más ecuaciones resultantes para colocarlas adecuadamente en el código de núcleo numérico. 24. El sistema según la reivindicación 17, en donde las reglas de optimización son reglas para optimización semántica. 25. El sistema según la reivindicación 17, que comprende además instrucciones para convertir los nombres simbólicos provenientes del lenguaje del traductor de lenguaje simbólico al lenguaje de programación de alto nivel. 26. El sistema según la reivindicación 17, que comprende además instrucciones para generar un conjunto de entradas de prueba para uno o más de los operadores simbólicos de matriz residual y tangencial y calcular las salidas del uno o más operadores simbólicos de matriz residual y tangencial con base en las entradas generadas para probar los errores. 27. El sistema según la reivindicación 17, en donde el traductor de lenguaje simbólico es Mathematica . 28. El sistema según la reivindicación 27, que comprende además instrucciones para resolver la una o más ecuaciones sin utilizar la función Intégrate de Mathematica. 29. El sistema según la reivindicación 17, en donde la una o más ecuaciones son ecuaciones diferenciales parciales. 30. El sistema según la reivindicación 29, en donde la una o más ecuaciones describen un sistema físico cuatridimensional . 31. El sistema según la reivindicación 17, en donde los medios para ingresar son una interfaz de computadora y en donde un humano ingresa la. una. o más ecuaciones y parámetros y todas las otras instrucciones se realizan automáticamente por la computadora . 32. El sistema según la rei indicación 17, en donde el lenguaje de programación de alto nivel es Java, C++ o Fortran. 33. El sistema según la rei indicación 17, en donde el simulador comprende un solucionado , una interfaz de usuario y los operadores nativos y un archivo de código de prueba.