Explore Projects

OCSMesh is a Python package designed for generating unstructured meshes tailored to ocean modeling. However, its current workflow, particularly the Digital Elevation Model (DEM) processing and JIGSAW mesh generation steps, remains highly time-consuming and not well-optimized for High Performance Computing (HPC) environments. To address this bottleneck, I propose introducing parallelism into the most computationally intensive stages of the workflow: DEM processing and JIGSAW-based meshing. My approach involves leveraging parallel computing libraries such as Dask and mpi4py to scale these operations across multiple cores and nodes. For the preprocessing stage, several components are already optimized for single-node performance and can be extended to work efficiently in an HPC setting. Regarding JIGSAW meshing, I plan to implement a domain decomposition strategy, partitioning the domain into smaller subdomains that can be meshed independently in parallel. These subdomain meshes will then be seamlessly merged to form the final unified mesh. This parallelized workflow is expected to dramatically reduce mesh generation time, enabling more scalable and efficient processing for large-scale ocean modeling tasks. I aim to integrate mpi4py support into the key functions across the codebase, while using Dask specifically for raster windowing and DEM data handling.

NAT64 is a transition mechanism from IPv6 to IPv4. it enables IPv6-only clients to communicate with IPv4-only servers. Despite the growing adoption of IPv6, many legacy systems still rely on IPv4. Implementing NAT64 support in NPF will enhance its networking capabilities, ensuring seamless communication between IPv6 and IPv4 networks. Project Goals: The following are the project goals but not limited to this alone: - Extend NPF to support IPv6-to-IPv4 translation - Optimize NAT64 processing within NPF to ensure minimal latency and efficient packet handling, especially in high-traffic environments. - Passing the information to the kernel, and modifying the kernel packet filter code to process the user/group filtering options and allow/drop packets, in addition to Implementing a robust and efficient NAT64 mechanism within NPF packet filters. Deliverables: With a commitment and devotion of 40 hours per week, the project is expected to be completed within 2 months and some days. Guidance from Mentors, personal research, reference implementations from sample codes or other open-source projects (such as Tayga and Jool) can serve as guides to ensure a standards-compliant solution and project completion. Most importantly, Code reviews from mentors and others will definitely help me to solve problems.

Augur is a Python library, REST server and Flask web application which is used to collect free and open source data and provide meaningful insights around it. The data is collected across various sources like open source repos, mailing lists and other communication systems. Augur uses categorised workers to collect specific data. Currently CHAOSS provides metrics by dividing them into working groups. Few of such metrics are frequency of contributions, types of contributions, time frame between opening and closing a pull request, diversity and inclusion, leadership, efficiency and effectiveness of mentorship programs. This project will play an important role in analysing the open source community health. It provides an efficient way to compute and visualise the metrics through an API. Using this API will provide a more accessible way to understand and visualise various metrics. Deliverables: 1. Create an API for visualising the metrics provided by various machine learning workers and improve their performance. 2. Work on implementing new metrics within the augur machine learning workers and test the performance of newly added metrics with the optimised model to see if the optimised model works for new metrics added. 3. Work on augur_view to provide a customised and accessible dashboard to the user.

Drupal's admin interface is powerful, but finding the right configuration page — especially for newer users or developers who don't work in Drupal daily — often means digging through multiple nested menus with no clear path forward. This project builds a Drupal module called Config Navigator that embeds a lightweight AI-powered chat widget into the admin UI, letting users describe what they want to configure in plain English and get back a direct, permission-filtered link to the right page. The module maintains a structured index of Drupal core admin routes with keywords and synonyms, which gets passed as context to an LLM (OpenAI or Claude) so responses stay accurate and Drupal-specific rather than relying on general model knowledge. A plugin API allows contributed module maintainers to register their own admin routes into the index, making the tool extensible across the whole ecosystem. Privacy is treated as a first-class concern — no site content or user data ever leaves the server, and sites with strict data policies can point the module at a local LLM endpoint instead. Deliverables include the full Drupal module on Drupal.org, a plugin API with documentation, a feedback mechanism, test coverage, and a developer guide.

