ref. Pasc-1_13/11/06

Resumen Octubre 2006. Un año de Pascaline.

(De gestodedios, equipo Pascaline)  13/11/06 - España

Hola a todos los pascalines.

Hace ahora un año que nació la idea del Proyecto Pascaline, y echando la vista atrás, basta para ello con leer este foro desde su inicio, creo que no nos podemos quejar. Comenzamos con serios retrocesos y alguna que otra vez estuvimos a punto de tirar la toalla. A la búsqueda de colaboración surgió el foro, y a él se sumó Coya, amigo de la Web, y luego Pachi y con él Python y un buen empujón al Proyecto. Luego se pasaron algunos meses entre titubeos informáticos hasta que por fin Coya se decidió a crear la primera función Pascaline... Acabamos de estrenar nuevo logo: un bebé bajo un arco jugando con la Pascalina, la máquina de calcular. Con Pascaline queremos aprender y educar en el cálculo de estructuras.

Octubre fue un buen mes para el Proyecto Pascaline, especialmente gracias a la incorporación al proyecto de Fredo y Jesús Torrecilla. Ambos han contribuido con dos nuevos códigos. Fredo con un programa sobre el cálculo de la presión de hundimiento basado en el DB-SE-C del Código Técnico de la Edificación, en la línea del ya existente sobre el cálculo del coeficiente de empuje activo. Por su parte, Jesús Torrecilla ha  implementado un código de cálculo matricial de barras articuladas.

En la versión del Pascaline que os ofrecemos actualmente (versión del 07/11/06) se ha incluido el programa de cálculo de presiones de hundimiento. El programa de barras se está revisando actualmente y todavía no se ha subido la primera versión, pero pronto esperamos hacerlo.

El proyecto sigue adelante. Seguimos esperando vuestras opiniones, pruebas y colaboración,

gestodedios, De Mecánica.

Para unirte al Proyecto o participar en el Foro dirígete al formulario Pascaline

¡Sin respuesta!

ref. Pasc-1_27/08/06

Resumen de reunión en Madrid en Septiembre.

(De gestodedios, equipo Pascaline)  15/08/06 - España

Hola a todos los pascalines.

Seguimos esperando vuestras opiniones y colaboración,

gestodedios, De Mecánica.

Para unirte al Proyecto o participar en el Foro dirígete al formulario Pascaline

¡Sin respuesta!

ref. Pasc-1_24/09/06

Posible inclusión de programas en Python

(De Jesús Torrecilla)  24/09/06 - España

Hola a todos.

Tengo realizado un par de programas en Python, uno de cálculo de estructuras articuladas (con interfaz gráfica wxPython) y otro (en fase pre-Beta) de cálculo de secciones. Si os interesan, puedo liberarlos. Sólo habría que ver bajo qué licencia.

Jesús Torrecilla.

Para unirte al Proyecto o participar en el Foro dirígete al formulario Pascaline

ref. Pasc-1_15/08/06

Resumen de lo visto en la lista Pascaline los últimos días (mediados de Agosto)

(De gestodedios, equipo Pascaline)  15/08/06 - España

Hola a todos los pascalines. Hago un breve resumen de los temas que se han visto en la lista los últimos días, sin duda el debate sobre temas de programación ha tomado el protagonismo:

- Se debate sobre la introducción de la programación orientada a objetos. De hecho el módulo georun.py se ha modificado introduciendo un objeto muro con sus métodos y propiedades, y se plantea la creación de un objeto terreno.

- Se discute sobre la programación <<de arriba a abajo>> o <<de abajo a arriba>>, es decir, si es mejor hacer un receso y plantear de nuevo globalmente el proyecto Pascaline, analizando los objetos necesarios; o seguir en esta línea de ida y vuelta en la que el código se renueva constantemente.

