Wanted to report that I am seeing a similar pattern of Invalid SCC results when verification is done with an earlier MacOS version.
My host
- Darwin 22.4.0
- Mac Mini
- i7-8700B

When I am paired with an older OS, which seems to be most of the time, the initial verification fails and a third task is issued. This is typically also an older OS, they validate, and I get marked Invalid.

https://www.worldcommunitygrid.org/contribution/workunit/314105617

Yet another one invalid only due to OS issues. I wish the SCC team read the boards and noticed this issue.

1. I can't upgrade the OS on this old machine.
2. I'd get more invalids if I upgraded as 22.5.0 only matches to 22.5.0 while all the other MacOSes match just fine.

It is a bit frustrating knowing we are screaming in the wind. Krembil won't acknowledge the issue. SCC won't know what we do about the system. Is the data valid anymore?? If the output from the different OSes is so different to get one set marked invalid, then what does this do to the whole data set? Will they get a wrong conclusion? Will they have to run the whole data set over??

Unixchick, TaurusOldBull;

Frustration understood (see my P.S.) -- perhaps the following might reassure you a little (even though it doesn't make this problem go away...)

Any application (such as SCC1 or OPN1/G) that uses adaptive replication has to be looking for results that are "good enough", not the perfect match that is necessary for, say, ARP1. Validation is then useful for spotting systems that produce wildly different results, on the assumption that big differences are down to hardware/run-time issues on the individual system(s), given that applications for all platforms should have been through the Beta test system and tasks are supposed to go to broadly similar systems (32-bit vs. 64-bit; choice of O/S)...

The real problem then is choosing a validation threshold that catches real problems but passes minor variations. The validation method might not allow a great deal of flexibility there :-(

We'd need the SCC scientists to confirm this, but I suspect that the only real issue would be if they were getting excessive false positives or false negatives, rather than some fairly minor variance in how well a ligand docks (or how badly it fails...)

With the above in mind, I suspect this specific issue isn't likely to be a show-stopper, unlike those accursed MyoD1-C batches. We know they are working on that, although I wouldn't expect any real news on that until they reckon they've resolved it [more or less] completely :-)

Cheers - Al.

P.S. Over at Einstein@home, something like 7 or 8% of my GPU tasks for one project are declared invalid because the initial wingman and the verification wingman both happened to be on Windows where the applications are built with different libraries for one reason or another; as it doesn't happen all the time the tech folks regard it [rightly, in my view] as lower priority than all the other stuff they have to do to keep the project(s) running. It isn't all one-sided, though; another 3% or so cause a Windows wingman to be declared invalid because the verification wingman uses Linux :-)

[Edit: to make the P.S. more clear]