...
Step | Description of action | Dependency on 3rd party services (EOSC-hub or other) |
|---|---|---|
UC1 | A researcher requests to access the services of the EPOS-ORFEUS CC. He is redirected to the CC Authentication Service (relying on B2ACCESS in the background) where he can log in at his home institution or create a local account if needed. He receives a token. Depending on his profile he might be authorised to use the services of the CC. Profiles include information about the groups he belongs to (e.g. read permission of particular restricted data). | B2ACCESS |
UC2 | A researcher (authenticated and authorised) searches for datasets of her interest, by using an API. She selects one or more staging nodes from the available ones received, by interrogating the API. Finally she initiates the data movement by calling a dedicated method of the same API. | B2STAGE, B2SAFE, EIDA WFCatalog (with Dublin Core extension) |
UC3 | A seismologist (authenticated and authorised) wants to perform an analysis on a datasets previously selected and staged. He logs in the Jupyter environment close to the staged datasets. He selects and launches a kernel containing his preferred seismological libraries. When the correspondent Jupiter notebook is up and running the datasets are available in a local directory and he can perform his analysis. He might choose to pause his work and save it for later. Finally he can download results on his PC, move them to his personal cloud storage folder or made them available on a local folder. | EGI Notebook, B2DROP |
| UC4 | A data centre acquires and stores waveform data by connecting to servers or devices. A network operator indicates data publicity policies to the data centre. At a next phase, a check of the expected data is performed as well as computation and ingestion of waveform data quality metrics (e.g. percentage availability). Meanwhile, manually data maintenance (e.g. gap filling) and replication is being implemented. Concerning replication, the data are transferred from the data archive to external resources by using B2SAFE. Finally, data requests via services are being traced and summed up to statistics regularly. | B2SAFE-DPM |
| UC5 | A seismologist wants to analyse data that is available (previously staged) at different distributed compute centres. After accessing one the available Jupyter environments, he writes and test his analysis code. When he is satisfied with the results he might decide to run such an analysis code on a selected number of compute centres. | EGI Notebook |
Architecture & EOSC-hub technologies considered/assessed
...
Requirement number | Requirement title | Link to Requirement JIRA ticket | Source Use Case | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
Example | EOSC-hub to provide an FTS data transfer service |
| UC1 | ||||||||
RQ1 | iRODS instance accessible from the Jupyter environment and federated with local B2SAFE/iRODS instances | UC2, UC3 | |||||||||
RQ2 | Customisable and permanent kernels in Jupyter (EGI Notebook) | UC3 | |||||||||
| RQ3 | Personal data folder with staged data available for mounting in the Jupyter notebook | UC3 | |||||||||
| RQ4 | Operating SeedLink slarchive and rsync for data acquisition, while ArcLink and FDSNWS for data exposal. WFCatalog for quality metrics collection and distribution, as well as B2SAFE for data replication and Webreqlog for statistics sum-ups. | UC4 | |||||||||
| RQ5 | Execution of distributed Jupyter notebooks | UC5 |
Capacity Requirements
EOSC-hub services | Amount of requested resources | Time period |
|---|---|---|
...