<p>Running a huge open wifi network that is split into different network areas needs monitoring to assure an appropriate quality of service to it's users. Until now we just monitor our servers to recognize network bottlenecks and failures. But to assure an appropriate quality of service we also need the users view onto the network.</p> <p>The goal of this task is to build a software running on low budget OpenWRT-Routers like WR841ND that acts like a client and regulary gathers status data from the clients view onto the network. Some common tasks of this software would be:</p> <ul> <li>connect the router as client to a wifi network</li> <li>connect the router to a fallback lan network</li> <li>get a list of network segments from Netmon-SC JSON REST API</li> <li>detect which network segment of the open wifi network the router is in</li> <li>get a list of resources to check based on which network segment the router is in</li> <li>check resources</li> <li>send the data that has been gathered to the Netmon-SC JSON REST API</li> </ul> <p>The software should be build as OpenWRT package and should contain a user interface for the Luci web interface</p>

This project aims to improve the scale and navigation inside the Phoenix application which is basically an Angular-based web application written in the ThreeJS library to visualize high-energy physics events in 3D. The application renders a detector that detects the collisions of particles that have been accelerated up to speeds comparable to that of light, along with the event data that consists of tracks, jets, missing energy, etc. after the collision. The problem statement is to improve the visualization of the event, for example, by developing a customizable and interactive cartesian grid functionality, so as to better give the idea of the locations and distances of the particles to the researchers. Also, the user should be able to view the dimensions of the individual detector parts. Apart from this, the users should be able to navigate to the individual detector parts. My plan for the first problem is to introduce a 3D cartesian grid with multiple equally spaced XY, YZ, and ZX planes, as well as, to be able to display the 3D coordinates of a point on clicking. For this, I will make use of the ThreeJS raycaster intersects. Also, I am planning to render the Euclidean distance between any two points clicked. To view the dimensions of the detector, I am planning to render the dimensions of the bounding box of the component. The solution for the second problem would be to list the detector parts and let the user select any one of them, after which it will be highlighted using a ThreeJS outline pass.

<p>As part of our DIAL-funded project to integrate Mifos with the open source Mojaloop payments platform the team from DPC consulting built out a middleware component called the payment hub to enable the integration with the Mojaloop APIs. This middleware will also serve as the point of integration for all other external payment systems - the payment hub is extendable by additional payment connectors. This project would focus on adding the connector for the GSMA Mobile Money API. In 2016 GSMA published a first set of harmonized mobile money APIs to "ensure best practice in API design, security design, and more and to "address the complexity and fragmentation that is apparent in the fast-growing industry.</p> <p>The GSMA Mobile Money APIs are OTT (Over the Top) APIs that have been designed to cater for a core set of mobile money use cases:</p> <p>-Interoperability between mobile money and banks, or among mobile money providers</p> <p>-Merchant payments, online and offline, including delegated authentication of transactions</p> <p>-Bill payments and instant notification of payment</p> <p>-Basic account management</p> <p>-International transfers, including request for quotation</p> <p>-Bulk transactions</p> <p>-Cash in / Cash out</p>

The MIFOS Payment Hub EE (PH-EE) is a microservice-based financial infrastructure requiring high availability, security, and resilience. However, systematic architectural testing—especially under failure and stress conditions—is currently limited. This project introduces an AI-driven testing framework designed to assess and improve PH-EE’s robustness by simulating faults, generating and analyzing synthetic logs, and applying machine learning models to detect anomalies and predict failures. Using tools like OpenTelemetry, Prometheus, Elasticsearch/Kibana, and Isolation Forest/Time-Series models, the framework will monitor service behavior, generate failure scenarios, and highlight weak points in system architecture. It will provide visual dashboards, anomaly tagging, and metrics to guide debugging and resilience improvements. Deliverables include: Architecture mapping and categorization of critical PH-EE components Synthetic log generation simulating realistic failure patterns Integration of AI-based anomaly detection models Dashboards and visualization for observability (Grafana, Kibana) A reproducible proof-of-concept and documentation This project will empower MIFOS developers and adopters with actionable insights to improve system health, scalability, and fault tolerance through intelligent architectural testing

