A.1.1.  Key features

The Data Analytics for Canadian Climate Services (DACCS) (OSF entry) project formed a multidisciplinary working group composed of Universities (Toronto, McGill, Concordia, Victoria, Alberta, Sherbrooke), and innovation hubs (CRIM, Ouranos) that lead to the development and maintenance of a federated server node network (Marble project), which aims to provide platforms for climate data analysis. Amongst this network, CRIM hosts the Hirondelle node (OSF entry), Ouranos hosts the PAVICS node (OSF entry), and University of Toronto hosts the Red Oak node. Each of these nodes, implemented using the birdhouse-deploy infrastructure as code (OSF entry), provide interoperable capabilities, but offering different combinations of processing components and datasets, according to the respective domains for which each organization focuses their work. Across these platforms, the following capabilities are provided.

With these capabilities, researchers and developers are able to interact with the processes and datasets at different levels of expertise, whether through Python scripts in Jupyter instances, or using more user-friendly interfaces as provided by the STAC browser. The common service interfaces allow distinct data and processing to be accessed by users in a standardized manner, although the underlying operations can differ greatly. For example, CRIM processes tend to focus more around dynamic applications for AI/ML development, while Ouranos’s efforts focus on long-lived hydrological and climate modeling and simulations.

A.1.2.  Development Roadmap

The development roadmap is two-fold:

Description: Define use cases to analyze and develop an initial structure that establishes the foundations of the applications that can be reused across participants and platforms to evaluate interoperability and capabilities relevant for open-science. Planned work includes the deployment of a land-cover mapping ML algorithm (OSF entry) as well as the implementation of the Algae Bloom use case for deployment using CWL.

Description: Development on the platform architecture offered by CRIM to address necessary adjustments to support open-science between participants using common interfaces, such as OGC API — Processes, CWL and CFF, and including the necessary definitions in OSF to share references to relevant platforms, API implementations and deployed OGC Application Packages using CWL that reproduce the open-science work.

A.1.3.  Galaxy Integration (Galaxy as a client of my service )

Provide adjustments as needed to the already available OGC API — Processes interface (i.e.: Weaver) to execute the selected use cases, such as the Algal Bloom use case, in order to provide necessary functionalities by the Galaxy tools to interact with the server accordingly. These adjustments could include, amongst other things, the addition of capabilities to provide metadata or response formats to support open-science and workflows across the multiple D100/101 platforms in an interoperable manner. For example, OGC API — Processes allows the definition of metadata in the process description, but no explicit requirements are mandated by the API specification to provide DOIs, CFF citations and other details to ensure open science and data lineage. Further, inputs and outputs of processes allow the specification of generic media-types (e.g.: GeoTiff for the Algal Bloom use case), but there are no explicit requirements enforcing specific sensors (e.g.: the Algal Bloom algorithm requires Sentinel-2 L2A products due to specific band calculations). Strategies to establish how these requirements can be communicated between Galaxy and OGC API — Processes remain to be defined.

A.1.4.  Open design questions

Current OGC API — Processes specification allow deployment of Application Packages (through Part 2 — DRU) which can be employed for the dynamic creation and integration of open-science applications. However, the specific implementation of supported Application Packages by an OGC API — Processes compliant server are left up to the design choices of each specific server. Furthermore, little to no details are provided regarding how the deployed application can then be shared externally. Only an abstract process description is made available through the core endpoints of the API. In order to make OGC Application Packages interoperable across OGC-compliant platforms and Galaxy, more design discussions must be made to provide details that will allow replicable open science workflows.

Current tool definitions in Galaxy expect users to provide the code and undertake the testing necessary to integrate their application using the technical structure (‘the wrapper’) prescribed by Galaxy. This produces notable constraints that need to be addressed.

First, the tool definition assumes that users that want to share their application as a result of open-science have the knowledge to do so efficiently, due to the high amount of technologies involved, and that they understand the intricate implementation details of Galaxy. In reality, the great complexity surrounding the DevOps requirements in the context of a platform could discourage the integration of open-science work because of this technological and knowledge barrier.

Second, the rapidly evolving nature of AI/ML and open-science resulting from it, asks for highly dynamic and evolving applications, for which the integration overhead in Galaxy could limit adoption.

Third, multiple services and processes are already available through standard interfaces, such as OGC API — Processes, which cannot be directly leveraged in Galaxy. Because of the quantity of existing applications, it is not reasonable to convert all of them to the format required by Galaxy.

