Bug in output stats

[GoogleCodeExporter]

Descripción del problema
El funcionamiento y salida del Prallel-clusterer no son los esperado.
Este computa tomando como entrada un archivo comprimido y genera un archivo de 
salida con estadísticas erroneas.

¿ Cual es el problema ?
La estadistica final:

    Metrics:
        Total Structures: 91
        Used Cutoff: 0.15
        Total Clusters: 1
        Cluster Sizes:
            0. 1
        Min Size: 1
        Max Size: 1
        Average:  1

    Results:
        Cluster Representatives:
            0. 0
        Maximum member-to-representative distance: 0
        Amount of members over cutoff: 0

Donde "Maximum member-to-representative distance" debe dar una distancia 
distinta de 0, ya que
indica la distancia maxima entre un miembro de un cluster y su representante.
Un dato que puede ser de utilidad es que sólo genera un único cluster.

Pasos para reproducir el bug:
(Recordar que FuD depende de la libreria boost y de mili)

    Instalar fud:

    1. cd $SRC_DIR
    2. svn checkout https://fud.googlecode.com/svn/trunk/ fud
    3. cd $BUILD_DIR/
    4. mkdir fud
    5. cd fud
    6. cmake -DCMAKE_BUILD_TYPE=Debug $SRC_DIR/fud/
    7. make install

    Compilar Backbones-generator y crear el archivo comprimido:

    1. cd $SRC_DIR
    2. svn checkout http://backbones-generator.googlecode.com/svn/trunk/ backbones-generator
    3. cd backbones-generator/
    4. cd serial/
    5. make
    6. ./petu -i data -r 7 -w compressed

Esto dará como salida un archivo comprimido con nombre "traj.xtc" por defecto.

    Compilar y ejecutar Parallel-Clusterer:
    (Recordar que Parallel-Clusterer depende de las librerías prot-filer, getoptpp y xdrfile)

    1. cd $SRC_DIR
    2. svn checkout http://parallel-clusterer.googlecode.com/svn/trunk/ parallel-clusterer
    3. cd parallel-clusterer/
    4. make
    5. En una terminal ejecutar el servidor: ./clusterer -i ~/$SRC_DIR/backbones-generator/traj.xtc -f compressed -l cluster -s stats
    6. En una terminal ejecutar el cliente: ./clusterer-client -a 127.0.0.1 -p 31337

Resultados esperados:
"Maximum member-to-representative distance" debería poseer un valor distinto 
de 0.
"Total Clusters" superior a 1.