- Se trataron aspectos sobre funcionamiento de parches y de test unitarios. Sobre los parches se puede consultar el artículo en el Blog de Pachi (http://blog.rvburke.com/2006/08/10/pequeno-curso-para-el-trabajo-con-parches). Sobre test unitarios los enlaces y comentarios que también él nos facilitó:

<<[1] http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3Book/unittests.html

[2] http://pyunit.sourceforge.net/pyunit.html

[3] http://mail.python.org/pipermail/tutor/2001-September/008816.html

[4] http://c2.com/cgi/wiki?TestDrivenDevelopment

[5] http://www.onlamp.com/pub/a/python/2004/12/02/tdd_pyunit.html

[6] http://www.onlamp.com/pub/a/python/2005/02/03/tdd_pyunit2.html

[1] usa Unittest, el módulo de Python para test unitarios, que tiene su documentación en [2] (además de en la documentación de Python).

[3] presenta la técnica más rudimentaria del assertr. Como se puede ver, Unittest simplemente sofistica algo más la técnica del assert...

En [4] se habla de una metodología en la que los test son casi lo más importante. Para entender porqué son importantes los test.

[5] y [6] son dos artículos muy buenos que explican un poco todo este asunto, con ejemplos concretos>>.

También éste proporcionado por Coya:

http://es.wikipedia.org/wiki/Prueba_unitaria

- Se trataron aspectos sobre el estilo de programación con Python con objeto de conseguir cierta homogeneidad entre todos los que vayamos a trabajar en el proyecto. También se recomendó alguna dirección:

http://www.python.org/dev/peps/pep-0008/

- Se entregaron nuevas versiones del geotecnia.py y del georun.py . La última versión como siempre la tenéis en la parte superior de ésta página.

Seguimos esperando vuestras opiniones y colaboración,

gestodedios, De Mecánica.

Para unirte al Proyecto o participar en el Foro dirígete al formulario Pascaline

¡Sin respuesta!

ref. Pasc-01_10/08/06

<<georun.py>>, una sencilla interfaz para <<geotecnia.py>>

(De Pachi, equipo Pascaline)  10/08/06 - España

Hola a todos.

Para animar un poco más el foro y para tener algún ejemplo más, aquí mando un nuevo archivo que, cuando se ejecuta en un directorio que contenga el anterior archivo geotecnia.py pide los valores necesarios para calcular el empuje usando la función que se define en dicho módulo.

Es una interfaz de texto hecha a toda prisa, así que falta gran parte de la validación de datos y, por supuesto, todavía no tenemos ningún test del módulo que usa...

Como ideas para extender lo que tenemos se podría hacer:

- Implementar otro algoritmo para el cálculo del empuje y extender la interfaz de texto para que pregunte cuál se desea usar.

- Hacer test que comprueben la validez de la función de empuje que hemos definido ya.

- Validar los datos (estudiar dónde se valida, si en la interfaz o en la función o en ambas y qué resultado produce cada caso).

Saludos,

Pachi.

   Archivo Pascaline: georun.py  <<Revision: 0.1 2006-08-09>>

Para unirte al Proyecto o participar en el Foro dirígete al formulario Pascaline

Hola Pachi. Hola a todos los pascalines.

Siguiendo lo que comenas ahí va una función que incluye el empuje activo.

Se trata simplemente de implementar la fórmula (6.1) de DB-SE-C. La he incorporado como una función dentro del módulo geotecnia.py.

He modificado la autoría por <<equipo Pascaline>>, dado que ya hemos participado varios miembros. A continuación de la línea de versión he añadido un comentario con el autor de la última modificación.

Propongo una traducción del mensaje de software libre.

Añadí una comprobación:

# con este bucle comprobamos que el programa no se para

# para ningún valor entero de dato12,

for dato12 in range(0, 91):

datos1 = (90, dato12, 0, 0)

coeficiente_empuje_activo_CTE(*datos1)

El valor dato12 será el coeficiente de rozamiento. El nombre de esta variable auxiliar es nemotécnico: dato 2 del conjunto datos1. ¡Muy discutible!

Por otra parte, tal vez habría que hacer una comprobación similar para todos los valores, pero hay dos problemas. El primero, técnico, es que es tarda lo suyo. Si recorrer este bucle le lleva un par de segundos, recorrer otros tres bucles anidados supongo que será lento. No sé si esta manera de comprobar es muy correcta. El segundo, coyuntural, es que aún no están fijados los intervalos para las variables. Por ahora no es un problema, porque lo más importante es saber si es una buena práctica de depuración hacer las comprobaciones a saco. Estas comprobaciones verifican que el programa no se para, no que da resultados aceptables.
 

Un saludo,

Coya.

   Archivo Pascaline: geotecnia.py  <<Revision: 0.3 2006-08-10>>
 

ref. Pasc-01_03/08/06

Comentarios y algunos datos útiles

(De Lampur)  03/08/06 - España

Hola a todos.

Encuentro vuestro proyecto muy interesante. Aunque a corto plazo no me es posible colaborar en él, es probable que a medio plazo sí. Desde hace algún tiempo estoy buscando programas de cálculo de estructuras (por el método matricial) que se puedan utilizar a nivel docente sin coste para los estudiantes. He encontrado CESPLA y CESTRI (cálculo de estructuras planas y tridimensionales) de Juan Tomás Celigüeta (profesor de la Universidad de Navarra). Funciona muy bien pero no es de código abierto (al menos de momento). Se le puede pedir al autor que libere el código o como mínimo puede servir de modelo. También he encontrado el STRUCEDIT (editor de estructuras) de Juan José Vidal. No tan depurado como los anteriores pero de código abierto. El problema es que está en Java. Está colgado como proyecto en curso en: http://javahispano.net/projects/strucedit

Me ha parecido que esta información os podía ser de utilidad. Saludos y adelante.

Lampur.

Para unirte al Proyecto o participar en el Foro dirígete al formulario Pascaline

Hola Lampur.

Sentimos que no te puedas incorporar al proyecto, de todas maneras, puedes acceder a nuestra lista de distribución y permanecer informado por si más adelante te <<picas>>:

Agradecemos tus datos, algunos de los programas que comentas ya los conocía, otros no. A diferencia de los programas que aludes nosotros tenemos una circunstancia desfavorable en un principio, que sin embargo a largo plazo nos ha de dar mucha potencia. Se trata de que tenemos que trabajar en equipo y no desarrollar algo a nivel personal.

Por otro lado, nosotros todavía no nos hemos planteado, al menos no a corto plazo, crear un programa general de cálculo matricial o bien por elementos finitos. En principio estamos enfocando más el proyecto a desarrollar funciones útiles para el cálculo en Estructuras y Geotecnia. Más adelante intentaremos dar ese paso, pero si hay software en el mercado en abundancia, si bien no libre, es acerca de este tipo de cálculo.

Lo dicho, te esperamos,

gestodedios, <<De Mecánica>>.

ref. Pasc-01_15/07/06

Primera función Pascaline

(De Coya, equipo Pascaline)  15/07/06 - España

¡La primera rutina de Pascaline!

Se trata de implementar la fórmula (6.3) del DB SE-C del CTE.

¿Por qué esta fórmula? Simplemente porque al leer el DB me hizo gracia.

Se trata, ante todo, de subir un programa para debatir sobre la programación, pues este es el objetivo de este programa pilote sobre empujes.

Tres cosas quisiera resaltar para el comentario.

En primer lugar, cuando estoy programando, suelo escribir órdenes de salida por pantalla de las variables, de manera que sea fácil realizar el seguimiento. Estas órdenes van seguidas de un comentario #seguimiento, para que luego puedan ser eliminadas. No sé si esa es una práctica correcta o si os parece engorrosa o superflua.

En segundo lugar, he empleado variables auxiliares (auxN) que no representan nada, sino que simplemente atomizan una fórmula que, de otro modo, sería ilegible en modo texto.

En tercer lugar, lo subo con cierta premura, sin revisar demasiado (o casi nada), por la ilusión de ver algo de código en el aire.

Se admiten (como no) todo tipo de comentarios y sugerencias, así pues, ¡a rajar!

Saludos,

Coya.

Para unirte al Proyecto o participar en el Foro dirígete al formulario Pascaline

Hola de nuevo :). Ya estoy de vuelta y con ganas de ir avanzando.
 