Therefore, for all above reasons, more work needs to be performed for Galaxy to support OGC API — Processes, such that the dynamic and evolving ecosystem surrounding applications for Climate, Earth Observation and Disaster response analysis can be quickly and easily integrated by users from multiple domain backgrounds.

One proposed candidate for sharing open-science work is the OSF platform. While the structure seems promising for building a knowledge archive to share scientific work, referencing documents, code, and relevant material sources to reproduce science, there is still a lack of details regarding a standard approach to provide metadata that could be reused by different platforms. Potential metadata annotation formats, such as STAC, CFF citations and others have to be considered and evaluated, to determine if they are sufficient to achieve reproducible and licensable open-science.

A.1.5.  SWOT analysis

A.2.1.  Key features

The GeoLabs integration leverages the ZOO-Project, an Open-Source Processing Engine and an OSGeo Project that complies with OGC standards, initially based on WPS 1.0.0 and later on WPS 2.0.0. It serves as a Reference Implementation of the OGC API — Processes — Part 1: Core. The ZOO-Project builds upon the ZOO-Kernel, which can execute local processes implemented in a variety of programming languages, including C/C++, Java, Python, PHP, Perl, and JavaScript (limozjs or Node.js).

ZOO-Project supports the execution of complex geospatial processing through existing libraries like OrfeoToolBox (OTB) and SAGA-GIS. It offers a framework to publish results as standard OGC Web Services or APIs (WMS, WFS, WCS), with minimal modifications required to process metadata. The integration with High-Performance Computing (HPC) environments, as demonstrated in projects like GeoSUD and Phidias-HPC, enables remote task execution using protocols such as Secure Shell (SSH) and workload managers like SLURM. This capability has been further enhanced through the use of Singularity containers for packaging workflows.

During the Testbed19 project, ZOO-Project showcased its ability to deploy workflows or individual applications using the OGC API Processes — Part 2: Deploy, Replace, and Undeploy (DRU) draft specification. The integration with the Earth Observation European Platform for Cloud and Analytics (EOEPCA) supports the Common Workflow Language (CWL) conformance class, providing a comprehensive environment for EO data management. This integration also includes a unified platform with the eoAPI (part of VEDA), supporting full OGC API — Processes (Part 1, Part 2, and partial Part 3) for seamless interoperability.

The ZOO-Project has been successfully integrated with various HPC components, making it suitable for scenarios requiring heavy computational resources and large-scale data processing. This framework enables users to interact with the Triton Inference Server for geospatial inference, providing an API that conforms to the OGC API — Processes — Part 1: Core Standard. In addition, the ZOO-Project-DRU Helm chart simplifies the deployment of the project, supporting both DRU and CWL, which enables easy deployment and management on Kubernetes clusters.

A.2.2.  Development Roadmap

*Strengthening Galaxy Integration: Improve the integration with the Galaxy platform by utilizing the ZOO-Project services to access VEDA’s processing and data capabilities.

A.2.3.  Current Integration Achievements:

A.2.4.  Open Design Questions:

A.2.5.  SWOT Analysis:

A.3.1.  Key features

Terradue brings an on-demand processing service for flood mapping using Sentinel-1 satellite data. This service simplifies flood extent mapping by utilizing pre- and post-event co-polarized Sentinel-1 Sigma Nought imagery. The process involves a user-defined dB threshold to binarize backscatter, effectively distinguishing water from other surfaces. The service masks out areas classified as water in both pre- and post-event images to accurately depict flooded regions.

The processing service requires specific parameters like pre- and post-event Sentinel-1 acquisitions, the AOI, backscatter thresholds, and the HAND (Height Above the Nearest Drainage) asset threshold. It’s designed to be a straightforward solution, with potential future enhancements like automatic image binarization, the use of permanent water masks, and extension to support optical data. The service follows a workflow with key steps for:

Terradue’s flood mapping service adheres to the OGC API Processes standards and uses the Common Workflow Language (CWL) for packaging and deployment. The service has been integrated with the Galaxy platform, allowing users to access its capabilities directly from Galaxy through the OGC API Processes endpoints. This integration offers flexibility and customization, enabling users to modify parameters for tailored flood mapping solutions.

The service’s architecture supports potential enhancements, such as the inclusion of optical data and automated image binarization, to broaden its applicability and improve processing efficiency. The combination of advanced technology, user-defined settings, and adherence to standards positions Terradue’s flood mapping service as a robust tool for EO data analysis and flood management.

A.3.2.  Development Roadmap

