Has anyone given any consideration of coding a plug in that would allow using the processor in a GPU to do the math for this project. NVidia has \"cuda\" which enables C programs to utilized the advanced processors in their 8xxx series and higher graphics cards to be used for number crunching.

Considering the time it takes to process a single model, even on a reasonably fast machine I believe this would greatly benifit the project.

Thanks

---

This matter has been brought up many times.
It won\'t work, because the maths of the GPU isn\'t good enough for science apps, just graphics displays.

If it were feasible (problem is CPDN uses Fortran, so it\'s impossible to make calls to the GPU), don\'t you think most of the projects would have done so by now?

---

I\'m not surprised that all sorts of possibilities seem reasonable and feasible because there are computers of sorts everywhere. I actually read that some project or other can already or will be able to run on a lawnmower. Honest, I\'m not kidding. The processor in a GPU seems in comparison a very sensible suggestion.

---

Cpdn news

\"run on a lawnmower\" was probably DIY@home, using various attachments to dig up the garden, trim the hedges, clean the swimming pool, and take the dog for walkies.

I posted about it here. The link goes to an article about Folding@Home. The disappointing lack of responses to my post means I still haven\'t managed to connect the Qualcast to the internet.

---

Cpdn news

If one Googles for: boinc lawnmower there will be a lot of web pages.

The story seems to have several origins, most I think on SETI (It\'s a while since I looked):

1) A post about a person\'s computer sounding like a lawnmower when running BOINC.

2) A person saying that others where getting lots more credit than him, and that he need more horsepower. Followed by a post saying that he needed a better computer, not a bigger car engine. Followed by the original poster saying: Oh! I was just about to connect my lawnmower to the net and run BOINC on it.

3) A person talking about attaching a laptop to his lawnmower, so that he didn\'t lose any time computing.

4) (Possibly in the same thread as the previous one.) A person asking about someone else\'s post elsewhere, who was remote controlling his lawnmower, and asking if it involved a computer, and how did he program it to avoid obstacles.

At least some the posts went back to about 2005, and I think that folding@home was mentioned, but on a computer programming forum.