> ¡La primera rutina de Pascaline!

¡Genial!

Buen motivo :).

Esto podemos pulirlo para no dejar el código tan sucio, creando una función debug, con parámetro un nivel de aviso, que imprima un mensaje si el nivel es inferior a uno dado. De esta manera podemos eliminar la salida simplemente en función de lo que necesitemos conocer.

Es, como muchas cosas, un asunto de gusto y de legibilidad. Se puede usar la barra hacia atrás para saltar de línea en medio de una expresión (\), aprovechando la existencia de distintos términos. Yo prefiero usar por lo general el salto de línea, aunque en este caso parece más claro lo que has hecho.

Eso es lo mejor en estos momentos. Mando los comentarios y un archivo adjunto con el código tal como lo he dejado. Más adelante, en cuanto tengamos algunos criterios básicos ya más establecidos probablemente sea mejor comentar el código en línea y adjuntar parches que hagan los cambios propuestos.

- Para empezar, es neceario saber que en Python se usan 4 espacios para indentar el código, no tabuladores, así que <<cuidadín>> con eso. Al ser significativo el nivel de indentación hay que cuidar que no se nos mezclen tabuladores y espacios.

- Por eso mismo es mejor insertar un archivo adjunto con el código que incluirlo en línea en los mensajes. En el caso de poner código en línea, se suelen separar los archivos con algo así (ya que puede haber varios):

