I concur,
With MW preferences set to crunch all WU types, in the client state I have the following names:

<app>
<name>milkyway_nbody</name>
<user_friendly_name>MilkyWay@Home N-Body Simulation</user_friendly_name>
<non_cpu_intensive>0</non_cpu_intensive>
</app>
<app>
<name>milkyway_separation__modified_fit</name>
<user_friendly_name>Milkyway@Home Separation (Modified Fit)</user_friendly_name>
<non_cpu_intensive>0</non_cpu_intensive>
</app>
<app>
<name>milkyway</name>
<user_friendly_name>MilkyWay@Home</user_friendly_name>
<non_cpu_intensive>0</non_cpu_intensive>
</app>

Here at WUProp I can see,

MilkyWay@Home N-Body Simulation
Milkyway@Home Separation (Modified Fit)
MilkyWay@Home

They match.

From Tasks Menu in Boinc, the WU's are named the same, but with additional detail (version number and if mt),

MilkyWay@Home N-Body Simulation 1.36 (mt)
MilkyWay@Home Separation (Modified Fit) 1.24 (opencl_nvidia)
MilkyWay@Home 1.02 (opencl_nvidia)

MT and ST WU's use the same app. There was a discussion about this at MW.

---

=sticky tape=

MT and ST WU's use the same app. There was a discussion about this at MW.

To be clear, they are different apps, with the same user friendly name.

<file_name>milkyway_nbody_1.36_x86_64-apple-darwin__mt</file_name>

vs.

<file_name>milkyway_nbody_1.36_x86_64-apple-darwin</file_name>

---

Reno, NV
Team: SETI.USA

*It is annoying when projects put the version number in the app name. The name should NOT change when changing the version number.

That is true only if the new version is computing on the same type of WUs and producing the same result files.

But if the WUs and/or results change the app name have to change.
And often projects don't want to think about new name and just add the new (major) version number to the name.

This was the case with 'SETI@home Enhanced' (app versions 5.x and 6.x) vs 'SETI@home v7' (app versions 7.x) and 'AstroPulse v5' vs 'AstroPulse v6'

(if this was M$ product I imagine names like 'SETI@home 2013' 'SETI@home Pro' 'SETI@home Ultimate' ;) )

---

- ALF - "Find out what you don't do well ..... then don't do it!" :)

*It is annoying when projects put the version number in the app name. The name should NOT change when changing the version number.

That is true only if the new version is computing on the same type of WUs and producing the same result files.

But if the WUs and/or results change the app name have to change.
And often projects don't want to think about new name and just add the new (major) version number to the name.

This was the case with 'SETI@home Enhanced' (app versions 5.x and 6.x) vs 'SETI@home v7' (app versions 7.x) and 'AstroPulse v5' vs 'AstroPulse v6'

(if this was M$ product I imagine names like 'SETI@home 2013' 'SETI@home Pro' 'SETI@home Ultimate' ;) )

Meh. That calls for a new app name. Not a new app version.

---

Reno, NV
Team: SETI.USA

If I am running a Multi Thread application for Yafu and it has run for over 2 hours on a 6 core AMD machine, why does it report that I have 2 hours pending?
It should be 6 times that.

I have been noticing since Yafu came back on line after being shut down for a few weeks that my WUProp times are only creeping up when I have been doing quite a few work units.

It seems to not be recording the multi thread nature of the work units.

Not sure of N-Body on Milkyway as I have not caught one running recently.

Conan

---

Not sure of N-Body on Milkyway as I have not caught one running recently.

WUProp is picking up the multi-threading N-Body tasks. I am running it on two of my slow computers (4-thread cpus) for the WUProp hours.