Q: providing additional info like "ns" by project

[billford]

It seems to me that what you're asking for is much of the configuration data used by the researcher to build the project… as such it should be fairly easily available, but it might be a bit much incorporating it into psummary!

If PG were agreeable to this data being available then perhaps a link in psummary to a more detailed "Protein Configuration" page? Possibly replacing the "Number of atoms" column; that would require minimum changes to psummary, and the replaced data would be in the new page.

Then donors could use whatever data interested them, and ignore that which didn't. Which for me, as a humble electronics engineer, would be most of it

Thoughts?

[7im]

... not for any purpose of comparison or measurement.

Maybe not for you... but any number added on the screen will eventually be used for a comparison, valid or not, just human nature. And that will generate questions and confusion for people who don't understand ns/day, and all it's non-comparative qualities, which is almost everyone except the enthusiast folder.

We have a hard enough time explaining why Joe gets 10K PPD and Tom gets 11K PPD on the exact same project. Good luck explaining and answering ns/day questions.

[billford]

… just human nature.

So is setting the beta flag when not a member of the beta team- put an "unsupported, use at your own risk" disclaimer in a sticky post and treat it the same way.

[ChristianVirtual]

a link in psummary to a more detailed "Protein Configuration" page?

Great idea ... Ideally and more simple a link to a JSON/XML file with those "raw" data /parameter. No need for style sheets and easier to process to those who want.
And most likely easy to generate with a few shell-scripts automatically.

[7im]

… just human nature.

So is setting the beta flag when not a member of the beta team- put an "unsupported, use at your own risk" disclaimer in a sticky post and treat it the same way.

Not trying to be circular here, but why waste programming efforts on an "unsupported, use at your own risk" feature?

Also, the beta setting and format are pretty well hidden for new donors. Putting ns/day on the front screen of FAHClient is very different.

You'd have better luck convincing a 3rd party developer like CV or Harlam to track and display that value. As bruce noted, bells and whistles come with a high cost and a limited developer budget, especially with low final benefit.

It's also a waste to add to the current client when it is already in the next client in some format or another. See the ocore beta thread.

[bruce]

Let's look at the costs.

It's reasonable to assume the Work Server knows this data for each of it's projects. It's also reasonable to assume that the work server does not publish this information so we probably have to assume that the each work server needs a change to its server code and some kind of an update must be performed. If the data is added to psummary, then the script to gather and publish that data needs to be changed and it needs to handle cases where the work-server code has not been updated. That's probably more expensive than you think There are 56 work servers listed on serverstat and they have not all been updated to a single version of the server code (much like if you happen to run 56 client machines, you're likely to be simultaneously running Win8, Win7, WinXP and perhaps a couple of versions of Linux and/or OS-X.

Changing the FahCore to publish the information in the local log isn't likely to happen, since it would require most of the same changes, plus an update to each of the active FahCores, including those which have not been updated in a long, long time. (I think collectively we've already eliminated this as a requirement.)

My current recommendation is even more economical. Suppose we ask the PIs to publish this information in the project announcement. Choosing an arbitrary group of recently released projects, consider projects 10171-2 and 10177-80. These were originally announced here and have project descriptions like 10177. We could ask Dr. Bowman to include that information on either of those posts. The information would be available but it would require a little more work on the part of the donors and/or a 3rd party app. What do you think?

[ChristianVirtual]

You'd have better luck convincing a 3rd party developer like CV or Harlam to track and display that value.

I'm already convinced

[ChristianVirtual]

and have project descriptions like 10177.

I would opt for the project description as I read that anyway in my current version on demand. Plus it use the project number direct as key. Getting the relevant data from there will be easy enough if we could agree on a fixed structure/format, ideally a table-construct easy to identify in html code. In the same way I reparse the psummary already to get kFactor for PPD estimations.

[billford]

Let's look at the costs.

If the data has to be acquired from the WS's then I take your point- I've been assuming that the data in psummary was entered into a project record by the researcher at project creation time, and that the suggested additions wold simply require the one-time entry of a few more fields into that record.

If this is not the case then clearly I need to reconsider...

[ChristianVirtual]

Psummary seems to be a more dynamic piece of list. Sometimes you see project coming and going and coming back. Depend on actual assignments to my understanding.

[billford]

It's also a waste to add to the current client when it is already in the next client in some format or another. See the ocore beta thread.

I'm not talking about adding to the client… do you ever read what's been posted before reflexively leaping to the defence of the status quo?

[billford]

Oops, missed this bit:

The information would be available but it would require a little more work on the part of the donors and/or a 3rd party app. What do you think?

As long as I don't need a degree in rocket science or molecular biology to find it, that's fine by me

[7im]

It's also a waste to add to the current client when it is already in the next client in some format or another. See the ocore beta thread.

I'm not talking about adding to the client… do you ever read what's been posted before reflexively leaping to the defence of the status quo?

I am addressing the original topic, not your side commentary. Note the "client" in the thread topic.

[bruce]

Cristian_Virtual asked the original question, specifying "client output." As I said in my previous post, I think everybody has agreed that's not required. Lets not get sidetracked from the nanosecond issue, itself.

Christian_Virtual can remove those words from his first post (or a mod or admin can) and we can continue a modified topic.

[ChristianVirtual]

Changed the topic to be more flexible on the solution ... As long any 3rd party tool can get it in an automatic way I don't mind where come from