------------- coeficiente_empuje_activo_cte.py -------------------

- La forma de poner los espacios entre parámetros de funciones, en expresiones, etc. es importante para mantener un estilo coherente y legible. En Python existe un documento, llamado PEP-8 (Python Enhacement Proposal 8, o, Propuesta de Mejora de Python 8) que trata de este asunto (como lo de los espacios, tabuladores, criterios de nombrado...)

http://www.python.org/dev/peps/pep-0008/

- El estilo habitual también desaconseja usar guiones bajos en los nombres de módulos para evitar problemas en algunos sistemas de archivos. Por eso deberíamos cambiar el nombre del módulo. Probablemente empezar con geotecnia.py puede estar bien. Ya moveremos las funciones a módulos más específicos cuando sea necesario. Usar un nombre corto nos ahorra problemas en sistemas de archivos limitados en ese aspecto.

- Es importante escribir las cadenas de documentación del módulo (archivo) y las funciones, con una primera línea corta que resuma el contenido y una explicación posterior más extensa. Es mejor documentar aquí que en medio del código. Si faltan aclaraciones en el código es que está mal abstraído (ya se nos darán casos...)

http://www.python.org/dev/peps/pep-0257/

En los casos triviales no es necesario repetir la información.

- También es mejor separar la adaptación de parámetros en diferentes líneas, en vez de usar asignación múltiple, al menos para operaciones no triviales (podemos querer comprobar límites más adelante, etc). Mejor no hacer una optimización prematura del código (en este caso en cuanto a compacidad) a costa de la legibilidad. En lenguajes menos expresivos se intenta hacer demasiado en cada línea por pura economía de espacio... en Python hay que relajarse un poco en ese aspecto.

- En vez de usar aux5 como nombre de variable es mejor usar Ka, por ser más significativo.

- He eliminado algunos mensajes de comprobación redundantes (principio y final de la función dentro y fuera de la misma) y he creado una función debug que manda los avisos por pantalla en función del nivel de información que deseemos. Con cambiar el valor de DEBUG_LEVEL controlamos la información que saca en pantalla el programa, y no tenemos que andar borrando o comentando zonas del código.