<p>Addition of required Javadoc comments and refactoring variable names, methods and some classes in the <strong>loklakj_lib</strong>​, so that it can be published in the Maven ​repository, <em>MavenCentral</em>. Adding loklak API endpoints that are not currently implemented in <strong>loklakj_lib</strong>. Implementing static methods for generating ​<em>oauth_nonce</em> and ​<em>oauth_signature</em> ​in both <strong>loklakj_lib</strong> and ​<strong>loklak_python_api​</strong>.</p> <p>Replacing Processing.org’s applet with auto-scrolling RecyclerView and ListView in the <strong>loklak_wok_android</strong>​ app and ​<strong>loklak_wok_desktop</strong>​ app respectively. Adding the following features to both apps:</p> <ol> <li>Search tweets using Loklak</li> <li>Post tweet using LoklakWok</li> <li>Push the posted tweet to Loklak server</li> </ol> <p>The GUI library for desktop app will be​ <strong>PyQt5​</strong>. The above listed app features can be implemented for desktop app using <strong>loklak_python_api</strong>. Desktop app will be either a new project (new repo) or the same repository (removing the current code), depends on mentor’s decision.</p>

The Android platform, including its development tools, operates on open-source principles. Debian-derivatives have emerged as preferred platforms for Android developers. Since the release of stretch, Debian has incorporated core Android SDK tools, enabling the creation of certain apps. The Debian Android Tools team is dedicated to integrating the complete Android toolchain and SDK into Debian, facilitating the development of Android apps using exclusively free software packaged in user-friendly formats. Collaborating with the Debian Java team, this initiative addresses common tools like gradle used in Java software development. Recognizing the enormity of packaging the entire Android SDK, the team's focus extends to specific use cases, such as APK analysis tools and simplified setup of standalone components beneficial to non-Android developers, including the Emulator and NDK. Together with projects like Replicant, this endeavor aims to transform Android, the world's most popular operating system, into a fully Free Software platform. The project's deliverables primarily encompass the completion and submission of finalized packages to Debian sid, encompassing both newly created packages and updated ones. Furthermore, efforts will be made to ensure the submission and integration of patches upstream in the Android sources whenever feasible.

Changepoint detection is widely used in modern data streams, but current regression based changepoint methods are limited in flexibility. Existing approaches typically assume that when a changepoint occurs, it affects all regression variables at the same time. This makes it difficult to model realistic scenarios where some components remain fixed while others change. This project aims to develop an open source R package implementing recent work on generalised changepoint regression, where users can specify both fixed and changing regression covariates. The approach builds on existing research level code, which will be refactored into a generic framework function capable of handling a range of regression models, including time series settings. The project will deliver a fully functioning R package with user-facing functions and supporting tools such as summary, print and plotting methods, designed to be consistent with existing changepoint packages. It will also include extensive testing, simulation functions for generating data, and clear documentation, with the goal of producing a CRAN ready package. Should time allow adding mixed effects or non-parametric regression models would be included. Overall, this project will provide a flexible and practical tool that addresses a gap in current changepoint methodology and will be useful for applied users.

<p>Phoenix is a web-based, experiment independent event display framework in JavaScript for visualizing HEP experiment data from multiple experiments. This project focuses on the following improvements to Phoenix.</p> <h5>Improvements</h5> <ul> <li>A more feature rich, control-oriented and intuitive GUI</li> <li>Easier selection of 3D objects and event data (like Tracks, Jets etc.)</li> <li>Keyboard controls for controlling the event display through keys</li> <li>Runge-kutta propagator for using Track parameters to calculate Track positions and decreasing data format size</li> <li>Extension of the current common JSON data format to support more diverse experiments and their event data</li> <li>Support for more CERN experiments like CMS</li> <li>Loaders for loading event data from ".root" and ".ig" files</li> <li>Loading and processing event data from cloud servers</li> <li>Animation of events to simulate the propagation of particles</li> <li>Improvement of VR features</li> <li>Investigating TGeo/GEANT4 geometries and implementing converters to display them in Phoenix</li> <li>Extending unit tests and creating UI tests</li> </ul>

