I'm sure I have the wrong attitude about this credit business, but does any of it really matter in the grand scheme of things? Is any of it effecting the science in any way? Are the models being computed incorrectly because of the amount of credit given or not given?

Or am I just being a cranky old man?

---

Well, of course the credits don't affect the scientific results of the individual models. However, to the extent that credits motivate some crunchers to keep going and contribute more, they probably do help to increase the overall participation levels. And that helps the researchers.

I can understand members feeling that BOINC credits are an irrelevant bore, but I can also understand the members who enjoy the spirit of competition.

We are receiving the right number of credits for every model type including HadAM3P. It's just the recent average credit calculation done by the CPDN server that's wrong if it includes HadAM3P. We'll have to bring this problem up again with Milo.

http://boinc.berkeley.edu/dev/forum_thread.php?id=3796

---

Cpdn news

We are receiving the right number of credits for every model type including HadAM3P. It's just the recent average credit calculation done by the CPDN server that's wrong if it includes HadAM3P. We'll have to bring this problem up again with Milo.

I am aware of this and would like to fix it. There are a couple of things getting in the way at the moment. The first is that I am not sure exactly where this problem lies and the second is that the entire credit process needs sorting out. Our current credit script is very slow with one particular part taking 5 hours to run and putting a heavy load on the database, and we really need to get this fixed. At the moment I'm trying some alternative means of performing the calculation.

I am not sure exactly where this problem lies.

Am I even close to collecting on my bet?

Am I even close to collecting on my bet?

Unfortunately not.

Am I even close to collecting on my bet?

Unfortunately not.

Shucks. Thinking cap back on, then.

I am not sure exactly where this problem lies.

Am I even close to collecting on my bet?

Is it day deprecation? Meaning a single core host producing 300 credits per day delivers this to the average credit formula:

Mon     300                             Mon   300
Tues    600                             Tues  300
Wed     900    when it should be --->   Wed   300
Thurs  1200                             Thur  300
Fri    1500 (completion)                Fri   300
Sat     300                             Sat   300

