A user alerted me to an apparent bug in the comparison (between forecast and actual) routine, done by wret (perhaps via autolearn), in the case of Cumulus MX, using the new, numerical month names. The routine works in general, BUT when the forecast crosses the end of the month, the station data is reverting back to the first of the first month, instead of moving on to the second month. For example, a forecast starting, say, November 29 properly compares the forecast to the correct actual data, UNTIL it gets to December 1. It then compares back to November 1, instead of December 1. I haven’t identified the cause yet, but I tested it on Weather Display log files and they did NOT show this error. It may be specific to Cumulus, and likely to the latest numerical month names in Cumulus. I plan to get this fixed in the next few days, but need to warn that the learned bias correction factors would be degraded substantially by this bug. I hope to post again with a fix within a few days. Meanwhile, maybe don’t use the learned bias corrections if you are using Cumulus MX with the recent change in log file names. Actually, if you are using that, confirmation that you are seeing this error (or that you’re not) would be appreciated.
Hi,
I download data from Meteobridge in cumulusMX format creating the file in the new numeric name of the month but I have not noticed any error or anomaly. Probably I did not understand what to look for exactly to confirm or not the error in question…
I remain available for further tests, if necessary
Regards
I think I have a fix already! I haven’t uploaded the entire package, but here’s the wret.exe executable. This also seems to fix a logged precipitation inconsistency problem you might have seen.
As best I can tell, neither WXSIM-Lite not WXSIMATE had the problem. It seems to have been particular to wret.exe.
Download this executable and use it to replace the one you have. It should refer to “Build 1.1” at the top of the main form. Let me know how it goes!
I’m pretty sure at this point it was Cumulus only, and then only if you have the recent update to that which names the log files with numbers instead of three-letter month names. I found an oversight in my code (and have corrected it, I’m pretty sure, with the latest posting of that file at www.wxsim.com/wret.exe).
Hi Tom,
I have never stopped running Autolearn since we started the original testing way back when, and still ruuning it since the cumulusMX numeric log date upgrade when it first came out.
Like Norbert mentioned earlier, I am unsure of what to look for to confirm I have this error.
I have not noticed any issues, but anyway I installed your first fix wret 1.1 on the 12th Dec and it caused my entire wsxim suite to be quarantined by my security software (never ever had that before). So reverted to wret 1.0 and un-quarantined wxsim suite. All ran fine again.
Then on the yesterday I installed your latest version wret 1.1 and had no security issues, however overnight at 01:00 when I always run Autolearn it failed to complete (complaing it could not find the yyyymmlog.txt files.
Wret version 1.0 was already finding and processing them, so I had to revert back to wret 1.0 again and now it runs fine, well aside from the un-known possible error as mentioned earlier (I am still unsure where to look for that)?
It’s becoming more common for security software to block based on “I’ve not seen many people run that program so it must be evil”. I’d be much happier if they asked “Do you trust this program?”
The way to see this is to compare actuals on Wret using a forecast file that transitions into the next month (say, one run on November 30th that goes into December). What I saw was that as soon as December hit, the actual temps were wrong. As it turns out, they were from the beginning of November.
I have tried it - for individual comparisons it works (single forecast and data). Then I also ran into the error seen here. I did email Tom. Meanwhile I rolled back to the previous Wret version. Problem is its not clear if this issue affects correction factors with the older Wret.
Well, sometimes you fix one thing and it messes something else up! Fortunately, the changes were minor and I should be able to figure out what got messed up. It did fix the immediate problem I was addressing, but now I see that had unforeseen consequences.
As for anti-virus/security programs flagging or quarantining WXSIM executables (or even the whole suite), I had that happen to me with Malwarebytes. I managed to override it (I forget how now). Please let me, and everybody, know if and how you manage to correct that. It’s really annoying. Norton, and I think sometimes Windows’ built in system occasionally have done this. They just don’t know “who” these programs are.
Reminds me of the first time I went over to my new girlfriend’s house when I was 20, and her mom answered the door and said, “And WHO are YOU!??”. She’s happily been my mother-in-law now for 42 years. Hopefully these security programs can be coaxed into a similar relation with my programs.
Trying again, and I’m pretty sure I fixed the problem I accidentally created, and kept the other fix in place. The program looks the same, but is dated December 16 instead of December 11. Let me know how this goes! www.wxsim.com/wret.exe).
Hi Tom,
Greatly appreciated, I confirm this latest wret fixes the issues.
Thank you so much, greatly appreciated.
With ref to the security/anti-virus issue quarantining wxsim suite (as well as many *.bat files it uses.
It was only that very first wret v1.1 that caused it for some reason.
I use Bitdefender and it allows me to un-quaranteen every single file I want to.
Not played up since.
Kindest Regards,
Tony
Hopefully these security programs can be coaxed into a similar relation with my programs.