- Las funciones pueden tomar valores por defecto, tal como se ve en la función debug, y que podemos aprovechar para los parámetros de la función de cálculo del empuje activo. Usar valores razonables puede ser interesante. Aquí lo he añadido por ver la funcionalidad.

- Otra duda que surge es si el nombre de la función es adecuado, ya que puede hacerse demasiado largo al usarlo en una expresión si no tenemos una variable intermedia para él. Por ahora vamos a seguir así... ya veremos qué nos pide el cuerpo más adelante :).

- He añadido una declaración de la codificación del archivo de código, para insertar acentos y caracteres especiales sin problemas (ojo... es la codificación del archivo, no de la salida...)

- Quedan por añadir test al código, comprobando las condiciones de contorno, valores significativos, etc, así como validación de los datos de entrada, mejor documentación, y lo que se nos ocurra. Así que, !a participar!

Otra opción es implementar otra función que use esta que hemos hecho o una función alternativa para calcular el empuje activo. Me parece más interesante lo primero, e ir intentando hacer algo útil cuanto antes.

En fin... a ver si se anima esto :)

Saludos,

ref. Pasc-02_08/07/06

Pascaline a principios de Julio

(De gestodedios, equipo Pascaline)  08/07/06 - España

Hola a todos los pascalines. Hago un breve resumen de los últimos temas:

- Pascaline utilizará como unidades las del sistema Internacional (S.I.), era algo obvio pero no deja de ser interesante constatarlo. Trataremos de sacar una tabla con las unidades a utilizar en el proyecto de prueba sobre empujes.

- Trataremos de publicar un apartado de Preguntas Frecuentes para animar a los visitantes del Foro a unirse al proyecto. Nuestro amigo Álvaro R. trabaja sobre ello.

- Hemos abierto una lista de distribución para tener una comunicación más eficaz que lo que este Foro puede permitir entre los pascalines. Por ahora somos sólo cuatro, esperamos ser muchos. Para suscribirse a la lista podéis ir a la dirección:

http://pascaline.rvburke.com/listinfo.cgi/pascaline-rvburke.com

Seguimos esperando vuestras opiniones y colaboración,

gestodedios, De Mecánica.

Para unirte al Proyecto o participar en el Foro dirígete al formulario Pascaline

¡Sin respuesta!

ref. Pasc-01_08/07/06

Presentación y comentarios

(De Ing. Kristian Edsberg)  08/07/06 - Argentina

La idea me parece genial, soy Ingeniero estructuralista y usuario de varios softwares muy conocidos, apoyo la idea y sigo en contacto para colaborar en experiencias y valores de constantes a aplicar en mi región (Nordeste Argentino).

¡Suerte ! Un abrazo,

Kristian Edsberg

Para unirte al Proyecto o participar en el Foro dirígete al formulario Pascaline

¡Sin respuesta!

ref. Pasc-01_28/06/06

Sobre el Código Técnico como guía

(De gestodedios, equipo Pascaline)  28/06/06 - España

Hola a todos los pascalines.

Para arrancar con esto de los empujes sobre muros de contención propongo partir de lo considerado en el nuevo Código Técnico de la Edificación (CTE). Propongo a los pascalines hacer una lectura (una lectura concienzuda, de estas de subrayar lo importante) del artículo 6 del <<Documento Basico SE-C Cimientos>>  y analizar su aplicación y posible guía para el programa.

Para ir acotando el problema sugiero las siguientes cuestiones:

- ¿Trataremos sólo el empuje sólo aplicado a muros o también a pantallas (continuas, de pilotes, tablestacas...)? Yo me inclino por comenzar exclusivamente con muros.

- En el caso de muros ¿de una sola altura? De nuevo me inclino por no complicarnos más en un principio.

- En el caso de muros ¿verticales? ¿con trasdós inclinado, quebrado? Quizás incluir el caso inclinado que es común.

- ¿Se tendrán en cuenta cargas aparte de las propias de terreno? Me inclino por considerar alguna más, como por ejemplo vehículos y edificaciones próximas. Sería interesante contemplar el caso de compactación pero es complicado.