A.3.3.  Galaxy Integration

Galaxy interacts with the flood mapping service via the OGC API Processes endpoint, allowing users to configure and execute the flood mapping workflow from the Galaxy interface. This setup leverages Galaxy’s existing tools for processing and visualizing EO data while using the OGC API Processes standard to manage workflow execution. The integration has successfully demonstrated the execution of flood mapping workflows, providing a seamless interface for users to access and utilize the service.

A.3.4.  Open design questions

An open issue for the deployment of the flood mapping service is the management of access control from Galaxy with user credentials delegation. As a solution, implementing signed URLs could be a viable approach. Signed URLs provide a secure way to grant temporary access to resources. By using unique tokens embedded in these URLs, the service can authenticate and authorize users without the need for more complex authentication mechanisms. This method simplifies the access control process, making it more efficient and user-friendly, while still maintaining a high level of security and control over who can access the service and when.

A.3.5.  SWOT analysis

Strengths:

Weaknesses

Opportunities:

Threats

A.4.1.  Key features

Ellipsis Drive provides a storage for spatial data with the following key features:
1 input flexibility: supports any common spatial format for raster, vector and point cloud. (from netcdf, to geodatabase. From las files to ECW’s). See the full list of file types:
2 output flexibility. When adding a number of files to a layer you can use the layer via any OGC protocol. Think of WMTS, WFS, WCS etc.
3 mosaicing. You can place up to 10 million files within the same layer
4 scalability. No matter the size of the original content the layer always performs the same way.
5 Access Management. You can easily set permission to content and share it. Many authentication methods are supported out of the box.
6 Embedded in an intuitive file system.
7 Equipped with a powerful spatial search based on relevant metadata

A.4.2.  Development Roadmap

1 Exposing coast line information and building footprints to the Galaxy platform..
2 Exposing a STAC endpoint for Galaxy to search content with

A.4.3.  Galaxy Integration (Galaxy as a client of my service )

Exposing layers as WFS/WCS services
Exposing a STAC core and STAC search endpoint

A.4.4.  Open design questions

There are four ways vector data can be fed to the Galaxy platform. WFS, as a batch in a compressed list, via a Features API or as vector tiles. Feeding data to Galaxy via a Features API would be preferable. It is still unclear which of these protocols would be most suitable for Ellipsis Drive.

Executing processes in Ellipsis Drive has been newly added and it is still an open design question how to effectively distribute recources and charge costs without complicating the UX too much.

A.4.5.  SWOT analysis

Strengths

Weaknesses

Opportunities

Threats

A.4.6.  Activities performed

Under D101 — Open Science Platform, Ellipsis Drive has contributed to co-design and requirements scoping, and has used its pre-existing platform (Ellipsis Drive) as well as the newly developed Information Factory, its assets and its capabilities to expand on existing endpoints, protocols, packages and plugins to facilitate cross-platform workflows that have been collaboratively created during the OSPD initiative.

A.5.1.  Key features

The Polar Thematic Exploitation Platform (Polar TEP) provides a complete working environment where users can access algorithms and data remotely, obtain computing resources and tools that they might not otherwise have, and avoid the need to download and manage large volumes of data.

The following are key components of Polar TEP:

 

Polar TEP Support of Open Science

Polar TEP provides tools to assist researchers in participating in all facets of open science (see Figure 1), including:

 

Figure A.1 — Polar TEP support of Open Science

 

A.5.2.  Development process

Within the OGC OSPD pilot, Polar TEP supports the algal bloom use case. The figure shows the OSF open science process cycle that begins with a research idea, moves through data collection and analysis, and continues to the publishing of results, before repeating again.

 

Figure A.2 — OSPD Open Sceince Process

 

Around the outside of the figure are the example steps taken within the OSPD project. These consist of:

1. Registering the Research on OSF

By registering on the Open Science Framework, research can be managed and shared throughout the entire project lifecycle.

2. Discovering a Foundation Study

A literature review resulted in a foundation study for the OSPD project. It concerns the use of Sentinel 2 satellite data to determine water quality. The study algorithms calculate measures of Chlorophyll a, Cyanobacteria and Turbidity. The foundation study used data from the Alqueva reservoir in Portugal in October 2017.

3. Implementing the Study Algorithm on Polar TEP

The study algorithms had already been coded in Java Script. The code was then translated into Python and implemented in Polar TEP as a Jupyter Notebook.

4. Acquiring Relevant Data

