Folding Forum

In order to have a quicker overview on what disease a certain project is supporting I would like to suggest to add that information to the psummary file. I know its in the description one click away hence low priority. But would be a good information to quick see in the overview (plus one could use it for reporting purpose).

ChristianVirtual wrote:In order to have a quicker overview on what disease a certain project is supporting I would like to suggest to add that information to the psummary file. I know its in the description one click away hence low priority. But would be a good information to quick see in the overview (plus one could use it for reporting purpose).

I don't speak for PG, but I know duplication of effort is not one of their design goals. Also that drive space is a premium, even at today's record low prices just because they use so much. And it adds undo workload to the stats servers doing the disease lookup for each project every 15 minutes. PSummary, as you know, is updated dynamically from the list of active WUs on the Work Servers. One extra piece of data on that page is non trivial for a trivial benefit.

And why not add Full, Adv, and Beta to each project on PSummary? And the number of WUs in that project? And...then where do you draw the line? Right before the server runs so slow it becomes useless?

Good idea. Not going to happen.

As most of my ideas ... I still dump them here ... Just in case ...

And your additional proposals would be nice too

Since the work units and work servers will eventually support that Cause Preference, why don't you suggest the client show that information? Then you might be able to show it with your nifty little tool.

7im wrote: And why not add Full, Adv, and Beta to each project on PSummary? And the number of WUs in that project? And...then where do you draw the line? Right before the server runs so slow it becomes useless?

I don't mind whether the info comes from psummary or somewhere else, but to have the full/adv/beta status shown in the client would be useful. It's not always easy to tell if a WU is still in beta -- announcements are not reliable (in reception or transmission), sometimes projects are "stuck" in beta and reappear after a break, etc. I don't want to report non-beta units on the beta forum (and vice versa).

David

Not the right place to add it, but yes, that has been a perpetual request as well.

Another problem with adding FAB to the PSum page (in addition to the problems listed above) is that work units from a single project can have a series of runs/clones in beta while having another series in advanced. Then you would need to double the lines to show both B and A for that project.

Again, only the individual WU header data shows the FAB setting, so this is best displayed by the client. Why don't you put in a suggestion for the client to show that information?

Perpetuated these 2 requests...

Ticket #1118: Add WU specific Cause Preference info to work unit info displayed in FAHControl

Ticket #1119: Add WU specific Client Type info to work unit info displayed in FAHControl

Thanks

7im wrote:Perpetuated these 2 requests...

Well one didn't last long

Partly JC has missed the point. It is NOT the slot that is beta/adv/full. The slot may have a beta flag, but it can then receive units of all three types.
We want/need to know which type each WU is. But if the info isn't there, it can't be displayed. Predumably getting the info requires a mod to every core.

So back to trawling psummary/psummaryb for every unfamiliar project on beta clients. And if, as more than one person who should know have suggested, projects can have WUs in more than one type, even that won't be reliable. The info must be found from each WU.

I'm beginning to think it's a waste of time suggesting improvements to the client.

David

davidcoton wrote:...Well one didn't last long
...I'm beginning to think it's a waste of time suggesting improvements to the client...

Please note that while a ticket can be closed now, there is always a possibility that it can be reconsidered in the future and could be implemented. Here is an example where the ticket was closed and 3 years later, is being reconsidered (https://fah.stanford.edu/projects/FAHClient/ticket/705). Thus, I would suggest that all reasonable suggestions be entered into the Trac system so that in future, it becomes easy to track features which could be reconsidered to implement into the next client version. Moreover, if someone else asks for the same feature which wasn't accepted, we can point to the closed ticket which could provide information as to why it won't happen.

The art of "Zen Folding" , it teaches patience

On topic: client-type by WU would be great (I might find my posting for that one); but at least we could present the closest value to donors. So if there is a beta WU for a general advanced project the donor would care and see only "advanced".

Found it: viewtopic.php?nomobile=1&f=66&t=24852