Posts by blackbird

1) Message boards : Number crunching : Problems with Rosetta version 5.43 (Message 33318) Posted 24 Dec 2006 by blackbird Post: dublicated
2) Message boards : Number crunching : Problems with Rosetta version 5.43 (Message 33317) Posted 24 Dec 2006 by blackbird Post: Suse Linux 10.1 2.6.18.2-jen37-default on Athlon 2400+ Rosetta crash with this WU cat stderr.txt Graphics are disabled due to configuration... # random seed: 3797287 # cpu_run_time_pref: 28800 No heartbeat from core client for 31 sec - exiting SIGSEGV: segmentation violation SIGSEGV: segmentation violation Stack trace (12 frames): [0x8ab6403] [0x8ace4bc] [0xa7f95420] [0x8b4e786] [0x8b4ec63] [0x8b1fdc1] [0x8b217e9] [0x80d0581] [0x8b34fdf] [0x8ac57f7] [0x8acf725] [0x8b60f0a] Exiting... Stack trace (13 frames): [0x8ab6403] [0x8ace4bc] [0xa7f95420] [0x89e17f3] [0x897a31c] [0x8a41e94] [0x83eac95] [0x80dc119] [0x84d61db] [0x85eb303] [0x85eb3ac] [0x8b2d9d4] [0x8048111] Exiting... tail stdout.txt --------------------------------------------------------- score1 done: (best, low) rms (best,low) -3.68180609 -8.59113979 0 0 standard trials: 20000 accepts: 1447 %: 7.24 e/trial: -0.00333 ----------------------------------------------------- Alternate score2/score5... kk score2 score5 low_score n_low_accept rms rms_min low_rms 0 -11.489 -0.333 -11.489 27 0.000 0.000 0.000 1 1.621 20.123 -8.383 31 0.000 0.000 0.000 2 -24.474 -2.889 -32.905 34 0.000 0.000 0.000 The bug is same as in this post
3) Message boards : Number crunching : Report Problems with Rosetta Version 5.07 (Message 15132) Posted 1 May 2006 by blackbird Post: Rosetta version is 5.07 WU has stopped, CPU time has stopped on 00:27:34. Thank you for the replies.
4) Message boards : Number crunching : Report Problems with Rosetta Version 5.07 (Message 15089) Posted 30 Apr 2006 by blackbird Post: It looks like my Rosetta has problems with this WU: http://boinc.bakerlab.org/rosetta/workunit.php?wuid=14208762 Application has stopped on 1.19%. My computer has Suse Linux 9.2 installed, details: http://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=54409 Stderr.log: # random seed: 3264160 # cpu_run_time_pref: 86400 SIGSEGV: segmentation violationStack trace (18 frames): [0x8822533] [0x883adec] [0xffffe420] [0x88bb810] [0x88bd0c9] [0x888be07] [0x888e1f1] [0x84bfcb8] [0x84c08a3] [0x84cf4e5] [0x84d1325] [0x87c0393] [0x869f41a] [0x86a1351] [0x8487fd2] [0x848b41b] [0x889a2d4] [0x8048111] tail stdout.txt: [T/F OPT]Default FALSE value for [-stringent_relax] [REAL OPT]Default value for [-farlx_cycle_ratio] 1 CYCLES::number is 1 x total_residue: 155 [T/F OPT]Default FALSE value for [-more_relax_cycles] initializing full atom coordinates [T/F OPT]Default FALSE value for [-do_farlx_checkpointing] starting score 1909.42151 rms 6.14713573 starting full atom minimization [T/F OPT]Default FALSE value for [-infinite_loop] [T/F OPT]Default FALSE value for [-relax_score_filter]
5) Message boards : Rosetta@home Science : Feedback, .. bandwidth usage :-( (Message 8868) Posted 12 Jan 2006 by blackbird Post: I've got the question similar the Andrew has - will the scientific value of the long WU remains the same. Another question. On my PC WU cpu time is about 2 hours. Considering that WU size is about 2 Mb now and acceptable traffic size for me is about 1 Mbday, would i have an opportunity to set -nstruct 200?
6) Message boards : Rosetta@home Science : Feedback, .. bandwidth usage :-( (Message 8789) Posted 11 Jan 2006 by blackbird Post: I'm thankful to SwZ for clearing my ideas (two russians can understand each other even in english :). If the WU will run 5 times slower (without any lost of scientific value, of course), and transfers can be compressed with LZMA 3 times better, the traffic can be decreased 15-fold. WU completion time is a psychological question, bandwidth is a financial and time-consuming question for participants.
7) Message boards : Rosetta@home Science : Feedback, .. bandwidth usage :-( (Message 8706) Posted 10 Jan 2006 by blackbird Post: UPX can be helpful with compressing Rosetta application: rosetta_4.80_i686-pc-linux-gnu 8323696 (uncompressed) rosetta_4.80_i686-pc-linux-gnu 3257302 (compressed) From my basic understanding how Rosetta works, i can suspect that the best way to decrease the traffic would be assigning a lot of random points for one protein. Eg. host downloads a protein, then 20 WUs with random points instead of loading 20 different proteins, thus reducing traffic (it would be the best solution). Another way to decrease the traffic is WU compression. As i have mentioned before, deep knowledge of WU structure is required to find the most apropriate compression method. In fact, if 2 digit mantissa of traectories is enough for computations, then traectories can be stored as words, which can give about 30% less compressed file size. Traffic issue is an often forgotten problem for scientists when intranet computations are transferred to internet-based solution. I believe that it is very important problem because more users mean more bandwidth for servers. In fact, you must select between building new server and optimising transfers.
8) Message boards : Rosetta@home Science : Feedback, .. bandwidth usage :-( (Message 8648) Posted 9 Jan 2006 by blackbird Post: As for me, i'm temporary switching to P@H until sheduler and traffic issues will be resolved. Jack?
9) Message boards : Rosetta@home Science : Feedback, .. bandwidth usage :-( (Message 8532) Posted 7 Jan 2006 by blackbird Post: Preprocessing of the WU file for compression gains about 20% of size. E.g. : aa1r69_09_05.400_v1_3 8609797 bytes (Uncompressed) aa1r69_09_05.400_v1_3.gz 2783855 bytes aa1r69_09_05.400_v1_3.7z 1029164 bytes (-mx7) After preprocessing with the program described below: aa1r69_09_05.400_v1_3 8609797 bytes (Uncompressed original file) aa1r69_09_05.400_v1_3.cr 2289588 bytes (Uncompressed coordinates in integers) aa1r69_09_05.400_v1_3.ot 1038759 bytes (Uncompressed other information, can be reduced) Compressed with 7z (-mx7 -mlc=4 -mlp=2) aa1r69_09_05.400_v1_3.cr.7z 663003 bytes aa1r69_09_05.400_v1_3.cr.ot 164619 bytes Thus, 827731 bytes after converting versus 1029164 bytes (-19.5%). Of course, the sheduler should assign only one type of WU for host when the work is requested, not 8 different with 20 Mb traffic!
10) Message boards : Rosetta@home Science : Feedback, .. bandwidth usage :-( (Message 7518) Posted 24 Dec 2005 by blackbird Post: Jack, i can repeat my suggestion . Delta integer compression with subsequent huffman integer compression stage can give very good results with coordinates. Deep knowledge of WU structure is required to make good compression, but even grouping reduces about 50% of file size.
11) Message boards : Number crunching : R@H is not suitable for dial-up users? (Message 6228) Posted 14 Dec 2005 by blackbird Post: I run R@H on dial-up connection and usually download new WUs each 5 days. Unfortunately, i had to download about 10 Mb of data last time - 1tif, 1r69, 1mkyA, 2reb, 1b72 structures on unstable connection. I suppose there are several reasons to reduce WU size, and this also mean reduced server traffic and workload. There are some ways to do this: 1. WU compression - column grouping, compress text columns e.g with Burrows-Willer -> Huffman, compress float columns with integer convertion-> delta encoding -> Huffman 2. WU distribution - i believe there is no need to receive 5 different proteins for 20 WU.
12) Message boards : Number crunching : WU Compression (Message 4810) Posted 30 Nov 2005 by blackbird Post: I have written some code in Pascal (67 lines) to test the idea. Column grouping between text 'Position: xxx Neighbors: yyy' was used. Results: (sizes in bytes) aa1dcj_09_05.200_v1_3 5294250 - original WU aa1di2_09_05.200_v1_3.gz 1585695 - gzipped WU With grouping: aa1dcj_09_05.200_v1_3 5294250 - original WU aa1dcj_09_05.200_v1_3.grpc 1664680 - converted WU aa1dcj_09_05.200_v1_3.grpc.gz 775250 - gzipped (gzip -9) converted WU You can see twofold decrease of WU size. Of course, better grouping code can be used.
13) Message boards : Number crunching : WU Compression (Message 4699) Posted 29 Nov 2005 by blackbird Post: First, only small part of code that converts downloaded WU file is required - this part converts binary data to text file. This also means that no major code rewriting is required. There are some other ways to increase the homohenity of raw data and therefore the compression ratio, e.g. using columns grouping instead of lines.
14) Message boards : Number crunching : WU Compression (Message 4578) Posted 28 Nov 2005 by blackbird Post: I can suggest that lowering WU size can both reduce server traffic and attract new users to the project. GZip is not good enough in compressing such files, and good compression rate can be reached with converting stage. E.g. 44-bytes string 1gox _ 264 A L -64.197 161.100 173.653 can be converted to 18-bytes string [4 char][1 char][word][char][char][int - by *100][int][int] and then gzipped. I can suspect very good compression rate.
15) Message boards : Rosetta@home Science : To David Baker, David Kim, Jack, & Other Admin (Message 3430) Posted 16 Nov 2005 by blackbird Post: I would welcome the idea to open Rosetta's sources - even under non-free license. Although i couldn't assist in code writing (i'm a clinical researcher), i prefer to use open source.