The ZOO-Project is an SDI manager which gives the users the capability of building their own map and web applications using Map server as the Open Geospatial Consortium (OGC) services engine. It is an open-source implementation of the OGC's Web Processing Service (WPS) standard. WPS Interface Standard provides rules for standardizing how inputs and outputs (requests and responses) for geospatial processing services (eg. polygon overlay). WPS also standardizes how a client can request the execution of a process, and how the output from the process is handled. The existing ZOO-Kernel supports C, C++, and JavaScript implementations. With this project, the objective is to have the ZOO-Kernel passing all the tests for WPS 1.0.0 and 2.0.0 OGC ETS. During the GSoC the main focus is on making the WPS 2.0.0 test suite working properly. The async tests are still wrong currently and should be fixed, this will be done during the GSoC. The next and final step will be to get the WPS 1.0.0 test suite working and comprehensive enough to get the Test Suite or the ZOO-Project fixed. Moving from OGC API - Processes - Part 1: Core to WPS 2.0.0. can also be added as second step for the project.

Problem: Installing Julia, opening a terminal, running Julia REPL, then opening the package manager, adding Pluto package, running Pluto, and then going to the browser to run it. How many steps was it? 7. Seems quite uninviting. Now think of a person who has never touched any terminal in his life. Seems like an even more daunting task. A person who is only interested in running a Pluto Notebook and running Julia on it may or may not know how to do any of these steps, and since these can be automated, why keep this task to the end user? My Plan to solve: This is where this app comes in, bundles all these steps, runs this in the background, and then only shows the user their notebook running inside the app itself, no browser required. Deliverable: An Electron app that can perform the following tasks: 1. Install Julia and pluto on the first run. 2. Show the pluto view inside the app. 3. Allow the view to interact with the server. 4. Support the native file system features of Pluto. 5. Support running more than one instance of Pluto views. 6. Support light and dark modes. 7. Be responsive (allow different screen sizes). 8. Show the Julia Package Page inside the app itself to refer to some documentation when and if required. 9. It should also have proper comments and documentation for future reference.

This project aims to build a context-first AI infrastructure to improve how contributors, maintainers, and repositories interact in open-source development. I will design and implement a system consisting of a Skill Bot (for answering contributor queries using repository-specific knowledge), a Skill Updater (to convert maintainer discussions into structured, reusable documentation), and a PR Dashboard (to help maintainers analyze and manage multiple pull requests efficiently). These components will be connected through a shared knowledge layer, ensuring that AI assistance is grounded in real repository context rather than generic responses, while maintaining a human-in-the-loop approach for reliability and control. In parallel, I will work on XOps, a CI/CD-native infrastructure for programmable value transfer in open-source workflows. This involves building a reusable execution engine that enables secure, policy-driven payouts triggered by repository events such as PR merges. The system will support multi-chain execution, configurable policies, and auditable workflows, reducing manual accounting overhead and enabling scalable, transparent contributor reward systems. Together, these systems aim to improve contribution quality, reduce maintainer workload, and introduce a standardized, automation-first approach to both collaboration and value distribution in open source.

Modern sandboxed applications (like Flatpaks) rely on XDG Desktop Portals for essential OS integration, such as screen sharing, opening files, or sending notifications. Tiling window managers often lack a complete and well-maintained xdg-desktop-portal backend, leaving users with a broken experience for many applications. This project will create a working xdg-desktop-portal backend for the Regolith desktop environment. Regolith is a productivity-focused Ubuntu-based desktop environment that combines tiling window managers (Sway, i3) with GNOME components for system management and GUI features. By using xdg-desktop-portal-luminous as a foundation, this project will deliver native portal implementations for complex features like Background and Clipboard, closing a major functionality gap. A key focus of this project is also on upstream contributions. The work will involve implementing the missing Usb portal in the xdg-desktop-portal-gtk backend and helping define and implement a new ScreenCast API version with audio support. This upstream work will directly benefit the entire Linux desktop ecosystem by providing a standard, secure way to capture application audio, a critical feature for apps like Discord and OBS Studio.

