En orden de mejorar las capacidades operativas de los análisis que desarrollo para mi trabajo de grado me encontré con la tarea de habilitar los solucionadores de CALCULIX para que trabajen con mas de un núcleo. De nada vale comprar un computador costoso con 6 cores cuando solo se va a utilizar uno ¬¬.
La documentación de como hacer esto se encuentra en la Internet para el que sabe como buscarla, el problema esta en todas esas fuentes incomprensibles o erróneas que nos pueden hacer perder tiempo. Versiones antiguas, programas o librerías diferentes, plataformas distintas o simplemente escasa documentación es lo que normalmente se encuentra.
Para esto decidí crear mi propio tutorial en busca de dejar la documentación en caso de volverlo a hacer:
Lo primero es instalar todas las herramientas necesarias para nuestro trabajo, como debemos compilar los paquetes debemos asegurarnos de tener en nuestro sistema los siguientes programas.
Copiamos estos 5 archivos a la carpeta /usr/local y los descomprimimos todos asegurándonos de copiar el contenido del PATCH dentro de la carpeta creada ARPACK y reemplazar los archivos.
Bien, hora de compilar Spooles, acá la cosa se pone interesante ya que debemos hacer unos arreglos a mano antes de compilarlo con MAKE, entonces los cambios son:
-En /usr/local/spooles.2.2/Tree/src/makeGlobalLib debemos cambiar:
drawTree.c por draw.c
(Esto debido a un error en la configuración de Spooles, ¬¬)
-En /usr/local/spooles.2.2/Make.inc debemos cambiar
CC = /usr/lang-4.0/bin/cc por CC = /usr/bin/cc
(Esto es para definir donde esta ubicado nuestro compilador de C)
Luego de esto si podemos compilar la librería de spooles con el siguiente comando ubicados en la carpeta de spooles.2.2 por supuesto:
$ sudo make lib
Hecho, tenemos spooles compilado normal, pero como todo esto es con el objetivo de tener Spooles en paralelo tenemos que hacer otro paso, lo que pasa es que hay dos formas de hacer funcionar Spooles multi-core y son: (A) Compilando las librerías normales y MT en una sola o (B) compilarlas por separado, en este caso nos decidimos por la opción B para que CALCULIX llame a cada librería por separado según requiera.
$ cd MT/src/
$ sudo make spoolesMT.a
Y hecho de nuevo.
Ahora para ARPACK también debemos editar algunos archivos.
-En /usr/local/ARPACK/ARmake.inc debemos cambiar
home = $(HOME)/ARPACK por home = /usr/local/ARPACK
(Para definir el lugar donde tenemos los archivos de ARPACK)
PLAT = SUN4 por PLAT = linux
(Hace falta explicar eso? ¬¬)
FC = f77 por FC = gfortran
FFLAGS = -O -cg89 por FFLAGS = -O2
MAKE = /bin/make por MAKE = /usr/bin/make
(Esto se cambia para especificar nuestro interprete de Fortran y la ubicación de MAKE)
Acá viene el "Machete" , resulta que hay una sub-rutina en ARPACK que sirve para determinar el tiempo de ejecución del proceso que trae un pequeño problema, la función "ETIME" ya no es una función externa utilizada en Linux, pero esperen un momento, no hay un parámetro que hace precisamente esto mismo en Linux llamado "TIME" ? , pues si, resulta que podemos despedirnos de esta sub-rutina ya que le tenemos reemplazo.
-En /usr/local/ARPACK/UTIL/second.f debemos cambiar
EXTERNAL ETIME por *EXTERNAL ETIME
(Esto se puede compensar (a mi parecer) adicionando el parámetro time antes del comando con el que llamemos a ccx para que nos calcule el tiempo que demora el proceso en terminar)
Para luego poder compilar en /usr/local/ARPACK
$ sudo make lib
Ya con las dos librerías compiladas vamos a la carpeta descomprimida de CALCULIX para compilarlo.
En /usr/local/CalculiX/ccx_2.3/src:
Vamos a compilar la versión MT de CALCULIX pero recordemos que esta sigue usando tanto Spooles MT como el normal ya que los compilamos separadamente, para esto vamos a asegurarnos de que nuestro archivo Makefile quede igual a esto:
CFLAGS = -Wall -O3 -I ../../../spooles.2.2 -DARCH="Linux" -DSPOOLES -DARPACK -DMATRIXSTORAGE -DUSE_MT=1
FFLAGS = -Wall -O3
CC=cc
FC=gfortran
.c.o :
$(CC) $(CFLAGS) -c $<
.f.o :
$(FC) $(FFLAGS) -c $<
include Makefile.inc
SCCXMAIN = ccx_2.3.c
OCCXF = $(SCCXF:.f=.o)
OCCXC = $(SCCXC:.c=.o)
OCCXMAIN = $(SCCXMAIN:.c=.o)
DIR=../../../spooles.2.2
LIBS = \
$(DIR)/MT/src/spoolesMT.a \
$(DIR)/spooles.a \
../../../ARPACK/libarpack_linux.a \
-lpthread -lm
ccx_2.3_MT: $(OCCXMAIN) ccx_2.3_MT.a $(LIBS)
./date.pl; $(CC) $(CFLAGS) -c ccx_2.3.c; $(FC) -Wall -O3 -o $@ $(OCCXMAIN) ccx_2.3_MT.a $(LIBS)
ccx_2.3_MT.a: $(OCCXF) $(OCCXC)
ar vr $@ $?
Y terminamos con le comando:
$ sudo make
El cual nos creara un ejecutable llamado "ccx_2.3_MT" el cual lo moveremos a /usr/local/bin para tenerlo a la mano, también hace falta mover el ejecutable "cgx_2.3" que esta ubicado en /usr/local a esta carpeta y asegúrate que estos dos ejecutables tengan permisos para ejecutarse como programas.
( usualmente yo prefiero re nombrarlos a simplemente ccx y cgx para mayor facilidad pero esto es opcional)
Ya tenemos CALCULIX instalado en nuestro sistema, pero si hacemos algunas pruebas notaremos que los cálculos con Spooles siguen utilizando un solo core, esto se debe a que debemos especificar cuantos procesadores queremos utilizar en el análisis, esto se hace con la condicion CCX_NPROC.
CCX_NPROC = -1 tratara de detectar el numero de procesadores para usarlos todos (no es recomendado)
CCX_NPROC = 1 usara 1 procesador
CCX_NPROC = 2 usara 2 procesadores ... y así sigue ¬¬
En el caso que se utilicen mas de 1 procesador en el análisis se creara un archivo en la carpeta de trabajo llamado spooles el cual nos dirá "Using # threads" , cuando se utiliza solo uno el archivo no es creado.
FIN, ahora podemos probar CALCULIX multi-core con:
$ export CCX_NPROC= #
$ time ccx jobname o sudo time ccx jobname
Una pequeña prueba me arrojo estos resultados sorprendentes:
Con el objetivo de contribuir un poco a la causa, decidi diseñar un simple Label para el DVD.
Con el objetivo de contribuir un poco a la causa, decidi diseñar un simple Label para el DVD.
Antes que nada se debe leer un poco acerca de las propiedades mecanicas del hueso, ahunque no representa la investigacion oficial para los analisis del proyecto de investigacion si son una buena partida para entender como funciona este material. La diferencia radica en que no podemos solo especificar un modulo de YOUNG y un radio de POISSON'S ya que el hueso no se comporta de la misma manera para cargas en distintos ejes coordenados, este no experimenta la misma deformacion o esfuerzo sobre toda su geometria; lo que quiere decir que (como minimo) debemos conocer las diferentes propiedades mecanicas para este material ANISOTROPICO en las distintas direcciones.
