Fetching the latest programs, projects, and workspace data.
Bridging Gap Between Student Work and Successful Open Souce Projects
Showing 4 of 4 projects. Click any project card for scope, mentors, and proposal studio.
Mentors: Student: Ashay Shirwadkar
<p>This proposal will develop object-class methods to transform on-disk Flatbuffer data (row oriented) into Apache Arrow format (col-oriented) in memory, then work toward extending our row-oriented filters and aggregations to column-oriented versions using the Arrow APIs.</p>
Mentors: Student: Mohd Arshul Mansoori
<p>This project will help in scientific research and exploration by automating the repetitive tasks in the research domain. We will create actions that will aid in automating the scientific workflows, like uploading and downloading data-sets, installing software using package managers, running various benchmarks, etc. Also, we will create example workflows for the showcasing of actions that we have created and how anyone can use them in their own workflows. The pipelines from v1.x will be ported to workflows for popper 2.0.</p>
Mentors: Student: Jayjeet Chakraborty
<p>This project focuses on adding various new features to Popper 2.0 like the addition of various runtimes, adding more subcommands, developing a searchable actions library, working on remote workflows and files, report generation, etc. It also focuses on building an Automated Popper Compliance Verification System which would verify that a pipeline is popper compliant.</p>
Mentors: Student: Barbaragd
<p>The current way of interacting with the Popper engine is through the Popper CLI tool. This tool implements all the features of the engine including execution, scaffolding, CI integration, etc. A project that wishes to use the Popper engine has to use the CLI tool. I propose separating Popper into two parts in order to make it easier to use the workflow execution engine in other projects: First a library with all the execution engine itself. Second, a CLI frontend that implements the aforementioned library. With these changes users will be able to extend Popper by creating new ActionRunner and Workflow subclasses. In addition I wish to implement a REANA workflow engine for Popper, this will allow Popper workflows to use all the features REANNA has like kubernetes, workflow specifications, shared storage systems, container technologies, etc. This will also expand the REANA ecosystem and give existing users of the platform another way of defining workflows.</p>