Beta 962 - Zero Annual Rainfall

[WestOz]

Hi Steve

Just upgraded from Beta 956 to Beta 962. Everything appears to be working as normal except the Rainfall figures are now all Zeros. I've attached two Diag files, one for 956 and one for 962.

I've reloaded 956 and it's all working again.

Regards

Ian

[werribee_au]

You're correct WestOz.

I looked at View|this year/this period and found that this year only used the jan10 data, and when trying this period it only used the start date month for the data (from what I can work out)

Steve, if you want to log into my station notebook with teamviewer to have a look you're more than welcome, just PM me so we can set it up if you wish.

[steve]

It thinks you have a problem in your dayfile.txt. Note the error message in the diags file:

8/11/2010 11:38:15.228 : Error in dayfile.txt around line 77: ''4/'' is not a valid integer value

If the problem isn't obvious, please attach your dayfile.txt

[WestOz]

8/11/2010 11:38:15.228 : Error in dayfile.txt around line 77: ''4/'' is not a valid integer value

Got it! Thanks once again Steve. It was an incorrect format of the date, should have read "04/02/2009" but actually read "4/02/2009" ie. a missing zero

Strange that it shouldn't have caused a problem in previous versions of C1.

Regards

Ian

[steve]

It was an incorrect format of the date, should have read "04/02/2009" but actually read "4/02/2009"

That doesn't sound good. Cumulus writes the dates in dayfile.txt in the format "dd<separator>mm<separator>yy", i.e. with a 2-digit year, and that's how it expects to find them when it reads them back. If you have 4-digit years in there, it's going to cause problems, e.g. in the 'This Year' etc displays.

[WestOz]

It could well have been me that stuffed it up at some time by editing the file because there wasn't a 05/02/2009 entry either. It all seems to be OK now.

[werribee_au]

My problem is slightly different,

'View|This Month' looks like it is displaying data from the first line of the selected monthly log file but only for monthly log files prior to this month. November 2010 is fine.

'View|This Year' looks like it is displaying data from the first line of the Jan10log.txt file.

On a side note, Toolbox will not open any monthly log file prior to and including Jan10log.txt file.

It was on the 9th Oct that I changed from 1.9.0 to 1.9.1 and have the current build installed. (Also have backups prior to each install)

Attached is the latest diag file, there is no elf file.

I could post a monthly log file if needed.

I could start up one of the backups and see what happens.

[steve]

9/11/2010 05:43:11.296 : Error reading Dayfile around line 389: '' is not a valid floating point value
9/11/2010 05:54:46.562 : Error reading Dayfile around line 114: '' is not a valid floating point value
9/11/2010 06:07:39.687 : Error reading Dayfile around line 1: '' is not a valid floating point value

I'm not sure if people realise it, but these diags files are just plain text files; you can open them in a text editor and look for the error messages.

[werribee_au]

9/11/2010 05:43:11.296 : Error reading Dayfile around line 389: '' is not a valid floating point value
9/11/2010 05:54:46.562 : Error reading Dayfile around line 114: '' is not a valid floating point value
9/11/2010 06:07:39.687 : Error reading Dayfile around line 1: '' is not a valid floating point value

I'm not sure if people realise it, but these diags files are just plain text files; you can open them in a text editor and look for the error messages.

I guess I didn't look far enough

Ah! found the problem. Sunday I used the latest toolbox to edit the dayfile.txt (The first time I have used the toolbox editor), but when I saved the changes, toolbox padded out the missing fields prior to nov10 with commas.

I couldn't see these with toolbox editor, but with notebook++ it hit me in the face.

Could you look at this David?

Now I have removed them it appears fine.

Thanks Steve for pointing me in the right direction

Back to notebook++ for now.

[steve]

Ah! found the problem Sunday I used the latest toolbox to edit the dayfile.txt (The first time I have used the toolbox editor), but when I saved the changes, toolbox padded out the missing fields prior to nov10 with commas.

Ah - I've seen this in other's files, and I'd assumed it was Excel doing it...

[Synewave]

Steve,

Just for my info, could it have been Toolbox that may have caused a similiar problem with the extra commas for me (and a few others)?

Not pointing the finger at anything, just curious.

[Hillbilly]

Hi,

Can anyone confirm why the commas padding out the end of each line are a problem? I have exactly the same issue as werribee. Viewing month or year summaries through Cumulus takes the first line of the period in question and shows that.

Diag file shows that there is 'Error reading Dayfile around line xxx: '' is not a valid floating point value'

In each case, the line in the dayfile corresponds to the first of each month I try and view.

I am running v1.9.1 build 962 and used Toolbox Build 46 to edit the dayfile after I upgraded to Cumulus 962, to include highs and lows from earlier in the year. If I go into dayfile and delete all the commas at the ends of lines, how can I keep those values?

Diag file and dayfile attached.

[mcrossley]

Helen, it's because the beta versions of 1.9.1 have added extra values to the file. Lines that are padded with empty comma values cause a problem because Cumulus sees that the 'extra' values should be there (due to the commas) but when it tries the read the values they will be null.

If the commas aren't there, Cumulus will not try and read the 'extra' values at all.

[steve]

The extra commas are (were) a problem because they parse as null values. You can delete commas at the ends of lines without losing real values, I don't really understand why you think you would lose data by deleting them? But in any case, I put a change into one of the builds to work around them (I can't remember which one). It's possible that I haven't changed everywhere that needs changing, though...

[Hillbilly]

Hi thanks for the prompt replies. I hadn't realised that Cumulus doesn't parse null values.

You can delete commas at the ends of lines without losing real values, I don't really understand why you think you would lose data by deleting them?

When I upgraded Cumulus, I wanted to edit the high and low apparent temperature values in dayfile so that the overall high and low for the year would be closer to accurate. I took heat index on the hottest day of the year and wind chill on the coldest day of the year as proxies and added these to the dayfile in Toolbox on the relevant date in the new apparent temp fields.

So the dayfile now contains mainly commas for the new fields but on those record days, I have a series of commas, then a temperature value, then a time then a comma or two. If I delete all the commas I will lose these values. I intended to have them there to load into my sql database.

OK, so I'll either delete them or all or upgrade to the latest version.