- ¿Incluiremos tipos de terreno con parámetros definidos o por el contrario será el usuario el que indique la densidad, el ángulo de rozamiento, etc.? Sería interesante contar con ambas posibilidades.

- ¿Incluiremos el empuje del agua? Creo que es necesario.

- ¿Empuje activo, pasivo y en reposo? Creo que debería incluir todos estos casos.

- ¿Un sólo tipo de terreno o varios estratos? Parece mejor comenzar sólo con uno.

- ¿Cómo elegir las funciones del programa? Parece claro que para cada coeficiente de empuje (k_P, k_A, K_o) debería haber al menos una función. Igual para el cálculo de la ley de empujes (σ_h) -parece interesante que como resultado se pudiera obtener tanto la ley de empujes ¿gráfica y analíticamente? como su resultante, ¿no?

-...

Esperamos vuestras opiniones y colaboración,

gestodedios, De Mecánica.

Para unirte al Proyecto o participar en el Foro dirígete al formulario Pascaline

Saludos a todos ¿Qué tal?

He estado leyendo el foro con calma, también he aprovechado para meditar sobre todo lo que comentáis, además he descargado el entorno que me decíais (IDLE) y he comenzado a probarlo, durante la próxima semana aprovecharé para imprimir y leer el manual que recomienda Coya en el foro (<<El mejor documento de aprendizaje de Python que he encontrado en la Web es un libro en pdf escrito por Andrés Marzal e Isabel Gracia y está editado por el Departamento de Lenguajes y Sistemas Informáticos de la Universitat Jaume I. Se titula Introducción a la Programación con Python y está en la dirección: http://marmota.act.uji.es/MTP/pdf/python.pdf. En la misma Web hay más información sobre programación en Python y en C>>)

Con respecto a lo de comenzar analizando empujes sobre muros, creo que puede resultar sencillo y de paso nos servirá para empezar a sacar conclusiones sobre la forma de trabajo, efectivamente debemos de partir de lo dicho en el CTE, Ramón yo comenzaría con muros ménsula rectos, definiendo acciones como tierras (empuje activo), nivel freático y sobrecargas además de acciones exteriores puntuales, inicialmente con casos concretos para más adelante generalizar el uso del programa a otros casos. Comenzaré a enviar algunos ejemplos a finales de esta semana a gestodedios@demecanica.com para que los echen un vistazo, espero sus comentarios.

Un saludo.

ref. Pasc-01_24/06/06

Sobre la posibilidad de usar C/C++

(De Álvaro R.)  25/06/06 - España

Hola a todos, disculpar que tarde en contestar pero he estado bastante ocupado finiquitando algunas asuntos, veo que la gente sigue haciendo sus críticas y comentarios, con respecto a decidirnos con un lenguaje de programación sigo apostando por C/C++, el motivo es que son varias las empresas que conozco y lo emplean para el desarrollo de programas comerciales de análisis de estructuras, si bien es cierto que es más complicado que otros permite el desarrollo de aplicaciones mucho más potentes (sobre todo a largo plazo), tiempo atrás Gestodedios me preguntabas si he trabajado con Dev C++ en aplicaciones de ciertas dimensiones, siendo sincero, te diré que no, pero he trabajado con gente que si lo a hecho obteniendo buenos resultados, otro de los motivos por los que apuesto por este lenguaje es que son ya muchas las publicaciones que existen, está mas que probada su solvencia y los resultados que con el se obtienen, no hace falta buscar mucho para darse cuenta de que por ejemplo tanto en el desarrollo de Linux en sus orígenes como para sus aplicaciones es totalmente imprescindible (y esto quiere decir algo...), lo que implica que existan una enorme cantidad de compiladores como librerias de libre distribución, dado que este es uno de los objetivos que se persigue con Pascaline. Si bien es cierto que el uso de C/C++ puede resultar inicialmente complicado, pero aquellos que ya saben programar aunque sea para hacer pequeñas aplicaciones tienen ya una parte importante del camino recorrido. Bueno espero nuevas críticas y comentarios, mediten sobre lo que les he comentado.

Un saludo,

Alvaro R.

Para unirte al Proyecto o participar en el Foro dirígete al formulario Pascaline

ref. Pasc-01_25/06/06

Nuevas ideas para el Proyecto Pascaline tras reunión en Madrid

(De gestodedios, equipo Pascaline)  25/06/06 - España

Hola a todos los pascalines.

Tras un pequeño encuentro en Madrid el pasado Jueves 22, hemos llegado a algunas conclusiones cara al proyecto que paso a resumir:

- En breve pondremos en funcionamiento una lista de distribución <<Pascaline>> que sirva para potenciar la comunicación entre los distintos miembros del grupo. Este foro seguirá funcionando de forma paralela, centrándose en temas generales, comentando y publicando la información, animando a nuestros visitantes a participar en el proyecto y resumiendo periódicamente su estado.

- A partir de ahora, los <<fijos>> funcionaremos como <<Equipo Pascaline>> (por el momento, Pachi, Coya y el que suscribe) siendo además los responsables del proyecto. Esperamos que os animéis a participar y formar parte de este equipo para lo cual sólo es necesario algo de dedicación.

- Si todo va bien y el programa logra salir adelante, se colgará el código en una Web propia y exclusiva para Pascaline, desde donde se podrá descargar tanto el programa como el código, todo bajo licencia GNU.

- Dado que el primer módulo a desarrollar tratará sobre el cálculo de empujes sobre estructuras de contención, se abre un periodo de documentación y valoración de bibliografía y programas. Necesitamos también una biblioteca de ejemplos que servirá para la comprobación del código, cuantos más ejemplos mejor.

Esperamos por tanto vuestras aportaciones en este sentido (comentarios de libros, análisis de programas cuyo estudio de los empujes os parece interesante, ejemplos extraídos de libros o apuntes, etc.) que podéis enviarnos, por ahora, al correo gestodedios@demecanica.com

- Durante los próximos meses procederemos a investigar cuales son las funciones y variables que utilizaremos con Python para la implementación del código de empujes.

Esperamos vuestras opiniones y colaboración,

gestodedios, De Mecánica.

Para unirte al Proyecto o participar en el Foro dirígete al formulario Pascaline

¡Sin respuesta!

ref. Pasc-01_18/06/06

Resumen del Proyecto Pascaline a mediados de Junio 2006

(De De Mecánica)  18/05/06 - España

Hola a todos los pascalines.

A día de hoy siguen vigentes las ideas que lanzamos hace unos meses:

- Pascaline ha de ser un software libre y gratuito. Debe tener un marcado carácter educacional y servir para aprender Estructuras y Geotecnia. Ha de ser un software transparente y dúctil.

- Pascaline está abierto a todos aquellos que deseen participar en el proyecto.

Además, se han decidido las siguientes nuevas cuestiones:

- El lenguaje de programación elegido será Python, software libre con todas las ventajas ya se han tratado en el foro.

No todos los pascalines conocemos Python, por lo que estamos iniciando su aprendizaje, que al parecer es rápido, al menos comparado con otros lenguajes.

- Se ha considerado mejor trabajar con módulos (pequeños proyectos), al menos en un principio,  que con un programa general, esto permitirá arrancar más fácilmente. El primer módulo, por los mismos motivos, consistirá probablemente en el desarrollo del cálculo del empuje sobre estructuras de contención.

Esperamos vuestras opiniones y colaboración,

gestodedios, De Mecánica.

Para unirte al Proyecto o participar en el Foro dirígete al formulario Pascaline

ref. Pasc-01_16/06/06

Una idea sobre el esquema del programa

(De Martin75)  16/06/06 - España

La verdad que la idea es atractiva, en cuanto a lo de programas independientes, existen en el mercado programas de ese tipo de libre distribución como el <<Prontuario Informático del Hormigón Estructural>> que se puede descargar desde www.ieca.es. Yo, personalmente dividiría de la siguiente manera:

- Geotecnia: Se tendrían en cuentas las reacciones a nivel de cimentación.

1. Capacidad Portante

2. Estudio de Asientos

3. Estudio Dinámico del Terreno (Licuefacción)

- Estructura

1. Introducción Datos

1.1. Definición Geometría

1.2. Definición Materiales

1.3. Definición Acciones

2. Predimensionamiento

3. Analisis(MEF)

4. Dimensionamiento y Comprobación

5. Módulo Secciones

5.1. Comprobación de Secciones

5.2. Verificación de Nudos

5.2.1. Estructuras Metálicas

5.2.2. Estructuras Madera

5.2.3. Estructuras Mixtas

Un saludo,

Martin75.

Para unirte al Proyecto o participar en el Foro dirígete al formulario Pascaline

¡Sin respuesta!

ref. Pasc-01_10/06/06

Comenzar...

(De Coya)  10/06/06 - España

Hola, Ramón; hola a todos:

Creo que ya es hora de pensar dos cosas: cómo será la estructura del proyecto y por donde empezamos.

La primera decisión es integrar todo el proyecto en un único programa, con módulos interdependientes, o crear programas independientes.

La primera alternativa es más ambiciosa, con más futuro, pero también más compleja. Es posible que perdamos demasiados esfuerzos en planificar la globalidad del proyecto sin tener nada tangible, lo que incluso podría dar al traste con él. También es probable que, dada nuestra inexperiencia en programación, luego nos encontrásemos con que dicha estructura que ahora nos pareciera estupenda luego no fuese lo bastante robusta, con lo cual no habríamos ganado nada.

La segunda alternativa es más sencilla, nos permitiría arrancar antes y no daría la posibilidad de ir tratando temas para los que no hay otros programas.

Sea cual sea el camino, para arrancar podemos plantear un tema de cálculo y hacer inmediatamente un módulo. Sería un módulo piloto, que tal vez luego no se pueda integrar en el proyecto, pero nos permitiría varias cosas:

- Empezar de una vez a trabajar, que ya parecemos los del Frente Nosequé de <<La Vida de Brian>> (de los Monty ?)
    - Tomar contacto con el lenguaje de programación.
    - Conocer la manera de pensar la programación de los miembros del proyecto.
    - Colgar un programa que anime a entrar a potenciales miembros.
    - Anticipar los problemas que aparecerán en el proyecto. ¡Los experimentos con gaseosa!
    - Ver nuestras posibilidades y plantear con el grado justo de ilusión y realismo el futuro del proyecto.

Un saludo,

Coya.

Para unirte al Proyecto o participar en el Foro dirígete al formulario Pascaline

Hola de nuevo :).

Sobre las dos alternativas que plantea Coya, yo me decantaría por seguir la segunda opción, aunque con matices. Me parece mejor hacer módulos independientes planteados para problemas específicos, ya que, tanto por la forma previsible de trabajar, como porque todavía no está perfectamente definido el problema, es mejor un diseño de abajo a arriba en este caso. El riesgo con diseños de arriba a abajo (gran diseño previo), es que podemos morir de sobrediseño al hacer las librerías, implementando funciones que no acabemos necesitando más tarde, o encontrándonos que el diseño al que hemos llegado se debe rehacer completamente en cuanto empecemos a aplicarlo a un problema concreto. Anteriormente planteaba que empezar con algo como lo que resuelve el Prontuario Informático del Hormigón ya es bastante ambicioso.

Esta temporada estaré un poco liado, pero quiero poner en marcha una Web en agosto, y espero poder tener incluso ahí recursos para trabajar mejor entre todos. Por otra parte, vivo en Madrid, y no sé cómo estamos repartidos por el mundo, de forma que incluso se pudiese plantear una jornada de planificación presencial.

Saludos,

Pachi.