<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=us-ascii" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.19190"></HEAD>
<BODY bgColor=#ffffff text=#000000>
<DIV dir=ltr align=left><SPAN class=418005309-29022012><FONT color=#0000ff
size=2 face=Arial>Hello Karl,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=418005309-29022012><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=418005309-29022012><FONT color=#0000ff
size=2 face=Arial>I think its an error if someone tries to
publish an unknown diagnostic with product=output. *But* do
we know the scale of the problem of data already in the system?
How much data has the wrong product assigned (either in the DRS id, or in the
files netCDF attribute)? Is there an expectation that this data will
be reassigned to the correct product? Or will we just live with
it? If its sufficiently large volume/number of files *and* we are
going to 'live with' the legacy problem then I don't see a strong reason to fix
new data - users already have to deal with the wrong products. (but happy
to be wrong on this)</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=418005309-29022012><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=418005309-29022012><FONT color=#0000ff
size=2 face=Arial>Jamie</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=418005309-29022012><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left>
<HR tabIndex=-1>
</DIV>
<DIV dir=ltr align=left><FONT size=2 face=Tahoma><B>From:</B>
go-essp-tech-bounces@ucar.edu [mailto:go-essp-tech-bounces@ucar.edu] <B>On
Behalf Of </B>Karl Taylor<BR><B>Sent:</B> 28 February 2012 16:51<BR><B>To:</B>
stephen.pascoe@stfc.ac.uk<BR><B>Cc:</B> Drach, Bob;
go-essp-tech@ucar.edu<BR><B>Subject:</B> Re: [Go-essp-tech] output1 vs.
output2<BR></FONT><BR></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px"
dir=ltr>
<DIV></DIV><FONT face="Times New Roman">Dear all,<BR><BR> thanks for
identifying the likely bug. <BR><BR>While fixing this problem, we should check
whether the publisher correctly treats product="unsolicited" data sets
correctly. Is there an "if test" for this case? What should we do
with data where product as been set by the data writer to "output", but "the
product cannot be determined" by the publisher? Should we set product to
"output" as the publisher apparently now does, or should be throw an error, or
should be set it to "unsolicited"?<BR><BR>Please vote. (and give reasons for
your view).<BR><BR>thanks,<BR>Karl<BR></FONT><BR>On 2/28/12 3:14 AM, <A
class=moz-txt-link-abbreviated
href="mailto:stephen.pascoe@stfc.ac.uk">stephen.pascoe@stfc.ac.uk</A> wrote:
<BLOCKQUOTE
cite=mid:4C353E6E4A08AE4792B350DAA392B52126751A2D@EXCHMBX01.fed.cclrc.ac.uk
type="cite">
<META name=Generator
content="Microsoft Word 12 (filtered medium)">
<STYLE>@font-face {
font-family: Cambria Math;
}
@font-face {
font-family: Calibri;
}
@font-face {
font-family: Tahoma;
}
@font-face {
font-family: Consolas;
}
@page WordSection1 {size: 612.0pt 792.0pt; margin: 72.0pt 72.0pt 72.0pt 72.0pt; }
P.MsoNormal {
MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman","serif"; COLOR: black; FONT-SIZE: 12pt
}
LI.MsoNormal {
MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman","serif"; COLOR: black; FONT-SIZE: 12pt
}
DIV.MsoNormal {
MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman","serif"; COLOR: black; FONT-SIZE: 12pt
}
A:link {
COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.EmailStyle17 {
FONT-FAMILY: "Calibri","sans-serif"; COLOR: #1f497d; mso-style-type: personal-reply
}
.MsoChpDefault {
FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.WordSection1 {
page: WordSection1
}
</STYLE>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<DIV class=WordSection1>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">Karl,
Bob,<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"><O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">I
think this is a bug in ESG publisher. I've just taken a look at the
code and it converts the variable to lower-case before looking it up in an
internal table, however the internal table has "sfcWind" so it never finds
the variable. Other variables that may be affected are tasAdjust,
tsAdjust and parasolRefl<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"><O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">###
In esgcet.config.cmip5_product<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">def
getProduct(cmor_table, variable, experiment, year1,
year2):<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">
"""Get the DRS product value associated with the file.<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">
Returns<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">
'output1' for datasets to be replicated,<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">
'output2' for datasets outside the replicated
datasets,<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">
'output' if the product cannot be determined.<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">
"""<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">
cmor_table = cmor_table.lower()<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">
variable <B>= variable.lower()</B><O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"><O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">###
In esgcet.config.cmip5_tables<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">#
cmor_variables : cmor_table => { variable => (priority,
dimension_names)}<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">cmor_variables
= { '3hr': { 'clt': (1, ['longitude', 'latitude',
'time']),<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">
# ...<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">
'amon': { 'ccb': (1, ['longitude', 'latitude',
'time']),<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">
# ...<O:P></O:P></SPAN></P>
<P class=MsoNormal><B><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">
'sfcWind'</SPAN></B><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">:
(1, ['longitude', 'latitude', 'time', 'height10m']),<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">
'ta': (1, ['longitude', 'latitude', 'plevs', 'time']),<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">
'tas': (1, ['longitude', 'latitude', 'time',
'height2m']),<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">
'tasAdjust': (1, ['longitude', 'latitude', 'time',
'height2m']),<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"><O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"><O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">Cheers,<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">Stephen<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"><O:P></O:P></SPAN></P>
<DIV>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: Consolas; COLOR: #1f497d; FONT-SIZE: 10.5pt">---<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: Consolas; COLOR: #1f497d; FONT-SIZE: 10.5pt">Stephen
Pascoe +44 (0)1235 445980<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: Consolas; COLOR: #1f497d; FONT-SIZE: 10.5pt">Centre of
Environmental Data Archival<O:P></O:P></SPAN></P>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: Consolas; COLOR: #1f497d; FONT-SIZE: 10.5pt">STFC
Rutherford Appleton Laboratory, Harwell Oxford, Didcot OX11 0QX,
UK<O:P></O:P></SPAN></P></DIV>
<P class=MsoNormal><SPAN
style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"><O:P></O:P></SPAN></P>
<DIV>
<DIV
style="BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0cm; PADDING-LEFT: 0cm; PADDING-RIGHT: 0cm; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<P class=MsoNormal><B><SPAN
style="FONT-FAMILY: 'Tahoma','sans-serif'; COLOR: windowtext; FONT-SIZE: 10pt"
lang=EN-US>From:</SPAN></B><SPAN
style="FONT-FAMILY: 'Tahoma','sans-serif'; COLOR: windowtext; FONT-SIZE: 10pt"
lang=EN-US> <A class=moz-txt-link-abbreviated
href="mailto:go-essp-tech-bounces@ucar.edu">go-essp-tech-bounces@ucar.edu</A>
[<A class=moz-txt-link-freetext
href="mailto:go-essp-tech-bounces@ucar.edu">mailto:go-essp-tech-bounces@ucar.edu</A>]
<B>On Behalf Of </B>Karl Taylor<BR><B>Sent:</B> 28 February 2012
00:52<BR><B>To:</B> <A class=moz-txt-link-abbreviated
href="mailto:go-essp-tech@ucar.edu">go-essp-tech@ucar.edu</A><BR><B>Subject:</B>
[Go-essp-tech] output1 vs. output2<O:P></O:P></SPAN></P></DIV></DIV>
<P class=MsoNormal><O:P></O:P></P>
<P class=MsoNormal>Hi all,<BR><BR>I have noticed (using the new p2p search
engine, which works much faster, and I'm pretty sure is accurate) that
sfcWind_Amon_historical output is designated as "output 1" for some models
(from IPSL, MOHC, MPI-M, and NOAA-GFDL), but "output2" for the rest. I
think "output1" is correct. <BR><BR>Can anyone explain why the
publisher correctly characterized the output from some groups, but not for
the rest?<BR><BR>thanks,<BR>Karl<O:P></O:P></P></DIV><BR>
<P>-- <BR>Scanned by iCritical. </P><BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>