SH/MUF retuirns very questionable results (1.0.9)

[n9jr]

SH/MUF now predicts forward in time at the expected 1 hour intervals, but the returned data set is extremely questionable. At 1200 UTC I would not expect a viable 160m path exists between Wisconsin and England. Or on 80m either which was reported with a better potential signal strength.

Closer, it now reports predictions in the future but they are not correct. There is something in the VOCAP engine between DXSpider and pyCluster.

[AI3I]

Partially addressed in 490a7cb by suppressing clearly questionable low-band daytime MUF signal estimates, with test coverage around midpoint daylight behavior. Leaving this open because the remaining concern is model-quality parity with expected propagation/VOCAP behavior and should be validated against known paths before closing.

[n9jr]

Still no joy in 1.0.9 it predicted a path from Wisconsin to England at 2200 UTC with S1 on 160m. And that is 3 hours before my sunset. If only it were true.

I dod a side beside from the predictions on DXSpider and pyCluster. They generally followed the same trends but pyCluster was 3 bands low from the DXSpider VoCAP model

[AI3I]

Follow-up in 0541ef4: MUF path signal estimates now consider daylight at the path endpoints as well as the midpoint before showing low-band signal reports. This specifically suppresses 160m/80m optimism when one end of the path is still in daylight. Leaving this open for operator validation against known DXSpider/VOCAP paths because the remaining concern is model parity, not just the obvious daylight false-positive.

[n9jr]

Still issues. I looked at the sh/muf results from pyCluster, DXSpider and VOACAP online. While VOACAP online doesn't plot 160m there was generally good agreement between VOACAP and DXSpider. Less agreement with pyCluster. Assuming the modeling between DXSpider and pyCluster is close pyCluster indicated the MUF was about 7MHz below what DXSpider reported. I just checked sh/muf G and at 2300 UTC it estimated the MUF at 12.4 MHz and DXSpider estimated it at 23.1 MHz.

And starting at 0000 UTC pyCluster estimated the MUF to be 0 MHz with no path between W9 and G.

[AI3I]

Updated the 1.0.9 worktree to remove the split between telnet MUF and public web solar values. Added a shared propagation module for solar snapshots and MUF3000/signal calculations; telnet show/muf now calls the shared estimator, and /api/solar now prefers recent stored WWV SFI/A/K data while retaining HamQSL enrichment for band/VHF extras. The public propagation page now displays the first-party MUF3000 value and a source badge (WWV or WWV + HamQSL). Leaving this issue open pending live comparison against DXSpider/KC2G/expected path outputs, but the data/calculation paths are now consolidated for pyCluster surfaces. Verified with: pytest tests/test_public_web.py tests/test_telnet_commands.py -q (204 passed, 16 skipped).

[n9jr]

I've made a comparison of VOACAP online, DXSpider and pyCluster. I used a short path from Wisconsin to England, a path I know well. It seems that pyCluster is more generous on the lower frequencies than VOACAP and starting at 0000 UTC the MUF is 0 and there is no path. See attached file.

MUF Comparison.rtf

[AI3I]

Current status: still open as deeper model-parity work. pyCluster now shares MUF/solar calculations across telnet and web, but Joe's VOACAP/DXSpider comparison still indicates path-quality differences, especially low-band optimism and 0000 UTC zero-MUF behavior. This needs a targeted comparison harness or algorithm review, not just live validation.

[AI3I]

Implemented in the 1.0.9 worktree: show/muf path reports now use a MINIMUF 3.5-style path MUF calculation for the hourly target path instead of the previous lightweight SFI/daylight heuristic. The displayed R value now uses the MINIMUF SFI-to-sunspot curve, and the path signal labels use the computed path MUF. Added regression coverage for the Wisconsin-to-England UTC-midnight case so the path no longer collapses to 0 MHz after 0000Z. Validation: full suite passes (pytest: 531 passed).