[Go-essp-tech] output1 vs. output2
Estanislao Gonzalez
gonzalez at dkrz.de
Tue Feb 28 10:54:06 MST 2012
Hi,
my vote will be to break with an error. That should be the most
reasonable procedure IMHO if some ask the publisher to perform something
and this cannot be done.
The user is not forced to trigger the product detection, so it could
just set it to "unsolicited" manually.
The question would be: is there any scenario where the data producer
creates data without knowing if it's solicited or not (or better said,
mixing both)?
If so, then there could be yet another option for this particular
behavior. At least the data producer should "know" if some of the data
is "unsolicited"... or in any case after an error is displayed, it
certainly will.
My 2c,
Estani
Am 28.02.2012 17:50, schrieb Karl Taylor:
> Dear all,
>
> thanks for identifying the likely bug.
>
> 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"?
>
> Please vote. (and give reasons for your view).
>
> thanks,
> Karl
>
> On 2/28/12 3:14 AM, stephen.pascoe at stfc.ac.uk wrote:
>>
>> Karl, Bob,
>>
>> 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
>>
>> ### In esgcet.config.cmip5_product
>>
>> def getProduct(cmor_table, variable, experiment, year1, year2):
>>
>> """Get the DRS product value associated with the file.
>>
>> Returns
>>
>> 'output1' for datasets to be replicated,
>>
>> 'output2' for datasets outside the replicated datasets,
>>
>> 'output' if the product cannot be determined.
>>
>> """
>>
>> cmor_table = cmor_table.lower()
>>
>> variable *= variable.lower()*
>>
>> ### In esgcet.config.cmip5_tables
>>
>> # cmor_variables : cmor_table => { variable => (priority,
>> dimension_names)}
>>
>> cmor_variables = { '3hr': { 'clt': (1, ['longitude', 'latitude',
>> 'time']),
>>
>> # ...
>>
>> 'amon': { 'ccb': (1, ['longitude', 'latitude', 'time']),
>>
>> # ...
>>
>> * 'sfcWind'*: (1, ['longitude', 'latitude', 'time',
>> 'height10m']),
>>
>> 'ta': (1, ['longitude', 'latitude', 'plevs', 'time']),
>>
>> 'tas': (1, ['longitude', 'latitude', 'time',
>> 'height2m']),
>>
>> 'tasAdjust': (1, ['longitude', 'latitude', 'time',
>> 'height2m']),
>>
>> Cheers,
>>
>> Stephen
>>
>> ---
>>
>> Stephen Pascoe +44 (0)1235 445980
>>
>> Centre of Environmental Data Archival
>>
>> STFC Rutherford Appleton Laboratory, Harwell Oxford, Didcot OX11 0QX, UK
>>
>> *From:*go-essp-tech-bounces at ucar.edu
>> [mailto:go-essp-tech-bounces at ucar.edu] *On Behalf Of *Karl Taylor
>> *Sent:* 28 February 2012 00:52
>> *To:* go-essp-tech at ucar.edu
>> *Subject:* [Go-essp-tech] output1 vs. output2
>>
>> Hi all,
>>
>> 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.
>>
>> Can anyone explain why the publisher correctly characterized the
>> output from some groups, but not for the rest?
>>
>> thanks,
>> Karl
>>
>>
>> --
>> Scanned by iCritical.
>>
>>
>
>
> _______________________________________________
> GO-ESSP-TECH mailing list
> GO-ESSP-TECH at ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
--
Estanislao Gonzalez
Max-Planck-Institut für Meteorologie (MPI-M)
Deutsches Klimarechenzentrum (DKRZ) - German Climate Computing Centre
Room 108 - Bundesstrasse 45a, D-20146 Hamburg, Germany
Phone: +49 (40) 46 00 94-126
E-Mail: gonzalez at dkrz.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20120228/28af9a68/attachment.html
More information about the GO-ESSP-TECH
mailing list