Polar TEP was then used to find the Sentinel 2 images that were used in the foundation study. Here is the Sentinel 2 image over the Alqueva reservoir on the foundation study date of October 12th, 2017.

 

Figure A.3 — Sentinel 2 Image of the Study Area

 

5. Replicating the Study

The algorithms were applied to the Sentinel 2 data. The results from the foundation study paper are shown on the left. The results from the Polar TEP replication of the study are shown on the right. The differences are due to variations in colour reproduction.

 

Figure A.4 — Study Replication

 

6. Extending the Study in Time and Space

Polar TEP was then used to extend the use of the algorithms in time and space. Here the three algorithms have been used to analyze an area of Lake Erie in Canada in June 2023.

 

Figure A.5 — Study Extension

 

7. Making the Algorithm Available to Others

To support the work of others in replicating and extending the research, the algorithms are made available within and outside of Polar TEP. Within Polar TEP, they are available in four forms:

Outside of Polar TEP, they are available in two ways:

Use on Polar TEP or from Galaxy requires a Polar TEP account. The code on OSF is freely available.

A.5.3.  Galaxy integration

Within the OSPD project, Polar TEP will utilize the Galaxy Platform as a web-based system that allows users to develop and manage complex data processing workflows. For example, the algae bloom algorithm will be triggered from the Galaxy platform but executed on Polar TEP.

The Galaxy tools will act as intermediaries, communicating through the OGC API Processes endpoint to submit and monitor jobs, and retrieve results and metadata. This integration will allow users to execute sophisticated workflows without needing to manage computing infrastructure across multiple platforms.

 

Figure A.6 — Polar TEP / Galaxy Integration

 

A.5.4.  Open design questions

How will cloud credits for data processing on Polar TEP be provided? Options: i) A Galaxy account is created on Polar TEP so that users coming from Galaxy can invoke processes; ii) A user has an account on Polar TEP and user authentication is passed from Galaxy. In either case, there needs to be communication between Galaxy and Polar TEP to provide the estimated cost of processing for approval by the user before processing is triggered.

A.5.5.  Outlook

Within the first phase of OSPD, Galaxy did not have time to integrate Polar TEP. It is expected that integration will be accomplished in a manner identical to that used for the Terrabyte platform (see Section A.6).

A.6.1.  Developments

After setting up the OGC API Processes endpoint using the open source Python package pygeoapi, the algae bloom use case was implemented as a containerized EO application package based on OGC EO Application Package including Common Workflow Language (CWL). The workflow can be run on terrabyte either directly through the OGC API Processes endpoint or from Galaxy (see next section).

 

Figure A.8 — Screenshot of the OGC API Processes web page of terrabyte

 

A.6.2.  Galaxy Integration (Galaxy as a client of my service)

Galaxy serves as a web-based workflow management platform. The algae bloom workflow was deployed as a tool within Galaxy based on terrabyte’s OGC API Processes endpoint. Thus, processing does not occur on Galaxy itself, but on terrabyte. In the established setup, the Galaxy tool acts merely as a client that communicates with the OGC API Processes endpoint to submit and monitor processing jobs, as well as receive processing results. Since terrabyte is only accessible for registered users, access to the OGC API Processes endpoint is controlled by OpenID Connect (OIDC) bearer tokens that have to be obtained through a two-factor authentication (2FA)-token service and submitted as part of the Galaxy workflow.

 

Figure A.9 — Screenshot of the terrabyte Galaxy tool

 

 

Figure A.10 — Screenshot of the terrabyte process execution in Galaxy

 

A.6.3.  Restrictions

As is common with many platforms, access to terrabyte is restricted to specific user groups. Accessing terrabyte’s resources and APIs requires authentication procedures that include 2FA and the generation of OIDC access tokens. These requirements limit the interoperability of workflows in Galaxy across different platforms and hinder the sharing of intermediate data among them.

A.6.4.  Summary & Outlook

As part of the OGC OSPD Phase 1, terrabyte has been extended with an OGC API Processes endpoint to execute OGC EO Application Packages on the terrabyte infrastructure. Similar to the other OSPD platforms, the endpoint has been integrated into Galaxy, which acts as a central execution platform.

While the current setup focuses solely on OGC EO Application Packages, another standardized approach for providing reproducible algorithms, OpenEO, should also be considered in future phases of OSPD. terrabyte will continue to work on deploying and operating services for the standardized execution of processes via both OGC API Processes and OpenEO API. The prototype OGC API Processes service deployed within OSPD will serve as a foundation to transition this service into full operations.

A.7.1.  Key features