And some of the BOINC project posts mentioned lawnmowers as a side matter.
(One of the posters hurt his back while mowing the lawn, another used his lawnmower to \"rake up\" the leaves.)

If it were feasible (problem is CPDN uses Fortran, so it\'s impossible to make calls to the GPU), don\'t you think most of the projects would have done so by now?

There are Cuda add ons for SETI that have been certified. It might require transfering the entire process to a new program. With out the code to look at I can\'t say. That\'s is why I asked.

This matter has been brought up many times.
It won\'t work, because the maths of the GPU isn\'t good enough for science apps, just graphics displays.

Gee, And here all the time I thought it took a bunch of equations to move the little gobler in packman.

These climate programs are a million or so lines of Fortran, written by many people over several decades, to run on the supercomputers at the UK\'s Met Office.

The maths uses very large numbers of precision because of the need to encompass the range of things like the large amount of water vapour in the air, while at the same time including the miniscule amounts of things like sulphate particules.

The graphics for computer games don\'t have anywhere near the same range of values.

These climate programs are a million or so lines of Fortran, written by many people over several decades, to run on the supercomputers at the UK\'s Met Office.

The maths uses very large numbers of precision because of the need to encompass the range of things like the large amount of water vapour in the air, while at the same time including the miniscule amounts of things like sulphate particules.

The graphics for computer games don\'t have anywhere near the same range of values.

Thanks for the info. Nice to know there are is at least someone willing to hoist out and be civil.

Hi Dale

I hope I didn\'t offend you by my posts in this thread. I didn\'t intend to suggest in any way that your original suggestion in your opening post wasn\'t reasonable. It was of course a perfectly sensible suggestion, even though it\'s not useful for CPDN.

If I gave the wrong impression by going off at a tangent, or appeared to be treating your suggestion flippantly, I do apologise and assure you that this was never my intention.

Mo

---

Cpdn news

The 32 bits limitation is in the memory addressing range.
Internally, the processors use registers which can handle larger bits of precision.

e.g. see this article, at the end of the section: Integer range

These climate programs are a million or so lines of Fortran, written by many people over several decades, to run on the supercomputers at the UK\'s Met Office.

The maths uses very large numbers of precision because of the need to encompass the range of things like the large amount of water vapour in the air, while at the same time including the miniscule amounts of things like sulphate particules.

The graphics for computer games don\'t have anywhere near the same range of values.

A year has past since this post, so I think I\'ll revisit it.

My understanding (I\'m not an expert on this) is that the latest Nvidia cards support double precision math. (As you stated, most older cards only did single precision math, since that was more than enough for graphics.)

Does CPDN use precision higher than double? If so, that\'s not supported in the CPU hardware either, so it would have to be emulated in the Fortran libraries. That emulation could be ported to the GPU.

If double precision is used in the calculations, that\'s directly supported by the newer GPUs.

Considering those GPUs run an order of magnitude faster than even the fastest CPUs, and the length of the CPDN workunits, this would be a superb project to be GPU\'d.

All that aside, there\'s the Fortran thing. Porting massive programs from Fortran to C is not a trivial task, and that, in and of itself, might prohibit CPDN from ever being available on a GPU.

As for converting the app to run on a parallel processor, I would think that CPDN would be a great fit for this. The supercomputers used to run many weather forecasting systems are (or were) supercomputers because of their specialized vector (i.e., parallel) math capabilities. I\'d be surprised if the original code written for the supercomputers wasn\'t written to take advantage of the parallel processing abilities of those computers.

An awful lot of coding would be involved. Not only do you have to translate the programing language, but rewriting the application to take good advantage of the specific type of parallel processing available in a GPU is something that requires some skill, thought, and time.

I guess it depends on where the project wants to put its resources. There\'s a ton of GPU processing ability out there. Is it worth it to get results back much faster, meaning many more WUs get processed? Imagine crunch times for CPDN models that are measured in hours, instead of days. (The latest GPUs could probably complete the smaller CPDN models in less than a day.)

Mike

---

Want to find one of the largest known primes? Try PrimeGrid. Or help cure disease at WCG.

Let\'s look at it from a different direction.
The project\'s servers are already struggling to cope with the huge amounts of data being returned. Why do you want to increase this so drastically?

It would be simpler to decrease the so called \"deadline\" to 6 months, so that the thousands of people who feel that they have years to return the complete model, speed up their processing.

And I\'m sure that the project\'s programmer has heard of GPUs and cuda.

It\'s also a question of the manpower available, which depends entirely on funding. CPDN has two full-time programmers and a small number of researchers who help out to some extent with the model programming. Last year we spent at least 6 months beta-testing models to make them and their graphics BOINC 6-compatible. As a result CPDN is well behind schedule with one big new research project and there\'s another queuing up.

The models have to be released and crunched to tight deadlines so the PhD students get their data in time to analyse it and write up their research within the 3-year limit for PhD grants. The programmers already have a hard time meeting some of the deadlines set for them by the researchers.

There\'s just no slack in the system at CPDN, at least at the moment, to redesign anything from zero. Everybody\'s already working flat out.

---

Cpdn news

It\'s also a question of the manpower available, which depends entirely on funding. CPDN has two full-time programmers and a small number of researchers who help out to some extent with the model programming. Last year we spent at least 6 months beta-testing models to make them and their graphics BOINC 6-compatible. As a result CPDN is well behind schedule with one big new research project and there\'s another queuing up.

The models have to be released and crunched to tight deadlines so the PhD students get their data in time to analyse it and write up their research within the 3-year limit for PhD grants. The programmers already have a hard time meeting some of the deadlines set for them by the researchers.

There\'s just no slack in the system at CPDN, at least at the moment, to redesign anything from zero. Everybody\'s already working flat out.

Thanks for the informative reply! I didn\'t realize CPDN had an issue with processing the incoming results. I can certainly understand how the very last thing you would want to do would be to speed up the client-side processing!

And I fully understand that the effort involved would be very large. I\'ve personally done the Fortran to C translation on a very large program, and the two languages are simply from very different eras. They don\'t map to each other very well, at least not if you want to end up with understandable C code when you\'re done. A lot of effort is required to do it right.

Once again, thanks for the explanation.

Regards,
Mike

Yikes! We\'re doing more work than you can process!

Well, maybe it\'s time for some volunteer processor time for results analysis. Maybe the code can be easily converted, maybe not, but it must be easier than converting CPDN by a lot.

And if they are using a commercial analysis tool, it may already be available for micros.

I\'m ready to volunteer one or two machines for this work. What would it take?
PS. Physics degree, long time programmer, starting with Fortran.

BillN

---

Hi Bill

When Les said \'The project\'s servers are already struggling to cope with the huge amounts of data being returned.\' I think he was mostly referring to the extraction of data for the researchers. Milo must set up a search for a particular model type and within that type for models that produced a particular sort of result or that have specific parameters values. Because the ensembles are so large, these searches are huge and can take two days or more. I assume he does these searches on the climateapps2 server because when he\'s extracting data this forum slows down.

I expect he then transfers what he\'s extracted to the researchers\' own computers where they analyse the extracted models with whatever statistical program they use. One of my sons is involved in research into optimising renal dialysis; he has a massive database of results but his hospital provides him with a commercial statistical analysis program. I expect CPDN provides some similar program for its research staff and students.

---

Cpdn news