WXSIM 11.0.1 and WXSIMATE 3.0.1

Hi Everybody,

New versions posted at www.wxsim.com, with teeny little bug fixes:

(1) in the comparison/retieval module, an occasional bad scaling of the relative humidity plots has been fixed.

(2) in WXSIMATE, that first-of-the-month bug has been fixed

(3) I took an aopstrophe off the default file name 'latest, making it just latest, on the save forecast form in WXSIM.

That’s it! :slight_smile:

Tom

Tom just downloaded and installed this update. I now get an input past eof at line 1909 when I try to start wret.exe!

Stuart

Stuart,

Thanks for letting me know. Actually, I somewhat doubt this error is new to this version, because the change was really trivial and would only be encountered when using the comparison routine.

Nevertheless, something obviously happened! :frowning:

Has anyone else seen this happen with this version (or the last)?

Thanks again,

Tom

Tom,

I just downloaded the latest versions and wret.exe works just fine for me. - Jim

As I just pointed out to Tom in an email this happens on wret starting up, so it is strange. I cannot do anyting with wret as the window never opens. I’ll try a re-download and re-install just in case the archive got corrupted.

Stuart

Just to confirm that a re-install did not fix it. Still fails on startup.

Stuart

Stuart,
Try reinstalling the NET Framework again, I had other applications using it and for some reason they wouldn’t start, reinstalling it fixed them again. Just a thought.
Peter

I just went back to 11.0.0 and lo and behold wret starts no problem so I guess NET framework is OK. For me it is definitly a problem with the 11.0.1 upgrade.

Stuart

Hi Stuart,

That is strange. I’m glad at least you still had the eariler version! You’re not missing much not having 11.0.1 instead of 11.0. The only thing I changed (intentionally anway!) was an issue with the scale of the relative humidity plots when you do the compare. I wonder if some really obscure thing happened when I was compiling the program. Hardly anything’s different in the code.

Oh - one more thing to try. Now that you got 11.0 working, how about trying to install the upgrade (wxsimupg.exe) over it, and try again? That’s just in case it was some error in a file, and maybe it got replaced now and it’ll be OK.

I don’t know, but it may be worth a shot.

At some point I’ll have an update (probably called 11.1), but maybe not as quickly as before. I start back teaching school next week (well, pre-planning next week and then the kids come back the week after that), so this frantic pace of upgrading will have to cool off a bit. I plan to work more gradually and fill orders, and fix bugs as time permits. It’s been a busy (but good) summer!

Tom

Tom I have just done as you suggested and installed 11.0.1 again over 11.0.0 and it works now. Who knows what happened, its really strange but true.

Stuart

Actually I spoke to soon. If I select any of my manually saved forecast .wxf files they work fine. However if I try and select any of the archived .wxf files saved with names like f06080408.wxf the I get the popup box showing Error occured at line 1909: Subscript out of range. So there is something funny going on here.

I’ll email you the file so you can take a look.

Stuart

Tom I am having the same problem.
so it must be a bug. Thanks
Chuck

I’ve been able to reproduce Stuart’s error now, but only by using a .wxf file he sent me. There’s actually a section missing from it! This is probably the fault of wxsim.exe, not wret.exe. When I use the latest version of wxsim.exe, it creates .wxf files which start with

“v100”
297.014661666149
305.668823421287
999
305.668823421287
293.470399287789
307.657714598223
293.470399287789
307.657714598223
294.582102109701
308.839875747
294.582102109701
308.839875747
297.157109978386
300.069939601356
297.157109978386
0
“*”
“(No comments yet)”
“Atlanta”,33.65,84.42,1033,2006

Stuart’s .wxf file starts with:

“v100”
“Broadstairs”,51.36,-1.44,130,2006

All those 300’ish numbers (which are various kinds of daily min and max temperatures, in Kelvin degrees, by the way) are missing. In going from version 11.0 to 11.0.1, the only changes I made in wxsim.exe were to remove an apostrophe in front of the word latest in the default text of a text box, and to change the version name. It’s very unlikely that those things could have caused this kind of problem. I can think of two possible scenarios:

(1) Something strange happened during compiling that allows a problem to happen, but only on some computers.

(2) Something is different about the conditions of the forecast (i.e. the date, the number of days being forecast, the starting time, etc.).

My problem is that I can’t seem to get these bad .wxf files to occur on this end. If it’s #1, then maybe recompiling would work, but I’d like to check #2. Stuart, I know you have access to the prior version (maybe others do, too?). Can you try running exactly the same forecast in 11.0 and 11.0.1 and see if that section is missing from the .wxf file in one and not the other?

Thanks for your help! :slight_smile:

Tom

I originally wrote this as an email to Stuart, but it would be helpful to have more “hounds on the trail”! :slight_smile:

Hi Stuart,

