wrong message, sorry.

You might have a bad batch in the mix:
de_nbody_orbit_fitting_11_18_2025_v194_OCS_north__data__01_1763492010_30918
de_nbody_orbit_fitting_11_18_2025_v194_OCS_north__data__01_1763492010_10155

This is likely the important part of std_err output, we had that before IIRC:

hackCofM: tree structure error.

---

Yep, adding some to that list
https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1011257970
https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1011372731
https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1011348052

Also a weird one, 2 validated it, I got invalid (NaN likelihood), 3 others had error:
https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1011345773

And here I got an apparently valid result that ended up being considered invalid because two others had the NaN likelihood one:
https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1011313870

Thanks for sharing these workunits. It seems all of the errors coming up are on windows, so there may be something wrong with the windows application. I'll look into it and see if I can find anything.

Two more
https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1012331497
https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1012204535
The second seems to confirm that assessment, since a Linux host completed it while the Windows hosts errored out.

The second seems to confirm that assessment, since a Linux host completed it while the Windows hosts errored out.

This one confirms that too.

---

Also https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1012203112
On the other hand, https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1012080493 has 4 Windows hosts so far, 2 errored out, one gave NaN likelihood, one seems to return a valid-looking result.

And on https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1012399301 my computer returned NaN likelihood while 2 other Windows hosts had apparently valid and matching results.

They seem to be piling up:

https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1012898677 (1 completed, 4 errors)
https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1012851775 (2 completed and validated, 3 errors)
https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1012887563 (4 errors)
https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1012978439 (4 errors)
https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1012750311 (1 completed, 4 errors)
https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1013120633 (3 errors so far)
https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1012839197 (1 completed, 4 errors)
All Windows, including the completed ones, so the issue doesn't always trigger even on Windows, just most of the time.

https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1012898677 (1 completed, 4 errors)

Well, this one maybe didn't end as "error while computing", but this isn't a useful result:

<core_client_version>7.16.20</core_client_version>
<![CDATA[
<stderr_txt>
<search_application> milkyway_nbody 1.94 Windows x86_64 double  OpenMP, Crlibm </search_application>
Using OpenMP 4 max threads on a system with 16 processors
Running MilkyWay@home Nbody v1.94
Optimal Softening Length = 0.002983598945218 kpc, Upper bound = 0.025924117868790 kpc, Lower bound = 0.000343381507173 kpc
Dwarf Initial Position: [34.012283126660634,8.877454242345657,-34.127796851283485]
Dwarf Initial Velocity: [123.693929825971466,-94.318262981375895,-104.901444483550222]
Initial LMC position: [135.182581423281277,856.595685245141681,-275.862481511407225]
Initial LMC velocity: [-16.753777443590952,-123.501592415045153,21.093874110049356]
Initial body data written to 'initial.out'
Likelihood was NAN. Returning worst case. 
<search_likelihood>-9999999.900000000372529</search_likelihood>
strftime() failed called boinc_finish(0)

</stderr_txt>
]]>

https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1012851775 (2 completed and validated, 3 errors)

These are indeed useful results.

https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1012750311 (1 completed, 4 errors)

Same as the first.

https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1012839197 (1 completed, 4 errors)

This was a single useful result, which is now lost:

<core_client_version>8.2.4</core_client_version>
<![CDATA[
<stderr_txt>
<search_application> milkyway_nbody 1.94 Windows x86_64 double  OpenMP, Crlibm </search_application>
Using OpenMP 16 max threads on a system with 32 processors
Running MilkyWay@home Nbody v1.94
Optimal Softening Length = 0.000903778095629 kpc, Upper bound = 0.007852814774540 kpc, Lower bound = 0.000104015549786 kpc
Dwarf Initial Position: [-32.427126958012167,-5.323459462046818,31.737632722924701]
Dwarf Initial Velocity: [86.081574897206025,147.017238464885736,-89.135359201483510]
Initial LMC position: [133.895554707308634,877.948737840626222,-251.017015851749875]
Initial LMC velocity: [-15.287729129102473,-117.958463315616754,15.276892208040378]
Initial body data written to 'initial.out'
<search_likelihood>-249.642865872354065</search_likelihood>
<search_likelihood_EMD>-123.578672319975027</search_likelihood_EMD>
<search_likelihood_Mass>-75.196537390981078</search_likelihood_Mass>
<search_likelihood_Beta>-6.639685028975216</search_likelihood_Beta>
<search_likelihood_BetaAvg>-21.937696840304120</search_likelihood_BetaAvg>
<search_likelihood_VelAvg>-13.359746128746899</search_likelihood_VelAvg>
<search_likelihood_Dist>-3.217089377896983</search_likelihood_Dist>
<search_likelihood_Momentum>-5.713438785474729</search_likelihood_Momentum>
strftime() failed called boinc_finish(0)

</stderr_txt>
]]>

---

When investigating edge or boundary conditions it is vital to know where that edge is so both results you quote could be equally as important.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

They really do seem to be getting ever more frequent.
And here's another where the NaNs validated each other and the possibly valid result (happened to be mine) was invalidated: https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1013537540

I have been able to fix the bug on my end; I'll try to get the fix on to the server soon.

That's good news!

They really do seem to be getting ever more frequent.

Currently most WUs are very short, most complete in less than 5 minutes for me, so we are processing a lot more and likely because of that, we also see more errors. Over 600k results in progress according to SSP, have not seen that many in long time. But good to hear, that it will be fixed soon.

---