Application: Long runs (8-12 hours on fastest card)
So it's about 5% too long to fit the description - I think we can afford 'em a bit a slack on this one ;)
Anyway, it might take 12h exactly on a GTX580 optimized under Linux-x64.

There are many different task types so there will be variety in run lengths, and they don't all fit the same performance/credit scheme due to differences in the calculations and amount of CPU usage.

I share your concern about task lengths, after seeing several tasks take over 1day on a GTX260. However having a low cache has always been recommended for GPUGrid. Perhaps this time some notice would have been useful as these are so long but I am not sure we generally need an announcement every time a task has a different length. If we do then we need a table of different task types and expected completion times for different cards on different systems (XP or Win7). That would require a lot of maintenance.

Those 13h Linux tasks started and stopped 5 times during their runs, but I accept that if a task takes over 12h on the fastest card and operating systems then the default Boinc setting of a 0.5day cache would be undesirable even for the fastest card.

I usually keep a very low cache (0.01 to 0.20), even on my GTX470 Fermi systems. The only time I don't is when I am crunching the normal/short tasks, and even then I usually stick to 0.5 (even though it's not needed for GPUGrid, it stops having too many CPU tasks in the queue). When I notice Long tasks taking longer I drop back to between 0.01 and 0.05.

I think that the idea of Ignasi was to announce the new project EGF, not every single batch that it is put online for that project. Of course, this can be done as well. It should not require too much time.

gdf

...It wouldn't have to be complete, but it's a good basis for checking the performance of someone's system.

Hello: I just finished one of these tasks (p20-IBUCH_5_cetumutEGFR. ..) on my GTX295 in more than 27 hours.

Presuming appropriate optimizations/recommended settings are in place, and stock cards.
Estimated runtime for X-IBUCH_X_cetumutEGFR tasks (Linux/XP, Vista/W7), ball-park estimates:

GTX 590 GF110 40nm CC2.0 2488 BoincGFlops peak (3359) 17.7h, 19.7h
GTX 580 GF110 40nm CC2.0 1581 BoincGFlops peak (2134) 14h, 15.5h
GTX 570 GF110 40nm CC2.0 1405 BoincGFlops peak (1896) 15.8h, 17.4h
GTX 480 GF100 40nm CC2.0 1345 BoincGFlops peak (1816) 16.5h, 18.2h
GTX 295 GT200b 55nm CC1.3 1192 BoincGFlops peak (1669) 27.3h, 30.4h
GTX 470 GF100 40nm CC2.0 1089 BoincGFlops peak (1470) 20.3h, 22.5h
GTX 465 GF100 40nm CC2.0 855 BoincGFlops peak (1154) 27.7h, 30.7h
GTX 560 GF114 40nm CC2.1 1263 BoincGFlops peak (1136) 26.3 29.1h
GTX 285 GT200b 55nm CC1.3 695 BoincGFlops peak (973) 23.9h, 26.4h
GTX 275 GT200b 55nm CC1.3 674 BoincGFlops peak (934) 24.96h, 27.3h
GTX 260-216 GT200b 55nm CC1.3 596 BoincGFlops peak (834) 27.9h, 30.4h
GTX 460 GF104 40nm CC2.1 907 BoincGFlops peak 768MB (816) 35.8h, 40.5h
GTX 460 GF104 40nm CC2.1 907 BoincGFlops peak 1GB (816) 36.6h, 40.5h
GTX 550 GF116 40nm CC2.1 691 BoincGFlops peak (622) 48h, 53h
GTS 450 GF106 40nm CC2.1 601 BoincGFlops peak (541) 55h, 61h

Note that dual GPU cards will return each task slower than the highest single GPU cards.
PS. Initially, these were going by old comparisons on old apps, so there was some discrepancies. I have since better adjusted for the GTX200 series cards. Drivers might also influence the situation. Linux on 6.14 with SWAN_SYNC might be slightly faster than on XP without (different app).

After looking at a few tasks I think the chart might be out by about 27% for the GTX200 series cards. I will correct it below.

Bedrich Hajek, your task just about finished before the 24h mark, but because of your cache settings and possibly not using report tasks it did not get reported within 24h, so you only got 25% credit rather than 50%.

GL

Hi criadoperez, thanks for completing the very long task.
Ignasi dropped everything to address the size concerns. No more extra long cetumutEGFR tasks are being released. The new cmEGFR (Cancer) tasks are much shorter, and should finish in time for the biggest bonus on your GPU.

PS. It seems my initial estimates may have been closer to the mark for the 6.14app and my altered/present estimates for the cetumutEGFR tasks might be better for the 6.15app. Not that it matters now that the task size has been reduced.

WRT the structure of the NIS protein, I found a description of the Putative
(presumed) ‘secondary structure’ with this image,

Ref. http://edrv.endojournals.org/content/24/1/48.full

I could not find a 3D structure, suggesting as Ignasi said the tertiary and quaternary structure is not accurately known.
Doesn't surprise me looking at it; a 13 domain bi-lipid layer spanning protein complex. While these trans-membrane segments are probably fairly rigid themselves, they could float about somewhat independently within the bi-lipid layer as the external parts of the protein might be fairly flexible, or could form a tight quaternary structure, or both at different times/under different circumstances. While a lot is known/presumed about the secondary structure, who knows what sort of functional channel it forms.

Zoltan, I think you have glimpsed the future; the expansion of the present molecular simulation systems into new territory, with more complex fluids/solutions, and perhaps even the merging of molecular dynamics with existing and future fluid modeling techniques.

____________
FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help