<h4>Prombench is the automated E2E testing and benchmarking for Prometheus.</h4> <p>Prombench uses Kubernetes to benchmark Prometheus using various scalable configurations of fake web servers. Prombench uses Prometheus, Grafana and Loki for monitoring difference between versions.</p> <p>Presently Google Kubernetes can only be used for prombench. This creates a scarcity of use of prombench. This problem can be resolved using following :-</p> <ul> <li>Use of another cloud provider like (AWS)Amazon web services</li> </ul> <p>Presently, Grafana Dashboard consist of many useful graphs and useful visualization but there is a scope of improvement. Various issues which aims to improve visualizations for grafana are as follows :-</p> <ul> <li>Refactor the grafana dashboards to show a more consistent memory usage(#324)</li> <li>Revisit all current dashboards to add new and remove unneeded to make them more useful for catching bugs(#186)</li> <li>Node exported does not get filesystem size metrics from SSD path /mnt/disks/ssd0(#159)</li> <li>Add explanations to all panels on the Prombench dashboard(#305)</li> <li>Loki not showing previous test prometheus instance logs(#322)</li> </ul>

This project aims to enhance the BEAD framework for anomaly detection in high-energy physics by developing a new multi-stage architecture that combines a contrastive variational autoencoder (VAE) with a self-supervised transformer and multi-task fine-tuning layers. The key goal is to learn generator-invariant representations from 4-momentum vectors of background events by pretraining the VAE using generator labels (e.g., Pythia, Herwig, Sherpa). The latent variables produced are then masked and enriched with high-level physics features (e.g., MET, HT, Meff) and passed through a transformer trained to reconstruct them, encouraging deeper physics representation learning. The enhanced latent space is decoded using fine-tuning layers that perform multiple tasks simultaneously: reconstructing event-level features, predicting jet properties, and regressing unseen quantities. This structure encourages collaboration between the VAE and transformer components, increasing robustness against spurious correlations and improving anomaly detection performance. Deliverables will include: - A modular implementation of the full architecture within BEAD - Integration with tools like Weights & Biases for experiment tracking - Docker support for reproducibility - Evaluation benchmarks on synthetic datasets - Final documentation and presentation of findings at the CERN ML Forum

The proposal aims to enhance Dubbo-python to meet the evolving needs of the AI sector by addressing compatibility issues, architectural limitations, and functionality gaps. Currently, Dubbo-python faces challenges due to its reliance on Python 2, deprecated libraries, and incomplete RPC communication capabilities, hindering its adoption within mainstream AI frameworks. To tackle these issues, the plan includes: 1. Upgrading Dubbo-python to support Python 3 and modernizing its architecture following the Microkernel + Plugin design principle. 2. Implementing complete RPC communication functionality, including server-side service exposure and client-side service invocation, with support for the new Triple protocol. 3. Developing service governance capabilities such as service discovery, registration, and load balancing, including the design of a GPU metric-based load balancing algorithm to address GPU workload imbalances in AI frameworks. 4. Writing comprehensive test codes to ensure the reliability of each functionality and providing detailed documentation to facilitate easier adoption and contribution to Dubbo-python. By accomplishing these objectives, the aim is to transform Dubbo-python into a robust, high-performance RPC framework compatible with mainstream AI frameworks, thus empowering developers to build scalable and efficient AI systems.

The `loo` package is a widely used R package in the Stan ecosystem which exposes a clean API to cross-validate (CV) Bayesian models. As new CV methods and diagnostics are created and adopted by the field, the `loo` package must be updated to support them. Currently different predictive performance measures have different APIs and varying level of supported features. This project is focused on refactoring the API to unify the support for different predictive measures to make all useful features available for all predictive measures to make it easier for the modellers to use the most appropriate measures for their applications. Key technical components will include creating a flexible object which can report multiple metrics and scores. Additionally, we need to create functions to support model comparisons for all these scores and metrics. We will also allow for measures besides log score for LOO-CV to be used under the same, unified interface as existing options and create a consistent loo object for all measures. We will further unify the interface by allowing for non-log score measures for in-sample, test data, and K-fold-CV use cases. We will also be extending the model comparison functions to carry forward information on what measure is being compared, diagnostic data, and information on how to calculate the standard error (SE) of the differences of various measures.

<p>FreeBSD has an audit subsystem which is responsible for monitoring a variety of security-relevant system events, such as user-logins, configuration changes, file system &amp; network access. Although the audit framework is indispensable for security conscious organizations running FreeBSD servers, currently there is no tool to test its reliability and the intended behavior.</p> <p>The project aims to develop a regression test-suite, which will evaluate the audit framework for proper logging of most auditable system calls classified in TCP/IP &amp; UDP sockets, File I/O, process control and device management, along with the semantics of audit trail's BSM/XML/ text output.</p> <p>BSM tokens can be obtained via synchronous I/O multiplexing on a special clonable device <code>/dev/auditpipe</code>, by configuring various preselection parameters for local mode auditing with the provided IOCTLs. Several <code>libbsm(3)</code> APIs and functions within the FreeBSD kernel can be used to analyze syscall tokens in the audit record. Finally, <code>kyua(7)</code>'s run-time engine will be used to automate regression testing of entire operating system at once, <code>audit(4)</code> included.</p>

<p>The Project includes :</p> <ul> <li>Designing and Implementing the Admin dashboard.</li> <li>Merging Admin and public templates following the WCAG norms.</li> <li>Adding breadcrumbs to navigate back and forth.</li> <li>Removing “Related Actions” &amp; using Admin dashboard, Header menu for navigation to relevant entities, and bootstrap tags/badge at the bottom where it is necessary. </li> <li>Delete modal with entity’s name and denial for delete right if there are other linked entities. </li> <li>Implementing missing UI for nearly all Edit and Add pages via a proposed common unified design.</li> <li>About page.</li> </ul> <p>These improvements will allow administrators to publish and maintain the CDLI’s entities since options are presented hierarchically with keeping the administrators' workflows in mind. Also, the project aims to solve discrepancy problems by merging the templates and enhancing the UX. I have included some designs in my proposal for implementing the above tasks and will incorporate suggestions in design by its actual users at an early stage of GSoC. Once the Front end is done with the existing sass elements to unify UI with existing pages, then I will be checking for any Violations of WCAG using Axe Devtools and will reiterate the front end.</p>

This projects aims to bring the well known ColBERTv2.0 information retrieval system to Julia! In this project, we aim to implement various components of the ColBERT model, with the major focus on indexing and search. Being a late-interaction retrieval system, ColBERT isolates all the computations between the queries and documents to enable pre-computing the document embeddings offline. Combined with a RAG pipeline as an embedding and retrieval backend, ColBERT can make the usage of existing AI tools really powerful. As part of the project, we also aim to apply this model to Julia's own extensive documentation (over thousands of packages), and integrate ColBERT with AIHelpMe.jl and PromptingTools.jl. Combine this with a locally hosted LLM, all Julia users get a powerful, modular, and easily hackable local AI assistant, allowing them to integrate ColBERT with their own RAG pipelines. The main deliverable of the project will be a new package (called ColBERT.jl), with the implementation design inspired from the original Python implementation of ColBERTv2.0 (i.e the centroids + residuals compression method). The project will also have an extensive number of addons, including, but not limited to, implementing the training module for this package, which will allow users to train their own ColBERT models instead of relying on pretrained checkpoints, and distributed training (using existing art like DaggerFlux.jl).