Possible work-around for genome-crashes.

[Rattledagger]

One solution popping up in the "official" genome-group is this:

Then crashing, change the seed-number in seed.dat. It's a 32-bit-number, therefore max 2^32.
Stefan's comment to this is:
<blockquote>This will work, and not cause any major problems. However, I wouldn't make a habit of it, since it's harder for us to verify the data if the seed has been changed.</blockquote>

Of course, a wu crashing in first sequence is probably corrupted, and should be discarded. Another thing, if re-looping same wu, don't choose the same seed as you've already used for this wu...

[Ees]

After you've changed the seed, will the entire unit be recalculated? If so, I'd take the safe way out and just get myself a new unit.

Martin

[Sisyfos]

Originally posted by Ees
After you've changed the seed, will the entire unit be recalculated? If so, I'd take the safe way out and just get myself a new unit.

Martin

It continues from the sequence where it crashed.

> Hi,
>
> I had the 0.98 client cause a GPF on the 25th sequence of a 99aa this
> morning. It takes nearly a day to process that size of gene on that
> particular machine I found that if I changed the seed.dat manually,
> the work unit would continue processing with no problems. Since the
> 30th sequence is the only one added to the database, how would this
> affect the results if I uploaded the completed WU? Is this a bad idea
> to change the seed? Inquiring minds want to know...

Quoted post from Yahoo

Kim

[Rattledagger]

Hopefully fixed the genome-bug.

<blockquote>In this same vein, I've tracked down the infamous memory access violation bug, and pending the success of my overnight tests, should have a new version out tomorrow.</blockquote>

from http://groups.yahoo.com/group/genomeathome/message/2817

If released tomorrow, this version will not contain http-support.