As a user I want to be able to perform detailed analysis on large volumes of data in parallel using scalable cloud resource in order to achieve more rapid results than sequential processing and avoiding downloading large quantities of data to local storage.

As a user I want the results of my analysis available to me anywhere and be able to share it with colleagues before publishing in order to discuss and confirm the outcomes.

As a user I want to ensure my input data is accessible regardless of physical location (for example, by making use of persistent identifiers), since then I do not need to implement my own code to deal with these changes.

As provider of the Climate gateway I want to empower researchers from academia to interact with datasets stored in the Climate Catalogue, and bring their own applications to analyse this data on remote cloud servers

As a data producer I would like scientists to be able to reference the source data used for downstream analysis and get accreditation in any subsequent publications.

As a data manager I want any analysis to generate provenance metadata in order to understand what analysis has been performed to allow both confirmation of results and increase confidence in the scientific methods and analysis.

As a decision maker I want to have confidence in the scientific results on which I rely to make policy decisions.

As a data manager I want to ensure data is replicated across multiple sites to ensure that it is always available to users and to ensure the safe-keeping of the data.

(This is not relevant to ECAS - ECAS is not doing data replication ...?)

As a data manager I want to ensure that data stored in external storage is safe by ensuring and auditing of regular fixity checking and, where necesary, self healing from good replicas ensures that data accessed by users is valid..

(Same as above, not an ECAS concern?)

A user would like to run a climate data analysis experiment across CMIP51 or CMIP62 data. The targeted model output (?input?) data come from multiple modelling groups across the globe and are therefore hosted at different ENES data sites across Europe. For a specific target experiment, as a preliminary step, the user runs a distributed search on the ENES data nodes to discover the required input files, which will result in a list of input dataset PIDs. The user then assembles a processing job specification and submits it to the ENES data
analytics service. The service will arrange for the data to be available at the processing site; data locality will be exploited by default, but
data movement could be also needed. Once the data are available, a data analytics workflow runs on the service instance. After the
analysis has completed, the user receives an e-mail notification with a link to a shared folder at a publication service folder from which she
can access and download the processing results.

The challenge is to do the server-side and parallel computation on the distributed data by making transparent the access to the data
(including data movement), the allocation and use of the computational resources, the analytics experiment, the provenance
tracking, and the overall experiment orchestration.

At a later point, another user discovers the data from the previous analysis on the publication service. In order to be certain that the
data can be used for the purpose at hand, she would like to evaluate its generation history, including the details of the processing that was
done and the specifics of the input data used. She retrieves data and accompanying metadata from the publication service and uses the
PIDs of the processed data to discover additional information on the processing and the full list of PIDs of all input datasets. She can then
make a judgement based on the assembled information whether the data are fit for her purpose without having to contact the user who
originally requested the data processing.

As a user, I want to be able to make selected results of my data analysis or the analysis script I developed available to others. These recipients may be my immediate colleagues but also a wider range of external third parties. The workflow to make these data available should be largely hassle-free for me.

User needs to discover the location of all required input data

ESGF Metadata Service/B2FIND

Input data must have a PID associated with it.

ENES Data Analytics Service must be able to transfer data from its current location to the processing site based on PID

(Low priority - I am not sure if we will do this; it is not entirely in the original plan, though I agree it makes sense. It depends on how data input integration ultimately looks like and what can be done with limited effort.)

Users will select individual files or entire directories from their ECAS workspace and then select to publish them. The ECAS workspace will inquire a destination location for the files in the user's B2DROP workspace. The publishing workflow for the users will start from the ECAS workspace but end with a view on the publishing repository (B2DROP) showing the newly published files as confirmation.