(I know these numbers don't match an actual HADAM3P run--just illustrating the point.)

Ahh... all is quiet on the climateapps2 board. The new scripts and hardware upgrades are working swimmingly--the admins and programmers richly deserve our appreciation and adulation.

However we still have beaucoup RAC with HADAM3P\'s!

Oh well, life is full of imperfections. It doesn\'t bother me so much because I use boincstats.com to look at monthly and weekly credit accumulations. Hopefully the newbs aren\'t too put-off by this.

I think you\'re right - beaucoup trop. Since my beta models finished and I\'ve been running more HadAM3P, my blue RAC line has jumped above the red BoincStats RAC line. That\'s even though my slower AMD is only running Mid-Holocenes. I know the blue and red RACs are calculated by different formulas, but they shouldn\'t usually be way out of sync. Un mystère inexplicable.

I certainly shouldn\'t have a CPDN RAC above 2000 because my two computers together can only manage about 1450 daily max.

I\'ve noticed btw that on my C2Duo the HadAM3Ps run noticeably faster when there\'s a Mid-Holocene on the other core and not another 3P.

---

Cpdn news

It\'s just a minor annoyance. One could even say it spices the project up a bit.

mo.v, here\'s an early congratulations on 1,000,000 credits. Nice work!

Eric

Don\'t HADAM3P use the more advanced SSE2 instruction set on cpus? If so, they do more calculations per clock and boinc might expect that they would be awarded more credit. Just my thought on this.

As has been posted many times, this project doesn\'t use the BOINC credits system.
Use the Advanced search, and set the Search limits to 1 year.

---

Backups: Here

For each model type there\'s a specific number of credits per trickle. HadSM and HadSM MH are essentially the same type so the number\'s the same. If you crunch faster and produce more frequent trickles you earn more credits.

The compilation is always designed to produce the highest quality model results, not to make the models run as fast as possible.

HadAM3P models receive their correct number of credits per trickle but produce incorrect, artificially inflated RAC (recent average credit) values. Milo has looked at this but cannot find the reason.

---

Cpdn news

.....................
HadAM3P models receive their correct number of credits per trickle but produce incorrect, artificially inflated RAC (recent average credit) values. Milo has looked at this but cannot find the reason.

This may be a very naïve remark, but, if the calculation seems correct, is there any chance the \"average credit\" weighting from HadAM3P models could be entered twice in the calculation as it seems that the RAC that should be just over 1,000, displays as just over 2,000?

I was running HadAM3P exclusively and had settled at 2,350 RAC after the replacement of servers.
Then I have been running exclusively hadsm (Holocene & Slab).
The straight line of \"Total Credit\" proves the same rates of credits have been given.
But RAC has sunk over the same 16 days and is levelling off at about 1,050.

During those 16 days total credits rose from 724,600 to 731,200.
That is an increase of 6,600.
That works out at just over 400 per day.

So, how come the RAC is calculated at the average over TWO AND A HALF DAYS.
That seems absurd.

As the RAC never seems to make any sense, it does not worry me.
I just ignore it as useless.
Quite happy aligning a ruler along the total credit graph to see delays caused by late returning or crediting of trickles.

I am just very, very curious as to what \"average\" means.
A speed is reckoned as miles per hour or feet per second.
But this mysterious RAC is just a number with no meaning.
\"Credits per day\" or \"Credits per week\" would be reasonable descriptions, but they are obviously neither of these.

Keith

Well, I can tell you what RAC *should* be. It should be calculated using a moving average credits granted per day, over 7 days. The formula for this is here:
http://en.wikibooks.org/wiki/Statistics/Summary/Averages/Moving_Average

The fact that only one model miscalculates the RAC is a strange anomaly. Again, though, choose your battles. What\'s it worth time & effort to properly calculate RAC?

Well, I can tell you what RAC *should* be. It should be calculated using a moving average credits granted per day, over 7 days. The formula for this is here:
http://en.wikibooks.org/wiki/Statistics/Summary/Averages/Moving_Average

The fact that only one model miscalculates the RAC is a strange anomaly. Again, though, choose your battles. What\'s it worth time & effort to properly calculate RAC?

OK. So, I enjoy mathematical puzzles, and this certainly is one.
It appears from that link, the average may be based on 10 days rather than on 7 days, but no matter.
The \"moving average\" whether \"weighted\" or not should be irrelevant in my case.
With minor fluctuations the total credits over 16 days were 400 per day.
This has remained steady in the period using HadAM3P exclusively, then running hadsm exclusively.
But the RAC has shown as 2,350 (nearly 6 times what it should) with HadAM3P.
Now settling down at just over 1,000 (still well over double what it should be) under hadsm.

So, I disagree that HadAM3P is the only model showing incorrect RAC.
It just is a more extreme example of inaccuracy, I think you must agree.

I agree with the formula to smooth out the curve, but wonder what values are taken for the weighting, and what happens at the \"near edges\" calculations that are mentioned.

It all seems to be a very complicated bit of work, when a straight average over the previous 14 or 28 days (total divided by the number of days) would give adequate smoothing anyway.
The \"adequate smoothing\" is provided by dividing the difference of the latest day added at one end and the day removed at the start of the average period, as this change is divided by 14 or by 28 depending on which of the 2 periods that I suggested are used.
And much, much simpler for computing (and more importantly, easily understood).

I wonder if the programmers might heed this, and think it might be worth considering?

Keith

The programmers are busy with the Hi-res models and the 1200 year models.
However: \"Your input is important to us. Please call again later.\" :)

I MUST APOLOGISE.
I miscalculated the daily rate of credits as 400.
It should have been 660 per day. I misread a date on the graph.
So the period was 10 days and not 16 days as I previously said.
That could just about at a stretch be the figure the graph will finally level out.
So, I must withdraw my comment about ALL averages being way out.
Blush, blush. Sorry for not taking care to double check my calculations.

Although, if the 10 days mentioned in the link are to be believed, the graph should already have levelled out at 660 after the 10 days had elapsed.
It is still at 1,075 after 15 days on the hadsm models (which are accurately calculated?)

Keith

The formula for RAC is:
Old_RAC * 0.5^(1/7) + Today\'s_credit * (1-0.5^(1/7)) = New_RAC

That is a weighted average so that more recent credit has a higher weight. It also means that your RAC has a half-life of 7 days.

If you start with a RAC of 2350 and your daily output is 660 credit, then according to the formula your RAC should be 974 after 17 days. Your current RAC seems to be 965, pretty close.

What\'s it worth time & effort to properly calculate RAC?

I agree--it\'s not worth the effort. But we could probably prevent a lot of head scratching by removing RAC from this site--or at least put some math violation in the script so everyone\'s RAC shows an error or zero. It\'s meaningless, so why keep advertising it as meaningful?