[Go-essp-tech] CMIP5 Web interface requirements matrix

martin.juckes at stfc.ac.uk martin.juckes at stfc.ac.uk
Wed Jan 11 05:27:37 MST 2012


Hello All,

There are a number of different questions to be answered, not only related to the different timescales that Estani highlights, and I doubt a single requirement list is going to work for all of them.

Within GO-ESSP we have, I think, a general philosophy of distributed services allowing data access through multiple portals. The infrastructure we have deployed for CMIP5 deals with the security problems which follow from this philosophy (i.e. anyone can publish links to the data, but the user will still have to go through PCMDI to get authorization) but not with issues of "branding". As a community we don't, I think, attach much importance branding for its own sake, but lack of clarity can make life confusing for users -- and that is something we do need to take seriously.

This may not be the right list for the discussion, but there needs to be an agreement on how we deal with multiple portals and associated branding.  We currently carry an "Earth System Grid" banner on the gateways -- giving more prominence to the software provenance than most people would expect to find in a web site banner. The infrastructure is not "brand" friendly, as each gateway installation can provide access to a mix of projects, and "Project" is treated just like any other facet. I guess it is like any other facet, as not all data under "Project=CMIP5" is authorised by PCMDI (there is still some restricted to modelling group associates) -- the authorisation provider information is only revealed when the user tries to access a dataset. This is one example where lack of clarity about who the data belongs to makes life difficult for users.

Branding is not just about who authorises the data: for the IPCC Data Distribution Centre we are happy let others mirror the data and provide translated guidance documents, but use of the IPCC logo on such mirror sites is strictly prohibited.

We could, for instance, have one (at PCMDI) or more WCRP branded gateways -- which would then, of course, be restricted to providing access to datasets approved, in some sense, by a WCRP working group. Other gateways would be allowed and be the responsibility of the host organisations (as per the GO-ESSP philosophy above), but WCRP branded gateways would be subject to stricter requirements -- and the branding would make the distinction clear.

cheers,
Martin


________________________________
From: go-essp-tech-bounces at ucar.edu [go-essp-tech-bounces at ucar.edu] on behalf of Estanislao Gonzalez [gonzalez at dkrz.de]
Sent: 11 January 2012 10:42
To: Pascoe, Stephen (STFC,RAL,RALSP)
Cc: Luca.Cinquini at jpl.nasa.gov; go-essp-tech at ucar.edu
Subject: Re: [Go-essp-tech] CMIP5 Web interface requirements matrix

Hi,

I haven't read Luca's list, but the current one looks already long enough to me (although I've commented on a longer list indeed).
The way I see it we have three different requirement categories to cope with:

1) AR5: This is immediate and involves letting people access data and being able to cite it at the papers being currently written. This requirement is already due and there are still issues that need to be addressed.
2) CMIP5 (general): a mid term goal which extends beyond the AR5 deadline. It involves preserving data for more time and probably more efficiently. Although it's already due it involves a longer timespan as data will keep on arriving even after the AR5 deadline. Tools enabling the comparison and trimming or computing of data are key in this step.
3) Climate data portals: This is a longer term goal which involves many features, some of them already developed. To plan for the future we need a comparison in these fields.

This is very simplistic, but I think the main idea is still there. Feel free to correct me.
There are a lot of features that are nice and some even great, but we are still lacking the basics (according to the help-desk). People are desperate to get the data and for one reason or another, we are not performing as well as we should.

My 2c,
Estani

Am 11.01.2012 10:55, schrieb stephen.pascoe at stfc.ac.uk:<mailto:stephen.pascoe at stfc.ac.uk:>
Hi Luca,

This is where deciding the scope of the matrix gets difficult.  I can agree with some of your requirements but many seem too P2P focused to me.  So I'll respond point-by-point to your sheet soon but expect some push-back on what is in and out of scope.  I'm not ready to relinquish control over this yet.  No-one is completely neutral in this debate but someone has to hold the ring.

We need to be focused on what this sheet is for.  It is not for planning general ESGF development (at least not at this stage).  It is for planning how we meet the requirements for CMIP5.  I.e. what we promised WGCM and what users are asking for.  In the short term this sheet is to help us fix the terrible usability and performance problems we have.  There are 2 potential solutions and we need to decide which to deploy in the short/medium and long term.

I think it is vital that we stick to functional requirements as far as possible.  Some non-functional requirements are needed, like consistency and performance, but having too many subjective non-functional requirements will make the matrix useless.  I actually resisted including sections 12 and 13 (deployment and development) because I think they are subjective and difficult to agree on.  However, others were very keen to have them in so I included them.

I'll get back to you in more detail asap.
Stephen.

