Ver versión completa : ¿CYPE analiza los programas de la competencia?
Una cosas sísifo, en CYPE me imagino que analizareis los programas de la competencia ¿no?
En todo caso me parece bien que no opines sobre este particular, ;) aunque hay otros foros en los que gente relacionada con algunos productos no tiene ningun empacho en hablar de los de la competencia.
saludos.
en CYPE me imagino que analizareis los programas de la competencia ¿no?.
Ten en cuenta que en CYPE hay varias personas diseñando software, y cada uno tiene sus preferencias respecto a mirar o no los programas de la competencia. A mí en concreto nunca me ha gustado. Yo creo que, para hacer un programa realmente innovador, mirar los programas existentes es contraproducente. Al final, acabas haciendo una versión mejorada del programa de la competencia y, encima, te olvidas de cosas.
Por supuesto, si lo que se quiere es hacer una versión mejorada de un programa concreto de la competencia, que a veces es el caso, lo mejor es estudiárselo.
Tú parece que llevas bastante tiempo como usuario de programas de varias empresas. Si recuerdas, antes de CYPECAD los programas que había eran SICE, de Soft, Porto, de PHECOR, el de pórticos de Arktec (no recuerdo si se llamaba EH o EPH), y programas de calculista tipo el de Promonal de finales de los 80. ¿Crees que CYPECAD habría sido mejor por haber mirado aquellos programas?
En todo caso me parece bien que no opines sobre este particular, ;) aunque hay otros foros en los que gente relacionada con algunos productos no tiene ningun empacho en hablar de los de la competencia.
Si me mandas un MP con la dirección, entraré a curiosear.
Saludos
No me refería a programas de estructuras, sino especialmente de diseño gráfico (hay gente de Autodesk y de Allplan en algunos foros hablando de su producto o del de la competencia) o por lo meos da esa impresión.
Saludos.
Yo creo que, para hacer un programa realmente innovador, mirar los programas existentes es contraproducente. Al final, acabas haciendo una versión mejorada del programa de la competencia y, encima, te olvidas de cosas.
Por supuesto, si lo que se quiere es hacer una versión mejorada de un programa concreto de la competencia, que a veces es el caso, lo mejor es estudiárselo.
Tú parece que llevas bastante tiempo como usuario de programas de varias empresas. Si recuerdas, antes de CYPECAD los programas que había eran SICE, de Soft, Porto, de PHECOR, el de pórticos de Arktec (no recuerdo si se llamaba EH o EPH), y programas de calculista tipo el de Promonal de finales de los 80. ¿Crees que CYPECAD habría sido mejor por haber mirado aquellos programas?
Hombre, yo creo que lo importante es la mejora continua (vosotros teneis tambien la ISO 9000 ya sabeis a lo que me refiero). A veces no es preciso inventar la pólvora ni hacer cosas distintas de la competencia, tampoco digo plagiar burdamente un programa, pero ¿para que cambiar una cosa que funciona o está bein hecha?
Al final los usuarios tenemos que utilizar varios programas, algunos son mejor para algunas cosas y otros para otras. Lo ideal sería dominar un solo programa que nos sirviera prácticamente para todas las estructuras que tuvieramos que hacer en el día a día. Cype es un buen programa para ello, y es el que manejo en el 99% de los casos desde aproximadamente el año 1996, pero tambien tengo el tricalc, que, si bien lo utilizo poco, me resuelve algunas cosas que con Cype me resultarían algo mas complejas, aunque tal vez esto se pueda resolver en un futuro su Cype mejora como lo está haciendo y con algo de formación por mi parte.
Saludos.
jasonkid13
23/12/2005, 16:43
Estoy con vorpal...
tampoco creo que analizar un programa de la competencia te cierre la mente tanto (ni que fueran tan malos :D :D :D )
E igual programas de la competencia no, pero seguro que a pequeñas rutinas de cálculo a nivel mas académico (estudios de doctorado e investigaciones mas o menos innovadoras) les echareis un ojo de vez en cuando si os suenan bien ¿no?
¿o tan potente es el equipo de diseño y desarrollo de vuestro software? ¿No hay ningún apoyo externo? Imagino que sí, si puedes (no es secreto empresarial ni nada de eso) tengo cierta curiosidad con esto
sds a todos
carsanor
24/12/2005, 13:42
hoy en día lo que mas prima en un programa, no es la capacidad, rapidez... sino que sea intuitivo, que sin saber nada, o sabiendo lo basico, de los programas basicos, puedas acercarte a el.
facil aprendizaje.
hay muchos programas en que te cuesta mucho llegar a ellos, si que es cierto que una vez que se sabe parece facil. pero les falta intuición. botones en que aparezca un menu para que son, rapidos accesos a la ayuda o ejemplos... etc.
un saludo
Estimado jasonkid13, lo que se utiliza normalmente en un programa comercial suele estar en los libros más de veinte años antes, y en algunos casos se remonta a más de un siglo atrás. La mayor parte de los algoritmos son anteriores a la existencia de los ordenadores. No suele ser necesario buscar las últimas tecnologías.
Para lo que sí es importante buscar apoyo externo es para fijar las prestaciones de un programa nuevo. Cuando es una segunda versión del programa, con escuchar a los clientes suele ser suficiente, pero si es un programa sobre algo de lo que no se tiene experiencia, es fácil hacer un programa que resuelve un problema teórico a la perfección, pero que realmente no interesa a nadie. Lo más grave, además, es que las prestaciones que te has inventado y no interesan a casi nadie tienen que ser mantenidas en sucesivas versiones.
jasonkid13
08/01/2006, 12:46
Estimado jasonkid13, lo que se utiliza normalmente en un programa comercial suele estar en los libros más de veinte años antes, y en algunos casos se remonta a más de un siglo atrás. La mayor parte de los algoritmos son anteriores a la existencia de los ordenadores. No suele ser necesario buscar las últimas tecnologías.
Metiendome en un berenjenal que no domino... De acuerdo en que la base teórica de los algoritmos de cálculo matricial, la matematica discreta y las transformadas integrales se conocen mucho antes del uso de ordenadores... pero su aplicación y optimización?
Si no recuerdo mal, el primer algoritmo MEF aplicable a una rutina de cálculo informatico fue creado por ingenieros de BOEING para modelizar los esfuerzos en punta de ala hacia el año 40...
Los ultimos grandes avances en este campo son del 70 aproximadamente... y estoy seguro que los métodos de implementación y resolución de ciertos problemas matemáticos de alto nivel han cambiado desde hace 30 años... (no me puedo creer que lo que fuera válido para el hardware del 80 lo sea para los microprocesadores actuales)
Por supuesto que la aplicación de un modelo teórico al campo comercial tarda 10-20 años en función de las ventajas que genere ($$)... ¿pero realmente no os habeis servido jamás del nuevo metodo de implementacion que ha desarrollado tal chaval de la autonoma o de esa solucion teórica que ha desarrollado tal otro departamento de estructuras?
ya sabeis eso tan raro del I+D+I :)
Desde mi mas profunda ignorancia un saludo ;)
J
JF Sebastian
08/01/2006, 17:26
Ten en cuenta que los avances teoricos se realizan de muy en cuando en cuando, por ej. hace 30 años K.J. Bathe publica su tesis doctoral con la aproximacion de autovalores por subespacios, Irons su tecnica de resolucion de ecuaciones por el metodo frontal o mas recientemente un equipo de la Univ. de Cantabria en su libro "orthogonal sets and polar methods in linear algebra" proponen un metodo revolucionario para el reanalisis de sistemas de ecuaciones e inversas de matrices, incluso simbolicas -que segun ellos es como pasar de trabajar a pico y pala a trabajar con escavadora-. Estos desarrollos no los suelen realizar chavales en sus ratos libres sino gentes que llevan media vida dedicada al estudio de un determinado campo.
Por otro lado la optimizacion de algoritmos no suele ser tan importante hoy en dia (dado que tales algoritmos ya estan muy optimizados) frente al incremento en prestaciones de las computadoras y la aplicacion de las nuevas herramientas informaticas que se llevan gran parte del esfuerzo por parte de los programadores. Recuerdo los tiempos de MS-DOS cuando habia que pelearse programando sucedaneos de memoria virtual para resolver sistemas de ecuaciones, accesos a memorias extendidas, expandidas... cuando ahora el uso de la memoria virtual es totalmente transparente, al menos para las tareas comunes, (aqui sisifo te podra informar mejor).
En el futuro proximo se pondran de moda los sistemas multiprocesadores y supongo que los de Intel desarrollaran sus propias rutinas de explotacion de dichos recursos (nadie mejor que ellos para realizarlas :rolleyes: ) dejando en manos de los programadores de aplicaciones la tarea del diseño de interfaces graficas...
Para que os hagais una idea, CYPECAD utiliza, para la resolución del sistema de ecuaciones general, el método frontal de Irons (años 70). La implementación concreta está adaptada a partir de una implementación en FORTRAN de unas fotocopias de un libro, creo recordar que de Hinton y Owen, que tengo desde los tiempos en que no me podía permitir comprar un libro (hace más de 20 años). Tiene como novedoso que le metí un sistema de condensación de subestructuras (¿siglo XIX?) al incorporar los forjados reticulares y de losa maciza, con la ventaja de que una subestructura puede ser reutilizada varias veces, aprovechando con esto el concepto de grupos de plantas de CYPECAD. Para el análisis dinámico, realiza la inversión de la matriz por medio de una descomposición LU que programé por primera vez en el año 80 para una calculadora HP41C con 2 Kb de memoria. Curiosamente, la descripción del algoritmo la saqué del manual de programación de una calculadora Texas que me prestó un amigo para un examen. El cálculo de autovalores y autovectores se realiza con el método de la potencia (Power Method, del año del catapum) que, aunque es el ABC para cualquier estudioso de la materia, en palabras del propio Irons es "todo lo que se necesita saber", sobre todo si el problema está bien condicionado, es decir, siempre en una estructura de edificación, salvo que hayamos introducido un mecanismo. Etc, etc.
soloarquitectura
08/01/2006, 20:19
Para que os hagais una idea, CYPECAD utiliza, para la resolución del sistema de ecuaciones general, el método frontal de Irons (años 70)
¡Cielos! ¡Todos los secretos de CYPECAD al descubierto! :D
¡Cielos! ¡Todos los secretos de CYPECAD al descubierto! :D
Lo dices de cachondeo, supongo. :eek: :eek:
soloarquitectura
08/01/2006, 20:25
Lo dices de cachondeo, supongo
Noooo, que va :) :) :)
Por cierto, si alguien está interesado en el método que busque el libro:
IRONS, B. M. 1970. A frontal solution program for finite element analysis
JF Sebastian
08/01/2006, 21:18
a partir de una implementación en FORTRAN de unas fotocopias de un libro, creo recordar que de Hinton y Owen,
Oye sisifo, ese libro se titula por casualidad "Finite Element Programming" lo tengo escaneado y encuadernado de unas fotocopias de un amigo que hizo un pfc de barras 2D y cuadrilateros.
Es de 1977 y por cierto la subrutina front les ocupa unas 300 lineas con comentarios incluidos
a partir de una implementación en FORTRAN de unas fotocopias de un libro, creo recordar que de Hinton y Owen,
Oye sisifo, ese libro se titula por casualidad "Finite Element Programming" lo tengo escaneado y encuadernado de unas fotocopias de un amigo que hizo un pfc de barras 2D y cuadrilateros.
Es de 1977 y por cierto la subrutina front les ocupa unas 300 lineas con comentarios incluidos
Me parece que sí. Lo tendría que confirmar. Hace como 10 años que no lo reprogramo. En cualquier caso, fíjate en que el "Cuentame cómo pasó" va por dos años antes y en 3 ó 4 episodios nos pilla.
Por cierto, si alguien está interesado en el método que busque el libro:
IRONS, B. M. 1970. A frontal solution program for finite element analysis
Cuanto más cerca de la fuente, más clara es el agua, pero a veces falta caudal.
http://epubs.cclrc.ac.uk/bitstream/612/sRAL2004026.pdf
Contiene bibliografía en cantidad suficiente para aburrir a las cabras:
K.A. Cli
e, I.S. Du
, and J.A. Scott. Performance issues for frontal schemes on a cache-based high
performance computer. Inter. Journal on Numerical Methods in Engineering, 42, 127{143,
1998.
I.S. Du
. MA32 - a package for solving sparse unsymmetric systems using the frontal method.
Report AERE R10079, Her Majesty's Stationery Oce, London, 1981.
I.S. Du
. Enhancements to the MA32 package for solving sparse unsymmetric equations. Report
AERE R11009, Her Majesty's Stationery Oce, London, 1983.
I.S. Du
. Design features of a frontal code for solving sparse unsymmetric linear systems out-ofcore.
SIAM J. Scienti c and Statistical Computing, 5, 270{280, 1984.
I.S. Du
and J.A. Scott. MA42 { a new frontal code for solving sparse unsymmetric systems.
Technical Report RAL-93-064, Rutherford Appleton Laboratory, 1993.
I.S. Du
and J.A. Scott. The design of a new frontal code for solving sparse unsymmetric systems.
ACM Trans. Mathematical Software, 22(1), 30{45, 1996.
P. Hood. Frontal solution program for unsymmetric matrices. Inter. Journal on Numerical
Methods in Engineering, 10, 379{400, 1976.
HSL. A collection of Fortran codes for large-scale scienti c computation, 2004. See
http://hsl.rl.ac.uk/.
Y.F. Hu and J.A. Scott. Ordering techniques for singly bordered block diagonal forms for
unsymmetric parallel sparse direct solvers. Technical Report RAL-TR-2003-020, Rutherford
Appleton Laboratory, 2003.
B.M. Irons. A frontal solution program for nite-element analysis. Inter. Journal on Numerical
Methods in Engineering, 2, 5{32, 1970.
J.A. Scott. Exploiting zeros in frontal solvers. Technical Report RAL-TR-98-041, Rutherford
Appleton Laboratory, 1997.
J.A. Scott. On ordering elements for a frontal solver. Communications in Numerical Methods in
Engineering, 15, 309{323, 1999.
J.A. Scott. The design of a portable parallel frontal solver for chemical process engineering
problems. Computers in Chemical Engineering, 25, 1699{1709, 2001a.
J.A. Scott. A parallel solver for nite element applications. Inter. Journal on Numerical Methods
in Engineering, 50, 1131{1141, 2001b.
14
J.A. Scott. Multilevel hybrid spectral element ordering algorithms. Technical Report RAL-TR-
2004-018, Rutherford Appleton Laboratory, 2004. Communications in Numerical Methods
in Engineering, to appear, 2004.
S.W. Sloan. An algorithm for pro le and wavefront reduction of sparse matrices. Inter. Journal
on Numerical Methods in Engineering, 23, 1315{1324, 1986.
soloarquitectura
08/01/2006, 22:19
http://epubs.cclrc.ac.uk/bitstream/612/sRAL2004026.pdf
Contiene bibliografía en cantidad suficiente para aburrir a las cabras
Muy bueno :cool:
Si alguien tiene interés en los métodos frontales, no hay que olvidar, además, los algoritmos de ordenación de elementos. Igual que los métodos de matrices en banda son sensibles a la ordenación de nudos, los métodos frontales son sensibles a la ordenación de elementos, y a veces se adelanta más mejorando el algoritmo de ordenación que el de resolución.
Pablo8000
19/01/2006, 18:01
en CYPE me imagino que analizareis los programas de la competencia ¿no?.
En todo caso me parece bien que no opines sobre este particular, ;) aunque hay otros foros en los que gente relacionada con algunos productos no tiene ningun empacho en hablar de los de la competencia.
Si me mandas un MP con la dirección, entraré a curiosear.
Saludos
Yo también quisiera saber esas direcciones para curiosear, si no llego demasiado tarde :) :)
berobreo
09/08/2007, 15:25
Vaya, menudo hilo me había perdido.
Si al final va a resultar que cypecad son media docena de líneas de código para calcular y tropecientos megas de pdf.:D
Si al final va a resultar que cypecad son media docena de líneas de código para calcular y tropecientos megas de pdf.:D
Algo más de media docena. Teniendo en cuenta que, en total, son varios millones de líneas, un porcentaje bajo siguen siendo muchos miles de líneas.
De todos modos, hay mucha más cantidad de código en comprobaciones de que la geometría está correctamente introducida que en el cálculo en sí. La distribución de armados en vigas, por ejemplo, tiene más código y es más complicada que todo el cálculo de esfuerzos. Lo mismo, el dibujo de cualquiera de los planos.
Vale......y entonces Sisifo.....cuando pasaremos del "C" a "C++"??????????
Algo creo yo que avanzaremos...:-":-"
berobreo
09/08/2007, 23:42
De todos modos, hay mucha más cantidad de código en comprobaciones de que la geometría está correctamente introducida que en el cálculo en sí. La distribución de armados en vigas, por ejemplo, tiene más código y es más complicada que todo el cálculo de esfuerzos. Lo mismo, el dibujo de cualquiera de los planos.
Cuestiones que por otra parte son las algunas de las grandes bazas de cypecad.
No sé si este hilo es el adecuado, pero hay algunos puntos que creo que, aunque en su momento pudiesen ser los más acertados, parece que piden una revisión. En mi humilde opinión, la hipótesis de diafragma rígido puede ser uno de ellos. Comparto que fue una hipótesis muy útil, pero a estas alturas ya supone cierto lastre.
Por otra parte, todo lo que tiene que ver con muros me parece lo más flojo del programa a estas alturas. Tiene muchas limitaciones -muchas de las cuales están comentadas en las listas de deseos- y da muchísimos errores.
tlatoani
11/08/2007, 00:58
¿Y nunca han sentido el impulso de hacer ingeniería inversa? a algun trozo de programa para ver como hace algo, tal vez como grafica la estructura ó como permite ver los diagramas de momentos, cortes, deformaciones etc.
con el desarrollo actual de los desensambladores aún es bastante latoso (me imagino), aunque tengo entendido que algunas tesis de doctorado permiten vislumbrar en el futuro cercano desensambladores que no solo obtendrán el lenguaje máquina, sino el codigo fuente en algún lenguaje como el "c" ó similares.
Claro que las medidas de seguridad también se habrán de modernizar.
En fin si la respuesta a la pregunta inicial es no, sin duda con candidatos firmes a la canonización.
Saludos......... tlatoani;);)
yo soy usuario de bastantes programas de cálculo: robot, sofistick, saap y cype (con todas sus versiones y módulos), y si es verdad que el cype a nivel de potencia de cálculo no tiene nada que hacer contra los programas de elementos finitos, al ser un programa matricial, pero lo que es indudable, que en el mundo de la ingenieria en el cual todo vale mientras sea rapido, indefiniciones y dudas, el cype tiene la capacidad casi mágica que es capaz de realizar un "proyecto" con algo mas que una burda descripción geometrica y un par de cosas mas, intuitivamente y con muchisima eficacia. Por lo tanto opino que para los estructureros de edificación el CYPE no tiene parangon ni competencia, pues los demas programas hay que hacer una carrera para modelizar una viga, losa y ya no digamos edificio, en obra civil, al estar todo mejor definido es mejor los elementos finitos al ser mas "exactos".
Resumiendo, burbuja inmoviliaria, prisas y "numeros gordos" el cype es monumental, cuando se acabe la gran cantidad de proyectos en la ingeniería primara mas el detalle y el calculo exacto con E mayuscula, y se tender´´a a hacer un estudio mas pormenorizado de cada elemento estructural.
PD: esto es una opinion muy personal, desde el punto de vista de mi experiencia como proyectista de estructuras (y por que no decirlo ... calculista)
berobreo
11/08/2007, 13:19
primara mas el detalle y el calculo exacto con E mayuscula
Comparto lo del detalle, no lo de la exactitud. ¿Qué exactitud puede esperarse cuando los datos de cargas son simplemente valores redondos en KN/m² o los límites de flecha se limitan a L/n?
jejeje eso es exactamente, lo de la sobrecarga me imagino que tiene espectativa de tener larga vida, pues es dificil establecer otro sistema, y lo de la flecha creo que con los elementos finitos pasaremos de medir flechas a compatibilizar deformaciones. pero claro, dile a alguien que necesitaba visar el proyecto antesdeayer que le vas a hacer un estudio de deformaciones...... ^^U, simplemente si sabe de que te va el tema es que le limites la flecha activa y a correr....
berobreo
11/08/2007, 13:52
con los elementos finitos pasaremos de medir flechas a compatibilizar deformaciones.
Estaría bien. Eso sí, sería preciso definir las características de pavimentos y tabiquerías con mucha precisión.
Mientras escribía el párrafo anterior se me ocurría un factor que a la vez que complejiza esa modelización puede ayudar en el comportamiento: las desolidarizaciones que puedan ser precisas por las crecientes exigencias de aislamiento acústico.
por ejemplo has intentado medir la flecha activa o total de una viga,en la cual tienes tirantes y cambios de sección ?
Es muy peligroso un programa con la capacidad de calcular de una forma muy intuitiva, pues puedes cometer errores muy graves si no tienes criterio en lo que metes a calcular y tienes en cuenta las limitaciones del programa.
berobreo
11/08/2007, 15:01
por ejemplo has intentado medir la flecha activa o total de una viga,en la cual tienes tirantes y cambios de sección ?
No.
Es muy peligroso un programa con la capacidad de calcular de una forma muy intuitiva, pues puedes cometer errores muy graves si no tienes criterio en lo que metes a calcular y tienes en cuenta las limitaciones del programa.
Eso es volver al tema de siempre, pero no entiendo qué tiene que ver con lo que veníamos hablando.
Con la tecnología de vBulletin® versión 4.1.12. Copyright © 2012 vBulletin Solutions, Inc. Todos los derechos reservados.
