<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: ccc-gistemp release 0.4.0</title>
	<atom:link href="http://clearclimatecode.org/ccc-gistemp-release-0-4-0/feed/" rel="self" type="application/rss+xml" />
	<link>http://clearclimatecode.org/ccc-gistemp-release-0-4-0/</link>
	<description></description>
	<lastBuildDate>Sat, 04 Sep 2010 02:39:50 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Global Warming Contrarians Part 1.1: Amateur Temperature Records &#171; Planet James</title>
		<link>http://clearclimatecode.org/ccc-gistemp-release-0-4-0/comment-page-1/#comment-2691</link>
		<dc:creator>Global Warming Contrarians Part 1.1: Amateur Temperature Records &#171; Planet James</dc:creator>
		<pubDate>Fri, 09 Jul 2010 09:07:23 +0000</pubDate>
		<guid isPermaLink="false">http://clearclimatecode.org/?p=224#comment-2691</guid>
		<description>[...] (generally independent of each other) including Zeke Hausfather of The Blackboard, Nick Barnes of Clear Climate Code (a project to replicate GISS results using clearer processing code), Tamino of Open Mind, Joseph of [...]</description>
		<content:encoded><![CDATA[<p>[...] (generally independent of each other) including Zeke Hausfather of The Blackboard, Nick Barnes of Clear Climate Code (a project to replicate GISS results using clearer processing code), Tamino of Open Mind, Joseph of [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kicker</title>
		<link>http://clearclimatecode.org/ccc-gistemp-release-0-4-0/comment-page-1/#comment-715</link>
		<dc:creator>Kicker</dc:creator>
		<pubDate>Fri, 26 Mar 2010 19:43:27 +0000</pubDate>
		<guid isPermaLink="false">http://clearclimatecode.org/?p=224#comment-715</guid>
		<description>clearclimatecode.org - da mejor. Guardar va!
 Gracias

Kicker</description>
		<content:encoded><![CDATA[<p>clearclimatecode.org &#8211; da mejor. Guardar va!<br />
 Gracias</p>
<p>Kicker</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nick.Barnes</title>
		<link>http://clearclimatecode.org/ccc-gistemp-release-0-4-0/comment-page-1/#comment-424</link>
		<dc:creator>Nick.Barnes</dc:creator>
		<pubDate>Mon, 15 Mar 2010 19:06:35 +0000</pubDate>
		<guid isPermaLink="false">http://clearclimatecode.org/?p=224#comment-424</guid>
		<description>I don&#039;t recall why GISTEMP uses the &#039;X&#039; values.  I recommend that you do try running with &#039;raw&#039;, &#039;tob&#039;, and &#039;F52&#039; datasets, and use the tool/compare_results.py script to compare the results.
If I have time later in the week, I might do this myself, and make a blog post here to show the results.</description>
		<content:encoded><![CDATA[<p>I don&#8217;t recall why GISTEMP uses the &#8216;X&#8217; values.  I recommend that you do try running with &#8216;raw&#8217;, &#8216;tob&#8217;, and &#8216;F52&#8242; datasets, and use the tool/compare_results.py script to compare the results.<br />
If I have time later in the week, I might do this myself, and make a blog post here to show the results.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: carrot eater</title>
		<link>http://clearclimatecode.org/ccc-gistemp-release-0-4-0/comment-page-1/#comment-423</link>
		<dc:creator>carrot eater</dc:creator>
		<pubDate>Mon, 15 Mar 2010 17:49:57 +0000</pubDate>
		<guid isPermaLink="false">http://clearclimatecode.org/?p=224#comment-423</guid>
		<description>drj

You&#039;re right; the raw does have the &#039;Q&#039; flag in it, and flagged values should be excluded there as well.    I&#039;ll try it out sometime.     Thank you for the reply.


Any idea why the &#039;X&#039; flag isn&#039;t excluded from GISTEMP, as well?      On my reading of the readme file, the values in F52 with the flags E, Q and X are all in-filled using FILNET; just for different reasons. 

If GISS does not want to use infilled values, I don&#039;t understand why it doesn&#039;t exclude all of them.</description>
		<content:encoded><![CDATA[<p>drj</p>
<p>You&#8217;re right; the raw does have the &#8216;Q&#8217; flag in it, and flagged values should be excluded there as well.    I&#8217;ll try it out sometime.     Thank you for the reply.</p>
<p>Any idea why the &#8216;X&#8217; flag isn&#8217;t excluded from GISTEMP, as well?      On my reading of the readme file, the values in F52 with the flags E, Q and X are all in-filled using FILNET; just for different reasons. </p>
<p>If GISS does not want to use infilled values, I don&#8217;t understand why it doesn&#8217;t exclude all of them.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: drj</title>
		<link>http://clearclimatecode.org/ccc-gistemp-release-0-4-0/comment-page-1/#comment-422</link>
		<dc:creator>drj</dc:creator>
		<pubDate>Mon, 15 Mar 2010 17:33:12 +0000</pubDate>
		<guid isPermaLink="false">http://clearclimatecode.org/?p=224#comment-422</guid>
		<description>@carrot eater: I just reviewed the USHCN v2 readme.txt file, the code, and had a quick look at a the latest raw USHCN v2 file.  I see no reason why it wouldn&#039;t work, and I don&#039;t think you&#039;d need to edit the code.

The raw and F52 data files are in the same format.  The raw file still has flags in the same column positions, and it would still seem sensible to ignore E and Q values (although the raw file only seems to use the Q flag).

You can download whatever USHCNv2 file you want and unpack to input/ushcnv2 and ccc-gistemp will use that without downloading a new one.</description>
		<content:encoded><![CDATA[<p>@carrot eater: I just reviewed the USHCN v2 readme.txt file, the code, and had a quick look at a the latest raw USHCN v2 file.  I see no reason why it wouldn&#8217;t work, and I don&#8217;t think you&#8217;d need to edit the code.</p>
<p>The raw and F52 data files are in the same format.  The raw file still has flags in the same column positions, and it would still seem sensible to ignore E and Q values (although the raw file only seems to use the Q flag).</p>
<p>You can download whatever USHCNv2 file you want and unpack to input/ushcnv2 and ccc-gistemp will use that without downloading a new one.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: carrot eater</title>
		<link>http://clearclimatecode.org/ccc-gistemp-release-0-4-0/comment-page-1/#comment-421</link>
		<dc:creator>carrot eater</dc:creator>
		<pubDate>Mon, 15 Mar 2010 16:19:59 +0000</pubDate>
		<guid isPermaLink="false">http://clearclimatecode.org/?p=224#comment-421</guid>
		<description>I&#039;m getting quite very tempted to try our your product, now.

Any gut idea on whether it will have trouble running properly if I read in USHCN data from the raw or TOB file, instead of the fully adjusted F52.avg.gz file?    

Because step 0 reads in and acts on the flags in the F52.avg file, marked as &#039;E&#039;, &#039;X&#039; or &#039;Q&#039;, I&#039;d have to edit out these lines in step 0:

            flag = line[m*7+17]
            if ((flag in &#039;EQ&#039;) or    

Is there anything else that could go wrong?    I doubt it would make much of any difference to the global numbers, but the differences between the USHCN raw, TOB and final adjustment are not negligible, so being able to choose the input file would be a fun capability.</description>
		<content:encoded><![CDATA[<p>I&#8217;m getting quite very tempted to try our your product, now.</p>
<p>Any gut idea on whether it will have trouble running properly if I read in USHCN data from the raw or TOB file, instead of the fully adjusted F52.avg.gz file?    </p>
<p>Because step 0 reads in and acts on the flags in the F52.avg file, marked as &#8216;E&#8217;, &#8216;X&#8217; or &#8216;Q&#8217;, I&#8217;d have to edit out these lines in step 0:</p>
<p>            flag = line[m*7+17]<br />
            if ((flag in &#8216;EQ&#8217;) or    </p>
<p>Is there anything else that could go wrong?    I doubt it would make much of any difference to the global numbers, but the differences between the USHCN raw, TOB and final adjustment are not negligible, so being able to choose the input file would be a fun capability.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dick Veldkamp</title>
		<link>http://clearclimatecode.org/ccc-gistemp-release-0-4-0/comment-page-1/#comment-420</link>
		<dc:creator>Dick Veldkamp</dc:creator>
		<pubDate>Sun, 14 Mar 2010 19:14:17 +0000</pubDate>
		<guid isPermaLink="false">http://clearclimatecode.org/?p=224#comment-420</guid>
		<description>Re: Delaunay triangulation

@DRJ: I think that St Helena does not get more weight than it does in rectangular gridding. Suppose the grid cell containing St Helena has no other stations, then St Helena would fix the temperature for that entire cell.

If we do not apply any physical modelling to the problem of finding the global average temperature, it seems to me that for each point on the Earth we can make no better temperature estimate than by interpolation based on triangles. The station weights follow from this.

Well, maybe that is not true. Continuing with the &#039;What&#039;s the best estimate?&quot; question, why not construct some smooth surface -by kriging say- and find the average temperature based on that?

I would love to try out a couple of thee things, but unfortunately my regular work leaves me no time just now.</description>
		<content:encoded><![CDATA[<p>Re: Delaunay triangulation</p>
<p>@DRJ: I think that St Helena does not get more weight than it does in rectangular gridding. Suppose the grid cell containing St Helena has no other stations, then St Helena would fix the temperature for that entire cell.</p>
<p>If we do not apply any physical modelling to the problem of finding the global average temperature, it seems to me that for each point on the Earth we can make no better temperature estimate than by interpolation based on triangles. The station weights follow from this.</p>
<p>Well, maybe that is not true. Continuing with the &#8216;What&#8217;s the best estimate?&#8221; question, why not construct some smooth surface -by kriging say- and find the average temperature based on that?</p>
<p>I would love to try out a couple of thee things, but unfortunately my regular work leaves me no time just now.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: drj</title>
		<link>http://clearclimatecode.org/ccc-gistemp-release-0-4-0/comment-page-1/#comment-388</link>
		<dc:creator>drj</dc:creator>
		<pubDate>Fri, 12 Mar 2010 07:30:23 +0000</pubDate>
		<guid isPermaLink="false">http://clearclimatecode.org/?p=224#comment-388</guid>
		<description>@Dick: Delaunay triangulation is an interesting idea.  We don&#039;t do it of course because ccc-gistemp does what GISTEMP does, which is an equal area grid of boxes.  In the future we hope to make the gridding step more flexible and allow a choice of grids.

One question for your Delaunay idea: How big would the triangles be that touch St Helena (or any other isolated station such), and why should those stations get more influence than others?</description>
		<content:encoded><![CDATA[<p>@Dick: Delaunay triangulation is an interesting idea.  We don&#8217;t do it of course because ccc-gistemp does what GISTEMP does, which is an equal area grid of boxes.  In the future we hope to make the gridding step more flexible and allow a choice of grids.</p>
<p>One question for your Delaunay idea: How big would the triangles be that touch St Helena (or any other isolated station such), and why should those stations get more influence than others?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dick Veldkamp</title>
		<link>http://clearclimatecode.org/ccc-gistemp-release-0-4-0/comment-page-1/#comment-387</link>
		<dc:creator>Dick Veldkamp</dc:creator>
		<pubDate>Thu, 11 Mar 2010 21:20:25 +0000</pubDate>
		<guid isPermaLink="false">http://clearclimatecode.org/?p=224#comment-387</guid>
		<description>Now there&#039;s such a wonderful new version, requests will pour in to make the program even nicer! 

One thing about which I have been thinking for a while is this: why use (semi) rectangular gridding to calculate the global average temperature? Wouldn&#039;t it be more natural to put a Delaunay triangulation on the globe with the stations as vertices? Station weights would follow naturally from the dimensions of the triangles. Also the polae regions would be included without special tricks.

Is there a reason not to use this method, apart from convention?

Keep up the good work!</description>
		<content:encoded><![CDATA[<p>Now there&#8217;s such a wonderful new version, requests will pour in to make the program even nicer! </p>
<p>One thing about which I have been thinking for a while is this: why use (semi) rectangular gridding to calculate the global average temperature? Wouldn&#8217;t it be more natural to put a Delaunay triangulation on the globe with the stations as vertices? Station weights would follow naturally from the dimensions of the triangles. Also the polae regions would be included without special tricks.</p>
<p>Is there a reason not to use this method, apart from convention?</p>
<p>Keep up the good work!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nick.Barnes</title>
		<link>http://clearclimatecode.org/ccc-gistemp-release-0-4-0/comment-page-1/#comment-386</link>
		<dc:creator>Nick.Barnes</dc:creator>
		<pubDate>Thu, 11 Mar 2010 18:49:35 +0000</pubDate>
		<guid isPermaLink="false">http://clearclimatecode.org/?p=224#comment-386</guid>
		<description>I have fixed the bug that Tim reported, and made &lt;a href=&quot;http://ccc-gistemp.googlecode.com/files/ccc-gistemp-0.4.1.tar.gz&quot; rel=&quot;nofollow&quot;&gt;release 0.4.1&lt;/a&gt;.</description>
		<content:encoded><![CDATA[<p>I have fixed the bug that Tim reported, and made <a href="http://ccc-gistemp.googlecode.com/files/ccc-gistemp-0.4.1.tar.gz" rel="nofollow">release 0.4.1</a>.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