---
Stephen Pascoe  +44 (0)1235 445980
Centre of Environmental Data Archival
STFC Rutherford Appleton Laboratory, Harwell Oxford, Didcot OX11 0QX, UK

From: Cinquini, Luca (3880) [mailto:Luca.Cinquini at jpl.nasa.gov]
Sent: 10 January 2012 19:06
To: V Balaji
Cc: Pascoe, Stephen (STFC,RAL,RALSP); go-essp-tech at ucar.edu<mailto:go-essp-tech at ucar.edu>
Subject: Re: [Go-essp-tech] CMIP5 Web interface requirements matrix

Hi Stephen, Balaj et all,
        I added many more requirements to Stephen's original spreadsheet, including IPSL's download tool. I marked the spreadsheet with tomorrow's date to indicate it's an updated version.
thanks, Luca



On Jan 10, 2012, at 10:30 AM, V Balaji wrote:

> Following up on the discussion of command line tools on this call, I
> would like to propose adding Sebastien's synchro_data to the list of
> gateways!
>
> On Tue, Jan 10, 2012 at 12:22 PM, Cinquini, Luca (3880)
> <Luca.Cinquini at jpl.nasa.gov><mailto:Luca.Cinquini at jpl.nasa.gov> wrote:
>> Hi Stephen,
>> so what is the process for adding requirements to this list ? As I
>> mentioned, there are many other items that should be part of a full
>> evaluation. Should I just send an update version to your list ?
>> thanks, Luca
>>
>> On Jan 10, 2012, at 9:31 AM, <stephen.pascoe at stfc.ac.uk><mailto:stephen.pascoe at stfc.ac.uk>
>> <stephen.pascoe at stfc.ac.uk><mailto:stephen.pascoe at stfc.ac.uk> wrote:
>>
>> In response to a query on the telco: the sheet I sent is the latest,
>> although I have not included notes from MOHC and DKRZ therefore the size of
>> many cells are smaller.  I was thinking we should make a clean start with
>> this wider release of the sheet.  Also the snazzy colour coding hasn't
>> survived translation from OpenOffice to XLS but that's not important.
>>
>> Stephen.
>>
>> ---
>> Stephen Pascoe  +44 (0)1235 445980
>> Centre of Environmental Data Archival
>> STFC Rutherford Appleton Laboratory, Harwell Oxford, Didcot OX11 0QX, UK
>>
>> From: Pascoe, Stephen (STFC,RAL,RALSP)
>> Sent: 10 January 2012 14:32
>> To: go-essp-tech at ucar.edu<mailto:go-essp-tech at ucar.edu>
>> Subject: CMIP5 Web interface requirements matrix
>>
>> Dear all,
>>
>> To help the CMIP5 centres plan our upgrade to the next major release of the
>> CMIP5 archive system BADC has been collating a
>> spreadsheet of web interface requirements with input from PCMDI, DKRZ and
>> MOHC (see attached).  We hope to use this sheet as a tool to plan migration
>> of the CMIP5 web interface at the main CMIP5 centres: PCMDI, BADC and DKRZ.
>>
>> The sheet is still work in progress and there is lots to discuss and
>> clarify.  I have begun to suggest scores for the three systems being
>> considered, Gateway 1.3.4, Gateway 2.0 and P2P, but these are speculative at
>> this stage, particularly for the P2P system with which I have the least
>> experience.
>>
>> If there is time I'd like to briefly introduce the sheet at the GO-ESSP
>> telco today and schedule a time for a more thorough discussion.
>>
>> Cheers,
>> Stephen.
>>
>> ---
>> Stephen Pascoe  +44 (0)1235 445980
>> Centre of Environmental Data Archival
>> STFC Rutherford Appleton Laboratory, Harwell Oxford, Didcot OX11 0QX, UK
>>
>>
>> --
>> Scanned by iCritical.
>>
>>
>> _______________________________________________
>> GO-ESSP-TECH mailing list
>> GO-ESSP-TECH at ucar.edu<mailto:GO-ESSP-TECH at ucar.edu>
>> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
>>
>>
>>
>> _______________________________________________
>> GO-ESSP-TECH mailing list
>> GO-ESSP-TECH at ucar.edu<mailto:GO-ESSP-TECH at ucar.edu>
>> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
>>
>
>
>
> --
>
> V. Balaji                               Office:  +1-609-452-6516
> Head, Modeling Systems Group, GFDL      Home:    +1-212-253-6662
> Princeton University                    Email: v.balaji at noaa.gov<mailto:v.balaji at noaa.gov>


--
Scanned by iCritical.




_______________________________________________
GO-ESSP-TECH mailing list
GO-ESSP-TECH at ucar.edu<mailto: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<mailto:gonzalez at dkrz.de>
-- 
Scanned by iCritical.


More information about the GO-ESSP-TECH mailing list