VEDA Deployment using Kubernetes: A unique instance of the Visualization, Exploration, and Data Analysis (VEDA) platform was deployed using kubernetes. This demonstration is the first test of a full VEDA deployment using kubernetes, and provide a blueprint for users hoping to implement their own instance of VEDA outside of NASA supported instances. Lessons learned were used to improve the source code for VEDA, and documented to encourage others to deploy VEDA in their own cloud environments.

Dashboard: The primary frontend component of the VEDA platform is the Dashboard. We deployed a Dashboard instance that has content relevant to the use cases. This Dashboard visualizes EO data, showcasing the abilities of Analysis-Ready, Cloud-Optimized (ARCO) data, and is accessible from osf.io.

Data Services: We created a unique instance of the data ingestion services and STAC catalog developed on VEDA. We use Airflow to ingest data through an OGC Processes API, and there are OGC-compliant APIs to make the STAC records available to Galaxy. Users are be able to search the STAC catalog via API, through the Galaxy hub. Documentation for these services are available through osf.io.

A.7.2.  Development Roadmap

A.7.3.  Galaxy Integration (Galaxy as a client of my service )

To support OSPD users building workflows using Galaxy, we provide an OGC-compliant API for Galaxy to conduct a simple STAC search on any of the data that has been ingested to match the use cases. This enables users to find comparable ARCO datasets that support their use cases. Through Galaxy, users can provide broad, spatiotemporal search queries, or more precise queries using collection-specific properties such as cloud coverage, or the availability of specific spectral bands. The results will be provided as a GEOJSON “FeatureCollection”.

This workflow is useful and viable because the GeoJSON output fits into Galaxy’s existing understanding of “datasets” and processes. The GeoJSON output can be used as a “dataset”, despite describing dozens or hundreds of matching assets from several collections. Galaxy users can then narrow down and select which assets to include in the rest of their workflow, but this model allows them to continue to do so using this VEDA instance, without leaving the Galaxy environment.

An example of this type of service can be found on VEDA’s STAC. This example STAC is not currently OGC-compliant, but the implementation here will be iterated on to be compliant with OGC processes.

A.7.4.  Open design questions

A.7.5.  SWOT analysis

Strengths

Weaknesses

Opportunities

Threats

A.8.1.  Key features

Use the same code in your notebook: APIBaker allows you to seamlessly transition your notebook code into a fully functional API with just a few clicks. You can select specific code cells or functions from your notebook to expose as API endpoints. This feature ensures that the current workflow developed within a jupyter notebook can be reused without the need for code rewriting or duplication.

Custom domain support: With APIBaker, you can easily configure your API to use your own custom domain name. This adds a professional touch to your API endpoints and provides a branded experience for your users.

Version control integration: APIBaker seamlessly integrates with version control systems (e.g. Git) to manage the evolution of your API. Each time you make changes to your notebook and re-generate the API, APIBaker automatically tracks these changes and prompts you to commit them to your version control repository. This ensures a clear history of all modifications to an individual’s API codebase and enables collaboration with team members.

Token-based security: APIBaker provides robust security features by allowing you to secure your APIs with tokens. When setting up your API, you can generate unique access tokens that users must include in their requests to authenticate and access the endpoints. This token-based authentication mechanism ensures that only authorized users can interact with your API, protecting sensitive data and preventing unauthorized access.
By incorporating these extended features, APIBaker empowers users to create, customize, and secure APIs from their Jupyter notebooks with ease, flexibility, and confidence.

Strengths:

Weaknesses:

Opportunities:

Threats:

A.8.2.  Recent Development Activities

Following client feedback, the team is actively working on APIBaker version 2.1. This version will introduce several enhancements focused on improving workflow efficiency, environment compatibility, and user experience. Planned updates include:

A.8.3.  Prospects for Future Activities

A.8.4.  Open Design Questions

A.9.1.  Key features

User Flow Diagram Development: A significant milestone was the creation of a potential user flow diagram, illustrating how collaborators could utilize OSF’s project and registration services to store and archive research materials. This workflow, critical for enhancing user experience and integration capabilities, was continuously refined to align with grant needs and technical feasibility. We look forward to continuously refining this workflow in year 2.

 

Figure A.11 — User Flow Diagram

 

OSF Registry for OSPD: We successfully established a publicly available OSF Registry for OSPD, designed to facilitate the archiving of research through tailored registration template for platforms in use with geospatial research. This template captures essential information to enable reproducibility and further research, adhering to branding requirements. Additional templates will be created for other objects (ex. services) in year 2. You can find the registry at osf.io/registries/ogccommunity.

