All tasks started having this error.
https://milkyway.cs.rpi.edu/milkyway/result.php?resultid=942925980

Yep, badly formatted tasks. All mine are erroring out too.

---

same here

<core_client_version>7.24.1</core_client_version>
<![CDATA[
<message>
The data is invalid.
 (0xd) - exit code 13 (0xd)</message>
<stderr_txt>
<search_application> milkyway_nbody 1.86 Windows x86_64 double  OpenMP, Crlibm </search_application>
Using OpenMP 8 max threads on a system with 8 processors
Running MilkyWay@home Nbody v1.76
Error evaluating NBodyCtx: [string "-- /* Copyright (c) 2016 - 2018 Siddhartha ..."]:117: bad argument #0 to 'calculateEps2' (Expected 3 or 6 arguments) 
Failed to read input parameters file
strftime() failed called boinc_finish(13)

</stderr_txt>
]]>

---

It looks as if orbit-fitting tasks in the new data feed (04_03_2024 in the task name) also have the problem that the previous feed (03_29_2024) had. (And like the previous data-set, the task names don't have "orbit_fitting" in them this time, which might hint at what the previous problem was!)

I still have some retries for earlier dates and those are viable.

Cheers - Al.

How can I prevent getting the bad WUs ?

Something I can add in the app_config?

Just disable the Orbit-fitting app in your Project preferences here on the website. Just do the regular N-body app.

https://milkyway.cs.rpi.edu/milkyway/prefs.php?subset=project

---

Thanks!

It looks as if orbit-fitting tasks in the new data feed (04_03_2024 in the task name) also have the problem that the previous feed (03_29_2024) had. (And like the previous data-set, the task names don't have "orbit_fitting" in them this time, which might hint at what the previous problem was!)

I still have some retries for earlier dates and those are viable.

Cheers - Al.

Since you looked over the data set naming did you notice the data sets have a 4 day cycle (excluding weekends)?

Einstein longs are about 3 days. Switched to them and will check back Wednesday.

Off topic, is my Marmot avatar showing?

It looks as if orbit-fitting tasks in the new data feed (04_03_2024 in the task name) also have the problem that the previous feed (03_29_2024) had. (And like the previous data-set, the task names don't have "orbit_fitting" in them this time, which might hint at what the previous problem was!)

I still have some retries for earlier dates and those are viable.

Cheers - Al.

Since you looked over the data set naming did you notice the data sets have a 4 day cycle (excluding weekends)?

Einstein longs are about 3 days. Switched to them and will check back Wednesday.

Off topic, is my Marmot avatar showing?

No it isn't

Conan

---

same here

<core_client_version>7.24.1</core_client_version>
<![CDATA[
<message>
The data is invalid.
 (0xd) - exit code 13 (0xd)</message>
<stderr_txt>
<search_application> milkyway_nbody 1.86 Windows x86_64 double  OpenMP, Crlibm </search_application>
Using OpenMP 8 max threads on a system with 8 processors
Running MilkyWay@home Nbody v1.76
Error evaluating NBodyCtx: [string "-- /* Copyright (c) 2016 - 2018 Siddhartha ..."]:117: bad argument #0 to 'calculateEps2' (Expected 3 or 6 arguments) 
Failed to read input parameters file
strftime() failed called boinc_finish(13)

</stderr_txt>
]]>

it's interesting one of my tasks from this project was validated successfully https://milkyway.cs.rpi.edu/milkyway/result.php?resultid=943313023

---

rilian wrote:

it's interesting one of my tasks from this project was validated successfully https://milkyway.cs.rpi.edu/milkyway/result.php?resultid=943313023

This task is from a previous batch of workunits (de_nbody_orbit_fitting_03_21_2024_v186_*) from before the introduction of this bug.

By the date in the task name, that one was from an earlier run with good formatting. There are a few straggler resends from earlier that still process fine with the Orbit Fitting app.

But 90% of the Orbit Fitting tasks from the past two days are bad. If you choose to still run them, then your production is likely to take the same 90% hit from all the bad tasks relative to the few good tasks.

The _04_03_2024 named series are the bad ones. Eventually the _04_03_2024 series will error process out after four failure counts.

[Edit 1]
I'm re-enabling them now to see if the bad ones are still coming through or see if the they have error counted out

[Edit 2]
Evidently still coming through so toggling them off again.

---

alanb wrote:

It looks as if orbit-fitting tasks in the new data feed (04_03_2024 in the task name) also have the problem that the previous feed (03_29_2024) had. (And like the previous data-set, the task names don't have "orbit_fitting" in them this time, which might hint at what the previous problem was!)

I still have some retries for earlier dates and those are viable.

Yes, Orbit Fitting batches from before the problematic ones are not yet completed. My own results list contains ~2,000 results from good Orbit Fitting batches, from tasks which I received during the past 5 days including today. (That's alongside ~10,000 error results from tasks from the bad Orbit Fitting batch(es).)

Keith Myers wrote:

But 90% of the Orbit Fitting tasks from the past two days are bad. If you choose to still run them, then your production is likely to take the same 90% hit from all the bad tasks relative to the few good tasks.

The _04_03_2024 named series are the bad ones. Eventually the _04_03_2024 series will error process out after four failure counts.

[Edit 1]
I'm re-enabling them now to see if the bad ones are still coming through or see if the they have error counted out

[Edit 2]
Evidently still coming through so toggling them off again.

I for one keep running them, and take measures to avoid a hit to my production. :-) Would of course be better if administration would retract the bad batch(es), carefully.

Well you are doing your part in retiring the "bad" tasks as fast as possible then. Thanks.

---

Sorry for the bad tasks. I have notified the person in charge of these tasks and they should fix this issue soon.

Well you are doing your part in retiring the "bad" tasks as fast as possible then. Thanks.

I added MW to a spare client. Just to get them get them an abort. Some do appear OK still.

I think someone accidentally sent normal batch to orbit-fitting queue

Still getting plenty of the bad tasks from 04_03. The only ones that run have orbit_fitting in the name

Good: de_nbody_orbit_fitting_03_21_2024_v186_OCS__data__6_1709197135_1941068_1
Bad: de_nbody_04_03_2024_v186_OCS__data__5_1709197135_2333913_3

I think someone accidentally sent normal batch to orbit-fitting queue

+1

---

Well you are doing your part in retiring the "bad" tasks as fast as possible then. Thanks.

I realized that pushing thru till they get 4 errors, then retired, was probably best and kept running.

The nasty thing about this is the BOINC client stalls after so many bad WU's, I need to do a manual update to Milkyway@home then BOINC client wants to d/l the master file table before reporting the finished WU's and getting a new batch.