Versiones:
Linux raul-Studio-1558 2.6.35-28-generic-pae
g++ 4.4.5
Backbones-generator r181 
(http://code.google.com/p/backbones-generator/source/detail?r=181)
Parallel-Clusterer r140 
(http://code.google.com/p/parallel-clusterer/source/detail?r=140)
mili r211 (http://code.google.com/p/mili/source/detail?r=211)
boost 1.42
Prot-filer r38 (http://code.google.com/p/prot-filer/source/detail?r=38)
getoptpp r138 (http://code.google.com/p/getoptpp/source/detail?r=138)
xdrfile 1.1

Información adicional:
 Adjunto se proporcionan los siguientes archivos:

 - Archivo comprimido "traj.xtc" el cual se usó para descubrir el bug.
 - Archivo "stats" con las estadísticas erroneas correpondientes a la computación del parallel-clusterer con el archivo "traj.xtc"
 - Archivo comprimido traj1.xtc, con el cual parallel-clusterer no genera errores.
 - Archivo "stats1" correspondiente a las estadísticas de salida del parallel-clusterer al computar con el archivo "traj1.xtc"

Original issue reported on code.google.com by rulito...@gmail.com on 28 Apr 2011 at 4:56

Attachments:

• traj.xtc
• stats
• traj1.xtc
• stats1

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Cometí un error ( por desconocer y no preguntar )  al describir las versiones 
de las librerías, el link correcto de la versión de cada librería está 
entre paréntesis.

Original comment by rulito...@gmail.com on 28 Apr 2011 at 5:14

[GoogleCodeExporter]

Pregunta 1: probaste con XTC viejos? (esto descarta el factor: bb-gen nuevo)
Pregunta 2: probaste el clusterer original sobre FuD, el que dejó billy?

Tendrías que combinar esas dos cosas:
   { xtc-generado, xtc-viejo } x { clusterer-boinc, clusterer-viejo }
y comparar y mostrar acá resultados.
Una tablita de 2 x 2 para las cuatro combinaciones, mostrando por ejemplo 
cantidad de clusters encontrados en cada caso.

Original comment by danielgutson@gmail.com on 28 Apr 2011 at 5:30

[GoogleCodeExporter]

respuesta 1: Cuando Hugo me dio una mano, probamos generar comprimidos con una 
versión de backbones-generator anterior ( la 139 ) pero el resultado fue el 
mismo. Otra versión para probar?

También probé con el archivo que adjunte llamado traj1.xtc, ese anda bien con 
la versión que utilice de clusterer. No se con que versión fue generado, ya 
que billy lo tenía de cuando laburó en el clusterer.

respuesta 2: No, lo pruebo.

Ok, pruebo todas las combinaciones e informo.

Original comment by rulito...@gmail.com on 28 Apr 2011 at 2:08

[GoogleCodeExporter]

Realice la primera prueba pendiente sobre la función "AddingJobJobUnit":

Ejecución:
 -Server: ./clusterer -i traj.xtc -f compressed -l cluster -s stats -m
 -Client: ./clusterer-client -a 127.0.0.1 -p 31337

Imprimí las posiciones de cada átomos de cada proteína que se inserta en el 
mensaje
en la línea: 
http://code.google.com/p/parallel-clusterer/source/browse/trunk/server/jobs/addi
ng_job.cpp#137

 Print en la función AddingJobJobUnit obtenido computando con traj.xtc (server side):
 Protein ID: 0
 Atom ID: 0 X: 0 Y: 0 Z: 0
 además, first = last = 0

 Salida del cliente:
 Adding 1 proteins in cluster 0
 Centers received cluster 0
 Centers received 1 proteins.

Resultado obtenido computando con traj1.xtc (funcionamiento correcto):
http://pastebin.com/eqfvMKyw

Original comment by rulito...@gmail.com on 28 Apr 2011 at 8:39

[GoogleCodeExporter]

Gente, una duda, cual seria la revisión del clusterer original?
Probé con las revisiones 122 y 132 pero me tiro el siguiente error al 
ejecutarlo (de la misma manera de siempre): Error in main application: Error 
initializing database. Wrong filename?

Original comment by rulito...@gmail.com on 4 May 2011 at 7:50

[GoogleCodeExporter]

Entonces, hay diferencia etre la versión original y la actual?

Original comment by danielgutson@gmail.com on 16 May 2011 at 12:39

[GoogleCodeExporter]

Bueno, estuvimos haciendo pruebas con billy y llegamos a lo siguiente:

Básicamente se leen 91 estructuras que para el clusterer son todas iguales.

Del lado servidor se imprimieron las proteínas y sus átomos con sus 
respectivas posiciones. 

Al ser todas iguales, la siguiente salida contiene únicamente una de esas 
proteínas: http://pastebin.com/Nqte36hR

Ahora, combinado con una característica del código cliente del clusterer, que 
elimina proteínas duplicadas, los resultados finales terminan siendo que hay 
un único cluster, que tiene un representante y ningún miembro. Por eso la 
salida estadística previamente mostrada.

Esta característica (que a este punto no se sabe si es una optimización y si 
debería o no estar) esta en la siguiente línea:
http://code.google.com/p/parallel-clusterer/source/browse/trunk/client/clusterer
_processor.cpp#129

Como es de esperar, la comparación del if da siempre falso, justamente porque 
son todos iguales.

A continuación otro mensaje sobre algunas conjeturas sobre donde se puede 
encontrar el problema.

Original comment by rulito...@gmail.com on 18 May 2011 at 1:56

[GoogleCodeExporter]

Al ser todas las estructuras iguales para el clusterer hay un problema. 
Corresponde ahora determinar la causa.

Hipotesis 1: Problema en el generador

Una posibilidad es que efectivamente en el archivo sean todas iguales, lo cual 
indicaría un problema en la generación del mismo.

Se genero con: ./petu -i data -r 6 -w compressed

Se utilizo una herramienta para explorar la salida generada: 
http://pastebin.com/tRfN24gQ

Con esto obtuvimos la siguiente salida: http://pastebin.com/BcJ1Tbm0

Sin conocer que representa esta salida, daria la impresion de no repetir 
patrones.

Hipotesis 2: Problemas en prot-filer

La otra posibilidad es que el archivo efectivamente corresponda a una secuencia 
de estructuras diferentes, pero la base de datos que se lee con prot-filer me 
devuelve siempre la misma proteina.

Aclaracion: Se esta usando la revision 38 de prot-filer.

Por otro lado, el archivo traj1.xtc previamente mencionado no tiene este 
problema, lo cual a priori parece indicar un problema con el generador, pero no 
se puede confirmar todavia.

Se sigue investigando :)

Original comment by rulito...@gmail.com on 18 May 2011 at 2:05

[GoogleCodeExporter]

Mi comentario, un poco descolgado.
Hay dos roles: un productor, y un consumidor.
El rol del productor, es el bb-gen/prot-filer.
El del consumidor, el clusterer/prot-filer.

Sugiero combinar con dos implementaciones de estos roles de juguete (en el caso 
del productor: un main() q sólo guarde 3 estructuras con datos hardcodeados 
para saber qué esperar del otro lado).
Así las cosas,
 productor      consumidor
 ---------      ----------
 [juguete]  ->  [juguete]
 [juguete]  ->  [posta] (clusterer)
 [posta]    ->  [juguete]

Sólo con la primer combinación (juguete/juguete) , si no funciona, ya sabemos 
que puede ser el prot-filer.

Otra cosa, billy me dijo que xtc dejó de funcionar, xfav carguen el issue en 
el proyecto que corresponda, necesitamos seguir soportando este formato.

Original comment by danielgutson@gmail.com on 18 May 2011 at 6:58

[GoogleCodeExporter]

Dije que el soporte de .xtc (normal, no comprimido) dejo de funcionar en algun 
momento durante (o sea, en el medio) del desarrollo de prot-filer mientras se 
agregaba soporte para xtcs comprimidos (digamosles .xz).

Rulo: subite el traj1.xtc viejo (comprimido) como traj1.xz.

Es importante tambien que el clusterer tenga soporte para .xtc (normales). Pero 
es probable que ya lo tenga, simplemente que yo no lo he probado con ningun 
.xtc comun hace rato.

Original comment by billybiset on 18 May 2011 at 7:02

[GoogleCodeExporter]

Aca adjunto el compirmido traj1.xz

Original comment by rulito...@gmail.com on 18 May 2011 at 3:03

Attachments:

• traj1.xz

[GoogleCodeExporter]

Hugo (y Raul):

Lo que hay que responder a continuacion es lo siguiente:

Las estructuras generadas reciententemente son todas iguales?
    La salida http://pastebin.com/BcJ1Tbm0 pareciera indicar que no, pero no se interpretar ese output.

Si son distintas, por que cuando el clusterer las lee de prot-filer son todas 
iguales?
   Podra ser que hay un error en prot-filer respecto de la utilizacion de las tablas de angulos en el nuevo formato?

Tuvimos un problema al compilar el ultimo prot-filer acerca de stl-debug. 
Daniel?

Raul, lo que tendrias que hacer en conjunto con Hugo es diseñar y desarrollar 
casos de prueba para el prot-filer/bbgen (ya se me confunden tantas 
herramientas, Daniel: no te copa hacer un wiki de la fundacion?).

Los casos de prueba deberian escribir estructuras dummy y verificar luego su 
contenido al leerlas.

Daniel, levantamos issues en los otros repos?

Original comment by billybiset on 18 May 2011 at 5:01

[GoogleCodeExporter]

Billy, eso esta hecho en los tests de prot-filer, la version nueva
(los casos de prueba).

Lo unico que todavia dudo, es si es correcto considerar iguales o no
dichas estructuras. En ppio, me pareceria que no, porque esa es la
combinatoria que bbgen DEBE hacer. Pero que se yo..

Original comment by hugo.arregui on 18 May 2011 at 7:15

[GoogleCodeExporter]

Correcto no deberia ser. Si la salida del generador de estructuras son N 
proteinas iguales, no creo que sea muy util.

Me da la impresion que hay un problema entre prot-filer y la traduccion de los 
archivos generados recientemente, pero necesito Hugo que nos des una mano para 
entender donde puede estar.

En esencia, el traj.xtc (que seria un .xz) del comentario original, cuando el 
clusterer lo lee, ve siempre la misma estructura 91 veces, eso tiene que estar 
mal.

Vos me podes responder estas preguntas sobre este archivo:
Son efectivamente 91 estructuras iguales?
De no ser asi, cuando uno obtiene la traduccion a un arreglo de puntos, se 
obtienen 91 iguales?

Si tenes los casos de prueba, ambas preguntas se podrian responder haciendo una 
impresion de todos los puntos para cada frame del .xtc ese original. Ojo, tiene 
que ser leyendo de la misma manera que lo hace el clusterer.

Original comment by billybiset on 19 May 2011 at 12:55

[GoogleCodeExporter]

Gente, este es el programa que use: http://pastebin.com/B6dqjZZ1

y esta es la salida: http://pastebin.com/wR2Wkmyn

no son iguales, pero son muy parecidos. Puede ser eso?

Original comment by hugo.arregui on 20 May 2011 at 12:56

[GoogleCodeExporter]

Hugo, podes subir el archivo comprimido con el que probaste el programa?, Como 
lo generaste?, con que version bbgen?

Probe con el que genere yo, pero la salida da siempre igual. 

Original comment by rulito...@gmail.com on 20 May 2011 at 1:15

[GoogleCodeExporter]

Rulo: Por favor hace un esfuerzo de usar todas las ultimas versiones en todo. 
Si no compila, trata de arreglar, si no te sale, avisa por aca.

Va a ser imposible discutir sobre lo que esta pasando mientras usemos versiones 
diferentes.

Che, veo que en lo que pega Hugo son distintas las estructuras, sobre todo al 
final. Eso esta bien.

Por favor fijate que la forma en la que el lee y la que nosotros leemos sea la 
misma, tratemos de usar el mismo archivo de datos y verifiquemos todo.

Hugo: Puede ser que esto se haya arreglado en alguna version posterior a la 38 
del prot-filer? o del generador?

Rulo: De nuevo, actualiza todo, desde ahora en mas. Laburemos siempre en la 
ultima version... de todo :)

Original comment by billybiset on 20 May 2011 at 1:50

[GoogleCodeExporter]

ok, si estoy en eso!..... la ultima version de prot-filer ya la compile, ahora 
sigo con el bbgen que me tire muuuchas quejas!...uso todo lo mas actual posible 
y pruebo!

Original comment by rulito...@gmail.com on 20 May 2011 at 1:54

[GoogleCodeExporter]

Gente cuidado, la ultima version de prot-filer y bbgen no la van a poder usar 
con clusterer. Mande un mail sobre esto en su momento, despues lo reenvio para 
mantenernos al tanto, pero a lo que importa: probe con la rev 38, y con el 
archivo que vos subiste Raul. (el traj1.xz)

Original comment by hugo.arregui on 21 May 2011 at 3:00

[GoogleCodeExporter]

ok Hugo gracias por el aviso!.....El archivo en cuestion es el traj.xz que te 
adjunto.
El traj1.xz es el que funciona bien!

Original comment by rulito...@gmail.com on 23 May 2011 at 1:25

[GoogleCodeExporter]

con traj1.xz se reconocen estructuras distintas?

Original comment by hugo.arregui on 23 May 2011 at 1:28

[GoogleCodeExporter]

si, con ese archivo se reconocen estructuras distintas. Ese lo genero billy 
para probar el clusterer cuando lo desarrollo.

Original comment by rulito...@gmail.com on 23 May 2011 at 1:35

[GoogleCodeExporter]

Si, con traj1.xtc (generado hace mucho) se reconocen estructuras distintas.

Con archivos generados hace poco, no.

Rulo: Por favor subi en un solo mensaje los archivos que tengas (ponele 
viejo-chico.xz, viejo-grande.xz y nuevo-r6.xz) y explica que pasa con c/u.

Original comment by billybiset on 23 May 2011 at 1:36

[GoogleCodeExporter]

ok, adjunto los archivos:

1 - viejo-chico.xz: Este fue generado por por billy para probar el clusterer 
original.
2 - viejo-grande.xz: También generado por billy para probar el clusterer 
original, pero es bastante grande. No fue probado por nosotros todavía.
3 - nuevo-r6.xz: Archivo generado por mi ( ./petu -i data -r 6 -w compressed ), 
con el cual se reconocen todas las estructuras iguales. Utilice la revisión 
181 de bbgen.

Original comment by rulito...@gmail.com on 23 May 2011 at 1:55

Attachments:

• viejo-chico.xz
• viejo-grande.xz
• nuevo-r6.xz

[GoogleCodeExporter]

Hola de nuevo gente, Hugo, tengo una duda:

Considerando que la salida del programita que proporcionaste tomando como 
entrada el traj.xz, da todas estructuras iguales, se podría descartar algún 
problema en el prot-filer e inclinarse por algún problema en bbgen? teniendo 
en cuenta también que con el traj1.xz la salida es correcta.

Original comment by rulito...@gmail.com on 23 May 2011 at 9:31

[GoogleCodeExporter]

Sinceramente no se, bbgen no sabe de proteinas. Lo que hace es combinar 
angulos. Y la combinacion parece ser correcta. Tengo que debuggear un poco.

Original comment by hugo.arregui on 24 May 2011 at 11:37

[GoogleCodeExporter]

xfav no olviden cargar los issues de los otros proyectos (prot-filer para lo de 
formato no comprimido, y stl-debug).

Original comment by danielgutson@gmail.com on 1 Jun 2011 at 4:46

[GoogleCodeExporter]

Otra cosa: le falta Owner a este issue -> ???

Original comment by danielgutson@gmail.com on 1 Jun 2011 at 4:46

[GoogleCodeExporter]

Aca cargue (a las apuradas, perdon por lo breve) un issue en prot-filer.

http://code.google.com/p/prot-filer/issues/detail?id=13

El problema existe y estoy 90% seguro de que es lo que provoca esto. Todavia no 
se porque ocurre y tampoco se si ocurre en la version nueva (la que clusterer 
todavia no usa).

Original comment by hugo.arregui on 1 Jun 2011 at 11:24

[GoogleCodeExporter]

Hola gente, sobre el tema del owner, este issue no tiene owner porque lo cree 
yo y se ve que no tengo los permisos suficientes para agregar owner, poner que 
tan critica es, etc.

Original comment by rulito...@gmail.com on 1 Jun 2011 at 12:13

[GoogleCodeExporter]

Ahí te agregué como committer del proyecto, y te puse como owner.
Esto de gcode hasta q no tenga una api para administrarlo desde consola....

Original comment by danielgutson@gmail.com on 1 Jun 2011 at 8:52

[GoogleCodeExporter]

Original comment by rulito...@gmail.com on 1 Jun 2011 at 8:54

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Gente, novedades:

estuve probando y la nueva version de prot-filer + bbgen, no tiene el bug. 
Entonces, les propongo lo sgte: dejenme resolver (dos dias, 3 maximo), un mini 
issue que terminar en el branch biopp de clusterer, y vamos con la nueva 
version en todos lados.

Para que puedan ir viendo, en bbgen hay dos programas (make tools), que 
permiten leer archivos comprimidos/xtc. Le agregue al de compressed para que 
lea tanto angulos como proteinas (van a tener que comentar una funcion y 
descomentar la otra, perdon por lo casero del asunto). Estaria buenisimo que 
prueben a ver si encuentran algo, pero en ppio creo que esta todo andando joya.

Una vez terminado lo que me queda del branch, voy a necesitar que todos me den 
una mano para testear todo junto (y quizas Billy una explicacion general de 
como funca todo), asi corregimos lo que se pueda haber roto en la migracion.

Les parece?

Original comment by hugo.arregui on 1 Jun 2011 at 11:15

[GoogleCodeExporter]

Si Hugo, totalmente de acuerdo.

Puedo darte una overview general del algoritmo de clusterizacion. Toda la parte 
de lectura de estructuras es nueva y no lo tengo interiorizado.

Saludos y gracias por trabajar en esto.

Original comment by billybiset on 2 Jun 2011 at 9:39

[GoogleCodeExporter]

update?

Original comment by danielgutson@gmail.com on 13 Jun 2011 at 9:09

[GoogleCodeExporter]

Estado actual: peleando con el bug de bad_alloc que ocurre en el cliente. 
Este finde lo estuve viendo y no saque nada todavia. Si alguno tiene tiempo, 
cualquier ayuda es bienvenida.

Original comment by hugo.arregui on 14 Jun 2011 at 10:14

[GoogleCodeExporter]

Hola gente, Hugo te comento que actualizamos las versiones cuando lo propusiste 
y cuando ejecutamos el parallel clusterer nos tira un "segmentation fault" del 
lado cliente. 

Según gdb :

0x08052236 in biopp::Coord3d_Aspect<biopp::NIL_Atom_Aspect, 
float>::Coord3d_Aspect (this=0x805ced8, other=...) at 
/usr/local/include/biopp/prot_structure/Atom.h:49
49          z(other.z)

Viene de la ejecución de "represantives-process", cuando intenta obtener el 
contenido del "input" que el server envía.

Original comment by rulito...@gmail.com on 14 Jun 2011 at 1:18

[GoogleCodeExporter]

Raul, la ultima vez que hablamos tiraba un std::bad_alloc. De ahi en
mas, que actualizaste/cambiaste/etc para que tire eso?

Original comment by hugo.arregui on 14 Jun 2011 at 1:21

[GoogleCodeExporter]

Raul: svn diff es tu amigo :)

Original comment by billybiset on 14 Jun 2011 at 1:24

[GoogleCodeExporter]

El 9 de junio pusiste esto en el thread de mails:

"Fixed (el bug es en prot-filer asi que actualicen ambos)"

Ahí, actualizamos clusterer-biopp y prot-filer a versiones de esa fecha

Original comment by rulito...@gmail.com on 14 Jun 2011 at 1:33

[GoogleCodeExporter]

Comentario absolutamente descolgado, que no sé si aporta o no:

 sólo viendo esa línea, incluso sin ir al archivo,
    z(other.z)

en donde un segfault ocurre sin punteros, es porque o bien this está mal, o la 
dirección de other está mal (especialmente si este other se recibe por 
referencia), posiblemente porque haya sido destruído antes de pasárselo a 
esto.
Ejemplo
      void f(const Objeto& obj) { lee obj }

Obj* pObj = ...;
delete pObj;
f(*pObj);

A veces pasa incluso sin punteros, si se pasa un temporal. Ej:

Objeto& bug()
{
    Objeto ret;
    return ret;
}

f(bug());  // segfault

Original comment by danielgutson@gmail.com on 16 Jun 2011 at 4:50

[GoogleCodeExporter]

Se corrigió el erro. La revisión r150 fue probada con asio y BOINC y 
funcionó correctamente, por lo tanto cerramos el issue.

Original comment by rulito...@gmail.com on 30 Jun 2011 at 8:01

• Changed state: Fixed