I’ve narrowed things down a bit more. I normally wouldn’t bore you with technical details, but here it might help us figure this out, so here goes:

wxsim.exe writes the .wxf file “as it goes”, meaning every time it loops through the calculation process, it adds the latest data to latest.wxf. It then closes the file when it’s done with the forecast.

However, a few versions ago, I decided I needed raw values of the various max and min temperatures in the .wxf file. The problem is that these can’t be known until ech day is over, so the program can’t write them until it’s done with the forecast. To get around this problem, I had it rewrite the .wxf file, by reading it to a temporary file called wxf.tmp. It then writes to a new .wxf file by writing the designator “v100” (which was there before, anyway), followed by all that max/min temperature data, then an asterisk, and then it reads back your site name and all that other data from the tmp file. Finally, it rewrites the wxf.tmp file as “empty”.

It looks like your file is not getting “translated” into the newer form. The instruction to do this is triggered by many different ways of closing the output form, such as hitting Repeat, Fresh, or Quit. In auto mode, Repeat is hit by the program itself, but only when it reverts to the main screen again. It’s possible you have checked it to leave that screen up for display until time for the next run. At that point the new version of the .wxf file has not been written.

I’m wondering if some action of yours, or some bug in the program, is allowing the .wxf file to remain in its untranslated state. Maybe some way of closing the program, or of booting up wret.exe, which I haven’t thought of, is doing this. What I’m really puzzled about is why there would be any difference between 11.0 and 11.0.1.

Some things to check:

(1) When did wxf.tmp get updated, and what are its contents? If it didn’t update when the forecast was finished, that’s a clue.

(2) What if you just run it manually, hit repeat, and then File/Retrieve? Does it work then?

Thanks!

Tom

Tom from a quick look at the files now, wx.tmp has one line in it saying “empty” (including the quotes) and was last updated at 08:08 today the time I made the forecast. The latest.wxf file does indeed contain the numbers you expect where you expect them. The only thing which does not contain them is the file I sent you which is the one created automatically by wxsim when I click on the archive box, so maybe you copy the archive at the wrong point before these numbers are added to the latest.wxf file!

Stuart

Hi Stuart,

Can you retrieve the latest.wxf file? Thanks for your suggestion about when the file is getting copied. I’ll check on that.

What i’m still puzzled about is why there would be any change from 11.0 to 11.0.1. Have you tried exactly the same sequence of actions with each program, and gotten different results? My problem is that I can’t seem to make the error happen here, but I’ll try some more things and post again in a little bit.

Thanks,

Tom

I think I found it!

I have the translation occuring, as it should, before archiving for the Save, Repeat, and Fresh buttons, but seem to have them switched on the Quit button. Is that what you’ve been using? I had been going right back to the Entry form every time to retrieve, but perhaps you’ve been quitting the program then reopening to retrieve (?).

That should be a legitimate, allowable sequence of actions, but I simply hadn’t done it that way. I’ll be fixing that soon.

Meanwhile, I still can’t see how it would have changed from 11.0 to 11.0.1. That particular problem at least (and I hope that’s all it was) should have existed in 11.0 as well. Regardless, it was a bug that needed fixing, and I thank you.

Tom

Yes I do use the quit button at the end of a forecast. I usually go and do a retrieve later in the day so just start WXSim and do a Retrieve. To be honest I had not tried the Retrieve on an archive file in 11.0.0 as up to that point I had been manually saving the files (which works and includes this data). Dont forget initially that I had been unable to start wret at all which is why I went back to 11.0.0.

Stuart

Tom & Stuart,

I think I may have stumbled onto the reason for the “Error Occured at line 1909” issue that started this thread. If WxSim fails to complete it’s run, you’ll be left with a 0 byte latest.wxf and that will cause wret.exe to generate the error.

This happens to me on occasion when WxSimate is denied access to the WD logfiles. It generates an error message, halts and leaves localcal.txt open. WxSim then generates an error message when it tries to access localcal.txt and halts until I intervene. If I select “quit”, I’m left with the 0 byte latest.wxf.

When I noticed the zero byte file following one of these sessions, I ran through a complete new forecast. After that, wret.exe worked. I then created a 0 byte latest.wxf with wordpad and was able to duplicate the error.

I hope this helps with that part of the mystery. - Jim

Jim,

I think you’re probably right about what may have caused the earlier error Stuart saw, and I’m now nearly certain that using the Quit button is what caused the problems later, and that it wasn’t a change from 11.0 to 11.0.1, but rather the new sequence of actions.

I’ve already made the necessary change in the code, but still need to recompile, package the new version (11.0.2) into the installers, and upload them. I might get that done as soon as today.

By the way, what specifics have you learned about the problem you mention, with access denied while WD is writing to its files. Is there a particular time when that happens? Something that could be “worked around” either in WXSIM’s code or in instructions for its use?

Thanks!

Tom