A.9.2.  Development Roadmap

CompletedMilestones:

Challenges and Resources:

A.9.3.  Galaxy Integration (Galaxy as a client of my service )

A.9.4.  Open design questions

Addressing Core Design Principles: TThe OSPD pilot leveraged the OSF’s registry service to embody principles of Reusability, Portability, Transparency, and ESG + SDG consciousness. The registration templates were crafted to ensure detailed documentation of research protocols, facilitating reproducibility and adherence to open science practices.

A.9.5.  SWOT analysis

Strengths

Weaknesses * None at this time.

Opportunities

Threats

A.10.1.  Key features

Google Earth Engine (GEE) is a cloud-based platform for planetary-scale environmental data analysis that combines a multi-petabyte catalog of earth observation and geospatial datasets. GEE has powerful computing capabilities to enable scientists, researchers, and developers to detect changes, map trends, and quantify differences on the Earth’s surface. Launched by Google in 2010, this platform provides access to a vast archive of historical and real-time geospatial data, including satellite imagery, climate datasets, and elevation data, among others. By leveraging Google’s cloud infrastructure, Earth Engine facilitates the analysis of large datasets, making it a crucial tool for environmental monitoring, natural resource management, agricultural planning, and climate change research. Its user-friendly interface and extensive API support various applications, from deforestation tracking and water resource management to urban planning and disease spread modeling, significantly contributing to global efforts in sustainability and conservation.

openEO is an open API designed to unify the way geospatial processing and analysis are performed across various cloud-based platforms. It aims to make Earth observation data more accessible and easier to analyze for scientists, researchers, and developers by providing a standardized interface for interacting with large Earth observation data repositories. Through openEO, users can connect to multiple data sources, perform complex analyses, and scale their computations without needing to be experts in the underlying cloud computing technologies. This initiative supports a wide range of pre-defined processes for a wide range of use cases.

The openEO Google Earth Engine driver is a component that implements the openEO API for Google Earth Engine, enabling users to leverage GEE’s Earth observation data and computing capabilities through the openEO standardized API. This driver acts as a bridge, allowing for seamless access to GEE’s vast satellite imagery and geospatial data collections for analysis and processing within the openEO ecosystem. By doing so, it allows to create comparable and reproducible EO workflows.

The key features of the openEO Google Earth Engine (GEE) driver include:

A.10.2.  Tasks completed

A.10.3.  Galaxy Integration (Galaxy as a client of my service)

Not planned for OSPD year 1. Instead an instance of the openEO Web Editor will be deployed (see the corresponding section).

A.10.4.  Design investigations

A.10.5.  SWOT analysis

Strengths

Weaknesses

Opportunities

Threats

A.11.1.  Key features

Institute for Geospatial Understanding through Integrative Discovery Environment (I-GUIDE) is a NSF funded institute that seeks to enable transformative discovery and innovation to tackle fundamental societal challenges by harnessing the large diversity of geospatial data being collected and managed by various organizations. With “geospatial data-on-demand” as its central theme, the I-GUIDE platform [1] enables seamless integration of advanced cyberinfrastructure and cyberGIS capabilities to empower users to undertake computationally reproducible and data-intensive geospatial analytics at scale.
The most relevant feature of the I-GUIDE Platform to OSPD is the CyberGIS-Compute framework [2] which provides transparent access to HPC resources, while enabling users to manage containerized computational models and tools that can be configured and launched on HPC through an interactive interface. The following figure illustrates the architectural components of the CyberGIS-Compute framework.

 

Figure A.12 — The CyberGIS-Compute middleware connects python and jupyter notebook interfaces with diverse cyberinfrastructure back end architectures.

 

CyberGIS-Compute middleware is not tied to a specific HPC backend. It can provide access to any HPC backend given certain configuration requirements. At this time, CyberGIS-Compute allows HPC jobs to be scheduled on following HPC backends

 

Figure A.13 — _Globus provides a facility for the transfer of data between the Galaxy platform and HPC environments.

 

CyberGIS-Compute has an option which allows for interacting with the service from anywhere. In this case, all interactions with the CyberGIS-Compute is managed by an automated agent deployed over CyberGISX. While this can be a good starting point, this approach has serious drawbacks in terms of data management.

A.11.2.  References

[1] I-GUIDE Platform
[2] CyberGIS-Compute
[3] Galaxy-Globus Integration