Hi there!
My WU went up to 66.66% and then the problems began. I think climate wanted to compress the data like it did at 33.33%. But anyhow it doesn't do it right. The progress turnt suddenly to 551779,15%. After restarting Boinc, the progress got back to 0.00%.
Phase 3 started not at timestep 0, but at -3627100.
In graphicsmode climate shows 'post-processing increased disk activity...'
My account shows following:
26 Mar 2005 21:02:49 Phase 3 Timestep 259248 CPU Time 2682216 Average 3.4487
26 Mar 2005 21:02:49 Phase 2 Timestep 259248 CPU Time 2682073 Average 5.1728
(http://climateapps2.oucs.ox.ac.uk/cpdnboinc/show_host_detail.php?hostid=69459)
I don't know, if that's normal, but I don't think.
Climate meant to do some work, but its behaviour is pretty strange, especially the negative timestep...
Maybe someone knows this problem and can help me.
I'm using Boinc 4.25 for windows. I uppgraded it from 4.19 about a week ago without any problems.

edit: as you can see, i got even the credits for phase 3 without crunching it...

edit2: nice... climate is now uploading. Perhaps it worked normal. Nevertheless it is strange, that I didn't have to crunch the 3. phase of the model.

I have seen this reported before but only once I think. You have provided more information re negative timestep which may help to fix the problem. Where did you see this, on the visualisation?

However, I don't imagine that it will get a lot of attention for some considerable time as very few people seem affected and there are lots of more important problems and development to do.

Thanks for the report and welcome to the board.

Thanks for your reply!

As you supposed, I saw the negative timestep on visualisation.
And as you said, it's not a big problem. Just a little unfair, cause I got credits for phase 3 without crunching it. Hopefully it's just an exception!

Would be interesting to see the result of a query like this :


SELECT count(*), round (result.granted_credit / 94.5175, 0)
FROM result
WHERE ( result.outcome = 3
OR result.server_state = 4 )
AND result.granted_credit > 90
AND result.granted_credit < 6800
GROUP BY round (result.granted_credit / 94.5175, 0)
ORDER BY 2;


I'm not too familiar with the exact MySQL syntax but maybe you get the idea.

I would expect to see three quite high peaks at 23, 47 and 71

Another interesting thing about the WU with the speedy phase 3 :

It must have been on some hard wired ferrite cores or those paper cards with the holes representing the bits :

created 20 Jun 1973 23:10:50 UTC

> created 20 Jun 1973 23:10:50 UTC

Interesting observation Ananas. <a href="http://climateapps2.oucs.ox.ac.uk/cpdnboinc/workunit.php?wuid=201188">WU 201188</a> did the same to me last December (<a href="http://climateapps2.oucs.ox.ac.uk/cpdnboinc/result.php?resultid=394873">result id 394873</a>), and it was created on the same day. My strange result for that one is because I tried every trick I could think of to force it to restart phase 3 and failed dismally :(

<a href="http://climateapps2.oucs.ox.ac.uk/cpdnboinc/workunit.php?wuid=249845">WU 249845</a> was, however, created on the same day and has been fully completed by one host (still waiting to start on one of my hosts running the sulphur cycle alpha trial).

---

"The ultimate test of a moral society is the kind of world that it leaves to its children." - Dietrich Bonhoeffer

I'm now experiencing this problem with wu 243501.

---