[Go-essp-tech] output1 vs. output2

[Estanislao Gonzalez]

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