0.51 scipy-2026 2026-07-13 2026-07-19 7 00:05 https://pretalx.com US/Central Intro Tutorial 2026-07-13T08:00:00-05:00 08:00 04:00 Enjoy a gentle introduction to Python for folks who are completely new to it and may not have much experience programming. Learn how to write Python while practicing loops, if’s, functions, and usage of Python’s built-in features in a series of fun, interactive exercises inside Jupyter Notebooks. By the end you’ll be ready to write your own basic Python -- but most importantly, I want you to learn the form and vocabulary of Python so that you can understand Python documentation, interpret code written by others, and get the most out of other SciPy tutorials. Installation Instructions: https://github.com/jiffyclub/scipy-2026-intro-to-python#setup-instructions scipy-2026-93259-introduction-to-python-and-programming-room-hsec-3-110 Tutorials Matt Davis en To make the most of SciPy it helps to have some basic familiarity with the Python language itself. This beginner level tutorial is designed for folks who are brand-new to Python and may not even have much programming experience. I’ll help you get a working Python installation in which you can launch Jupyter Notebooks, a common tool used in scientific research with Python and in SciPy tutorials. Attendees will learn to work with Python variables, the object interface, loops, conditional statements, function definitions, and the use of basic Python data structures through hands-on exercises inside of Jupyter. Students will use the ipythonblocks library to manipulate an image-like grid of colors for immediate, interactive feedback that makes it easy to tell whether code had the intended effect. My goal is for you to leave the tutorial with a basic familiarity with Python (and a working Python installation) that helps you focus on the scientific libraries you’ll learn about in the other tutorials and throughout SciPy. Familiarity with the usage and features of Jupyter will also help you dive headfirst into other tutorials. false https://pretalx.com/scipy-2026/talk/M8AZH8/ https://pretalx.com/scipy-2026/talk/M8AZH8/feedback/ Viz Tutorial 2026-07-13T08:00:00-05:00 08:00 04:00 This tutorial is for anyone who works with data in Python notebooks. [marimo](https://marimo.io) is a reactive notebook that can serve as a personal data environment. Cells run in a deterministic order based on their dependencies, interactivity is built in, and notebooks are self-contained Python scripts you can share, version, and deploy. We start with a tour of marimo: its execution model, interactive elements, SQL, plotting, and sharing. From there, we get practical, composing off-the-shelf UI elements to build interactive tools for your data, then creating your own custom widgets with [anywidget](https://anywidget.dev) when you need something tailored to your workflow. Installation Instructions: https://github.com/manzt/scipy-2026-anywidget scipy-2026-93214-interactive-computing-with-marimo-and-anywidget-room-hsec-2-138 Tutorials Trevor Manz en marimo is a reactive Python notebook. Cells declare dependencies through variable references, and the runtime executes them in a deterministic order. Notebooks are stored as pure Python scripts with inline dependency metadata (PEP 723), so they carry everything needed to reproduce themselves. Prior web experience is not required for most of the tutorial, but familiarity with HTML, CSS, and JavaScript will help in the custom widget sections. The tutorial is split into four sections. **A tour of marimo.** Covers the reactive execution model, cell types (Python, SQL, markdown), plotting (matplotlib, Altair), and built-in UI elements (sliders, dropdowns, tables, interactive charts, dataframe explorers). Shows how elements compose across cells: a dropdown drives a chart, a selection filters a dataframe, a table displays the result. Also covers grouping patterns (arrays, dictionaries, batch, form), layout (tabs, accordion, sidebar, grid), and editor features like the dependency graph, package management, and app view. **Building custom widgets with anywidget.** Sometimes you need a specialized view of your data, a custom visualization to explore a relationship, or an interface tailored to a specific analysis. anywidget lets you build these: you define an ESM module and a Python class, and it handles the communication between Python and the browser. Covers one-way and two-way data bindings, importing third-party JavaScript libraries (D3, Leaflet), and modern JavaScript fundamentals. Each exercise builds on the last. Custom widgets participate in marimo's dataflow graph like any built-in element. **Beyond the notebook.** Covers how to get your work out of the editor and in front of others. marimo notebooks are stored as Python files and can be executed as standalone scripts (e.g., `uv run my_notebook.py`), but also viewed and shared in a variety of ways depending on audience (e.g., interactive web app, exported as a PDF, turned into slides). They can be versioned on GitHub, published as gists, exported as WASM pages, or shared on molab (https://molab.marimo.io), a cloud-hosted workspace for marimo notebooks. **Open exploration.** Q/A, advanced topics (packaging widgets to PyPI, the widget ecosystem), or one-on-one help. Contact us in advance with your project so we can plan accordingly. ### Learning Goals After this tutorial, attendees will be able to: - Work in marimo's reactive execution model - Compose built-in interactive elements across cells - Build custom widgets with anywidget - Share and deploy marimo notebooks in multiple formats ### Prerequisites Attendees should have basic understanding of: - Python: imports, if statements, for loops, function definitions, class definitions, return statements - Python environments: ability to create a new environment for the tutorial - Notebooks: launch a notebook, code in cells, execute code - Python data science libraries: basic knowledge of NumPy arrays and Pandas DataFrames - Web fundamentals (custom widget sections only): basic JavaScript (functions, arrow functions, async) and basic DOM manipulation. No need to be an expert; we cover what you need. ### Outline **Part 1: A tour of marimo (~60 min)** - Reactivity: cells, variables, and the dataflow graph - Cell types: Python, SQL, markdown - Plotting: matplotlib, Altair - UI elements: sliders, dropdowns, number inputs, tables, interactive charts, dataframe explorer - Composing elements across cells: a dropdown drives a chart, a selection filters a dataframe - Grouping patterns: `mo.ui.array`, `mo.ui.dictionary`, `mo.ui.batch`, `mo.ui.form` - Layout: `mo.hstack`, `mo.vstack`, tabs, accordion, sidebar, grid - Editor features: dependency graph, package management, app view - Hands-on: build an interactive data explorer **Part 2: Building custom widgets with anywidget (~60 min)** - Motivation: specialized views, custom visualizations, tailored interfaces - Modern JavaScript fundamentals: ESM, web platform APIs, the DOM - How Python and the browser communicate (widget protocol) - "Hello world" anywidget (one-way data binding) - Counter widget (two-way data binding) - Importing third-party JavaScript libraries (e.g., D3, Leaflet) - Accessing selections, serializing dataframes, sending binary data - Composing custom widgets with built-in elements in the dataflow graph - Hands-on: build a custom widget for a specific data task **Part 3: Beyond the notebook (~30 min)** - Running notebooks headless as scripts - Inline dependencies (PEP 723) and sandboxed execution with `uv` - App mode: serving notebooks as interactive apps with `marimo run` - Exporting: PDFs with rich outputs, slides - Sharing: molab, GitHub gists, WASM standalone pages - Hands-on: export and share a notebook in multiple formats **Part 4: Open exploration (~30 min)** - Packaging and publishing widgets to PyPI - Tour of the anywidget/widget ecosystem - Q/A and one-on-one help with personal projects false https://pretalx.com/scipy-2026/talk/TBVN9E/ https://pretalx.com/scipy-2026/talk/TBVN9E/feedback/ Viz Tutorial 2026-07-13T13:30:00-05:00 13:30 04:00 With everything from microscopes to telescopes to satellites, scientists produce image data in countless formats, shapes, sizes, and dimensions. Python provides a rich ecosystem of libraries to make sense of them. napari is a Python library for multidimensional image visualization, but it does double duty as a standalone application that can be easily extended with GUI tools for analysis, visualization, and annotation. In this tutorial, we'll start with the basics of image visualization and analysis in napari, then show how to extend the napari user interface to make analysis workflows as easy as pushing a button, and finally show how to share these extensions as *plugins*, which can be easily installed by users and collaborators. If you work with images (particularly multidimensional images), and especially if you work with scientists who may not be comfortable with Python, this tutorial might be for you! Installation Instructions: https://napari.org/workshops/extend/setup/ scipy-2026-92514-create-custom-image-visualization-and-analysis-tools-with-napari-room-hsec-2-110 Tutorials Tim MonkoAshley Anderson en Just like we take more pictures of food than we will ever look at, scientists are using powerful microscopes, telescopes, satellites, MRI machines and myriad other sensors to produce more images than they can ever look at. These images come in different file formats, they might be 3D, contain a time-lapse component, many different channels, or other features that increase the complexity of loading them for visualization. Even when specialized viewers provide ways to load these images and look at them, analyzing, interacting with, and visualizing the results of these analyses can still be a challenge. This tutorial is aimed at folks who have some experience in scientific computing with Python. To get the most out of it, you should be familiar with NumPy arrays, Jupyter notebooks, and Python scripts. Ideally, you should have some idea of how images can be represented as arrays of numbers, and the types of analyses that might be performed on these arrays e.g. filtering and segmentation. You don’t necessarily need to be familiar with how these tools and methods work - it’s enough to know that they are out there! The tutorial will be split into three main parts, each around an hour to 75 minutes long. Each part will cover a different aspect of how napari can be used to simplify your analysis workflows, and the workflows of your colleagues and coworkers. **Part 1: Using Python and napari to view and analyze imaging data** In this section we will look at opening and viewing 2D, 3D and even 4D images in napari. We will see how different layer types can help you display your analysis results, how Jupyter notebooks can streamline your image processing, and how napari’s plugins can help you access different analyses through the napari viewer. **Part 2: Customizing your analysis workflow by extending napari’s functionality** We will teach you how to customize your analysis workflow by adding new keybindings and mouse bindings to napari, and adding event handlers that can listen for different layer and viewer events. Finally, we will show you how easy it can be to add your own GUI widgets with minimal code. **Part 3: Distributing your customized functionality with plugins** Once you’re happy with your customized analysis tools, you may want to distribute them to other colleagues and coworkers, or to napari users at large! This section will cover how to package your custom bits of code into pip-installable napari plugins. false https://pretalx.com/scipy-2026/talk/FVRNKP/ https://pretalx.com/scipy-2026/talk/FVRNKP/feedback/ AI/ML Tutorial 2026-07-13T08:00:00-05:00 08:00 04:00 Through the construction of a Deep Research Agent, tutorial participants will learn the fundamental building blocks of LLM-driven applications. Starting with in-context learning and prompt design, we will progress through memory management, tool integration via the Model Context Protocol (MCP), and planning workflows. Participants will build a working agent that can query a Zotero citation library, synthesize literature summaries, and engage in multi-turn research conversations. We will also discuss failure modes, limitations, and the role of such agents in an age of coding assistants. Installation Instructions: https://github.com/ericmjl/build-deep-research-agent/ scipy-2026-92510-building-a-deep-research-agent-room-hsec-3-150 Tutorials Benjamin BatorskyEric Ma en In this tutorial, we will walk you through the practical construction of a Deep Research Agent - an LLM-powered system that can search, summarize, and synthesize scientific literature from a Zotero library. While building agents can seem daunting, breaking it down into core components makes it approachable. We will start with what we think is the most intuitive way to understand agents - seeing them as LLM-backed systems with memory, tools, and planning capabilities. From there, we will show you how to build each component: crafting effective prompts for research tasks, managing conversation state, connecting to external tools via MCP, and implementing both deterministic and ReAct-style planning workflows. Based on our experience building research agents, we've designed a progression that builds a fully functional single agent. We will also demonstrate how specialized agents can collaborate on literature review tasks. Tutorial participants will leave with a working agent and the knowledge to customize it for their own research workflows. This tutorial is structured based on what we wished we knew when we first started building LLM agents, and is ordered for maximum productivity in learning. By the end of the tutorial, participants should be able to build and customize their own research agents! false https://pretalx.com/scipy-2026/talk/BMPMUR/ https://pretalx.com/scipy-2026/talk/BMPMUR/feedback/ AI/ML Tutorial 2026-07-13T13:30:00-05:00 13:30 04:00 Large Language Models (LLMs) are transforming how we build applications, but the path from "cool demo" to "production-ready tool" is littered with challenges: hallucinations, verifiability, and more. This tutorial covers the basics of how to build AI apps that avoid these challenges, yet are still effective and simple to build. We'll start with [**querychat**](https://pypi.org/project/querychat/), an open-source package that lets users explore data through natural language. querychat demonstrates a powerful pattern: rather than letting an LLM access raw data directly (where it can hallucinate calculations), it constrains the LLM to generate SQL queries that are displayed and executed by a proper database engine. This "tool-based" architecture ensures reliability through transparency and precision -- users see exactly what query was executed along with it's exact results. From there, we'll peel back the layers to reveal [**chatlas**](https://pypi.org/project/chatlas/), the foundation powering querychat. chatlas provides a unified, provider-agnostic interface to 19+ LLM providers (OpenAI, Anthropic, Google, local models via Ollama, and more). You'll learn how chatlas makes it trivial to: - Build multi-turn conversations with history management - Stream responses in real-time for responsive UIs - Switch between providers with minimal code changes - Define custom tools that let LLMs interact with external systems (safely) - Extract structured data using Pydantic models By the end of this tutorial, we'll have built two complete apps: a data exploration chatbot (using querychat with your own data) and a custom AI assistant with tools you define. You'll leave with practical patterns for constraining LLM behavior, validating outputs, and building apps that are genuinely useful, maintainable and production ready. Installation Instructions: Go to [dev.workshop.posit.team](dev.workshop.posit.team) and sign in prior to the workshop. This will ensure you can access the provided computing environment for the tutorial. Once logged in, click "New Session", then "Launch". You may see a blank page for a minute before being directed to a hosted [Positron session](https://positron.posit.co/) (https://positron.posit.co/). If you run into issues, or have any questions, please email carson@posit.co. scipy-2026-92304-intro-to-safe-reliable-and-maintainable-ai-apps-in-python-room-hsec-3-150 Tutorials Carson Sievert en false https://pretalx.com/scipy-2026/talk/HFWAYG/ https://pretalx.com/scipy-2026/talk/HFWAYG/feedback/ Accelerated Computing Tutorial 2026-07-13T08:00:00-05:00 08:00 04:00 GPU-powered math libraries are the core of accelerated scientific computing. The nvmath-python package aims to provide intuitive pythonic APIs giving users full access to all features offered by NVIDIA's libraries in a variety of execution spaces. It is your one-stop shop for Pythonic math libraries on the GPU. Installation Instructions: We will provide Nvidia Brev cloud instances. Attendees will only need their laptops and an Internet connection. scipy-2026-90434-accelerated-python-math-libraries-room-hsec-2-110 Tutorials /media/scipy-2026/submissions/SPXK7T/image_8cmmJQF.webp Katrina Riehl en In this hands-on tutorial, we will explore the nvmath-python library, bringing the power of the CUDA-X math libraries to Python. You will learn: - The landscape of CUDA Python libraries - nvmath-python host, device, and distributed APIs - How nvmath-python interoperates with existing array/tensor libraries false https://pretalx.com/scipy-2026/talk/SPXK7T/ https://pretalx.com/scipy-2026/talk/SPXK7T/feedback/ Accelerated Computing Tutorial 2026-07-13T13:30:00-05:00 13:30 04:00 Scientific researchers need reproducible software environments for complex applications that can run across heterogeneous computing platforms. Modern open source tools, like [Pixi](https://pixi.sh/), provide automatic reproducibility solutions for all dependencies while providing a high level interface well suited for researchers. This tutorial will provide a practical introduction to using Pixi to easily create scientific and AI/ML environments that benefit from hardware acceleration, across multiple machines and platforms. The focus will be on CUDA applications, such as machine learning frameworks and use of CUDA Tile, as well as using pixi-build to construct bespoke CUDA enabled conda packages. Installation Instructions: https://matthewfeickert-talks.github.io/reproducible-cuda-workflows-with-pixi-scipy-2026/setup/ scipy-2026-88569-reproducible-cuda-accelerated-workflows-for-scientists-with-pixi-room-hsec-2-138 Tutorials Matthew FeickertRuben ArtsKatrina Riehl en As artificial intelligence (AI) and machine learning (ML) becomes a modern part of the scientific toolkit, the need to have robustly reproducible scientific computing environments that support hardware acceleration, e.g. with CUDA, becomes more important. However, historically just installing a working CUDA environment on a single machine, let alone on multiple platforms with different requirements, could be a difficult task for non-experts. This led to many scientific machine learning workflows being reliably runnable on only particular machines, and, even worse, with environments that were not reproducible across time. With significant recent advancements by the NVIDIA open source team and the conda-forge open source community, the entire CUDA stack &mdash; from compilers to runtime libraries &mdash; is now distributed on conda-forge. This significantly reduces the overhead to _install_ CUDA dependencies, but packaging and distribution of binaries alone does not solve the problem of reproducibility. With automatic multi-platform hash-level lock file support for all dependencies that are available on package indexes (like PyPI and conda-forge), highly efficient solving strategies, and high level user interfaces, Pixi provides a missing piece to the scientific researcher toolkit. With Pixi, researchers are able to easily specify the hardware acceleration requirements they have, multiple different computational environments needed for their experiments, and the required software dependencies, and then quickly solve for a multi-platform lock file of all the dependencies required, down to the compiler level. This makes it possible to have multiple hardware accelerated environments defined that are able to run hardware accelerated workflows across heterogeneous machines with different GPU types and CUDA compatibility. This tutorial will be targeted to scientific researchers who use Python for scientific computing and use hardware accelerated workflows in their research, with a particular focus on AI/ML. No prior expertise with hardware accelerator systems is assumed. The tutorial structure will begin with an introduction to Pixi as a computational environment manager, and explore how it provides features beyond other more common package managers that might be used for Python dependencies. It will then extend to adding CUDA requirements to Pixi environments, and provide participants with exercises for solving environments and running simple AI/ML workflows using the PyTorch machine learning library and the [cuTile Python library](https://docs.nvidia.com/cuda/cutile-python/). The tutorial will then move towards more complex environment requirements in later exercises. The tutorial will conclude with examples and exercises on building bespoke CUDA enabled conda packages with pixi-build. Tutorial participants will code all examples themselves. Participants will also be given time to explore solutions to their own hardware accelerated Python workflows. To make the tutorial more practical and interactive, NVIDIA has agreed to donate cloud GPU resources on the [NVIDIA Brev](https://developer.nvidia.com/brev) platform, which will allow for participants to have CUDA enabled GPU resources to run their own examples on. false https://pretalx.com/scipy-2026/talk/9FQMMN/ https://pretalx.com/scipy-2026/talk/9FQMMN/feedback/ Other Tutorial 2026-07-13T08:00:00-05:00 08:00 04:00 Bridging the gap between new scientific findings and an accessible decision-support tool often requires researchers to either hire a web developer or self-navigate a likely unfamiliar and fragmented landscape of JavaScript frameworks, HTML templating, and CSS. Tethys Platform, a free and open source Python software package, helps bridge that gap by providing a Python-heavy development stack designed specifically for geoscientific and environmental web applications. This tutorial introduces the latest evolution of Tethys Platform: Tethys Component Apps. By integrating ReactPy, Tethys Platform builds on the shoulders of giants to facilitate the development of rich, robust, and reactive user interfaces entirely in Python—eliminating the need for separate scripts and frontend languages. If you have enough Python prowess to write code for your scientific workflows, you can harness it to develop web applications that leverage and showcase these existing workflows. In this hands-on session, participants will learn basic concepts of Reactive, Pythonic component web app development while building a basic, scientific app, step-by-step. These basic concepts include: - Reusable Web Components and UI Design - User Interactions and Event Handling - Application State Management - User Experience (UX) - Integrating 3rd Party Web Component Libraries ## Prerequisites An intermediate knowledge of Python is recommended. Familiarity with basic web development concepts is helpful but not required. Install and deploy a local Tethys Portal using Conda or Pip (see [Tethys Quickstart](https://docs.tethysplatform.org/en/stable/#quick-start)). Time estimate: <10 minutes. Clone and install the Component Playground application ([GitHub clone link]([url](https://github.com/shawncrawley/tethysapp-component_playground.git))) into your local Tethys Portal (see [Development Installation]([url](https://docs.tethysplatform.org/en/stable/recipes/scaffold_an_app_via_command_line.html#development-installation))). Time estimate: <10 minutes. Installation Instructions: https://gist.github.com/mwcraig/1baeeee30055e6deb8b5addc4846b702 scipy-2026-92109-one-language-to-rule-them-all-developing-reactive-scientific-web-apps-in-pure-python-with-tethys-platform-room-hsec-4-103-5 Tutorials /media/scipy-2026/submissions/CLBN3Z/image_N1um6yT.webp Shawn Crawley en false Tethys Platform QuickStart Installation Component Playground App GitHub Repository Tethys Platform GitHub Repository Tethys Platform Official Website https://pretalx.com/scipy-2026/talk/CLBN3Z/ https://pretalx.com/scipy-2026/talk/CLBN3Z/feedback/ Other Tutorial 2026-07-13T13:30:00-05:00 13:30 04:00 This tutorial session is intended to give attendees a gentle introduction to applying causal thinking and inference using python. Causal data analysis is very common in many academic domains (e.g. in social psychology, epidemiology, macroeconomics, public policy research, sociology, and more) as well as in industry (all of the largest Silicon Valley tech companies employ teams of scientists who answer business questions purely with causal inference methods). The tutorial will involve a combination of presentations with open Q&A and hands-on exercises contained in Marimo notebooks. This session will cover the difference between correlation and causation, the pitfalls of conducting an analysis using observational data, how causal inference can help get around these pitfalls, and examples of common, modern modeling approaches using the latest python causal inference frameworks (e.g. DoWhy). After the tutorial, the attendees should have a good foundational understanding of causality and the ability to confidently explore the topic on their own. Causal inference can be a very theory-heavy topic, making it impenetrable to novices. In this tutorial, we'll aim to take a more practical perspective on causal inference, while still occasionally touching on the theory. Tutorial participants are not expected to be familiar with causal inference before attending, but we hope they have an earnest curiosity to learn about it! To get the most out of the session, the participants ought to have experience working with the common python data stack: matplotlib, numpy, pandas, and scikit-learn. Attendees should have some experience conducting classic machine learning modeling using the scikit-learn API, although having advanced machine learning expertise is absolutely not a prerequisite. A very basic understanding of statistics would be helpful (e.g. understanding what a mean is, what confidence intervals represent). Materials and installation instructions can be found here: https://github.com/ronikobrosly/scipy_2026_causal_inference_tutorial scipy-2026-87948-introduction-to-causal-inference-room-hsec-3-110 Tutorials /media/scipy-2026/submissions/GB3N9K/causal_dag_KjBC6yt_LDzMK_0H0EjOK.webp Roni Kobrosly en * Course Introduction (5 minutes) * Introduce myself and course format * Poll: Poll learners’ comfort level with topic so I can fine-tune pacing and descriptions to match. * Outline goals of training session * Two initial examples of causal inference problems (10 minutes): * Hotel bookings and prices * Customers quitting a subscription and receiving a special deal * Introducing causal thinking and causal graphs (60 min) * Counterfactuals * Thinking of counterfactuals as a missing data problem. * Experiments and their limitations * The hierarchy of statistical associations, causal inference, and experiments * Causal inference vs typical ML questions * Causal graphs * Explaining the basics * GROUP EXERCISE: Audience helps me build a causal graph by shouting out answers (car insurance example) * The 3 primary types of causal relationships: * Confounding * Colliding * Mediation * Notebook 1 exercises: Exploring causal graphs and relationships (20 minutes) * Break (20 min) * Causal thinking continued (20 minutes): * A suggested workflow * Assumptions of causal inference (30 min) * GROUP EXERCISE: I talk through 4 bad examples of causal inference work, and audience shouts out the violated assumptions * Causal inference analyses (30 minutes): * Metrics: * A reminder about counterfactuals * Walk through all of the flavors of average treatment effect (ATE) * Interrupted Time Series * Difference in differences * Bayesian structural time series * Propensity Score Matching (PSM) * Talk through how PSM looks when using a dataset * Metalearners (S-learner / G-computation) * Talk through an example * Notebook 2 exercises: Metalearning exercise (20 minutes) * Break (15 min) * Overview of `DoWhy` framework (20 minutes) * Core workflow: Model, Identify, Estimate, Refute * Metalearning and causal root cause analysis * Notebook 3 exercises: Exploring DoWhy (20 minutes) * Explain bonus exercise notebook 4: Bayesian structural time series * Closing remarks (15 minutes) * How to troubleshoot common issues in causal inference analyses. * Returning to the basic causal inference assumptions we discussed before, with a final warning about them. * General Q&A and Wrap Up false https://pretalx.com/scipy-2026/talk/GB3N9K/ https://pretalx.com/scipy-2026/talk/GB3N9K/feedback/ Intro Tutorial 2026-07-14T08:00:00-05:00 08:00 04:00 Installation Instructions: https://github.com/ikrommyd/2026-07-14-scipy2026-tutorial-thinking-in-arrays Please do the setup before the tutorial. Python has become the dominant language in scientific computing, even in domains that demand high performance. This is largely due to the power of array-oriented programming, which separates complex problems into two parts: lightweight bookkeeping and heavy numerical computation. The latter is handled efficiently by vectorized operations that rely on fast, precompiled libraries. This tutorial introduces array-oriented programming as a distinct mindset that encourages new ways of structuring problems. Rather than focusing on any one library, we’ll cover general techniques that apply to any array library with a particular focus on NumPy and JAX. You'll work in groups on some short puzzles and three class projects: Conway's Game of Life using arrays just-in-time (JIT) compilation for the Mandelbrot set, and exploring data in ragged arrays. This tutorial focuses on the thought process: all of the problems are to be solved in an imperative way (for loops) and an array-oriented way. scipy-2026-91917-thinking-in-arrays-room-hsec-2-132 Tutorials Iason KrommydasJim Pivarski en Installation Instructions: https://github.com/ikrommyd/2026-07-14-scipy2026-tutorial-thinking-in-arrays Please do the setup before the tutorial. The tutorial will alternate between short lectures and short exercises for the audience followed by a guided tour through solutions, alternatives, and trade-offs. For exact time slots for each lecture and project, consult the table below. Part 1: Array-Oriented Programming Fundamentals Lecture 1: Introduce array-oriented programming as a paradigm. Compare imperative, functional, and array-oriented styles using simple and complex examples (3-body problem). Demonstrate speed/memory advantages. Work through all 5 NumPy puzzles from the lecture notebook: attendees solve each on their own, then the solution is shown. Project 1: Attendees implement Conway's Game of Life using arrays. Given imperative solution, attendees create a NumPy version that's significantly faster. Stretch goal: discover convolution-based solution. Solutions: Present manual solution, boundary condition handling, and elegant convolution approach with performance comparisons. Part 2: Limitations of Array-Oriented Programming Lecture 2: Discuss disadvantages: (1) intermediate arrays problem (quadratic formula example with timing), (2) "iterate until converged" problem (Newton's method, connection to ML epochs). Lecture only this time — no live project. (Optional homework, not covered live) Project 2: Attendees perform tree-traversal in an array-oriented way, walking all input points down a Scikit-Learn decision tree simultaneously. Solutions present immutable and in-place approaches, comparing performance across Python, NumPy, Numba, and JAX. Part 3: JIT Compilation Lecture 3: Introduce JIT compilation as a solution. Demonstrate Numba (requires imperative code) and JAX (array-oriented but limited by dynamic branching) on the quadratic formula. Project 3: Students accelerate Mandelbrot set computation using Numba and JAX. Compare performance of imperative Python, NumPy, and JIT-compiled versions. Solutions: Show optimized implementations, "Mandelbrot on all accelerators," discuss GPU programming advantages. Part 4: Ragged and Nested Arrays Lecture 4: Present ragged, nested, missing, and heterogeneous data examples. Project 4: Students compute path lengths from Chicago taxi trip data in Parquet format with ragged coordinate arrays. Solutions: Present efficient solution, discuss practical handling of ragged arrays, mention additional resources. Here is a general outline: - 0:00‒0:40 (40 min) Lecture 1: Array-oriented programming and its benefits, including all 5 NumPy puzzles - 0:40‒0:45 (5 min) Break - 0:45‒1:05 (20 min) Project 1: Conway's Game of Life using arrays - 1:05‒1:15 (10 min) Break - 1:15‒1:30 (15 min) Solutions to project 1 - 1:30‒1:50 (20 min) Lecture 2: Disadvantages of array-oriented programming - 1:50‒2:00 (10 min) Break - 2:00‒2:15 (15 min) Lecture 3: JIT-compilation with Numba and JAX - 2:15‒2:35 (20 min) Project 3: JIT-compilation of the Mandelbrot set - 2:35‒2:45 (10 min) Break - 2:45‒3:00 (15 min) Solutions to project 3 - 3:00‒3:15 (15 min) Lecture 4: Ragged and deeply nested arrays - 3:15‒3:35 (20 min) Project 4: Exploring data in ragged arrays - 3:35‒3:45 (10 min) Break - 3:45‒4:00 (15 min) Solutions to project 4 false https://pretalx.com/scipy-2026/talk/GRTY3K/ https://pretalx.com/scipy-2026/talk/GRTY3K/feedback/ Intro Tutorial 2026-07-14T13:30:00-05:00 13:30 04:00 Xarray provides data structures for multi-dimensional labeled arrays and a toolkit for scalable data analysis on large, complex datasets. Many real-world datasets fit this structure. However, a common roadblock for users is knowing how to load the data in Xarray and then how to best use Xarray’s tools to represent the structure of the data. In this hands-on tutorial we will showcase how to work with Xarray, various ways to get real-world data into Xarray (with examples from geosciences and biology) and finally how to easily make complex selections on data using community developed custom indexes. Installation Instructions: https://tutorial.xarray.dev/workshops/scipy2026/index.html scipy-2026-93238-everything-is-an-xarray-dataset-room-hsec-2-138 Tutorials Ian Hunt-IsaakNick HodgskinEniola Awowale en In this hands-on tutorial, users will work with example data from multiple fields of science (including biology and geosciences) to achieve these learning objectives: ### Understand xarray’s core data structures * Named arrays and coordinates (`Variable`) * Groups of arrays with coordinates (`DataArray` and `Dataset`) * Hierarchical trees of related groups (`DataTree`) ### Understand how to load data from different formats as an Xarray object with different access patterns: * VirtualiZarr * Intake * Backend engines - Rioxarray (rasterio) - pyDAP - Zarr * Icechunk ### How to use Xarray [flexible indexes](https://xarray-indexes.readthedocs.io/) to make queries on the data once it is loaded * Forecasts * Tree based indexing * Lazy Out of Memory ## Familiarity This hands-on tutorial assumes participants have some familiarity with Jupyter Notebooks, NumPy, Pandas, and Xarray, and focuses on intermediate workflows using real-world datasets. All material will be presented in curated Jupyter Notebooks with exercises to solidify understanding of key concepts. Tutorial material is available [online](https://tutorial.xarray.dev/) with instructions for running examples on free hosted infrastructure or on a local computer. No specific scientific domain expertise is required to participate effectively in this tutorial. Example datasets will either be small enough to download locally or available as in public cloud buckets. We encourage participants to review last year’s [tutorial](https://tutorial.xarray.dev/workshops/scipy2025/index.html) prior to attending and bring your questions and enthusiasm to make our 4-hour session as interactive as possible! false https://pretalx.com/scipy-2026/talk/XHCZTH/ https://pretalx.com/scipy-2026/talk/XHCZTH/feedback/ Intro Tutorial 2026-07-14T19:00:00-05:00 19:00 04:00 Join fellow SciPy attendees for a casual, self-organized dinner at **The Market at Malcolm Yards** (501 30th Ave SE), a lively food hall with tacos, Asian cuisine, pizza, vegan options, desserts, and beverages, including local craft beer and non-alcoholic options. This is an informal, community-organized meetup. Attendees are responsible for purchasing their own food and drinks. **Schedule** - 6:30 PM: Walk departs from the Graduate Hotel (led by Ed Rogers) - 6:45 PM: Passing the Days Hotel for anyone staying nearby - 7:00 PM: Arrival at Malcolm Yards Food Hall: https://malcolmyards.market/food/ Directions: https://maps.app.goo.gl/z33DMx8QJfkuDKKG6 scipy-2026-103272-evening-social-taco-tuesday-at-the-market-at-malcolm-yards Social Event en false https://pretalx.com/scipy-2026/talk/7GVREJ/ https://pretalx.com/scipy-2026/talk/7GVREJ/feedback/ Viz Tutorial 2026-07-14T08:00:00-05:00 08:00 04:00 Shiny is a framework for building web applications and data dashboards in Python. In this workshop, you will see how the basic building blocks of shiny can be extended to create your own scalable production-ready python applications. In particular, this workshop covers: - Overview of the basic building blocks of a Shiny for Python application - How to refactor applications into shiny modules - How to write tests for your shiny application - Deploy and share your application At the end of this course you will be able to: - Build a Shiny app in Python - Refactor your reactive logic into Shiny Modules - Identify when to write Shiny modules - Write unit tests and end-to-end tests for your shiny application - Deploy and share your application (for free!) Installation Instructions: https://chendaniely.github.io/scipy-2026-shiny/setup.html scipy-2026-92493-shiny-for-python-building-production-ready-dashboards-in-python-pwb-3-152 Tutorials Daniel Chen en Shiny is a framework for building web applications and data dashboards in Python. In this one-day workshop, you will see how the basic building blocks of shiny can be extended to create your own scalable production-ready python applications. In particular, this workshop covers: - 0-50: Overview of the basic building blocks of a Shiny for Python application - How to refactor applications into shiny modules - How to write tests for your shiny application - Deploy and share your application At the end of this course you will be able to: - Build a Shiny app in Python - Refactor your reactive logic into Shiny Modules - Identify when to write Shiny modules - Write unit tests and end-to-end tests for your shiny application - Deploy and share your application (for free!) The workshop will have both a lecture component and hands-on live coding practical component. We will work together to build and understand one of our Shiny for Python's Dashboard Templates: <https://shiny.posit.co/py/templates/> ### Workshop Breakdown: First Hour: Introduction - :00-:20 Overview of the basic building blocks of a Shiny for Python application - :20-:35 Input components - :35-:50 Output components - :50-1:00 break Second Hour: Build a more complex app - 1:00 1:35 A more complex application with multiple input and output components - 1:35-1:50 Introduction to Shiny's reactivity programming model. - 1:50-2:00 Break 3rd Hour: Refactoring your application and Shiny Models - 2:00-2:15 Introduction to shiny modules - 2:15-2:30 Refactor current app into modules - 2:30-2:50 Import your Shiny Modules into the new application - 2:50-3:00 Break 4th Hour: Testing and deployment - 3:00-3:30 Testing your shiny apps with playwright - 3:30-4:00 Deploying your application to the web (for free!) ### Workshop preparation: We will be using Positron in the workshop with the VSCode Shiny extension. You can also use VSCode with the Shiny extension as well. - Positron: <https://positron.posit.co/> - VSCode: <https://code.visualstudio.com/> - Shiny Extension: <https://marketplace.visualstudio.com/items?itemName=Posit.shiny> You will need the following python packages installed. An example `requirements.txt`: ``` faicons shiny shinywidgets plotly pandas ridgeplot ipykernel ``` ### FAQ 1. What if I'm a complete beginner? - You should have a basic understanding of Python and be able to install packages with pip, do basic data manipulation, and draw plots. 2. What if I've never built a Shiny app before? This workshops doesn’t require any Shiny or web application experience. We'll focus more on practical examples in the course. We do have additional resources for you to dive more into more Shiny details, but we will cover the basics needed to build larger and scalable applications. 3. Why should I learn Shiny if I already know Streamlit or Dash? We believe that Shiny is the best framework for building data applications in Python. It’s reactive execution model means that you can build performant applications without explicitly caching data or managing application state. See [this blog post](https://posit.co/blog/why-shiny-for-python/) for more on why we think that Shiny is worth learning. 4. I already know Shiny for R, is this workshop for me? The R and Python Shiny packages are quite similar, so some of the content in this workshop may be familiar to you. That said it’s a great opportunity to fill in missing pieces and ask question about Python best practices. We will also talk about Shiny modules and testing in this workshop, which will also be a precursor for you to learn more or incorporate Python Packaging to your Shiny applications. false https://pretalx.com/scipy-2026/talk/XZLPB3/ https://pretalx.com/scipy-2026/talk/XZLPB3/feedback/ Viz Tutorial 2026-07-14T13:30:00-05:00 13:30 04:00 This tutorial will show you how to use the Pandas, Dask, or Xarray APIs you already know to interactively explore and visualize your data, even if the data is gigabyte or petabyte sized or is in non-columnar scientific formats such as multidimensional arrays, networks, or unstructured grids. As soon as you have something you like, you can then share a live app as HTML+WASM or backed by a live Python server, by simply replacing your expression arguments with widgets so that users can explore it on their own. These tools let you focus on your data rather than the API, and let you build linked, interactive drill-down exploratory apps without having to run a web-technology software development project, which you can then share without becoming an operations specialist. Installation instructions: https://holoviz.org/tutorial/Setup.html scipy-2026-92413-hvplot-and-panel-powerful-data-visualization-exploration-and-apps-room-hsec-4-103-5 Tutorials /media/scipy-2026/submissions/VW3PAF/image_wXfs4Qo.webp James A. Bednar en Python offers many powerful visualization tools (listed on pyviz.org), each with their own strengths and advantages. Few people have the time and interest to learn all the different APIs required to use these different tools, but a de-facto standard API for data plotting has emerged in the Pandas .plot() API, now supported by many different plotting packages. In this tutorial, you will learn how to use hvPlot, a high-level interactive plotting library that exposes the power of Bokeh, Matplotlib, Plotly, Datashader, HoloViews, GeoViews, and Cartopy using the same .plot API you may already know from using Pandas, Dask, or Xarray's plotting interface. We'll also show you how to turn nearly any expression you can write with that API into a web app with plots and tables by simply substituting widgets for any parameters you want users to be able to change, easily creating reactive expression pipelines. Thanks to the HoloViz tools on which hvPlot is built, the resulting apps can easily handle big data (up to billions of rows on an ordinary laptop or petabytes on a distributed cluster), remote data (either in Jupyter or in standalone apps), streaming data, geographical data (building on the geoscience software stack), and multidimensional data (using Xarray). hvPlot's high-level interface should be sufficient for nearly all of the common data-exploration and data-analysis tasks you want to do with Pandas, Dask, or Xarray, but in keeping with the HoloViz philosophy of "shortcuts rather than dead ends", we'll also show you how and when to drop down to lower-level APIs when you need to, such as when building more complex apps using Panel, doing complex graphical data calculations using Datashader, or integrating plotting and interactivity into your own libraries using Param and HoloViews. We'll also provide guidance on how to use AI effectively with the HoloViz ecosystem, including a brief preview of our new Lumen.HoloViz.org tool for natural-languge data exploration along with advice for AI code generation. With the techniques you learn in the hands-on exercises in this tutorial, you'll get the tools and know-how to effectively explore, analyze and visualize simple or complex, small or large, and static or dynamic data easily, concisely, and reproducibly. The resulting visualizations and apps can be shared as static images, simple HTML documents with limited interactivity, HTML+WASM documents with full Python-backed interactivity, or as Python apps deployed on a remote server. We expect participants to have previously used some sort of plotting tool and to be comfortable with Python and at least one array-based Python library (Numpy, Pandas, Xarray, CuPy, cuDF, Dask, etc.). false https://pretalx.com/scipy-2026/talk/VW3PAF/ https://pretalx.com/scipy-2026/talk/VW3PAF/feedback/ AI/ML Tutorial 2026-07-14T08:00:00-05:00 08:00 04:00 Have you ever been frustrated when an LLM generates outdated or deprecated code? It's more common than you'd think. LLMs are trained up to a certain point, but software keeps moving forward. Functions get deprecated, new versions drop, APIs change, old patterns get replaced, and your model has no idea any of it happened. RAG, or Retrieval-Augmented Generation, is the fix. Instead of relying solely on what a model learned during training, RAG lets you supply it with current, curated information at the moment it generates a response. In this 4-hour, hands-on workshop, you'll build a RAG-powered SciPy coding assistant from the ground up. Here's what that looks like in practice: - **RAG Fundamentals**: You'll start by getting familiar with the core ideas behind RAG: what embeddings are (numerical representations of text that capture meaning), how vector similarity works, and how ChromaDB (a lightweight vector database) stores and retrieves that information. - **Building the Knowledge Base**: From there, you'll build the SciPy knowledge base itself. That means scraping SciPy's documentation, chunking it into digestible pieces, and processing it in a way that's aware of code structure, not just plain text. - **Wiring Up the Pipeline**: Once the knowledge base is ready, you'll wire up the full pipeline: querying it intelligently, engineering prompts that produce reliable code, and integrating with both OpenAI and Ollama (a tool for running models locally) so you're not locked into one provider. - **Evaluation and Deployment**: Finally, you'll wrap everything up by evaluating your system using real retrieval and generation metrics, and deploying a Gradio web app, a simple tool for building interactive UIs in Python, so your assistant is actually usable by people who aren't staring at a Jupyter notebook. By the end, you'll have a working SciPy assistant and, more importantly, a solid understanding of every moving part inside it. Installation Instructions: https://github.com/cynthiiaa/scipy-RAG#quick-start scipy-2026-92198-build-a-scipy-coding-assistant-with-rag-room-hsec-3-110 Tutorials /media/scipy-2026/submissions/KHQ3EK/image_CuMK08X.webp Cynthia Ukawu en Have you ever been frustrated when an LLM generates outdated or deprecated code? It's more common than you'd think. LLMs are trained up to a certain point, but software keeps moving forward. Functions get deprecated, new versions drop, APIs change, old patterns get replaced, and your model has no idea any of it happened. So how do you generate reliable code that reflects current patterns and practices? That's where RAG comes in. RAG, or Retrieval-Augmented Generation, is a technique that updates what your LLM "knows" at query time by pulling in fresh, relevant context from a knowledge base you control. In this workshop, you'll build a RAG-powered SciPy coding assistant from the ground up. That means scraping and processing SciPy documentation, embedding it into a vector database with ChromaDB, and wiring up a generation pipeline that pulls the right context before producing code. By the end, you'll have a working Gradio web app and a solid understanding of every moving part inside it. false https://pretalx.com/scipy-2026/talk/KHQ3EK/ https://pretalx.com/scipy-2026/talk/KHQ3EK/feedback/ AI/ML Tutorial 2026-07-14T13:30:00-05:00 13:30 04:00 The quality of the retrieval component is what drives Retrieval-Augmented Generation (RAG) systems. Therefore, a well-structured, measurable, and robust retrieval pipeline is critical to building effective large language model (LLM) applications. Working through guided code examples and hands-on experimentation, attendees will collectively develop, optimize, and enhance the performance of a complete RAG pipeline by improving retrieval in three stages: _Pre-Retrieval_, _Mid-Retrieval_, and _Post-Retrieval_. We will also cover structured and multimodal document parsing with _Docling_, systematic evaluation with _RAGAS_, and a capstone _Agentic RAG_ demo using _LangGraph_. The toolkit integrates _Qdrant_ for vector search and the _LangChain_ ecosystem for orchestration and experimentation. During the hands-on session, attendees will use Jupyter notebooks to learn about, experiment with, and benchmark techniques that produce significant improvements to retrieval quality using production-ready open-source libraries. At the end of the session, each participant will be equipped with a reusable _“Retrieval Playground”_ framework that can be leveraged to design, evaluate, and continuously improve RAG systems across various application domains. Installation Instructions: https://github.com/mahimaarora/retrieval-playground/tree/main/setup-guides scipy-2026-92299-engineering-better-retrieval-for-rag-room-hsec-3-110 Tutorials Mahima AroraAarti Jha en Retrieval is the foundation of modern LLM applications in science, engineering, and industry. However, most RAG implementations rely on naive chunking and basic vector similarity search, leading to brittle systems, hallucinations, and poor performance on structured and multimodal data. This tutorial provides a **structured, engineering-focused approach to optimizing retrieval pipelines** using a practical framework, a modular Python toolkit for experimentation, benchmarking, and evaluation. Participants will iteratively build a RAG pipeline and improve it across three stages: 1. **Pre-Retrieval Optimization** - Preparing data and queries correctly 2. **Mid-Retrieval Optimization** - Improving search quality and diversity 3. **Post-Retrieval Optimization** - Filtering, refining, compressing, and assembling context before generation We will also cover **structured and multimodal parsing for RAG** with Docling, including: - Typed text, table, and image chunks from PDFs - Hybrid Docling chunking alongside baseline, recursive, parent-child, and contextual strategies - Multimodal-aware metadata for richer retrieval (without separate SQL or ad-hoc query pipelines) The tutorial is designed for active coding, experimentation, and measurable benchmarking. More than 70% of the session is hands-on coding in Jupyter notebooks. Attendees will implement techniques step-by-step and evaluate performance improvements live. #### Detailed Outline (4 Hours Total) ##### Part 1: Foundations - Lecture + Guided Setup (40 minutes) - Introduction to Retrieval in RAG Systems - Why retrieval fails in real-world systems - The three-stage optimization framework - Overview of the Retrieval Playground toolkit and notebook flow (1A → 5) - Evaluation overview: retrieval, generation, and tool/agent metrics (RAGAS + custom) - Dataset introduction ##### Part 2: Pre-Retrieval Optimization - Hands-On Notebook (50 minutes) 1. Document Chunking - Recursive chunking - Contextual - Parent-child - Docling-based structured and multimodal chunking (text, tables, images) 2. Query Enhancement - Query expansion - Multi-query / RAG Fusion - Query decomposition - Query rewriting - Step-back prompting - Complexity classification and auto-orchestration 3. Semantic routing ##### Part 3: Mid-Retrieval Optimization - Hands-On Notebook (60 minutes) - Dense Search - Hybrid Search - Reranking - Parent-Child Retrieval - Multi-Query Hybrid - Route-Driven Retrieval - Adaptive Retrieval Interval: 15 minutes ##### Part 4: Post-Retrieval, Evaluation & Agentic RAG - Hands-On Notebook (60 minutes) 1. Post-Retrieval Context Preparation - Retrieval grading (relevant / irrelevant / ambiguous) - Knowledge refinement (sentence- or passage-level tightening) - Context compression (extractive and abstractive) - Document assembly (stuff chain for final generation) 2. Systematic Evaluation - Classical retrieval checks (hit rate@k, MRR, keyword overlap) - RAGAS context precision/recall, faithfulness and answer accuracy - Tool-selection metrics from routing and agent traces - Baseline vs post-retrieval A/B comparison and pipeline scorecard 3. Agentic RAG Capstone (intro + demo) - LangGraph ReAct agent with a retrieval tool backed by the workshop RAG stack - Prompt-based routing (direct answers vs retrieval) - Lightweight tool-selection evaluation ##### Final 15 Minutes: Wrap-Up, Future Directions and Q&A - Best practices and limitations - Production considerations and scaling strategies - Open discussion and troubleshooting _Expected Level: Beginner to intermediate._ _Target Audience: ML engineers, data scientists, developers working with LLMs in production, and anyone looking to learn how to build robust AI workflows using open source tools._ false https://pretalx.com/scipy-2026/talk/NWPPHA/ https://pretalx.com/scipy-2026/talk/NWPPHA/feedback/ Accelerated Computing Tutorial 2026-07-14T08:00:00-05:00 08:00 04:00 As GPU acceleration becomes essential for scaling Python workloads, many developers face new challenges: understanding installation, managing dependencies, and deploying GPU-enabled environments. Even experienced Python users can struggle to integrate GPUs effectively or troubleshoot performance issues. This tutorial addresses those barriers by walking participants step-by-step through the process of getting started with GPUs. Using NVIDIA’s RAPIDS ecosystem and familiar python tools, we’ll demonstrate how to set up, monitor, optimize and debug GPU-powered workflows—turning what often feels like complex infrastructure work into an approachable, reproducible process. Installation Instructions: https://developer.nvidia.com/nsight-systems/get-started scipy-2026-92294-deploying-and-debugging-gpu-accelerated-python-workloads-room-hsec-2-110 Tutorials Naty ClementiJacob TomlinsonJaya Venkatesh en Leveraging GPU acceleration is now a common necessity for scaling Python projects. NVIDIA GPUs offer unmatched speed and efficiency for data processing and model training, significantly reducing the time and cost associated with these tasks. GPU acceleration is already baked into many projects, or available via plugins. You can use PyData libraries including pandas, polars and networkx without needing to rewrite your code to get the benefits of GPU acceleration. However, integrating GPUs into our workflow can be a new challenge where we need to learn about installation, dependency management, and deployment in the Python ecosystem. When writing code, we also need to monitor performance, leverage hardware effectively, and debug when things go wrong. This is where RAPIDS and its tooling ecosystem comes to the rescue. RAPIDS, is a collection of open source software libraries to execute end-to-end data pipelines on NVIDIA GPUs using familiar PyData APIs. RAPIDS libraries give users access to GPU acceleration, reducing execution time and cost, but without needing to learn a whole new set of tools. In this tutorial we will cover: - A high level overview of popular Python libraries that have GPU acceleration - Answers to questions like: “Where do I get a GPU?”, “How do I run a container on a VM with a GPU?”, “How do I install GPU packages into an existing environment?”, “What if I use uv pip?”, “What about conda? ”as well as follow along examples to get a GPU up and running. - The GPU software stack from driver to Python and everything in between - Troubleshooting and monitoring: Examples of performance analysis, diagnostics, and debugging. Showcasing of diagnostic tools like nvdashboard, nvtop, nsys, pynvml, etc. #### Audience This is a hands-on tutorial, participants should ideally have some experience using Python, pandas and sci-kit learn. We'll use cloud-based VMs, so familiarity with the cloud and resource creation is helpful but not required. No prior GPU knowledge is needed. To maximize the tutorial's relevance, we will provide participants with the opportunity to submit their specific environment configurations ahead of time. Submissions received with adequate notice (between tutorial acceptance and conference date) will be integrated into the tutorial examples, allowing participants to see their real-world use cases addressed. **Key takeaways for participants will be:** - An understanding of the GPU Python software stack from driver through core libraries to high-level Python libraries - How they can use their preferring tooling and package managers to install all the components they need - How to monitor their GPUs and understand how well they are using their hardware - How to attach debuggers to their GPU code or record traces and profiles for debugging later false https://pretalx.com/scipy-2026/talk/XSWVVE/ https://pretalx.com/scipy-2026/talk/XSWVVE/feedback/ Accelerated Computing Tutorial 2026-07-14T13:30:00-05:00 13:30 04:00 This tutorial demonstrates how to accelerate agent-based simulations using modern Python tools. Using Thomas Schelling's classic segregation model as a running example, participants will learn to transform readable but slow Python code into high-performance implementations using NumPy and JAX. The tutorial explores how mild individual preferences can lead to extreme aggregate outcomes through simulation, while teaching practical techniques for leveraging modern hardware (including GPUs) to make realistic large-scale simulations computationally feasible. Participants will gain hands-on experience with performance optimization strategies applicable to economic modeling, urban planning, epidemiology, and other domains requiring large-scale agent-based simulations. Installation Instructions: https://github.com/QuantEcon/scipy_tutorial_2026 scipy-2026-92408-computational-methods-for-simulation-using-jax-and-numpy-room-hsec-2-110 Tutorials Smit Lunagariya en Simulation is a critical methodology for policy analysis across economics, public health, urban planning, and environmental science. Examples include DSGE models for monetary policy, pension reform analysis, climate policy evaluation, and agent-based urban models. However, realistic simulations often require tracking thousands or millions of agents over many time periods, making computational efficiency essential. This tutorial addresses the computational challenges of simulation through a concrete, historically significant example: Thomas Schelling's 1969 segregation model, which earned him the 2005 Nobel Prize in Economic Sciences. The model demonstrates a surprising result: extreme residential segregation can emerge even when individuals have only mild preferences for same-type neighbors. This finding has profound implications for understanding persistent urban segregation patterns observed in American cities. We begin with an intuitive object-oriented Python implementation that prioritizes readability, then systematically optimize performance through: 1. Array-based computing with NumPy 2. Just-in-time compilation and GPU acceleration with JAX 3. Parallelization strategies for modern hardware Through live coding demonstrations and hands-on exercises, participants will transform a slow baseline implementation (taking minutes) into a highly optimized version (running in seconds) capable of simulating realistic urban scenarios with tens of thousands of agents. The tutorial emphasizes transferable skills, and the optimization patterns learned apply broadly to agent-based models in computational science. The tutorial also explores the substantive implications of the model, connecting computational results to real-world segregation patterns and policy questions. Participants will see how computational tools enable researchers to test hypotheses about social dynamics that would be impossible to study analytically. false https://pretalx.com/scipy-2026/talk/RQQDGA/ https://pretalx.com/scipy-2026/talk/RQQDGA/feedback/ Other Tutorial 2026-07-14T08:00:00-05:00 08:00 04:00 Through the use of NetworkX's API, tutorial participants will learn about the basics of graph theory and its use in applied network science. Starting with a computationally-oriented definition of a graph and its associated methods, we will progress through the following concepts: path and structure finding, visualization, and graph storage on disk. We will also offer tutorial participants the option of one advanced topic overview, including the use of graphs alongside LLMs for knowledge retrieval, scalable alternatives to NetworkX including cuGraph, and the use of linear algebraic translation of graph problems to speed up computations. Installation Instructions: https://github.com/ericmjl/Network-Analysis-Made-Simple/ scipy-2026-93111-network-analysis-made-simple-hsec-4-103-5 Tutorials Eric Ma en In this tutorial, we will walk you through what we consider the most practical aspects of graph theory using NetworkX. While graph theory can seem abstract at first, having a computational framework like NetworkX makes it much more approachable. We will start with what we think is the most intuitive way to understand graphs - seeing them as computational objects we can manipulate with code. From there, we will show you how we approach common tasks like finding paths between nodes, analyzing graph structure, and creating visualizations that actually make sense. We will also cover how to store and read graphs to/from disk. Based on our experience working with graphs, we've selected three cutting-edge topics that we think are worth exploring: using graphs with LLMs for knowledge retrieval, scaling up to larger datasets with cuGraph and linear algebra, or an introduction to the use of graphs in deep learning. Tutorial participants will get to choose one of these topics live. This tutorial is structured based on what we wished we knew when we first started working with graphs, and is structured in the order that we believe to be most productive for learning. By the end of the tutorial, participants should be able to productively prototype with graphs immediately! false https://pretalx.com/scipy-2026/talk/VNQPKP/ https://pretalx.com/scipy-2026/talk/VNQPKP/feedback/ Other Tutorial 2026-07-14T13:30:00-05:00 13:30 04:00 Remote Sensing has proved to be an important tool in monitoring our earth's ecosystem. Satellite imaging is a vital part of Remote Sensing. Predominantly, Satellite Imaging of the earth has been done in the optical domain and optical Images serve the majority of purpose for earth monitoring. But, these satellites do not have all-weather acquisition capability and this lacuna is filled by the satellite sensors working in the Microwave domain of the Electromagnetic spectrum. Synthetic Aperture Radar(SAR) is an Imaging Radar that acquires images of a particular area on Earth in the microwave region of electro-magnetic spectrum. This workshop deals with the processing of SAR Images and how these images can be beneficial in a variety of geographical applications. Installation Instructions: Participants should use a computer or cloud compute with at least 16GB of memory. Downloads of approximately 1-2GB will be needed during the tutorial. scipy-2026-91953-microwave-image-processing-exploring-realms-of-earth-through-spaceborne-radars-using-python-room-pwb-3-152 Tutorials Shubham Sharma en Intended Audience : The workshop will be aimed at the audience belonging to any level of education. It will introduce them to the wonderful class of SAR images and how are these images useful from the perspective of various applications. Expected Outcomes (after the workshop, the audience will be) : i) Able to understand the acquisition of SAR imagery. ii) Able to understand the types of datasets utilized in remote sensing iii) Able to use the GDAL library to perform operations on images iv) Able to efficiently process SAR imagery using Python v) Able to draw a roadmap in order to utilize SAR imagery for various geographic applications Outline The workshop will be divided into the following sub-sessions : Sub-Session-1: Introduction to Microwave Remote Sensing (1.5 hrs) - This part will discuss the foundations of Microwave Remote Sensing. Theoretical aspects regarding the acquisition of images, the formation of images encompassing the generation of complex images and ground range detected images will be discussed. This session will also cover key topics such as basic utilization of GDAL, Numpy and Matplotlib Libraries for opening and visualizing Images which will cover developing basic codes for plotting, visualizing and understanding the imagery data. Sub-Session-2: Pythonic Way to SAR Image Processing (2.5 hrs): This part will focus on achieving the following Key points: 1) Codes will be developed separately for calibration for each SAR sensor(esp. Sentinel-1, Radarsat-2) from scratch.(1.5 hrs) 2) Utilization of the codes developed in (1) for various applications such as Oceanography, Forestry, etc.(1 hr) Datasets: Free Imagery data sets of Sentinel-1 SAR will be utilized. Also, free sample datasets available for different SAR earth observation sensors will be utilised. In addition, sample datasets of Radarsat-2, RISAT- 1 which are freely downloadable will be utilized. The sample datasets will be provided. For better understanding of the datasets, the participants may download and utilize the Sentinel-1 SAR free Image dataset initially .Sentinel-1 Free SAR Imagery (https://www.copernicus.eu/en) Conduct of the workshop : The workshop will be conducted through the means of Jupyter Notebooks. Along with the sessions, the audience will be provided with the exercises to clear their concepts of SAR Imagery. Total Duration The duration of the workshop will be 4 hours. false https://pretalx.com/scipy-2026/talk/B8S8PH/ https://pretalx.com/scipy-2026/talk/B8S8PH/feedback/ Memorial Hall Keynote 2026-07-15T09:15:00-05:00 09:15 00:45 Matplotlib Project Lead and Computational Scientist at Brookhaven National Laboratory scipy-2026-97802-opening-keynote-thomas-caswell-stories-in-code Keynotes en Stories are a core to the human experience and core to our understanding of complex technical systems. This talk will discuss the role that stories play in software in general and open source specifically. The stories we collectively write and share, in the form of code, are the concrete artifacts we create. How we go about organizing the development of these stories and the relationships between people are the spirit of SciPy. false https://pretalx.com/scipy-2026/talk/ZFNUEG/ https://pretalx.com/scipy-2026/talk/ZFNUEG/feedback/ Memorial Hall Tools Plenary 2026-07-15T10:00:00-05:00 10:00 00:25 A session featuring updates and roadmaps from maintainers of core Scientific Python libraries and tools. scipy-2026-97804-scipy-tools-plenary SciPy Tools en false https://pretalx.com/scipy-2026/talk/YZU7X8/ https://pretalx.com/scipy-2026/talk/YZU7X8/feedback/ Memorial Hall Talk 2026-07-15T10:45:00-05:00 10:45 00:30 In 2004, Matthew Brett asked me a provocative question born of frustration with existing fMRI tools: "Why don't we rewrite them in Python?" That question led to a 2005 meeting that brought together a small group of core Scientific Python tool builders from astronomy, neuroscience, physics, and statistics, and then to a series of follow-up meetings alternating between Berkeley, Enthought's offices, and other locations. This talk traces how that ground-up, cross-disciplinary collaboration helped turn SciPy from a workshop curiosity into the backbone of today's ecosystem, and how the same people and patterns later shaped the Scientific Python project. scipy-2026-93254-one-problem-many-projects-how-scientific-needs-built-an-ecosystem Spirit of SciPy Jarrod Millman en This talk tells the story of Scientific Python's growth through the lens of one institution and one fateful question. It follows how a small, domain-driven collaboration at UC Berkeley helped catalyze tools, practices, and organizations that now define the Scientific Python ecosystem, and how SciPy and its conferences became a shared planning space that later informed cross-project efforts like the Scientific Python project. I begin in 2000--2004, when I joined UC Berkeley's Brain Imaging Center at a time when Python was only starting to be used seriously for numerical work. SciPy 0.1 had just been released, the first SciPy workshop at Caltech in 2002 drew only a few dozen scientists, and our neuroimaging work was dominated by large, opaque lab-owned research software. My colleague Matthew Brett and I wanted to build something better for fMRI analysis in Python, a goal that quickly pulled us into broader discussions about the future of Numeric, numarray, and SciPy's architecture. Those conversations ultimately matured into the Neuroimaging in Python (NIPY) project and a series of tools and publications that showed what it meant in practice to build domain-specific software on top of a young ecosystem---where we could lean on NumPy, SciPy, and matplotlib as they were, and where we had to contribute upstream to make the work possible. The core of the talk focuses on the 2005--2007 period. A 2005 meeting at Berkeley brought together John Hunter (matplotlib), Fernando Perez (IPython), Travis Oliphant (then developing what became NumPy), Perry Greenfield (numarray/STScI), and others to sketch out concrete plans to unify on a single array core, refactor SciPy around that core, and treat SciPy as the base of a larger ecosystem rather than a monolithic library. Out of those conversations, and the broader discussions they sparked in the early developer community, came the decision to converge on NumPy, to split SciPy's functionality into a "core" plus separately maintained domain packages, and to prioritize packaging and installation so that scientists could actually adopt these tools. I will describe how this initial gathering turned into a series of small follow-up meetings---alternating between Berkeley, Enthought's offices in Austin, and other locations---that refined these ideas and effectively set the development roadmap for NumPy, SciPy, and the emerging Scientific Python ecosystem. The third act zooms out to the conference and community layer. Beginning in 2007, I served as release manager for NumPy and SciPy and later chaired the SciPy conference (2008--2011) and edited its proceedings (2008--2013) as it evolved from a small workshop into an international venue with peer-reviewed papers. During that time, we also built the pre-Curvenote proceedings machinery, an early example of shared documentation and publishing infrastructure that supported reproducible research across projects. I will connect those roles to the founding of NumFOCUS in 2012, formalizing community infrastructure that had grown out of the same set of collaborations. Finally, I bring the story to the recent past. At Berkeley's Institute for Data Science we helped launch the Scientific Python project, including SPECs, cross-project tooling, and the Scientific Python developer summits, explicitly aiming to recreate the collaborative atmosphere of the early SciPy workshops in a modern, multi-project setting. The Berkeley Open Source Program Office now helps sustain this kind of cross-lab, cross-institution collaboration as part of the university's regular activity rather than a one-off effort. Throughout, the intended audience is broadly the SciPy community: developers, researchers, and practitioners who use the ecosystem daily. Attendees will learn: - How one domain-specific frustration (fMRI analysis software) helped catalyze cross-project collaboration at a critical moment for scientific Python. - How small, in-person meetings and local institutional support can have long-term ecosystem impact, from the first SciPy workshop through Enthought and INRIA to the Scientific Python developer summits. - How Berkeley's roles---as an early scientific user, as SciPy conference chair and editor, and now as a home for the Scientific Python project---fit into the larger history of Scientific Python. false https://pretalx.com/scipy-2026/talk/YUVEYH/ https://pretalx.com/scipy-2026/talk/YUVEYH/feedback/ Memorial Hall Talk 2026-07-15T11:25:00-05:00 11:25 00:30 If you messed around with Python's command line options or read the official documentation, you might wonder what the -Xgil option or the PYTHON_GIL environment variable did to your scripts, and whether setting either affects performance. The hubbub on popular wheels such as pyo3, python-zstandard, numpy, uv, cffi, and cython supporting the free-threaded interpreter is no passing fad either. For Pythonistas that don't read PEPs in their spare time or contribute to the cpython project itself, an adventure that delves into a less known, yet jaw-dropping aspect of Python awaits! Python's Global Interpreter Lock, which determines which single thread can execute native Python code and call C API functions, simplifies writing multithreaded code. However, sticking with this execution model leaves out extra performance afforded by modern multicore CPUs with hyperthreading, as automatic locking and unlocking of the GIL does not scale well with thread counts, especially in performance-sensitive workloads. The newfangled free-threaded interpreter promises salvation when running either pure Python code or with compiled extensions. General multithreading rules apply (prefer thread-local variables, using locks to prevent simultaneous access of shared data), but when dealing with projects containing compiled extensions that directly or indirectly interface with Python's C API, more porting rules also apply. Key porting tips, including projects using the Limited API, include: port native code away from C API functions that avoid borrowed references because they aren't thread-safe; modify unit tests to catch concurrency bugs arising from assuming the presence of the GIL; and extend CI coverage of Python interpreters both for testing and to build free-threaded compatible wheels. Outline: * Introduction (2-3 min.) * What is the -Xgil option? * What is the GIL? * What is the free-threaded interpreter? (6-8 min.) * Global Interpreter Lock: downsides of automatic serialization of parallel workloads * How to try out the free-threaded interpreter * Increased parallelism with the no-GIL interpreter with multi-core CPUs * Porting tips (15-18 min) * Adding a trove classifier in pyproject.toml * Marking your extension module as supporting no-GIL * Limited API (and PEP 803) * Bumping key dependencies, including FFI wheels * Using locks, mutexes, and atomics in native code to prevent concurrency bugs * Including pytest-run-parallel to catch threading bugs * Closing Remarks (2 min.) * Q&A (2 min.) scipy-2026-90436-tying-up-loose-threads-making-your-project-no-gil-ready General Charlie Lin en false https://pretalx.com/scipy-2026/talk/HBZ9RC/ https://pretalx.com/scipy-2026/talk/HBZ9RC/feedback/ Memorial Hall Talk 2026-07-15T13:15:00-05:00 13:15 00:30 Field inspections in agriculture and science face a common problem: hands are full, data needs structure, and decisions require both inspection history and domain expertise. I built HiveGuide, an open-source field inspection system with three main components: (1) voice transcription for hands-free data entry, (2) AI extraction to structured data and action items, and (3) an AI assistant that provides intelligent advice by routing between personal inspection history and authoritative domain literature. For the assistant, I tested 7 routing strategies on 500+ queries to solve a dual-source problem: when to query your data versus domain references. The LLM classifier approach balanced accuracy and speed without requiring training data. The architecture is transferable to any inspection domain where you need minimal device interaction and intelligent advising. scipy-2026-88933-ai-powered-field-inspection-voice-capture-data-extraction-and-intelligent-multi-source-routing Data-Driven Discovery, Machine Learning and Artificial Intelligence Carolyn Olsen en ## Background Field work across agriculture, environmental monitoring, and scientific research shares common constraints: practitioners need structured data capture while their hands are occupied, dirty, or gloved. Current solutions—voice memos, note apps, or digitized forms—produce unstructured data that's difficult to query or analyze. More critically, field decisions require combining two distinct knowledge sources: personal inspection history ("what's normal for my sites?") and authoritative domain knowledge ("what do experts recommend?"). Generic AI assistants can't access your data; domain-specific apps don't leverage expert knowledge. I developed HiveGuide to solve this for beekeeping inspections, where you're holding frames with thousands of stinging insects while wearing propolis-covered gloves. The architecture proved generalizable to any inspection workflow requiring minimal interaction, structured capture, and intelligent advising. ## Methods The system is built on a Python FastAPI backend with PostgreSQL database, using LangChain for the RAG architecture and OpenAI APIs for transcription and language models. The frontend is React Native (iOS) and React Native Web, with the Python backend handling all AI/ML processing. The system has three components: 1. _Voice Transcription:_ Real-time streaming transcription (2-second delay) via iOS native app. Audio sent to server in chunks every few seconds, minimizing data loss risk compared to batch processing. Platform choice (native vs web) drove capability—web apps can't achieve this latency or reliability. 2. _AI Extraction:_ LLM converts voice notes to structured fields. Example: "It's in the 60s and cloudy. Fresh eggs in good pattern, didn't spot the queen" extracts temperature, queen_visible: False, eggs_visible: True, laying_pattern: "solid". Structured data enables querying and generates automated action items based on inspection findings. 3. _AI Assistant with Intelligent Routing_: This solved the core technical problem. Field inspection questions require either personal data ("Is my hive at normal weight?"), domain knowledge ("What causes bee dysentery?"), or both ("Is my hive's October weight normal for Wisconsin?"). I implemented 7 routing approaches: - LLM classifier (pre-classifies query intent) - Heuristic rules (keyword matching) - Embedding similarity (query vector vs source vectors) - Supervised classifier (trained on labeled queries) - Agent-based (agent decides tool usage) - Hybrid combinations - Always-both baseline Each routed to SQL database (inspection history) and/or vector search with pgvector (RAG over authoritative sources). A LangChain agent synthesized retrieved context. Validation layer caught generic responses and forced retry. ## Results Testing on 500+ queries: - Supervised classifier: 97.8% accuracy (highest), requires labeled training data - LLM classifier: 95.2% accuracy, ~1s overhead, no training needed—selected for deployment - Agent-based: good retrieval, higher error rates from increased complexity The LLM classifier balanced performance with practical deployment constraints. In use across multiple hives over several months, the system successfully generated structured inspection data, automated task lists, and provided contextualized advice combining personal history with domain references. To mitigate hallucination risk, responses link directly to source materials with specific page citations. ## Generalizability This pattern applies wherever you need: - Minimal device interaction (hands busy/dirty) - Structured data for later analysis - Decisions based on inspection history + domain expertise _Examples: equipment maintenance, scientific field inspections, beekeeping, etc._ ## Conclusion The dual-source routing problem appears across scientific and agricultural field work but lacks established solutions. Systematic testing of routing strategies showed LLM classifiers provide practical performance without training overhead. The architecture is open-sourced (Creative Commons NC) for adaptation to other inspection domains. ## Links - GitHub: [github.com/CarolynOlsen/hiveguide_public](github.com/CarolynOlsen/hiveguide_public) - Medium writeup: [https://medium.com/@carolyn.olsen/ai-powered-field-inspection-app-design-for-agriculture-and-science-a4507b85e30e](https://medium.com/@carolyn.olsen/ai-powered-field-inspection-app-design-for-agriculture-and-science-a4507b85e30e) - arXiv pre-print on routing strategies comparison is upcoming false https://pretalx.com/scipy-2026/talk/8QMU8G/ https://pretalx.com/scipy-2026/talk/8QMU8G/feedback/ Memorial Hall Talk 2026-07-15T13:55:00-05:00 13:55 00:30 Modeling and simulation enable iterative hypothesis testing and encoding subject matter expertise into reusable tools. While the Python community has a variety of libraries for modeling, few exist for system dynamics, a paradigm for top-down analysis of material and information flows over time. Reno is an open-source package combining creation, visualization, and analysis of system dynamics models with techniques for Bayesian inference through integration with PyMC, supporting probability distributions in system variables and MCMC sampling to produce posterior distributions based on observed values. This approach enables simulation and refinement of time series models where variables, policies, or knowledge are uncertain, and data/observations are sparse. scipy-2026-91127-reno-simplifying-application-of-bayesian-inference-to-system-dynamics Data-Driven Discovery, Machine Learning and Artificial Intelligence Nathan Martindale en # Introduction System dynamics models provide a means for exploring complex systems and effects that can arise from concepts such as feedback loops and time delays. This type of modeling has applications in a wide variety of fields including biology, economics, operations management, and social sciences. Industry standard tools for implementing this modeling process include Vensim and AnyLogic, but require a budget and lack the ability to construct programmatically from within Python. Existing Python-based libraries such as PySD provide the means to run models created in other tools but not to build them directly. Bayesian inference is a statistical tool for modeling with uncertainty and updating probability distributions based on potentially limited amounts of data. PyMC is an established library in the Python ecosystem that provides algorithms for Bayesian inference, but it can be challenging to use for implementing complex system dynamics models. The goal of this project is to provide a Python-based means for building system dynamics models with a straightforward API, and support refinement of unknown or highly uncertain variables through PyMC without requiring the developer to write extensive PyMC specific code. # System Dynamics Implementation We present Reno, a new open-source library with an API that centers around symbolically constructing equations that are used to define and reference stock, flow, and variable components, collectively constituting a system dynamics model. Conceptually similar to libraries like PyTensor and PyTorch, these equations create a compute graph that can be populated and evaluated to produce simulation data. Reno models, once defined, are called like a normal Python function to run a simulation, optionally passing in parameters to configure specific system variables. These model calls can efficiently run many simulations in parallel, allowing exploration of parameter space with parameter sweeps or input distributions, with results returned as XArray datasets. This section will discuss an example from a system dynamics textbook and show the process of implementing it in Reno along with possible visualizations and analyses of the system once created. # Incorporating Bayesian Inference By default, a Reno equation evaluates by running corresponding NumPy operations on the data passing through the compute graph. Given the similar API of PyTensor, the mathematics library underlying PyMC, everything within Reno compute graphs can also directly translate into a set of PyTensor/PyMC operations. A Reno model is thus converted into a PyMC model by compiling the component equations that evaluate for a single timestep, then wrapping with the necessary boilerplate to initialize the model and run the timestep function for a full time series simulation. Reno encapsulates this conversion process with a single function call, requiring no additional PyMC code from the model developer. Any observed data or measurements that are included in the function call are set within likelihood distributions and subsequently used in PyMC's MCMC sampling algorithms to approximate posterior distributions. This section will expand on the previous example, showing how an uncertain input variable can be provided a prior probability distribution to indicate incomplete or imperfect knowledge. Further demonstration will show how the distribution tightens/converges around the ground truth value as additional observed data points are supplied to the PyMC model calls. # Links Project repository: https://github.com/ornl/reno Example of a previous SciPy talk: https://youtu.be/uyfIQEoZPOo false https://pretalx.com/scipy-2026/talk/93ERQP/ https://pretalx.com/scipy-2026/talk/93ERQP/feedback/ Memorial Hall Talk 2026-07-15T14:35:00-05:00 14:35 00:30 AI tooling is moving fast, but many Python developers are unsure where to start or how today’s AI patterns fit into systems they already know how to build. This talk is a practical, hands-on overview of modern AI development patterns in Python, focused on what you need to know to go from zero to hero. We’ll walk through a real-world coding example broken into parts that illustrate the core building blocks of modern AI applications, and explain when each pattern makes sense. This example is designed in a way that doesn’t require any prior machine learning experience, and attendees will leave with an understanding of how AI systems work, what problems they’re good at solving, and how to maintain and observe what has been built. Topics we’ll cover: The modern AI stack in Python: LLM APIs, embeddings, tools, and agents Common Python AI patterns: prompts, function calling, RAG, and simple agents When to use a script vs an agent vs a service (and when not to) How to get something working quickly without sacrificing reliability or safety Practical guardrails: handling errors, controlling outputs, and protecting data How to generally stand up common AI workflows, such as LLM-powered scripts to lightweight AI agents / MCP-style services. Attendees will leave with a clear map of the AI landscape, working Python patterns they can reuse immediately, and the confidence to start building AI features without needing a machine learning background. scipy-2026-92333-from-hello-world-to-hello-llm-a-python-developer-s-survival-guide Data-Driven Discovery, Machine Learning and Artificial Intelligence Audrey WebbJasmine Omeke en false https://pretalx.com/scipy-2026/talk/MCEMT9/ https://pretalx.com/scipy-2026/talk/MCEMT9/feedback/ Memorial Hall Talk 2026-07-15T15:25:00-05:00 15:25 00:30 Scientific breakthroughs don’t happen in plain text, they live inside multi-column research papers, dense data tables, and intricate simulation diagrams. Yet the moment standard AI and Retrieval-Augmented Generation (RAG) pipelines encounter these layouts, they fail. Tables are flattened into meaningless strings. Figures are ignored. The structural signals that drive scientific reasoning disappear. In this talk, we show how to rescue scientific knowledge from the “text-flattening” trap using _Docling_, an open-source document understanding library designed to preserve layout, hierarchy, and element boundaries. Instead of reducing everything to text, we treat tables, figures, and sections as first-class data structures. Attendees will experience a live demo of a realistic scientific R&D workflow: uploading multiple dense technical PDFs, executing cross-document natural language queries, and successfully retrieving synthesized insights from text, structured tables, and scientific images scipy-2026-92356-docling-for-multimodal-retrieval Data-Driven Discovery, Machine Learning and Artificial Intelligence Mahima AroraAarti Jha en When analyzing simulation reports, experimental summaries, and technical journals, researchers must extract evidence, compare results, and validate claims across multiple sources simultaneously. To enable this rigorous level of analysis, we will walk through the technical implementation of a structure-aware ingestion pipeline. Using Python, we will demonstrate an architecture that decomposes document layouts into distinct semantic elements - sections, tables, and figures. This approach preserves experimental results as queryable data structures and converts diagrams into searchable semantic signals, all while maintaining the strict document hierarchy required for context-aware retrieval. Building on this foundation, we detail the construction of a hybrid retrieval system that actively supports: - Cross-document comparison - Numeric reasoning over extracted tables - Linking textual claims to supporting figures - Combining text, structured data, and visual insights in a single grounded response #### Outline - The Scientific Workflow Challenge - Structure-Aware Ingestion - Preserving and Querying Tables - Visual Representation and Linking - Live Demo & Multimodal Retrieval - Q&A Participants will gain a practical design pattern for building multimodal, structure-preserving retrieval systems that strengthen scientific reasoning and data-driven analysis. ## Resources - 📑 **Slides:** [Docling for Multimodal Retrieval](https://docs.google.com/presentation/d/1HrMgopkjV8sU8sT63W0DTnUhr-qQU2bN6FJ_xrxW900/edit?usp=sharing) - 💻 **Repository:** [multimodal-parser](https://github.com/mahimaarora/multimodal-parser) - ✍️ **Blog:** [Multimodal Parsing for RAG: Seeing Diagrams and Reading Tables with Docling](https://medium.com/@mahimaarora025/multimodal-parsing-for-rag-seeing-diagrams-and-reading-tables-with-docling-6079668361fb) false https://pretalx.com/scipy-2026/talk/SEYACQ/ https://pretalx.com/scipy-2026/talk/SEYACQ/feedback/ Memorial Hall Talk 2026-07-15T16:05:00-05:00 16:05 00:30 Optical character recognition (OCR) has been a long standing method of extracting text data from images. Traditional OCR models rely on pattern recognition and feature extraction using computer vision techniques and specialized Python libraries. Recently, large language models (LLMs) and generic AI assistants have provided an alternative method of text extraction. This talk explores the efficacy of using LLMs and VLMs for information extraction in production data pipelines and a data-driven approach for evaluating them against traditional OCR methods in terms of accuracy, reliability, latency, and cost. scipy-2026-92490-the-future-of-ocr-structured-text-extraction-with-llms Data-Driven Discovery, Machine Learning and Artificial Intelligence Patrick Deziel en Structured data extraction is a classic problem that has applications to many domains, such as document digitization, information extraction, and accessibility. There is great potential for LLMs to enhance automation for routine document processing tasks, but there are notable engineering risks associated with integrating these models into production data pipelines. LLMs can produce inconsistent outputs, produce hallucinations and confabulations, and are vulnerable to prompt injection. When evaluating the efficacy of OCR solutions, it's important to define metrics that capture not only accuracy but also latency, cost, and energy expenses. This talk explores the benefits and challenges of applying LLMs to extracting text from scanned images by contrasting three approaches. First, I will explore object detection approaches using the open source docling and RF-DETR Python libraries which directly identify characters and words from images. I will also discuss the docTR library which applies deep learning models to text recognition. Next, I will explore how state-of-the-art LLMs and AI assistants such as Gemini, Claude, and Qwen can be applied to targeted text extraction tasks. This includes a data-driven evaluation strategy that utilizes both automated and human feedback to compare LLM-based approaches to traditional OCR. Finally, I will discuss a hybrid approach that combines traditional OCR methods with LLMs. This is a two-stage process that uses an OCR model to extract text from the image, then passes the unstructured text data to an LLM to produce a structured output. This talk is for data scientists and machine learning engineers who are interested in prototyping and evaluating text extraction solutions in Python. I will walk through several Python code examples for structured extraction using open source libraries such as docling and docTR and demonstrate how to experimentally validate those methods against modern machine learning approaches that utilize LLMs and VLMs. ### Outline 1. Traditional OCR techniques (5 minutes) a. Object detection approaches with docling and RF-DETR b. Deep learning with open source models and the docTR library 2. Text extraction with LLMs (5 minutes) a. Extracting structured outputs with pydantic b. Prompt engineering c. Self-hosted vs. managed service models 3. Hybrid approach (5 minutes) a. Combining traditional OCR with LLMs b. Profiling performance metrics 4. Evaluating text extraction approaches (10 minutes) a. Automated vs. human evaluation b. Cost metrics (latency, compute and API expenses, energy) c. Creating an evaluation framework false https://pretalx.com/scipy-2026/talk/3TBXB8/ https://pretalx.com/scipy-2026/talk/3TBXB8/feedback/ Memorial Hall Lightning Talk 2026-07-15T17:00:00-05:00 17:00 01:00 Lightning talks are 5-minute talks on any topic of interest for the SciPy community. We encourage spontaneous and prepared talks from everyone, but we can’t guarantee spots. Sign ups are at the NumFOCUS booth during the conference. scipy-2026-97786-lightning-talks Lightning Talks en false https://pretalx.com/scipy-2026/talk/HZVFJS/ https://pretalx.com/scipy-2026/talk/HZVFJS/feedback/ Johnson Great Room Talk 2026-07-15T10:45:00-05:00 10:45 00:30 Are you a first time SciPy attendee? Confused about what the conference elements are or how to get the most out of your experience? Come join us for a casual chat, orientation, and suggestions for maximum fun and learning! scipy-2026-103283-first-timer-orientation General Julie HollekEd RogersAriana Mendible en false https://pretalx.com/scipy-2026/talk/CWCSEB/ https://pretalx.com/scipy-2026/talk/CWCSEB/feedback/ Johnson Great Room Talk 2026-07-15T11:25:00-05:00 11:25 00:30 Automated data enrichment, filling missing fields in structured records from unstructured sources, is the canonical case for pointing an autonomous agent at a database and letting it fill every blank. In high-stakes data that instinct is dangerous. A confidently wrong value is worse than a blank, and retrieval-grounded extraction reduces but does not remove the tendency to assert what the source never stated. An LLM can extract these fields; this paper asks where agentic judgment earns its place and where it becomes a liability. We study this on the Texas Justice Initiative's police shooting databases, where nearly two thousand records are missing the weapon, the subject's race, or the outcome, whose fields volunteers typically recover by hand, fifteen to thirty minutes each. Our LangGraph pipeline, deterministic in its control flow, searches, validates, extracts, and escalates hard cases to a human. It completes 92% of officer and 70% of civilian records and invents zero facts across twenty fabricated incidents. The recovery itself came from a deterministic prompt fix without any agent. An autonomous agent pointed at the same fabricated incidents, with more freedom, commits a wrong-article fabrication the pipeline escalates. If the deterministic core does the recovering, the agentic layer earns its place by making those recovered values trustworthy. Agency lives only in this thin judgment layer above extraction, and its components act in one of two ways. One acts on the pipeline's control flow: a relevance judge reads the retrieved articles and, when none actually report this incident, routes the record to a human instead of completing it. The other two pass judgment on what extraction produced: one deletes a value the source never states, and the other explains to the reviewer why the sources disagree on a value. Extraction calls an LLM too, but because it only proposes values for these judges to rule on, we do not count it as agentic. Every judge had to clear a reward-hacking-resistant evaluation gate before it shipped. The main contribution of this paper is a discipline, an "earn-it" protocol, for drawing the line between what a high-stakes pipeline should settle deterministically and where it is worth granting agentic judgment. scipy-2026-92471-automated-data-enrichment-for-police-accountability-where-agentic-judgment-earns-its-place Data-Driven Discovery, Machine Learning and Artificial Intelligence Hongsup Shin en ## The Data Quality Problem in Public Accountability In Texas, the Attorney General is required by law to collect a report on every officer-involved shooting, but the published summaries are high-level. The Texas Justice Initiative (TJI), a nonprofit, re-publishes the underlying incident records with the granularity that makes independent analysis possible. Yet those records are incomplete: across 1,956 incidents (2014–2024), 57% of civilian records are missing the weapon, 22.5% are missing the subject's name, and 39% of officer records are missing the officer's name. Volunteers recover these gaps by hand from news archives, fifteen to thirty minutes per record, because journalists routinely name people and describe circumstances that mandatory government filings omit. The author has volunteered with TJI since 2019 and co-authored its published report on officer-involved shootings. ## An Agentic Enrichment Pipeline The system is a seven-node LangGraph pipeline that searches the web, extracts fields, and escalates hard cases to a human. But it is mostly a *deterministic workflow*, not an autonomous agent, and that restraint is the point. After a **Load** node pulls a record from PostgreSQL, a deterministic **Coordinator** hub routes every transition through **Search** (Tavily), **Validate** (rule-based date/location/name checks), and **Synthesize** (LLM extraction), ending at **Complete** or **Escalate**. The single largest recovery gain came from a deterministic, dataset-aware extraction prompt, with no agent involved; a reasoning-and-acting loop tested on the same failures recovered nothing more. What ships as genuinely agentic is a thin *faithfulness* layer of three bounded LLM judges with graduated authority: a **relevance judge** that can *block* a record whose articles describe a different shooting, a **race verifier** that *nulls* a race the source never explicitly states, and a **conflict annotator** that only *advises* a human reviewer. The pipeline never writes back to the source database; escalation is a first-class outcome, and every committed value carries a confidence label and its source URLs. ## Evaluation Evaluation is treated as first-class engineering, not an afterthought. On held-out samples (100 records per dataset, with ground-truth fields hidden from the pipeline and compared only afterward), it completes 92% of officer records and 70% of civilian records, with exact-match field accuracy of 71–77% (86–89% under fuzzy match); officers complete more often because their shootings draw denser coverage. On a deliberately adversarial probe of 20 fabricated incidents (invented names placed in real Texas cities on real dates, six engineered as traps so that real articles about the *wrong* person would pass date and location checks), the pipeline invented zero facts and escalated all twenty. Run head-to-head on those same twenty incidents, a fully autonomous agent with free-text search, open web access, and none of the pipeline's guards declined most but completed one fabricated record the pipeline escalates, reproducibly and with no signal to warn a reviewer, at several times the cost. A generic instruction to cite sources is not the same as a mechanism with the authority to act on it. The safeguard behind every change is a reward-hacking-resistant, multi-objective evaluation gate: a pure function over two saved reports that scores completion, enforces a hard zero-hallucination veto, and checks field-level correctness on a *stable cohort*, so a completion gain can never launder a correctness loss. End to end, a record costs roughly $0.20 (about $400 for the full archive), set against the hundreds of volunteer-hours the manual workflow would take. Per-race completion is reported as a non-gating diagnostic, kept visible to a human reviewer rather than acted on automatically at these group sizes. ## Design Principles and Broader Applicability Four principles, each a stance on a tradeoff, shaped the system: do everything deterministic first, because every place a model may choose is a place it can choose wrong; calibrate each component's authority to how sharply it can decide (block, null, or advise); prefer faithfulness over coverage, because in an accountability database a wrong value is worse than a blank; and distrust the headline metric, because "complete more records" is trivially gamed by accepting weak extractions. No agentic component shipped on intuition; each had to clear an offline "earn-it" gate, and four of the seven ideas tried were gated out, failed, deferred, or declined, which is as much the contribution as the three that shipped. The discipline rests on three domain-general preconditions rather than on TJI specifics: a held-out signal to score against, a hard-veto safety metric that no other gain may override, and decisions that can be ranked by stakes. Where those hold (public-health surveillance, environmental incident tracking, historical archives, and other domains where structured databases have gaps that scattered public sources could fill), the pattern should carry. ## What Attendees Will Learn - The workflow-versus-agent design axis: where an LLM earns its place, and where a deterministic rule or prompt quietly beats one, shown by a head-to-head in which an unconstrained autonomous agent fabricates a record the bounded pipeline escalates - How to build a reward-hacking-resistant, multi-objective evaluation gate that cannot be satisfied by trading correctness for completion - Calibrating component authority to stakes (block / null / advise), and designing human-in-the-loop escalation as a first-class outcome rather than a failure - An "earn-it" protocol for admitting agentic components only after they clear an offline gate, including the null results that kept components out - Testing and mocking patterns for pipelines that depend on external web-search APIs and LLMs - Using LangGraph deliberately narrowly: typed state, deterministic routing, and a clean seam to inject or mock every model call ### Target audience Data scientists, ML/AI engineers, and scientific Python users interested in applied agentic AI, LLM evaluation, data quality, or civic tech. ### Source code [github.com/hongsupshin/police-data-intelligence](https://github.com/hongsupshin/police-data-intelligence) (open source, MIT, with tests and CI via GitHub Actions) ### Related publication [Officer-Involved Shootings in Texas: 2016-2019](https://texasjusticeinitiative.org/publications/officer-involved-shootings-in-texas) ### Speaking experience The author has presented at academic conferences and industry events on data science and machine learning topics. Video recordings are available from a [Texas Justice Initiative presentation](https://drive.google.com/file/d/1aXvxJ8E4pP9uE4WU0dW3A4ncglxvZhCH/view) and an [Austin Python Meetup community meetup talk](https://www.youtube.com/watch?v=gfqKaplRTsk). false https://pretalx.com/scipy-2026/talk/9UQN9C/ https://pretalx.com/scipy-2026/talk/9UQN9C/feedback/ Johnson Great Room Talk 2026-07-15T13:15:00-05:00 13:15 00:30 Upgrading your organization’s dependencies on open source libraries can be daunting. Major version releases promise bug fixes, new features, and security improvements, but these upgrades often require so much more work than just bumping a few numbers and letting your package manager sort out the rest. From planning to deployment, this talk is a step-by-step guide to upgrading your dependencies on open source libraries. We will offer practical strategies for scoping, coordinating, debugging, testing, releasing, and communicating major version upgrades -- all with as little pain for developers and users as possible. Whether you're maintaining internal extensions, forking core packages, or just trying to stay current, you'll learn real-world strategies to make major upgrades less painful, and maybe even routine. scipy-2026-87810-ship-it-or-skip-it-when-how-to-upgrade-your-open-source-dependencies General Rebecca ElyBalaji SundaramShruti Sapre en Major dependency upgrades are daunting, and the tail of downstream projects and end-user organizations putting them off is always long. Developers often find good reasons to delay major upgrades of dependencies. Resources are scarce, managers may see more value in introducing new features or fixing active bugs, and upgrading comes with the risk of regressions. However, delaying major upgrades hurts everyone: - Users must wait for security fixes and new features - Developers who put off upgrades end up facing a mountain of changes to simultaneously research, implement, test, and release - Upstream maintainers must choose between dropping support for still-popular versions or devoting resources to trying to maintain every version under the sun by backporting fixes to old branches Faster, more timely upgrade adoption means more platform stability for everyone. In this talk, we’ll share lessons learned from years of major upgrades to our platform’s dependencies on Jupyter ecosystem projects (Lab, Widgets, Server, Voila). We aim to provide attendees the strategies -- and confidence -- they need to tackle the next big upgrade long before the typical end-of-maintenance scramble. false https://pretalx.com/scipy-2026/talk/UFF7UR/ https://pretalx.com/scipy-2026/talk/UFF7UR/feedback/ Johnson Great Room Talk 2026-07-15T13:55:00-05:00 13:55 00:30 As funding levels have fallen in both the public sector and startup investing, many in the SciPy community are facing uncertain career futures or even job loss. Others may simply dream of being their own boss. This session will guide participants through a personalized analysis of the feasibility of securing paid work outside of formal employment, including solo consulting, building a product or service business with a team, or joining an existing tech startup. The session will also touch on tips for starting with limited funding, reducing unnecessary risk, leveraging open-source community resources, and pursuing next steps. scipy-2026-91050-assessing-the-entrepreneurship-option-in-uncertain-times General /media/scipy-2026/submissions/CV8VEH/image_EaCAME3.webp Jocelyn Graf en false https://pretalx.com/scipy-2026/talk/CV8VEH/ https://pretalx.com/scipy-2026/talk/CV8VEH/feedback/ Johnson Great Room Talk 2026-07-15T14:35:00-05:00 14:35 00:30 Your GPU is fast, so why does your Python code still feel slow? This talk shows a practical, Python-first profiling workflow with Nsight Systems, Nsight Compute, and NVTX for CuPy, Numba, PyTorch, JAX, and CUDA extensions. We will use timelines to find launch overhead, hidden synchronizations, and host-device copies, then drill into kernel bottlenecks like memory throughput and occupancy. You will leave with a repeatable loop for turning profiles into measurable speedups. scipy-2026-91679-profiling-python-gpu-code General Bryce Adelstein LelbachBradley Dice en Your GPU is fast, so why does your Python code still feel slow? When you accelerate Python with CuPy, Numba, PyTorch, JAX, or custom CUDA extensions, performance problems rarely look like a single slow kernel. They look like death by a thousand cuts: tiny launches, hidden synchronizations, accidental host-device copies, stream serialization, and kernels that are "fine" until you look at memory traffic. The good news is that NVIDIA's developer tools can make these issues obvious, if you know what to capture and how to read it. In this talk, I'll show a practical, Python-first profiling workflow using Nsight Systems, Nsight Compute, and NVTX. We'll start at the top with system-level timelines to answer "where did the time go?" then drill down into kernel-level analysis to answer "why is this kernel slow?" Along the way, you'll learn how to annotate Python code with NVTX so your traces are readable, how to profile from notebooks and CI, and how to turn profiler output into a short, repeatable optimization loop. Key takeaways: - How to use NVTX ranges and markers from Python to make timelines explain themselves. - How to capture the right Nsight Systems trace to spot launch overhead, sync points, copies, and stream issues. - How to pivot from a timeline hotspot to Nsight Compute and choose metrics that actually answer your question. - How to interpret common kernel bottlenecks (memory throughput, occupancy limits, instruction mix) without drowning in counters. - A checklist for avoiding profiling traps (implicit sync, warmup, clock variability, sampling noise, and "profiling changed my code"). - A repeatable workflow you can apply to real Python GPU stacks, from single kernels to end-to-end pipelines. By the end, you'll be able to profile Python GPU code with intent, isolate the bottleneck you actually have, and make changes you can measure and defend. false https://pretalx.com/scipy-2026/talk/77PGCB/ https://pretalx.com/scipy-2026/talk/77PGCB/feedback/ Johnson Great Room Talk 2026-07-15T15:25:00-05:00 15:25 00:30 This talk showcases a complete Python-based data pipeline for capturing and analyzing test data from electric motors powering BETA Technologies' fully electric CTOL (Conventional Takeoff and Landing) and VTOL (Vertical Takeoff and Landing) aircraft. We demonstrate how Python's open-source ecosystem enables seamless integration from edge to analytics: custom loggers decode machine data; a home-built data service batches and stores raw data in Apache Iceberg on AWS; dbt defines transformations that load into Redshift for analytics; Trino supports querying and joining to data from other sources; and Grafana serves visualizations, all provisioned via AWS CDK in Python. By leveraging modern data infrastructure and cloud solutions, we built an accessible, maintainable solution that handles terabyte-scale test data. scipy-2026-91830-electrifying-aviation-with-python-an-end-to-end-data-pipeline-from-test-stand-to-analytics General /media/scipy-2026/submissions/SUPRRW/image_I4OrfPd.webp Sarah Tabor en ### Background and Motivation Electric aviation represents a critical frontier in sustainable transportation, and Vermont-based BETA Technologies is pioneering this transformation. BETA is taking a methodical "crawl, walk, run" approach to FAA certification: first our H500A electric motor, then our ALIA CTOL (Conventional Takeoff and Landing) aircraft, and finally our ALIA VTOL (Vertical Takeoff and Landing) aircraft. Fast design iteration is fundamental to our development process, making quickly accessible, accurate data integral to the business. Our testing program generates terabytes of data as we validate motor performance and safety. Engineers need access to both near real-time and historical data, supporting everything from millisecond-level debugging to fleet-wide trend analysis. For FAA certification, we must preserve raw data indefinitely, and the pipeline architecture itself must be simple and explainable to regulators. We needed a solution our cross-functional team could own, understand, and modify. A Python-based pipeline built on open-source tools aligned perfectly with BETA's collaborative culture, allowing one language to unify our entire data stack from edge to cloud. ### Methods We built an end-to-end pipeline entirely in Python, integrating established open-source tools with modern cloud data infrastructure. Our entire AWS infrastructure is provisioned and managed using CDK, ensuring our infrastructure is as maintainable and version controlled as our application code. **Data Ingestion:** Custom Python decoders parse CAN (Controller Area Network) log formats from test stands. Decode specifications vary frequently as we iterate on motor designs, so we built CLI tools that allow test conductors to push new decode files whenever needed (sometimes 25 times per week!), ensuring the pipeline adapts to evolving requirements without data engineering intervention. **Raw Storage:** We leverage Apache Iceberg as our lakehouse format on AWS S3, using PySpark for writes. Iceberg provides schema evolution, time travel, and hidden partitioning, which is essential for managing growing datasets while maintaining data quality. This layer preserves tall-format, full-fidelity data indefinitely. Engineers can access any signal on demand, easily add or remove instrumentation as testing needs evolve, and the transparent storage architecture is easily explainable to the FAA for certification purposes. **Transformation:** Dbt defines SQL transformations that aggregate raw time series data and event metadata into well-defined, consistent data mart schemas and custom views. Its testing framework ensures data quality, the open-source Python library sqlfluff handles SQL linting, and its documentation features maintain living documentation directly in the code. **Analytics Layer:** Transformed data lands in Amazon Redshift, optimized for fast queries and ready for analysis. This data mart serves multiple downstream uses: engineers perform ad-hoc analysis in Python; automated Python scripts generate derived insights that are written back to our data platform and stored alongside observed data; and a dedicated time tracking database stores aggregated test hours by component and operating condition, critical for FAA testing requirements. We use Grafana, an open-source visualization tool that connects to any data source, seamlessly unifying our many databases into a single visualization layer. We've built a library of reusable Grafana dashboards that make stored data immediately accessible, serving analytics across the organization and transforming data into actionable insights for day-to-day decision making. **Orchestration:** Apache Airflow DAGs coordinate the entire pipeline through a mix of scheduled and event-driven jobs, with custom operators written in Python for our specific workflow needs. ### Results The pipeline processes half a terabyte of test data monthly, supporting 50+ engineers across multiple test stands and development programs. Data access that previously required hours of manual data extraction now completes in seconds, allowing engineers to spend less time hunting for data and more time iterating on designs. The best outcome: learnings from this project extend well beyond this single pipeline. By building reusable BETA-specific CDK constructs and establishing common architectural patterns, we've created a platform that accelerates development across all our data sources, from manufacturing sensors to flight test telemetry. This unified approach reduces development time and makes our entire data ecosystem more consistent and maintainable. false BETA's website The Most Beautiful Ferry Flight in America (and It’s Electric) Meet BETA Video We Fly What We Build https://pretalx.com/scipy-2026/talk/SUPRRW/ https://pretalx.com/scipy-2026/talk/SUPRRW/feedback/ Johnson Great Room Talk 2026-07-15T16:05:00-05:00 16:05 00:30 Awkward Array is a Python library widely used in high-energy physics for representing and manipulating nested, variable-length data. As analysis workloads increasingly rely on GPU acceleration, there is a need for solutions that deliver high performance while remaining accessible to Python developers. In this joint talk between the Awkward and the NVIDIA teams, we present recent developments in GPU execution for Awkward Array using the new native Python CUDA support for CCCL called `cuda.compute`. This novel Python interface for CCCL that enables users to achieve state-of-the-art GPU performance without dropping down to C++ when building new GPU algorithms. Our approach fuses sequences of Awkward operations into a minimal set of CUDA kernels, reducing kernel launch overhead and improving memory efficiency. Lazy execution allows entire expression graphs to be optimized before kernel generation, which benefits workflows involving jagged arrays, combinatorial operations, and reductions. In addition, the design enables user-defined Python code to be incorporated into GPU execution paths with minimal boilerplate, lowering the barrier for extending Awkward with custom GPU-accelerated logic. `cuda.compute` is a new component in the CUDA Python ecosystem that provides native access to optimized algorithms, such as transforms, reductions, and scans. It also provides a collection of iterators that defer execution of operations and enable fusing multiple operations. We demonstrate performance improvements using this approach over an eager GPU execution strategy for representative analysis patterns and show how it integrates into the existing Python workflows. These developments provide a practical, user-friendly path toward high-performance GPU-accelerated data analysis in Python. We thank NVIDIA for support and collaboration in developing the CUDA kernels and providing guidance on GPU optimization strategies. Their contributions are gratefully acknowledged. scipy-2026-91837-gpu-accelerated-awkward-arrays-with-cuda-python General Ianna OsborneAshwin Srinath en **Outline** **_I. Background & Motivation: The Reality of "Messy" Awkward Data_** - Beyond Rectangular Tensors: Real-world data is rarely a simple 2D matrix. Whether it's nested JSON, variable-length genomic sequences, or particle tracks in physics, "jagged" data is everywhere. - The Hardware Bottleneck: Standard GPU libraries often require padding jagged data to fixed lengths, which wastes memory and compute cycles. - The "Memory Wall": Even when using existing GPU kernels, executing them one by one (eagerly) forces the GPU to constantly move data between fast registers and slow global memory. **_II. Methods: Introducing `cuda.compute` and CCCL_** - A New Python Interface: We introduce cuda.compute, a novel component in the CUDA Python ecosystem that provides native access to CCCL primitives — transforms, reductions, and scans. - The Integration: How the Awkward Array team collaborated with NVIDIA to bridge the gap between high-level Python abstractions and low-level CUDA performance. - From "Fixed" to "Fused": Moving from a library of pre-written, static kernels to a system where users write their own kernel logic in Python, fused into an efficient CUDA kernel tailored to the task at hand. **_III. Deep Dive: Kernel Fusion and Lazy Execution_** - The Expression Graph: How Awkward Array now captures a user's intent — e.g., "filter these events, then calculate a mean" — as a graph rather than executing each step immediately. - Dynamic Compilation: Using `cuda.compute` to fuse this graph into a minimal set of CUDA kernels. - Efficiency Gains: Fusing operations reduces kernel launch overhead and keeps data on-chip (in L1 cache and registers) as long as possible. **_IV. Results: Performance in the Real World_** - Benchmarking Complexity: We demonstrate performance gains on representative analysis patterns — such as combinatorial matching and nested reductions — common in both high-energy physics (HEP) and large-scale data engineering. - Performance vs. Effort: This approach achieves C++-level performance while requiring zero C++ code from the end user. - Workflow Integration: How this fits into existing ecosystems like the broader SciPy stack. **_V. Conclusion & Outlook_** - Impact: This collaboration makes high-performance GPU analysis accessible to any scientist working with complex data structures. - Next Steps: Current availability in the Awkward Array ecosystem, with future plans to expand the `cuda.compute` primitive set. - Acknowledgements: We gratefully acknowledge NVIDIA's support in developing these kernels and optimization strategies. false https://pretalx.com/scipy-2026/talk/EJSCLM/ https://pretalx.com/scipy-2026/talk/EJSCLM/feedback/ Thomas Swain Room Talk 2026-07-15T10:45:00-05:00 10:45 00:30 For scientists wanting to work with and analyse earth science data, the standard remains delivering tooling via python packages, and data via HPC or the cloud. For data siloed on an HPC system, this presents a barrier to findability and accessibility. However, with agentic AI now widely available, the cost of learning a new tech stack or toolchain to deliver this data has plummeted. In this talk, I'll outline how we utilised agentic AI to translate an intake catalog into an interactive, single page web application, maximising data discoverability whilst leaning on our existing data infrastructure and established Python API's to constrain the scope, keep the wrapper thin, and the code from becoming spaghettified, unmaintainable AI slop. scipy-2026-92347-fairer-data-the-case-for-data-advertising-in-the-age-of-agentic-ai Environmental, Earth, and Climate Sciences Charles Turner en FAIR (Findable, Accessible, Interoperable, Reusable) data is widely agreed on as the benchmark for data management and stewardship. Unfortunately, findability is often an afterthought - and datasets that can't be found are difficult to access! In the earth sciences, we commonly assume that if a dataset can be found by someone who already knows what they are looking for or where to look for it, then it is findable. For small and tight knit research communities, or cloud distributed datasets, this might be the case. However, within the earth sciences, many datasets remained siloed on HPC systems, where it is often assumed that tribal knowledge that can be obtained from a supervisor, colleague, or collaborator is sufficient to guide new users through these systems. Worse yet, users are often expected to obtain login access to an HPC simply to discover which datasets are available, before they can even determine whether the data are relevant to their needs. In practice, this assumption means that datasets are only available to an in group of users who are already familiar with them. Why is this so often the case? The defacto tool for data analysis in the earth sciences is Python, but the best way to advertise and distribute datasets is through the web. If we want to distribute the data ourselves, without getting experienced web developers involved, this leaves us with a few options: static site generation through tools like readthedocs, writing a python web server, or going all in and learning enough JavaScript to create an interactive data exploration tool. The key issue? The better the interface, the more time and effort you'd need to sink into learning a new tech stack, toolchain, and way of thinking. The result of this - lots of clunky interfaces to explore and obtain data. Whilst this is still true, with AI agents now widely available, the cost of learning a new tech stack or creating new data delivery tools has plummeted. For an experienced developer with a hoard of well structured data, 'vibe-coding' a wrapper to advertise and distribute that data is now a serious option. In this talk, I'll walk through how we created a tool for advertising Australia's trove of earth science data, making it easy to find and discover for anyone with a browser and an internet connection - not just those who already had the right HPC login. Expect to learn: - Why well structured data, metadata, and documentation are more important than ever - not less - in this new data landscape. - How we used intake, duckdb-wasm, polars and Vue to create a tool that blends cloud and HPC data delivery. - Why the proliferation of social media and gamification of content has made data advertising more important than ever. - How keeping wrappers thin and focusing on the interactive experience lets the data do the talking. - How we went about testing, gathering feedback, and iterating on an interactive tool in an area where users expect to be provided with static content or a Python API. Intended Audience: Earth Scientists, people interested in data sharing, people looking to use emerging tools to make their work more impactful false https://pretalx.com/scipy-2026/talk/7PSPJP/ https://pretalx.com/scipy-2026/talk/7PSPJP/feedback/ Thomas Swain Room Talk 2026-07-15T11:25:00-05:00 11:25 00:30 The Ecosystem Services Market Consortium (ESMC) is expanding its agricultural sustainability programs to include biodiversity outcomes across the United States. To support this effort, we developed a Python-based Biodiversity Metric Module that estimates biodiversity gains associated with agricultural best management practices. The module integrates national land cover data, species occurrence records, protected lands datasets, and soil microbial biomass information within a unified geospatial workflow to generate standardized biodiversity unit estimates. This presentation outlines the ecological framework, computational architecture, and lessons learned while scaling biodiversity assessment across thousands of spatially explicit agricultural fields. scipy-2026-92367-computational-biodiversity-accounting-for-agricultural-systems-with-python Environmental, Earth, and Climate Sciences Hannah Ferriby en The Ecosystem Services Market Consortium (ESMC) works with agricultural producers across the United States to incentivize sustainable land management. As biodiversity increasingly becomes part of climate and sustainability reporting frameworks, ESMC identified the need for a consistent, scalable method to quantify biodiversity gains associated with agricultural best management practices. Unlike carbon accounting, biodiversity does not reduce to a single stock or flux. It reflects habitat condition, ecological function, spatial connectivity, and recovery through time. Estimating biodiversity change across working agricultural landscapes requires both a sound ecological foundation and robust computational design. To meet this need, we developed the Biodiversity Metric Module, a Python-based tool that supports biodiversity quantification within ESMC’s Monitoring, Reporting, and Verification platform. The module evaluates agricultural fields using a structured ecological framework and it calculates biodiversity units by integrating five interacting components: habitat quality, functional diversity, conservation context, habitat size, and time-dependent ecological response. We derived habitat quality from national land cover datasets (CDL, NLCD) and translated land cover classes into ecological condition scores using structured parameter tables aligned with program objectives. We represented functional diversity by analyzing species occurrence records (GBIF) to characterize ecological guild presence for plants, insects, and birds, and we supplemented those data with publicly available soil microbial biomass datasets. The model evaluates landscape context by calculating proximity to protected areas to reflect conservation priority and connectivity. It accounts for habitat size by incorporating the spatial footprint of each management practice. Time-dependent response functions model ecological recovery following practice implementation. The system computes biodiversity units for baseline and practice-change conditions and quantifies net biodiversity gain as their difference. We operationalized this framework by integrating publicly available, geospatial datasets at multiple spatial resolutions, including raster and vector. Scientific Python tools support spatial processing, numerical computation, and reproducible data management throughout the workflow (e.g. geopandas, rasterio, rasterstats). We deployed the Biodiversity Metric Module as a Flask-based application within the broader Monitoring, Reporting, and Verification platform architecture already in place. The application accepts spatial field boundaries and management attributes as inputs, executes geospatial and numerical workflows, and returns standardized geospatial outputs. This design enables consistent evaluation across fields while maintaining clear separation between ecological logic and user interface components. Throughout development, I focused on raster processing, habitat quality scoring, and integration of species occurrence data within spatial buffers. Aligning national land cover rasters at differing resolutions required deliberate aggregation and consistency checks across baseline and practice-change scenarios. Developing both the habitat quality and species function scores reinforced the importance of explicitly documenting ecological assumptions and spatial bias. These challenges highlighted the importance of modular design and transparent assumptions when building biodiversity metrics at national scale. The development of this tool highlights broader challenges in applied biodiversity modeling, including data limitations, spatial bias in species occurrence records, and temporal mismatches between ecological processes and national-scale datasets. It also demonstrates how scientific Python enables integration of diverse environmental data into scalable, reproducible, geospatial workflows. As biodiversity accounting continues to evolve, computational frameworks like this will play an increasingly important role in connecting ecological science with large-scale environmental decision-making. false https://pretalx.com/scipy-2026/talk/ZTAB8K/ https://pretalx.com/scipy-2026/talk/ZTAB8K/feedback/ Thomas Swain Room Talk 2026-07-15T13:15:00-05:00 13:15 00:30 UChicago's Data Science Institute (DSI) partners with 11th Hour Project to turn data insights into action. In this talk, I'll focus on our collaboration with Occidental Arts & Ecology Center (OAEC)'s Fuels to Flows program, which stabilizes upland waterways by adding brushwood that would otherwise fuel forest fires. Gullies are hidden by trees, so we used publicly available LiDAR to cleanly identify gullies by shape with a lightweight convolutional model. I'll show how Numba made it possible to convolve hundreds of gigabytes of images with unusually large kernels and how we delivered these map layers via static hosting using PMTiles, even with interactive features like computing elevation profiles along hand-drawn lines. scipy-2026-90928-from-lidar-to-action-detecting-upland-gullies-to-combat-erosion-and-forest-fires Environmental, Earth, and Climate Sciences /media/scipy-2026/submissions/E8QGYT/image_4szFT2I.webp Jim Pivarski en **Who this is for:** GIS data scientists who work with rasters, problems of scale, and shipping interactive results to non-technical stakeholders with minimum infrastructure. The general SciPy audience may also be interested in this example of a "right-sized" ML approach (the "lightweight convolutional model"), as well as ways data science can contribute to nonprofits and the public good. **Motivation/context:** The UChicago DSI 11th Hour group (https://datascience.uchicago.edu/outreach/11th-hour-project/) partners with 11th Hour Project grantees, spanning energy, food & agriculture, human rights, and marine ecology, to build software and data products for social and environmental impact. This talk focuses on one environmental case study within the broader pattern of supporting mission-driven organizations with tools that reduce manual work and scaling beyond ad-hoc analytics. **Problem:** OAEC has implemented the Fuels to Flows program (https://oaec.org/our-work/wildlands/fuels-to-flows/) on their own site and Monte Rio Redwoods Regional Park (both in Sonoma County, CA), but expanding the program requires identifying new sites, working with land-owners to secure the right permits, and hiring contractors. Our work addresses the first step by making gullies, ladder fuels, and erosion patterns visible on a county-wide interactive map. **Data:** Sonoma County publicly provides LiDAR-derived products: high-resolution DEMs scanned in 2013 and 2022 (1 m and 0.5 m grids), as well as proxies of ladder fuels that allow ground fires to climb to the forest canopy. **Method:** Standard gully-finding heuristics produce rasters to search by eye; we extended this technique to (1) reduce noise by convolving images with trough-shaped, rather than point-like, kernels, (2) approximate a CNN with engineered, rather than learned, features due to the paucity of hand-labeled data, and (3) build a vector-based "road network" of gullies, rather than an image. This technique has a spin-off used in the DSI's Clinic course: a UChicago student adopted it to vectorize blood vessels in MRI images to predict breast cancer treatment response. **Delivery:** We provide GIS-ready layers, but the intended users of this work are not GIS experts and the files are unwieldy (400 GB total). Therefore, we built a specialized map app as a website that loads data on demand as the user zooms into it. We also need to minimize our maintenance burden, since this is one of many projects, so we formatted the data as PMTiles, which are flat files that can be served with static web hosting (CloudFlare, in our case), with no application-specific server logic. **Map app:** https://oaec-found-gully.vercel.app/ **GitHub:** https://github.com/dsi-clinic/oaec-found-gully (currently private; I'll see if I can make it public before submitting) **What attendees will learn:** 1. A practical middle ground between simple filters and deep learning when labels are scarce. 2. How to insert a custom optimization with Numba when standard functions (`convolve2d` in various libraries) restrict performance due to unusual conditions (unusually large kernels in our case). 3. How to deliver large maps in tiles without requiring a custom server. false https://pretalx.com/scipy-2026/talk/E8QGYT/ https://pretalx.com/scipy-2026/talk/E8QGYT/feedback/ Thomas Swain Room Talk 2026-07-15T13:55:00-05:00 13:55 00:30 Geospatial analysis relies on raster data — n-dimensional arrays where each cell holds a spatial measurement. The scale of modern remote sensing data makes CPU-based workflows impractical, but raster operations are naturally parallelizable and well suited for GPU acceleration. This talk walks through a GPU-accelerated end-to-end workflow to classify satellite imagery into land cover types, covering data access via [STAC](https://stacspec.org/en), preprocessing (cloud masking, compositing, spectral index computation), training a Random Forest classifier on millions of pixels, and running inference on unseen tiles. The pipeline uses familiar APIs from Xarray, Dask, pandas, and scikit-learn, accelerated with RAPIDS. No prior geospatial or GPU experience is required. scipy-2026-92397-accelerating-geospatial-analysis-with-gpus Environmental, Earth, and Climate Sciences Jaya VenkateshJacob TomlinsonNaty Clementi en ## Motivation Monitoring land use and land cover (LULC) change is essential for understanding deforestation, urban growth, and the effects of climate change. Satellite missions like ESA's Sentinel-2 provide openly available multispectral imagery at up to 10-meter resolution with global coverage and a revisit frequency of roughly 5 days. However, a single tile contains millions of pixels across multiple spectral bands, and producing accurate LULC maps requires preprocessing raw imagery (cloud removal, temporal compositing, index computation), training a classifier, and running inference across large regions. On a CPU, each of these stages can take tens of minutes per scene, making regional-scale analysis slow and difficult to iterate on. Because each pixel in a satellite image can be processed independently, these raster operations are naturally parallelizable and well suited for GPU computation. This talk shows how existing Python tools in the geospatial ecosystem can be combined with GPU-accelerated libraries to make geospatial workflows significantly faster, often with minimal code changes. ## Methodology We present an end-to-end LULC classification pipeline built on publicly available datasets. Sentinel-2 Level-2A imagery provides the input features and ESA WorldCover provides per-pixel land cover labels, both accessed through the SpatioTemporal Asset Catalogs (STAC) specification. The pipeline covers several stages common to remote sensing workflows such as querying and loading cloud-hosted imagery into Xarray using Dask for chunked computation, masking clouds using the Sentinel-2 Scene Classification Layer, mosaicing overlapping tiles, computing an annual median composite, and deriving spectral indices such as NDVI and NDWI as additional features. The resulting data cube and matched labels are then used to train a Random Forest classifier on millions of labelled pixels, and the trained model is applied to previously unseen satellite tiles to generate LULC maps. We compare wall times for each stage (preprocessing, training, inference) against a CPU baseline (using scikit-learn) to quantify the practical benefits and ease of using GPUs when working with data in the geospatial domain. ## Results Across the full pipeline, GPU-accelerated stages run 3x to 5x faster than their CPU equivalents, with the largest gains in model training and full-scene inference. The trained model performs especially well at distinguishing major land cover classes like built area and water bodies. We also present visual comparisons of model predictions against reference maps over held-out regions for qualitative analysis. ## Conclusion Attendees will come away with a practical understanding of how to efficiently leverage GPUs when working with geospatial data in Python. We will also discuss the design choices made, challenges we encountered, and potential improvements to provide a complete understanding to attendees which they can leverage in their own work. The full notebook for this exercise with detailed explanations for attendees to follow is available at https://docs.rapids.ai/deployment/stable/examples/lulc-classification-gpu/notebook/ ## Talk Outline (25 min + 5 min Q&A) **Introduction (5 min):** What LULC classification is and why it matters for environmental monitoring, how satellite imagery is structured (tiles, bands, resolution, coordinate reference systems), and the datasets used in this talk (Sentinel-2 and ESA WorldCover). **Data access and preprocessing (10 min):** Querying cloud-hosted imagery via STAC, loading into Xarray/Zarr, cloud masking, temporal compositing, and computing spectral indices (NDVI, NDWI). **Model training and inference (5 min):** Building a feature cube from preprocessed imagery, training a Random Forest classifier on millions of labelled pixels, and generating LULC maps as inference over unseen tiles using the trained model. **Performance comparison and potential improvements(5 min):** CPU vs GPU wall-time comparisons across preprocessing, training and inference. Discussion of problems like class imbalance approaches on how to solve these issues. A brief discussion about best practices for chunking and memory management. **Q&A (5 min)** false https://pretalx.com/scipy-2026/talk/97QQ8D/ https://pretalx.com/scipy-2026/talk/97QQ8D/feedback/ Thomas Swain Room Talk 2026-07-15T14:35:00-05:00 14:35 00:30 The advent of multimodal large language models (mLLMs) provides new opportunities for automated data exploration tasks on multi-petabyte atmospheric data sets. In this presentation, we present Nepho, a Python package for parallel mLLM prompting on collections of atmospheric quicklook data plots. We then evaluate the accuracy of several mLLMs in answering questions about Atmospheric Radiation Measurement (ARM) atmospheric datasets. We demonstrate that the GPT 4/5 and llama3-vision models were the most accurate models for quicklook plot exploration and recommend prompt engineering and retrieval-augmented generation for such data exploration workflows. scipy-2026-92513-nepho-a-workflow-for-using-mllms-for-atmospheric-data-plot-exploration Environmental, Earth, and Climate Sciences /media/scipy-2026/submissions/N9YDEL/image_dx4cUo0.webp Bobby Jackson en Atmospheric datasets, such as the U.S. Department of Energy Atmospheric Radiation Measurement Facility’s archive span several petabytes and decades. This makes exploring such datasets difficult for users that are interested in specific weather phenomena. However, multimodal LLMs such as GPT 5.0 now support basic analyses of atmospheric data plots. Given that quicklooks are available on ARM’s dqplotbrowser website for most of ARM’s instrument and value added product data, mLLMs present a potential new opportunity for automated data exploration using agents. In this presentation, we present a feasibility study for using mLLMs for data exploration. In order to perform this study, we developed Nepho, a Python package that supports parallel mLLM inference of prompts on sets of quicklook plots. Nepho supports a wide variety of mLLMs using OpenAI, RESTful API, and ollama endpoints through a backend abstraction. Nepho encodes image timeseries into an embedding along with the prompt and performs inference of specific prompt-data plot pairs automatically for the user, making automated mLLM workflows easier on image collections. Nepho supports parallel inference for faster processing and therefore can scale to multiple processors. Nepho was used for a feasibility study for using mLLMs to explore atmospheric datasets through quicklook plots. As a part of this effort, atmospheric scientists developed a testing dataset of 132 prompt-data plot-answer triplets from a wide array of atmospheric datasets. An example of such a triplet is shown in Figure 1. In this example, we use an mLLM to explore spikes in eddy correlation flux data from the ARM Southern Great Plains site. We provide the multiple choice question about the plot and then assess accuracy by comparing against human-generated answers about the plot. We evaluated 12 mLLMs in total. GPT-4.1 and GPT-5 provided the best accuracy, both around 68%. The best open source model performance we evaluated was llama3.2-vision:90b with 57.58% accuracy. This shows that, without any effort to provide domain-specific information to the mLLMs, that mLLMs have fair accuracy on answering multiple-choice questions for this testing dataset. Since we did not include any domain-specific information in our prompt, we recommend methods to increase the accuracy for specific datastreams by including domain-specific information through retrieval-augmented generation to improve accuracy. Nepho has enabled other community efforts exploring the feasibility of mLLM-assisted data exploration. For example, the ARM Facility plans further feasibility studies on weather radar scene classification and exploration of data quality issues in atmospheric plots for the ARM Data Quality Office, incorporating these recommendations. LLM-Assisted Radar Scenes (LARS), a weather radar classification package based on Nepho, is already under development. false https://pretalx.com/scipy-2026/talk/N9YDEL/ https://pretalx.com/scipy-2026/talk/N9YDEL/feedback/ Thomas Swain Room Talk 2026-07-15T15:25:00-05:00 15:25 00:30 _Adapt v0.1_ is a real-time, reproducible data-analysis framework developed to support adaptive radar scanning within the U.S. Department of Energy Atmospheric Radiation Measurement (ARM) facility. It implements a declarative, store-driven architecture that separates acquisition, processing, and visualization into independent, thread-safe components. A continuous ingestion worker registers incoming radar data, while processing workers poll a central DataStore for newly available items and execute configured analysis chains. Visualization and external systems interact only with completed outputs, preventing interference with internal logic. The framework is built on the Scientific Python ecosystem, including Py-ART, Xarray, Scikit-learn, OpenCV, and SciPy, and is designed for maintainability and extensibility through well-defined input–output protocols. Adaptive radar scanning enables real-time response to evolving convective storms, overcoming limitations of fixed, omnidirectional volume scans that often miss rapid microphysical transitions. Because radar beam physics constrains full-volume update rates, dynamically focusing on sectors of interest can significantly improve temporal resolution. Achieving this requires low-latency analysis, forecasting, and decision support integrated directly into operational workflows. While legacy systems such as TITAN demonstrated real-time storm tracking decades ago, most modern Python-based radar and tracking tools were designed for offline analysis. Campaign-driven ARM operations require continuous ingestion, event-driven execution, streaming outputs, flexible configuration, and robust integration with operational infrastructure. Adapt addresses these needs through a lightweight, modular design that cleanly separates orchestration, scientific logic, and downstream consumers. The architecture consists of three loosely coupled layers. The scientific layer contains deterministic modules for detection, analysis, projection, and tracking that operate on structured inputs and produce explicit outputs. The orchestration layer manages item lifecycles, scheduling, and metadata state transitions including creation, queuing, processing, completion, or failure, enabling recoverability and preventing race conditions. The data access layer provides a client abstraction over the repository so downstream systems query structured metadata rather than raw files. Configuration files and CLI arguments define algorithm selection, runtime parameters, radar sources, and product definitions, supporting campaign-specific objectives. To prevent silent numerical corruption, Adapt enforces algorithm contracts that validate outputs immediately after execution. Segmentation products are checked for dimensional consistency, contiguous labeling, and mask integrity; projection products are verified for spatial alignment, finite motion vectors, and forecast horizon consistency; analytical outputs undergo schema and metadata validation. Violations halt processing for that item and record diagnostic state in the catalog, ensuring fail-fast behavior and reproducible debugging. The processing pipeline operates as an external script transitioning toward modular CLI tools. A downloader thread monitors configured sources and constructs items containing scan metadata, input paths, and expected outputs. Processor threads consume queued items, resolve dependencies through the catalog, execute scientific modules, validate outputs, write results atomically, and update state. Threads communicate exclusively through queues without shared mutable state, and algorithm modules remain stateless. The orchestrator supervises queue depth and dependency conditions without directly controlling thread execution. Multidimensional grids are stored in NetCDF, while tabular analysis and tracking outputs use Parquet for efficient columnar access. Partitioned directory structures enable scalable time-range queries. A metadata catalog records radar inventories, processing runs, product definitions, and lineage relationships. A data client supports batch queries and streaming mode, polling for newly completed products so dashboards can visualize segmentation masks, projected motion, and lifecycle metrics without disrupting active processing. Each execution is registered as a uniquely identified run storing configuration, radar selection, and product relationships, enabling deterministic replay of historical datasets using the same logic as real-time operation. Xarray provides labeled multidimensional data structures that preserve spatial coordinates and metadata, preventing index misalignment common in raw array workflows. Pydantic enforces strict configuration schemas and validates runtime parameters before execution. Dense motion fields are estimated using OpenCV’s Farnebäck optical flow on consecutive reflectivity frames, and cell geometries are derived using SciPy spatial triangulation methods. Py-ART provides Level-II decoding, coordinate transforms, and radar-specific processing foundations. Adapt remains in an alpha stage. Key development priorities include stronger dataset versioning and provenance tracking within the repository layer, improved support for concurrent reads during active writes, exploration of structured streaming and event-driven orchestration models, and development of interactive dashboards for operational visualization. Future work will also address containerized and distributed deployment for cloud-native scalability and object-storage–first architectures. The modular separation between orchestration, scientific computation, and data APIs allows independent evolution of components and invites community contributions in data management, streaming frameworks, visualization systems, distributed execution, and reproducibility practices. In summary, Adapt provides a modular, real-time architecture for adaptive radar scanning that enforces deterministic state management, contract-based validation, and repository abstraction. By eliminating thread entanglement and clearly separating system layers, it supports both historical reprocessing and operational guidance for live adaptive radar campaigns. scipy-2026-92113-adapt-prototyping-a-real-time-reproducible-data-analysis-framework-for-adaptive-radar-scanning Environmental, Earth, and Climate Sciences Bhupendra Raut en false https://pretalx.com/scipy-2026/talk/XZGSV7/ https://pretalx.com/scipy-2026/talk/XZGSV7/feedback/ Thomas Swain Room Talk 2026-07-15T16:05:00-05:00 16:05 00:30 Artificial Intelligence (AI) is reshaping meteorological science across two distinct frontiers. On one end, foundation-scale generative models, large-scale distributed training, and massive ensembles push the limits of high-performance computing and big-data orchestration. On the other, a "democratized edge" is emerging, where lightweight, heterogeneous inference workflows broaden access for experimentation. This dual expansion introduces a new class of software challenges spanning distributed training, ensemble-scale orchestration, and efficient, flexible inference pipelines. This talk will introduce Earth2Studio and PhysicsNeMo from NVIDIA, two software packages designed to enable and scale AI weather forecasting. By exploring their architectures, we will discuss the broader development journey of building AI-driven meteorological tools and share key lessons learned in managing the intersection of high-performance computing, data science and operational reliability. scipy-2026-92410-navigating-the-storm-software-orchestration-and-pipelines-for-ai-driven-weather-forecasting Environmental, Earth, and Climate Sciences /media/scipy-2026/submissions/ZZYN3X/image_UsgztaW.webp Nicholas Geneva en This is a talk for software engineers, data scientists, and climate researchers navigating the transition from classical simulation to AI-driven meteorology. The following core topics will be presented: **Framework Spotlight: NVIDIA PhysicsNeMo and Earth2Studio** We will introduce and compare two pivotal frameworks from NVIDIA's Earth-2 stack: - PhysicsNeMo: An open-source Python framework designed for developing AI-physics models at scale. We will discuss its architecture for high-throughput training specifically optimized for weather and climate datasets. - Earth2Studio: A modular inference and pipeline toolkit. We explore how Earth2Studio allows developers to chain together diverse data sources (ERA5, GFS, satellite) with pre-trained models to create production-ready AI workflows. **Architectural Paradigms in AI Weather** This talk dissects the various model paradigms currently dominating the field and the unique software requirements of each: - Prognostic Forecast Models: Such as StormScope, FourCastNet or GraphCast, which require stateful time-integration loops that autoregress forward in time, generating forecasts. - Diagnostic Models: Used for high-resolution downscaling (e.g., CorrDiff) or predicting new products from a forecast system relevant to a particular use case. - Data Assimilation Models: The bridge between raw satellite/sensor observations and model states, representing an emerging class of AI models accelerating weather and climate data assimilation. **The Challenges of the AI-Weather Stack** Moving from a research notebook to an operational service introduces significant challenges, which this session will address including: - Data Gravity & Structures: We will discuss the challenges of managing multi-petabyte datasets like ERA5 and the nuances of data formats (Zarr, NetCDF) when moving between high-bandwidth training and low-latency inference. - Scalability During Training: Designing models must have scalability in mind, navigating both the requirements for data pipelines as well as underlying architectures. State-of-the-art skill and impact often involves high-resolution and/or ensemble training, necessitating advanced parallelism techniques. - Operational Deployment: Lessons learned in deploying these models into production for users. - API Standardization & Model Interoperability: We will also discuss the challenges and solutions surrounding offering a large and diverse class of AI models under the same package(s) and providing a unified API for users. false https://pretalx.com/scipy-2026/talk/ZZYN3X/ https://pretalx.com/scipy-2026/talk/ZZYN3X/feedback/ University Hall Talk 2026-07-15T10:45:00-05:00 10:45 00:30 Bioimaging generates massive datasets in fragmented, proprietary formats that are difficult to share and align with FAIR principles. ngff-zarr is a lightweight, open-source Python toolkit implementing the OME-Zarr specification -- the community-driven, cloud-native bioimaging standard. With minimal dependencies and a simple pipeline interface, ngff-zarr converts, validates, and generates multiscale representations of extremely large images out-of-core via Dask. Features include multiple downscaling methods, OME-Zarr Zip archives (.ozx), RFC-4 anatomical orientation, and High Content Screening support. This talk also covers ngff-zarr's Model Context Protocol (MCP) server, which enables AI agents to perform bioimaging tasks through natural language, and lessons learned from its deployment at EMBL. scipy-2026-92398-a-lean-and-kind-ome-zarr-toolkit-for-bioimaging Biological and Medical Sciences /media/scipy-2026/submissions/TADDJP/image_Cas7m7A.webp Matt McCormick en **The problem.** Modern bioimaging instruments produce datasets that are large, multidimensional, and stored in vendor-specific proprietary formats. These monolithic files are not cloud-ready, are difficult to stream or share, and hinder reproducible, collaborative science. The community needs an open, chunked, cloud-native format backed by robust, accessible tooling. **OME-Zarr and the community.** OME-Zarr (OME-NGFF) addresses this need as a community-driven open standard built on Zarr's chunked, compressed, n-dimensional array storage. The specification and its ecosystem are described in Moore et al., "[OME-NGFF: a next-generation file format for expanding bioimaging data-access strategies](https://doi.org/10.1038/s41592-021-01326-w)," *Nature Methods*, 2021; Moore et al., "[OME-Zarr: a cloud-optimized bioimaging file format with international community support](https://doi.org/10.1007/s00418-023-02209-1)," *Histochemistry and Cell Biology*, 2023; and Lüthi et al., "[2024 OME-NGFF workflows hackathon](https://doi.org/10.37044/osf.io/5uhwz_v2)," *BioHackrXiv*, 2025. ngff-zarr is developed within and for this community. **ngff-zarr features.** [ngff-zarr](https://github.com/thewtex/ngff-zarr) is a lean, minimal-dependency implementation that is lazy, parallel, and web-ready -- no local filesystem required. Its features include: - A *simple Python interface* following a four-step pipeline: array to NgffImage to Multiscales to OME-Zarr store, accepting any Python Array API Standard input (NumPy, Dask, CuPy, PyTorch). - *Out-of-core multiscale generation* via Dask for processing extremely large datasets that exceed available memory. - *Multiple downscaling methods*: SIMD-accelerated Gaussian filtering via ITK-Wasm (default), bin shrink, label-image mode, and scipy-based fallbacks. - *OME-Zarr Zip (.ozx)* single-file archives for easy sharing and archival (RFC-9). - *RFC-4 anatomical orientation* metadata for medical and neuroimaging interoperability. - High Content Screening (HCS) plate/well support, TIFF/OME-TIFF and Leica LIF conversion, Zarr v3 sharding, and a command-line interface for batch workflows. **Python usage.** A typical conversion requires just a few lines: ```python import ngff_zarr as nz image = nz.to_ngff_image(array, dims=["z", "y", "x"], scale={"z": 2.0, "y": 0.5, "x": 0.5}) multiscales = nz.to_multiscales(image, scale_factors=[2, 4], chunks=64) nz.to_ngff_zarr("output.ome.zarr", multiscales) ``` Cloud stores (S3, GCS, Azure) are supported via fsspec, and the CLI (`ngff-zarr -i input.nrrd -o output.ome.zarr`) handles common batch workflows with memory-aware scheduling. **MCP server and lessons learned.** The `ngff-zarr-mcp` package exposes conversion, validation, inspection, and optimization tools to AI coding agents via the [Model Context Protocol](https://modelcontextprotocol.io/) (MCP). Researchers interact in natural language -- asking an AI assistant to convert a file, examine OME-Zarr metadata, validate spec compliance, or generate a batch processing script -- and the MCP server handles execution. Lessons learned include the importance of structured tool parameters for reliable agent interaction, designing functions that map to researcher intent rather than low-level API calls, and how natural language interfaces lower the barrier for scientists to adopt cloud-native formats and reproducible workflows. **Audience and takeaways.** Attendees will learn how to convert and manage bioimaging data with ngff-zarr's Python API and CLI, understand the OME-Zarr ecosystem, and see how MCP servers can bring AI-assisted automation to scientific data workflows. Source code: [github.com/fideus-labs/ngff-zarr](https://github.com/fideus-labs/ngff-zarr) | Documentation: [ngff-zarr.readthedocs.io](https://ngff-zarr.readthedocs.io) false Source code Documentation MCP Server PyPI Package https://pretalx.com/scipy-2026/talk/TADDJP/ https://pretalx.com/scipy-2026/talk/TADDJP/feedback/ University Hall Talk 2026-07-15T11:25:00-05:00 11:25 00:30 In the past year [Xarray](https://xarray.dev/blog/xarray-biology) has seen increased usage across various sub-fields of biology, revealing interesting challenges. It can be difficult to determine the best way to represent a data structure (e.g. anndata, NGFF-Zarr) as an Xarray object. Furthermore, some use cases such as whole brain imaging require the use of lesser known Xarray features such as custom indexes. In this talk I will showcase examples of how to encode common biological data structures as Xarray objects. Finally, I will demonstrate how the custom index infrastructure has expanded what types of data can be usefully encoded in Xarray. scipy-2026-93248-xarray-datastructures-in-biology-examples-and-best-practices Biological and Medical Sciences Ian Hunt-Isaak en ## Background Biological datasets come in a wide variety of shapes, sizes, and types. However, there are common challenges faced across biology when dealing with complex structured data, such as keeping track of real-world coordinates. [Xarray](https://docs.xarray.dev/en/stable/getting-started-guide/why-xarray.html) provides a powerful solution to these issues. Additionally, Xarray provides first class support for HDF and Zarr files, formats already in wide use in biology. ## Issues Increased usage in various projects has revealed issues around converting existing data structures into Xarray. For example some Napari developers use Xarray to keep track of physical units from images, but they struggled with the fact that various libraries had different conventions for encoding metadata into Xarray. That struggle is exemplary of a larger issue: The best way to convert an existing data structure (on disk or in memory) to Xarray may not be obvious, especially for newer users of Xarray. Or it is possible to be unaware of functionality (e.g. Custom Indexes) necessary to fully represent a data structure. ## Success Stories These conversion difficulties are solvable. I will present three examples of successful conversion of common biological data structures to Xarray. Through these I will discuss, what worked, what was hard, and recommendations for anyone interested in using Xarray for biology. - Microscope Images: [OME-Zarr (NGFF)](https://ngff.openmicroscopy.org/) - Omics Data: [AnnData](https://anndata.readthedocs.io/en/stable/) - Multimodal data (Single cell Raman Spectroscopy + Microscope Images + Lipidomics) ## Indexes A key enabling technology to allow some biological data structures to be represented in Xarray is the ability to write custom indexes. Custom indexes are powerful tools that can also encode complex interconnected relationships in metadata data structures and allow sophisticated selection queries. However they are not yet well known in the community. To showcase their use I will demonstrate the [indexes](https://ianhuntisaak.com/xarray-linked-indexes) developed for a real world use case of combined speech and intracranial EEG data. These indexes also show the benefits of cross field collaboration as they are useful in non-biological applications as well. Xarray also has newly built-in Indexes built using the custom index infrastructure. These indexes allow for opening huge data sets, such as whole brain images, which would previously have resulted in out of memory errors. I will show how these indexes enable opening a sectioned brain image in Xarray. ## Conclusion To conclude I will summarize the advice on how to convert a biological data structure into an Xarray object, and how to fully leverage Xarray’s functionality. This will include how to think through: - How metadata maps to Xarray - What kinds of selection queries you need - The practicalities of data loading Finally, and most importantly, advice on how to do this as a community, and where to get help. ### Context Blog posts: https://xarray.dev/blog/xarray-napari-plan https://xarray.dev/blog/flexible-indexing https://xarray.dev/blog/xarray-biology Prior SciPy Talk about Xarray and Biology: https://www.youtube.com/watch?v=ujOseM1Bk1g That talk focused on introducing the idea of Xarray - this talk is more concrete with examples and advice on loading data into xarray and what to do with it once there. **Speaker** I am a multimodal-microscopist who has since branched out to support multiple areas of Biology in my role as the Xarray Community Developer where I focus on ensuring Xarray has the tools biologists need and educating biologists about how Xarray might be useful for them. false https://pretalx.com/scipy-2026/talk/ETT3W9/ https://pretalx.com/scipy-2026/talk/ETT3W9/feedback/ University Hall Talk 2026-07-15T13:15:00-05:00 13:15 00:30 At CERN's Large Hadron Collider, we collide protons at near light-speed to discover new particles and understand fundamental physics. Python is becoming the primary language for analyzing this data, marking a significant evolution from the Fortran and C++ workflows of previous decades. This talk explores the modern Python-based analysis pipeline of High-Energy Physics (HEP) and the technical challenges it addresses. We'll present how we handle nested, jagged data structures and work with data at the petabyte scale using the community-driven Scikit-HEP ecosystem of specialized tools for efficient and high-performance data analysis. We'll show how we're building a Python stack that integrates with distributed computing frameworks and leverages GPU acceleration. Beyond domain-specific analysis tools, HEP's transition to Python has driven improvements to the broader Python packaging ecosystem, including contributions to cibuildwheel, the development of scikit-build-core, and advances in pybind11, benefiting anyone building Python packages with compiled extensions. scipy-2026-92409-discovering-particles-how-we-analyze-petabytes-of-particle-collision-data-using-python Physics and Astronomy Iason KrommydasHenry Schreiner en This talk takes you inside the data analysis pipeline at CERN's Large Hadron Collider, where physicists are transitioning from decades of Fortran and C++ workflows to Python-based analysis. We'll explore the technical challenges of working with petabyte-scale, nested data, and show how the solutions developed for High-Energy Physics (HEP) have become valuable tools for the broader Python community. We will begin with understanding why HEP computing evolved the way it did. Fortran dominated for decades, then C++ and the ROOT framework became standard in the 90s. We'll explain what triggered the recent shift toward Python: the maturation of NumPy and the scientific stack, the need for faster iteration, and the desire to make analysis more accessible. This history explains the design constraints and opportunities that shaped today's tools. At the heart of modern HEP analysis is Scikit-HEP, a community-driven collection of Python packages. We'll dive into the key components: uproot enables pure-Python access to ROOT files without C++ dependencies, Awkward Array provides NumPy-like operations on jagged data structures, hist delivers high-performance histogramming, and additional libraries handle vector math and statistical fitting. Through code examples, we'll demonstrate how these pieces fit together in an actual analysis workflow. One of the most interesting technical problems is the structure of collision data itself. When protons collide, each event produces a different number of particles, each with multiple properties. Traditional rectilinear arrays can't represent this naturally. You need nested, variable-length arrays. This isn't just a physics problem; it's the same challenge you face with nested JSON-like data. We'll show how Awkward Array's approach to jagged data offers an elegant solution that's applicable far beyond physics. Scale presents another major challenge. The High-Luminosity LHC upgrade will require analyzing petabytes in under an hour. We'll present our approach: leveraging distributed computing systems (like Dask) across clusters, using GPU acceleration where it provides the most benefit, and designing analysis facilities that colocate computation with data storage. These patterns are relevant to anyone tackling large-scale data problems. HEP's relatively late adoption of Python created an interesting dynamic: we needed production-quality infrastructure for building binary extensions but didn't have legacy tools to maintain. This drove significant contributions to the Python packaging ecosystem. We needed reliable cross-platform wheel building for packages like boost-histogram, awkward, and iminuit, which led to major improvements in cibuildwheel. We needed better build systems for C++ extensions, which resulted in scikit-build-core. We pushed forward pybind11 development and originally created the Scientific Python development guide and cookie template. These infrastructure improvements now benefit anyone distributing Python packages with compiled code. The broader theme is how domain-specific needs can drive general-purpose innovation. The tools and infrastructure HEP has developed address problems common across scientific computing and data engineering. false https://pretalx.com/scipy-2026/talk/BG3PSA/ https://pretalx.com/scipy-2026/talk/BG3PSA/feedback/ University Hall Talk 2026-07-15T13:55:00-05:00 13:55 00:30 Quantum computers promise to tackle strongly correlated molecular systems that defeat classical electronic-structure methods, but realizing quantum utility depends on every stage of the pipeline, not just the quantum algorithm. QDK/Chemistry, an open-source package in the Microsoft Quantum Development Kit, treats this entire pipeline as a single, modular Python framework. Immutable data classes and stateless algorithms with fixed interfaces let researchers swap backends without changing application code. This talk introduces QDK/Chemistry's composable architecture, shows how classical and quantum stages interoperate to minimize quantum resources, and offers design patterns applicable beyond quantum computing. scipy-2026-101378-qdk-chemistry-a-composable-python-toolkit-for-end-to-end-quantum-chemistry-on-quantum-computers Physics and Astronomy David Williams-Young en QDK/Chemistry is an open-source package in the Microsoft Quantum Development Kit that provides a composable, end-to-end framework for quantum chemistry on quantum computers. It spans every stage of the quantum-classical workflow, from molecular setup and classical reference calculations through active-space reduction, Hamiltonian construction, fermion-to-qubit encoding, state preparation, and measurement. These stages are connected through a unified Python API backed by a high-performance C++ core. The design rests on immutable data classes and stateless algorithms with fixed interfaces. A factory/registry plugin system makes every algorithm slot interchangeable: a researcher can swap a native backend for third party packages (e.g. PySCF, Qiskit, OpenFermion), or a custom implementation by changing a single string, with no rewiring of application code. Benchmarking, backend mixing, and custom extension are first-class operations rather than rewrites. Because every stage is an interchangeable module, classical methods generate the high-quality inputs that quantum algorithms depend on, and the same classical results serve as baselines for judging where quantum methods offer genuine utility over the classical state of the art. The emphasis throughout is on minimizing quantum resources at every step and on making workflows reproducible and shareable. Reproducible serialization in XYZ, JSON, and HDF5 formats supports shareable, benchmarkable workflows across groups. QDK/Chemistry is available on PyPI, with documentation, examples, and companion datasets openly available. false https://pretalx.com/scipy-2026/talk/SX9977/ https://pretalx.com/scipy-2026/talk/SX9977/feedback/ University Hall Talk 2026-07-15T14:35:00-05:00 14:35 00:30 Many scientific workflows rely on derivatives of complex models: Fisher forecasts, sensitivity analysis, gradient-based inference, and emulator construction. In practice, these derivatives are often difficult to compute reliably and integrate into end-to-end inference pipelines. DerivKit is an open-source Python toolkit that provides a unified framework for derivative-based scientific inference. It supports multiple derivative backends and connects model evaluation directly to downstream inference tools, including Fisher analyses and higher-order likelihood approximations. The framework also provides diagnostics and visualization tools for exploring parameter sensitivities and degeneracies. Originally developed for cosmological forecasting pipelines, DerivKit is designed to be domain-agnostic and easily integrated into scientific Python workflows. scipy-2026-93247-derivkit-end-to-end-derivative-based-inference-in-scientific-python Physics and Astronomy /media/scipy-2026/submissions/BFQAPR/image_DRsXSyg.webp Niko SarcevicMatthijs van der Wild en Many scientific workflows rely on derivatives of complex computational models. Derivatives are central to Fisher forecasting, sensitivity analysis, gradient-based inference, emulator construction, and uncertainty propagation. In practice, however, derivative calculations are often implemented in ad-hoc ways within individual projects. This makes them difficult to reproduce, hard to diagnose when they fail, and challenging to integrate with downstream inference tools. DerivKit is an open-source Python toolkit designed to provide a structured framework for derivative-based scientific inference. The goal of the project is to connect model evaluation, derivative computation, and inference tools into a coherent workflow that is easy to use and inspect. Rather than focusing on a single derivative technique, DerivKit provides a unified interface for multiple derivative backends and supports flexible strategies for computing derivatives of arbitrary scientific models. The framework allows users to wrap an existing model function and automatically construct derivative operators with respect to model parameters. These derivatives can then be used directly in inference pipelines, including Fisher matrix forecasts and higher-order likelihood approximations (DALI). In particular, DerivKit provides implementations of higher-order likelihood expansions that extend beyond the Gaussian Fisher approximation, enabling users to explore parameter degeneracies and non-Gaussian structure in likelihood surfaces. An important design goal of DerivKit is to make derivative-based inference transparent and diagnostic-friendly. The toolkit includes utilities for evaluating derivative stability, exploring parameter sensitivities, and visualizing degeneracies in model parameter spaces. These diagnostics help users identify when derivatives are unreliable or when parameter combinations produce nearly degenerate model responses. DerivKit also supports a direct model-to-plot workflow that allows users to move seamlessly from derivative computation to visual analysis of inference results. Although DerivKit was originally developed for cosmological forecasting pipelines used in large astrophysical collaborations, the design of the framework is intentionally domain-agnostic. Many areas of scientific computing face similar challenges when working with derivatives of expensive or complex models. These include climate modeling, epidemiological simulations, materials science, and simulation-based inference workflows. By separating derivative infrastructure from domain-specific modeling code, DerivKit aims to provide a reusable tool that can integrate naturally into a wide range of scientific Python environments. This talk will introduce the design principles behind DerivKit and demonstrate how derivative infrastructure can be organized to support robust scientific inference workflows. We will discuss common pitfalls in numerical derivative calculations, present the architecture of the DerivKit framework, and show examples of derivative-based inference applied to realistic models. Attendees will learn how to structure derivative computations in a reproducible way, how to diagnose instability and parameter degeneracies, and how derivative-based methods such as Fisher analyses and higher-order likelihood approximations can be incorporated into scientific Python pipelines. false https://pretalx.com/scipy-2026/talk/BFQAPR/ https://pretalx.com/scipy-2026/talk/BFQAPR/feedback/ University Hall Talk 2026-07-15T15:25:00-05:00 15:25 00:30 Genomic workflows remain tightly coupled to specialized file formats, forcing researchers to build brittle pipelines of format-specific CLI tools. We present projects that help shift this emphasis away from file parsing and towards declarative querying. Oxbow is a library that projects common genomic formats into Apache Arrow, enabling zero-copy integration with data frame libraries and analytics engines. GIQL (Genomic Interval Query Language) is an extended SQL dialect supporting genomic interval operations and semantics that transpiles to standard SQL, making genomic queries composable, readable, and backend-agnostic. Together, this architecture also facilitates the integration of genomic data into data warehouse and lakehouse platforms as well as agentic MCP workflows. scipy-2026-92475-declare-don-t-parse-composable-genomic-analysis-with-giql-and-oxbow Biological and Medical Sciences Nezar AbdennurConrad Bzura en Genomic data tools remain tightly coupled to specialized file formats, forcing researchers to build brittle pipelines of format-specific CLI tools connected by ad hoc serialization. Meanwhile, standard SQL -- the lingua franca of data analytics -- lacks the vocabulary to express genomic interval relationships and operations that are fundamental to the field. To address both of these issues, we present a pair of projects that together shift the emphasis in genomics from file parsing towards declarative querying. The first project, Oxbow, is a Rust-based adapter library that projects common genomic file formats, including BAM, VCF, BED, GTF, BigWig, and others, into Apache Arrow, a standard columnar in-memory representation for tabular analytics. By leveraging Arrow's C Data Interface, Oxbow streams records to Python with zero copy overhead, integrating directly with Polars, DuckDB, and Dask without intermediate serialization. Oxbow supports indexed range queries, column projection push-down, and remote data access via HTTP and object storage, enabling researchers to query genomic files hosted in the cloud without downloading them locally. The second project, GIQL (Genomic Interval Query Language, pronounced “JEE-quel”) is an extended SQL dialect and transpiler for genomic interval operations. GIQL introduces domain-specific operators, such as INTERSECTS, WITHIN, and NEAREST, that let researchers express genomic interval logic and spatial joins declaratively. For example, `WHERE a.interval INTERSECTS b.interval` transpiles into standard SQL predicates that any engine can execute. Because the transpiler targets standard SQL, it is backend-agnostic: the same query runs on DuckDB, Polars, SQLite, or any SQL-compliant engine. GIQL provides a declarative alternative to bedtools-style scripting, making genomic queries composable, readable, and reproducible. These libraries work together, where Oxbow streams legacy genomic files as Arrow record batches into a SQL engine, and GIQL provides the extended query semantics to interrogate them. We will demonstrate this composition in practice. By building on open, domain-agnostic standards, this architecture also facilitates the integration of genomic data into modern data warehouse and lakehouse platforms as well as agentic MCP workflows. false https://pretalx.com/scipy-2026/talk/NEKFB8/ https://pretalx.com/scipy-2026/talk/NEKFB8/feedback/ University Hall Talk 2026-07-15T16:05:00-05:00 16:05 00:30 Engineering enzymes with improved catalytic activity remains a central challenge in biotechnology. In this research, we focus on engineering PETase, a plastic-degrading enzyme, as a testbed for developing a simulation-informed machine learning workflow. We present a Python framework that integrates molecular simulations, docking, and structural analysis with modern machine learning methods to predict enzyme activity from sequence and structure. By combining simulation-derived descriptors—including active-site geometry, electrostatics, stability metrics, dynamics, and docking scores—with sequence embeddings, we generate interpretable predictions that guide rational mutation strategies. While developed for PETase engineering, the workflow is extensible to broader de novo enzyme design efforts. scipy-2026-92488-simulation-informed-machine-learning-workflows-for-petase-engineering Biological and Medical Sciences Sai Sanjana PrakashCharlie HouJustin Kashi en Polyethylene terephthalate (PET) plastic degradation has emerged as a major environmental challenge. The discovery of PETase, originally identified in Ideonella sakaiensis, opened new possibilities for enzymatic plastic recycling. However, improving PETase stability, activity, and substrate specificity remains an open problem in protein engineering. In this presentation, we introduce a modular Python workflow designed specifically to engineer improved PETase variants. The workflow integrates molecular modeling tools—including Rosetta, FoldX, and AMBER molecular dynamics simulations—with docking and modern machine learning frameworks (scikit-learn and PyTorch). Rather than relying purely on sequence-based ML, We incorporate simulation-informed descriptors such as: - Electrostatic potential and catalytic residue environment - Stability and ΔΔG predictions - Molecular dynamics–derived flexibility metrics - Docking scores with PET oligomers These simulation-derived features are combined with sequence embeddings to predict enzyme activity in an interpretable manner. This enables rational mutation prioritization rather than black-box screening. Key components include: **1. Data Pipelines** Standardized processing of sequence variants, simulation outputs, structural descriptors, and docking results in an automated and reproducible workflow. **2. Simulation-Informed Feature Engineering** Integration of structural, dynamic, and energetic descriptors with learned sequence embeddings. **3. Machine Learning Modeling** Cross-validation, uncertainty estimation, and careful evaluation to ensure robust predictive performance. **4. Interpretability for Engineering** Feature attribution methods to identify which structural or dynamic properties most strongly influence predicted activity — directly informing mutation strategies. We demonstrate the workflow by engineering PETase variants with predicted improvements in catalytic efficiency and stability. By integrating docking of PET oligomers, molecular dynamics simulations, and ML prediction, we show how simulation-informed features improve predictive performance compared to sequence-only baselines. This PETase-focused approach illustrates how tightly integrating physics-based simulations with machine learning enables actionable design decisions. While PETase is the immediate application, the framework generalizes to other enzyme families, offering a reproducible and extensible foundation for computational protein engineering. **What Attendees Gain** - A concrete PETase engineering case study - A reproducible Python-based workflow integrating simulations and ML - Practical strategies for combining docking, MD, and ML - Methods for interpretable prediction and rational mutation design - An extensible framework adaptable to other enzyme systems false https://pretalx.com/scipy-2026/talk/RE9ETJ/ https://pretalx.com/scipy-2026/talk/RE9ETJ/feedback/ University Hall Poster Session 2026-07-15T18:00:00-05:00 18:00 01:00 The Poster session will be in University Hall from 6:00-7:00pm. Meet with the poster authors to ask questions and learn about the posters that will be on display throughout the main conference. scipy-2026-97796-poster-session Poster Session en 1. **Hannes Hapke, David Cardozo, Triveni Gandhi** - Opening the Black Box: Mechanistic Interpretability of Agent Tool Selection with Sparse Autoencoders (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 2. **Gita Mohammadi** - Using Scientific Python to Study Trigger Efficiencies in Searches for New Higgs Bosons at CERN (Spirit of SciPy) 3. **Rudraksh Karpe, Shivay Lamba, Suvrakamal Das, Satyam Soni** - Python Carbon Loops: Closing the Feedback Loop Between Your Code and Its Climate Impact (Environmental, Earth, and Climate Sciences) 4. **Venkateswaran Shekar** - RECAP: A Python framework for reproducible experiment capture and provenance (General) 5. **Emmanuel I. Obi** - Teaching Python the Difference Between Radiation Dose and Damage (Biological and Medical Sciences) 6. **Alexander Luebbert** - Data-Driven Optimization Framework for Competitive Performance in FIRST Robotics Competition (Scientific Computing in Education) 9. **Carlos García Jurado Suarez** - Efficient Federated Inference on Entomology Images with PyTorch (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 10. **Allison Ding** - Minimizing Noise Clusters in Topic Modeling: A Scalarized Hyperparameter Optimization Approach with GPU Acceleration (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 11. **Nick Hodgskin** - Modernising Parcels for the era of Cloud-Native Geospatial data (Environmental, Earth, and Climate Sciences) 12. **Daniel McCloy, Eric Larson, Britta Westner** - On-boarding and retaining maintainer talent for MNE-Python (Maintainers and Community) 13. **Noor Aftab** - Building with Agents: The Open Source Story of the Scientific Repo-Agent (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 14. **Deven Maheshwari** - Climate is not a straight line: Scalable Python-based GAMM Workflows for Wildlife Conservation (Environmental, Earth, and Climate Sciences) 15. **Avik Basu** - Right Predictions, Wrong Reasons: Explanation Drift Monitoring in Production (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 16. **Erik Bolch, Mahsa Jami** - Multi-Sensor Earth Science Made Easy: NASA VITALS (Environmental, Earth, and Climate Sciences) 17. **Rachael Sexton** - Trimming the Hairball: Three Libraries for Better Network Recovery & Metrology (General) 18. **Abby Mitchell** - Unravelling the mystery of free threading for scientific computing (General) 19. **Joe Cheng, on behalf of Isabella Velásquez** - Merging without fear: Using validation to protect your Python workflows (General) 20. **Aishwarya Chander, Christian La France, Alexander** - A Cloud-Native Single-Cell Data Analysis pipeline with Zarr, Icechunk, and RAPIDS-singlecell (Biological and Medical Sciences) 21. **Richard Iannone** - Creating beautiful documentation sites for Python libraries with Great Docs (Maintainers and Community) 22. **Tarun Gandrathi** - Building Trustworthy Scientific Python Workflows in Pharma (Biological and Medical Sciences) 23. **Jesse Loi** - Bridging the Technical Gap: A Student-Led RAG Pipeline for Community-Driven Document Analysis (Scientific Computing in Education) 24. **Dylan Madisetti** - Hash all the things: Caching for fast notebook restarts (General) 25. **Bhupendra Raut** - Adapt: Prototyping a Real-Time, Reproducible Data Analysis Framework for Adaptive Radar Scanning (Environmental, Earth, and Climate Sciences) 26. ** Adam Theisen** - From Towers to Lidars: ACT Unifies Atmospheric Data into Reproducible Python Workflows (Environmental, Earth, and Climate Sciences) 27. **Marc Berliner** - 5x Fewer Stored Time Steps with Certified Accuracy: A Streaming Compression Algorithm for Adaptive Differential Equation Solvers (Environmental, Earth, and Climate Sciences) 28. **Lucas Sterzinger** - Improving access of HDF5/NetCDF4 data in S3 cloud storage: a case study using NASA Land Surface Model data (Environmental, Earth, and Climate Sciences) 29. **Sruthi Pisipati, Haris Javed** - Everything That Breaks When You Put an LLM Agent in Production (Data-Driven Discovery, Machine Learning and Artificial Intelligence) false https://pretalx.com/scipy-2026/talk/QF7KXB/ https://pretalx.com/scipy-2026/talk/QF7KXB/feedback/ Virtual Sessions Poster Session 2026-07-15T18:00:00-05:00 18:00 01:00 The Virtual Poster session will be hosted on Gather from 6:00-7:00pm. Gather is a browser-based virtual conference platform that allows participants to move around a digital conference space using customizable avatars. As attendees walk through the poster hall, they can view poster thumbnails, open full-size posters, and start video or audio conversations with presenters nearby. No software installation is required; Gather runs directly in your web browser. scipy-2026-99515-virtual-poster-session Poster Session en 1. **Georg Heiler, Daniil Gafni** - Versioning Multimodal Data with Metaxy (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 2. **Emmanuel I. Obi** - Define Your Own Dimensions: Algebraic Unit Conversion Beyond SI, CGS, and Natural Units (General) 3. **Yu-Lin Chen, Tyng-Ruey Chuang | 莊庭瑞, Cheng-Jen Lee | 李承錱** - Toward Reliable Localization of Free and Open Source Software: LLM-assisted Translation Workflows for QGIS (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 4. **Pavan BG** - NODEFit - Fit time-series data with a Neural Differential Equation (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 5. **Jeroen Janssens** - From Script to Tool: Leveling Up Your Python Workflow (General) 6. **Taewoon Kim** - From Transactions to Vectors: Embedded Multi-Model Data Workflows in Scientific Python (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 7. **Rodrigo Silva Ferreira** - 25 Years of Interactive Scientific Computing: From IPython and Jupyter to IDE-Native Notebooks (Spirit of SciPy) 8. **Rene Lagos** - A Reproducible "Data Lakehouse" for High-Resolution Gastric Cancer Epidemiology Study in Chile (Biological and Medical Sciences) 9. **Srilakshmi Bharadwaj** - When “Scalable” Isn’t Scalable: Real Lessons from Production Data Systems (General) 10. **Rylie Weaver** - alphagenome-pt: Training AlphaGenome Models in PyTorch (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 11. **Pankaj Arora** - AI-Driven Inventory Redistribution Between Hospitals to Reduce Waste and Shortages Using Predictive Analytics 12. **Gift Ojeabulu** - Why Reproducibility Still Fails in Modern Machine Learning (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 13. **Shaurya Agarwal** - The Silmaril strikes again - Practical Ontology Engineering for AI, Reasoning Engines and Real-World Applications (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 14. **Prashant Badiger, Gajendra Deshpande, Mallikarjun mrityunjaya** - math - Real-Time AI/ML-Based Phishing Detection and Prevention Using the Python (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 15. **Mohd Toukir Khan** - Beyond First PRs: Converting Students into Long-Term Open Source Contributors (Maintainers and Community) 16. **Aayush Gauba** - Numerical Stability Pitfalls in Scientific Optimization Pipelines (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 17. **Kedar Dabhadkar** - Self-Evolving Skill Graphs: Using Reflective Optimization for AI Agent Skill Organization (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 18. **Ahmad El Hajj** - Density Functions and Random Number Generators of Alpha-Stable Distributions (Scientific Computing in Education) 19. **Daniel Samuel Etukudo** - Using Food and AI to Manage Chronic Conditions (General) 20. **Aayush Gauba** - Detecting Anomalies in Scientific Data Using SciPy’s Statistical and Signal Tools (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 21. **Conor Hoekstra** - Parrot Python: Fused Array Operations for the GPU (General) 22. **Johannes Plambeck** - Optimising HCP Sample Allocation in Pharma: Combining Non-Linear Ensemble Learning, Spatial Lags, and Integer Programming (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 23. **Rudraksh Karpe, Shivay Lamba, Suvrakamal Das, Satyam Soni** - Recursive Language Models (RLMs): Scaling to Infinite Context via Programmatic Decomposition (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 24. **Gauri Sarode** - When Search Becomes Intelligent: The Rise of LLMs and AI Agents in Discovery Systems (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 25. **Sanjiban Sengupta** - A Unified Inference Interface for Low-Latency Machine Learning in High-Energy Physics (Physics and Astronomy) 26. **Sho Tanaka** - Avoiding Zero-Trade Policies in RL with a Decoupled MLOps Architecture (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 27. **Lucas Squarize Chagas, Avik Basu** - The Missing Lever in ML Deployment: Threshold Tuning using Regression Discontinuity (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 28. **Arunkumar Amaran** - Conversational AI Interfaces for Retail Data Engineering and Business Intelligence (General) 29. **Shivika Bisen** - Solving the AI Eval Gap: Domain-Aware Evals for Production AI Agents (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 30. **Petr Andreev** - JIT in the Wild: CPython’s Next Step vs PyPy and V8 (With Real Benchmarks) (Scientific Computing in Education) 31. **Petr Andreev** - CPython Under Load: NoGIL, Green Threads, AsyncIO vs Other Langs: deep-dive and benchmarks (Scientific Computing in Education) 32. **GUSTAVO COELHO HAASE, PAULO DOURADO** - PanelBox: A Comprehensive Python Library for Panel Data Econometrics (General) 33. **Vinay Vyas** - Benchmarking Edge-Accelerated Genomics: A Pilot Study of Unified Memory Architectures in Deep-Sea Metagenomics (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 34. **A Seshaditya** - Large Language Models and Physics-AI for Fluid Dynamic Simulations (Physics and Astronomy) 35. **Sauhard Bhatt** - Mr. (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 36. **Ruben Huidekoper, Camila Birocchi** - Be Your Own Consultant: Start Self-Diagnozing Your BI Tech Stack (General) 37. **Viraj Sharma** - XAI - MechInterp and Causal Visualizations (Data-Driven Discovery, Machine Learning and Artificial Intelligence) 38. **Shaurya Agarwal** - Vogon Poetry - Columnar Data, Zero-Copy, etc. etc.: key ideas for data and AI teams to up their game… (Data-Driven Discovery, Machine Learning and Artificial Intelligence) false https://pretalx.com/scipy-2026/talk/UZB8CN/ https://pretalx.com/scipy-2026/talk/UZB8CN/feedback/ Memorial Hall Keynote 2026-07-16T09:15:00-05:00 09:15 00:45 Research Director at the Metagovernance Project and founder of The Calm Tech Institute scipy-2026-97807-keynote-amber-case-calm-technology-and-the-history-of-ai Keynotes Amber Case en Amber Case's work explores the intersection of humans and technology, challenging us to design systems that inform rather than overburden. Case is redefining the relationship between humans and technology. As the founder of the Calm Tech Institute and a former fellow at MIT and Harvard, Case brings a profound perspective on how we can design complex systems to be calm: interfaces that work with peripheral attention and inform at different resolution levels. In her keynote, "Calm Technology and the History of AI," she will explore moving from "smart things" to "smarter people," how to design systems that inform us without overwhelming us, why the future of interface design might involve bringing back the button, and how to ensure modern systems are built in line with how the different parts of our brains interpret information. false https://pretalx.com/scipy-2026/talk/7UJUMK/ https://pretalx.com/scipy-2026/talk/7UJUMK/feedback/ Memorial Hall Tools Plenary 2026-07-16T10:00:00-05:00 10:00 00:25 A session featuring updates and roadmaps from maintainers of core Scientific Python libraries and tools. scipy-2026-97805-scipy-tools-plenary SciPy Tools en false https://pretalx.com/scipy-2026/talk/B9GAJH/ https://pretalx.com/scipy-2026/talk/B9GAJH/feedback/ Memorial Hall Talk 2026-07-16T10:45:00-05:00 10:45 00:30 Did you know that waffles were invented in the 14th century? Is Acetaminophen gluten free? If you said "yes" to both questions, you must have seen [Damon McDougall's legendary SciPy 2014 lightning talk](https://www.youtube.com/watch?v=ln4nE_EVDCg&t=3255s). Let's distill the lore of lightning talks and touch on SciPy culture over the years and "make sure we get all the history" (or a yeast squares sparse low rank approximation of it) Gather 'round, slithering scientists, and ye shall hear a beer-ful of stories, of yesteryear The Spirit of SciPy is the Track MC Pi (that's me), has got your back Been coming to the conference since 2009 Sharing memories and photos, which we'll all combine some will be profound, others asinine Honey, do you mead more proof? scipy-2026-93260-pun-intended-consequences Spirit of SciPy Paul Ivanov en Lighting talks are a perennial favorite for SciPy attendees. Let's celebrate the connection we make here, and give others a glimpse into our amazingly resourceful and creative community. I started coming to SciPy as a sponsored graduate student (2009-2011), gave talks in '13 and '14, started hosting lightning talks with Anthony Scopatz '17-'19, also volunteered as Communications Chair '18-'19, Program Co-Chair '20, '23, '24. Some of the SciPy lightning talks I co-hosted with Anthony Scopatz are linked in the middle of this page: https://pirsquared.org/talks/ (2017-2019). I also [gave my first and only SciPy Lighting talk in 2022](https://youtu.be/m3JbmBxKPBY?t=2898) Some of the photos I have I've also previously shared and talked about at the inaugural "Another Open Source Podcast" hosted by when I was a guest along with Madicken Munk https://open.spotify.com/episode/4LArGQQtRqGrixS9vnpNZk - [SciPy 2009](https://www.flickr.com/photos/tags/scipy2009) - last one at CalTech in Pasadena, CA - [SciPy 2010](https://www.flickr.com/photos/tags/scipy2010) - first one in Austin, Texas - [SciPy 2011](https://pirsquared.org/scipy2011/) false SciPy 2009 videos on Archive.org SciPy 2010 Python Evangelism 101 - Peter Wang SciPy 2014 Waffles Lightning Talk - Damon McDougal Robert Kern's excellent audio-visual combination from 2021 SciPy Five debut @ SciPy 2022 (Here at SciPy - tell me why!) https://pretalx.com/scipy-2026/talk/PSQLHP/ https://pretalx.com/scipy-2026/talk/PSQLHP/feedback/ Memorial Hall Talk 2026-07-16T11:25:00-05:00 11:25 00:30 After 3 years, Pixi is widely adopted in the scientific Python ecosystem. At SciPy 2026, we want to show why. Scientific Python has specific challenges that Pixi can solve well; a lot of our beloved packages contain C, C++, Rust, CUDA or even Fortran code. With Pixi, a single tool can install the compilers, different Python versions and other build tools in one go, thanks to piggy backing on the years of development that the Conda ecosystem has seen. Thanks to Pixi’s task system and native multi-platform capabilities, the contributor experience is also enhanced. Daunting tasks like running CMake, installing the correct Rust version or C++ compilers are all hidden away behind a magical: `pixi run foobar`. Are you interested to see how you could improve your own workflow and learn from what these big open-source projects are doing? Then you should join this talk! You'll be amazed by what is possible these days. scipy-2026-92076-scipy-numpy-xarray-and-python-all-have-a-pixi-toml-why General Ruben Arts en Pixi is getting widely adopted in the Scientific Python community. Projects such as [Python](https://github.com/python/cpython/tree/main/Tools/pixi-packages) itself, [NumPy](https://github.com/numpy/numpy/tree/main/pixi-packages), [SciPy](https://github.com/scipy/scipy/blob/main/pixi.toml), [cuda-python](https://github.com/NVIDIA/cuda-python) and [Xarray](https://github.com/pydata/xarray) have a `pixi.toml` file in their repository. Through the heroic work of Lucas Colley and other contributors, even CPython has a pixi.toml now. In this talk we want to explain what this means and what improvements this brings for users and contributors! Pixi helps for the following reasons: Primarily Pixi creates one or more environments on the developer machine containing Conda and Python packages (under the hood, uv is used to resolve and install Python packages). All packages are added to a lockfile that is used to recreate environments in a reproducible way. Pixi can bootstrap the entire development environment in seconds, including a consistent set of compilers, shared libraries, and other low-level pieces. Pixi’s task system makes it easy for contributors (old and new) to get started. Developers can add tasks such as lint, build, start, … to the pixi.toml file. This simplifies the commands that need to be remembered when starting out with a project. It makes it also easy to have “portable CI”. Pixi can run these tasks on Github, Gitlab, CircleCI on any operating system. Advanced use cases: The `pixi.toml` files in the CPython project are mainly used for advanced tasks such as building CPython itself with address sanitization turned on. Thanks to Pixi, downstream projects (Numpy, SciPy, …) can depend on CPython from source. This is enabled by the powerful `pixi build`. Pixi build brings building projects from source into packages to Pixi itself. Usually, package consumers and builders are quite disjoint in the Conda ecosystem! With Pixi you can now run crazy things like `pixi global install --git https://github.com/python/cpython --subdir Tools/pixi-packages/asan python` to obtain the latest version of Python built from main installed globally on your system. Our talk will also cover the following topics: - What is Pixi and the conda-ecosystem? - How do these big open source projects use Pixi? - What steps can one take to benefit from Pixi in their workflow? Pixi itself is open source under the BSD3 Clause, written in Rust and embeds astral-sh's uv to help with combining conda and Python packages into one virtual environment. Pixi is built on the rattler base library that is used in all sorts of different conda tools and is also making it's way into conda and conda-build. Some of the previously mentioned projects started to use Pixi because of one specific feature: cross-platform source building of Git packages into a local development environment. This experience is similar to depending on a package from source in a python environment but Pixi also takes care of all the complex compiler and low level system libraries that a user might require to have on their system. This feature has proven very useful for testing the latest (pre-release) versions of projects in their upstream environments. These workflows come with a few key steps: - Building packages from source code, from git or paths - Installing virtual environments on any platform, Windows, macOS, Linux - Reproducible environments with lockfiles - Cross-platform Makefile-like task system with Pixi tasks - Deployment with easy to share artifacts Relevant links: - Pixi repository: https://github.com/prefix-dev/pixi/ - Pixi documentation: https://pixi.prefix.dev/latest/ - Rattler repository: https://github.com/conda/rattler - SciPy 2025 talk: https://www.youtube.com/watch?v=UeyMkK5MzcA&t=5s - SciPy 2025 workshop: https://www.youtube.com/watch?v=8AYp3MlRSNA - EuroPython 2025 talk: https://www.youtube.com/watch?v=HOqv3kh4z_c false https://pretalx.com/scipy-2026/talk/MEKP9F/ https://pretalx.com/scipy-2026/talk/MEKP9F/feedback/ Memorial Hall Lunch and Learn 2026-07-16T12:15:00-05:00 12:15 00:50 Instro is an open-source Python library that puts one typed API in front of power supplies, DAQs, multimeters, oscilloscopes, and more. Write your test once, swap the driver, and your code stays put. We drive a power supply live using the built-in simulator, no hardware required, and show how to add your own. scipy-2026-103185-instro-an-open-source-python-library-for-interfacing-with-hardware-test-equipment-in-heritage-gallery Lunch and Learn John Hoehner en false https://pretalx.com/scipy-2026/talk/JMFW8M/ https://pretalx.com/scipy-2026/talk/JMFW8M/feedback/ Memorial Hall Talk 2026-07-16T13:15:00-05:00 13:15 00:30 Imbalanced datasets are common across science and industry: most screened molecules are inactive and most batted balls in baseball result in outs. One standard practice is to downsample the majority class or avoid collecting more of it. But majority-class examples are not interchangeable. Some are closely related to other examples, while others are distinct from any other example in the dataset. Others define the boundary between success and failure. This talk asks two practical questions: 1. How much majority-class data is actually necessary for a performative machine learning model? 2. If we cannot collect all of it, which majority-class examples should we collect? Using three wildly different datasets—antibacterial molecular screening, sandwich taste ratings, and Major League Baseball at-bat outcomes—I compare random downsampling to strategies that retain harder or more diverse majority-class examples, and evaluate the impact on generalization and performance for real-world machine learning models. scipy-2026-92516-just-throw-it-away-class-imbalance-lessons-from-molecular-machine-learning-to-meatballs Data-Driven Discovery, Machine Learning and Artificial Intelligence Jackie Valeri en **Motivation** The goal of this talk is pragmatic. Rather than assume that majority-class data is disposable, I measure its value in different domains and discuss how to retain the right subset under budget constraints. I also evaluate whether those choices improve performance where it matters most: generalization and discrimination on a decision boundary. **Intended Audience** This talk is aimed at: * Python data scientists working with imbalanced datasets * scikit-learn + other ML package users building applied ML systems * Anyone who has wondered whether all that negative data is actually necessary It assumes familiarity with basic machine learning concepts (classification, regression, cross-validation), but does not require deep theoretical background. The focus is on applied ML. **Datasets** I explore these questions across three domains. 1) Antibacterial screening: This dataset consists of ~40,000 small molecules experimentally screened for antibacterial activity. Only a small fraction (3%) show measurable activity. Evaluation uses both random splits and scaffold splits, where entire structural families of molecules are held out to test generalization under distribution shift. 2) MLB batted-ball outcomes: Using features such as exit velocity and launch angle, the task is to predict outcomes (out, single, double, home run). The majority of at bats result in outs. Rare but desirable events like home runs occupy a small section of feature space and can have similar features to near-misses. 3) “Roll for Sandwich” ratings: This dataset contains ingredient combinations (bread, meat, cheese, toppings) and a human rating from 0–10 from the TikTok series "Roll For Sandwich". Roughly half of sandwiches score above 7, while very low scores are rare (only ~11% have scores <3). The space of possible combinations is large and sparsely explored. This provides a regression setting where “negative” examples are low-rated sandwiches. **Evaluation** Across all three datasets, I run two main experiments. First, data saturation experiments: hold the minority-class examples fixed, and gradually increase the number of majority-class examples to determine where performance plateaus. Second, fixed-budget data selection: vary how the majority-class examples are chosen: * Random down-sampling * Hard examples near the decision boundary (e.g., inactive molecules structurally similar to actives, near-miss home runs, or sandwich variants that differ by one ingredient) * Diversity-oriented selection that maximizes coverage of feature space Evaluation includes classic ML metrics (e.g., F1 score). We also use matched pairs: pairs of examples that are highly similar in features but differ in outcome. In chemistry, these are matched molecular pairs that differ by a small structural modification yet flip activity. In sandwiches, these are nearly identical ingredient sets with different ratings. In baseball, these are batted balls with similar exit velocity and launch angle but different outcomes. Performance on these pairs measures whether a model captures meaningful decision boundaries rather than broad class separation. I also report top-k metrics (e.g., precision@k) to reflect practical decision-making scenarios. false https://pretalx.com/scipy-2026/talk/VLD7LX/ https://pretalx.com/scipy-2026/talk/VLD7LX/feedback/ Memorial Hall Talk 2026-07-16T13:55:00-05:00 13:55 00:30 Deploying deep learning models for time-series forecasting at retail scale presents a fundamental tension between prediction accuracy and computational cost. This talk presents a Python-based framework combining structured pruning, quantization-aware training, and knowledge distillation to compress LSTM networks for demand forecasting. Using NumPy, TensorFlow/Keras, and scikit-learn, we achieved 47% accuracy improvement over baseline models while reducing model size by 73% and inference costs by 92%. We discuss practical implementation patterns, reproducibility considerations, and how these compression techniques generalize beyond retail to any domain requiring efficient sequential prediction at scale. scipy-2026-93158-compressing-lstm-networks-for-scalable-retail-demand-forecasting-a-python-based-approach-to-efficient-time-series-prediction Data-Driven Discovery, Machine Learning and Artificial Intelligence /media/scipy-2026/submissions/ECYVWR/image_u7IWR0f.webp Ravi Teja Pagidoju en **Background** Many teams that use LSTM networks for time-series forecasting hit the same wall: as models get more complex, they become too slow and costly to run in production. In retail, for example, you may need to forecast demand for thousands of products every day. The same challenge shows up in energy, healthcare, logistics, and other fields. Model compression , making models smaller while keeping them useful , is well studied for image models (CNNs), but less explored for recurrent models like LSTMs used in time-series work. This talk fills that gap using tools from the Python ecosystem. **What We Built** We developed a three-step compression pipeline, all in Python: **Structured Pruning**: We used TensorFlow/Keras and NumPy to find and remove LSTM units that contribute the least. Unlike random pruning, this gives you a truly smaller model , not a sparse one that still takes up memory. **Quantization:** We converted model weights from 32-bit floats to 8-bit integers using TensorFlow Lite, which cuts memory use and speeds up predictions with minimal loss in quality. Knowledge Distillation: We trained a small "student" LSTM to learn from the larger "teacher" model. The student learns not just the final predictions but also the internal patterns the teacher uses, through custom Keras loss functions. Data processing used pandas and NumPy. We tracked experiments with scikit-learn pipelines and visualized results with Matplotlib. **Results** The compressed model delivered strong improvements: 47% better accuracy (lower RMSE) than the uncompressed model 73% smaller model size 92% lower inference cost (wall-clock time) An interesting finding: moderate compression acted like a regularizer, helping the model generalize better. This is consistent with the lottery ticket hypothesis , smaller networks can often outperform larger ones. **Who Should Attend** This talk is for data scientists, ML engineers, and researchers who deploy deep learning models in production and care about efficiency. You do not need to be a retail expert , the techniques apply to any sequential prediction task. **What You Will Learn** How to prune, quantize, and distill LSTM models using Python tools you already know When compression helps vs. hurts forecast quality Practical patterns for setting up reproducible compression experiments How to adapt these methods to your own forecasting domain **Why This Matters for the SciPy Community** This work shows that the standard Python scientific stack (TensorFlow, NumPy, scikit-learn, Matplotlib) is enough to build production-ready model optimization , no special proprietary tools needed. As more teams scale up ML inference, efficient models become essential. Links : https://ieeexplore.ieee.org/abstract/document/11380599 false https://pretalx.com/scipy-2026/talk/ECYVWR/ https://pretalx.com/scipy-2026/talk/ECYVWR/feedback/ Memorial Hall Talk 2026-07-16T14:35:00-05:00 14:35 00:30 The Atmospheric Radiation Measurement (ARM) User Facility Data Center (ADC) capable of supporting scalable, secure, and reproducible engagement with atmospheric research data is evolving towards AI-ready ecosystem. We will discuss architectural designs utilized in production scientific data setting including open-source technologies to further multi-agent coordination, agentic retrieval-augmented generation (A-RAG), shared contextual memory via vector stores, and model-agnostic inference orchestration within Kubernetes infrastructure. We will go over ARM's foundational stack designed to support agentic AI workflows for data discovery, metadata research, reasoning, and user engagement. Additionally, we will go over architectural decisions, trade-offs, and security measures pertinent to research computing environments with some demonstrations. scipy-2026-93250-enabling-agentic-ai-infrastructure-for-scientific-data-ecosystems Data-Driven Discovery, Machine Learning and Artificial Intelligence Chirag ShahUtkarsh MahaiAustin Aguilar en With large language models (LLMs) and agentic AI system becoming more prevalent, scientific data centers are investigating how this can improve data discovery, metadata interpretation/automation, and overall data-researcher interaction. Deploying LLMs alone aren't enough for advancing AI-enabled capabilities in scientific environments. We must think of a cohesive architecture that integrates with our existing research infrastructure and facilitates interoperability, reproducibility, scalability, and governance. This talk describes the design and implementation of an agentic AI infrastructure developed within the Atmospheric Radiation Measurement (ARM) User Facility Data Center (ADC) to support AI-enabled workflows across atmospheric science data systems. Rather than developing a single application, the effort provides a foundational stack that standardizes how AI agents engage with data, tools, and users throughout the ARM ecosystem. The architecture is organized as a layered system that facilitates modular and interoperable AI services. At its foundation is a centralized inference infrastructure providing model-agnostic access to LLMs deployed on GPU-enabled research systems. The framework introduces an Agentic Retrieval-Augmented Generation (A-RAG) approach tailored for scientific data workflows. Traditionally retrieval-augmented generation improves the accuracy of language models by grounding responses in externally retrieved information. With A-RAG, each specialized agent can retrieve domain-relevant information from ARM data services, metadata catalogs, documentation, and web services, enabling evidence-driven responses that reflect the structure and context of atmospheric research data. The framework adopts emerging protocols such as Model Context Protocol (MCP) for structured tool access, Agent-to-Agent (A2A) for coordinated communication among agents, and Agent–User Interaction (AG-UI) protocol that support traceable conversational workflows. These protocols allow conversational interfaces, tools and applications to integrate with the framework while reusing shared services. At the central of these capabilities is shared contextual memory layer implemented through persistent vector stores that hold embeddings of structured scientific artifacts and documentation. Through this contextual layer the agents can operate over a consistent state which in turn supports coherent reasoning across sessions and workflows. Attendees will learn about architectural patterns for building and developing agentic AI infrastructure, strategies for extending traditional RAG into coordinated multi-agent systems, and practical considerations for deploying open-source LLM tooling in environments that require security, governance, and reproducibility. Intended audience: Software Engineers, Architects, Maintainers or Practitioners interested in AI and enabling that in scientific platforms. While the implementation is grounded towards atmospheric science domain, the architectural principles presented are broadly applicable to other scientific data repositories, national laboratory computing environments, university research platforms, and open-source projects that aim to create interoperable and trustworthy AI-enabled workflows. Towards the end of presentation will have a demonstration illustrating how these architectural components enable coordinated AI agents to facilitate scientific data exploration in a production setting such ADC. false https://pretalx.com/scipy-2026/talk/GSBQXK/ https://pretalx.com/scipy-2026/talk/GSBQXK/feedback/ Memorial Hall Lightning Talk 2026-07-16T15:30:00-05:00 15:30 01:00 Lightning talks are 5-minute talks on any topic of interest for the SciPy community. We encourage spontaneous and prepared talks from everyone, but we can’t guarantee spots. Sign ups are at the NumFOCUS booth during the conference. scipy-2026-97788-lightning-talk Lightning Talks en false https://pretalx.com/scipy-2026/talk/JVKEV7/ https://pretalx.com/scipy-2026/talk/JVKEV7/feedback/ Memorial Hall Birds-of-a-Feather (Bof) 2026-07-16T16:40:00-05:00 16:40 00:55 "The Scientific Python project aims to support maintainers and grow the maintainer community. We do so via, e.g., the Scientific Python Ecosystem Coordination process (https://scientific-python.org/specs/), by building tools (https://tools.scientific-python.org/: `spin`, `lazy-loader`, web theme, etc.), and by hosting annual developer summits. When an impactful opportunity presents itself, we take on bespoke technical initiatives such as the SciPy Sparse Array API refactor, or maintaining the myst documentation engine. scipy-2026-102463-scientific-python-ecosystem-coordination-maintainer-support-in-heritage-gallery-room Birds of a Feather (BoFs) Stéfan van der Walt en In this BoF, we want to connect with the community to: - Learn about maintainer needs - Explore ecosystem-wide ideas that can be captured as SPECs - Connect with maintainers who are interested in participating - Discuss domain stacks: groups of field-specific packages Please join us to share your ideas for improving the ecosystem! false https://pretalx.com/scipy-2026/talk/WMAQPQ/ https://pretalx.com/scipy-2026/talk/WMAQPQ/feedback/ Memorial Hall Birds-of-a-Feather (Bof) 2026-07-16T17:45:00-05:00 17:45 00:55 Supply chain attacks on Python, including recent compromises of popular packages and CI workflows, have exposed structural weaknesses in the scientific Python ecosystem. This BoF will bring together library maintainers, downstream users, and security practitioners to discuss practical strategies for securing scientific Python stacks, from core packages (NumPy/SciPy) to domain libraries and analysis workflows. We will share current efforts (e.g., SPEC 8, Trusted Publishing, SBOM generation, GitHub Actions hardening), identify pain points and gaps, and brainstorm actionable steps the community can take over the next year to make scientific Python releases more trustworthy by default. Join us to share your experiences, challenges, and ideas on fortifying our open-source projects against potential threats and ensuring the integrity of scientific research. scipy-2026-102435-securing-the-scientific-python-supply-chain-in-heritage-gallery-room Birds of a Feather (BoFs) Juanita GomezJarrod MillmanMatthew Feickert en false https://pretalx.com/scipy-2026/talk/RKS93M/ https://pretalx.com/scipy-2026/talk/RKS93M/feedback/ Johnson Great Room Talk 2026-07-16T10:45:00-05:00 10:45 00:30 How do we build competent data analysis agents? Data analysis requires a willingness to pause, question conclusions, and dig into subtleties. Frontier LLMs, however, are optimized to push tasks toward completion, not to slow down when something seems off. This tendency works well for coding agents, where success is often verifiable. But for data analysis, verification is more complicated, and autonomous work by the agent can be at odds with the spirit of the discipline. Drawing on our experience building data analysis agents, we'll share evaluations that expose where LLM-driven analysis goes wrong and design patterns that keep analyses correct, transparent, and reproducible. scipy-2026-92504-agents-for-correct-transparent-and-reproducible-data-analysis Data-Driven Discovery, Machine Learning and Artificial Intelligence Sara AltmanSimon Couch en LLM-powered agents are increasingly used for software development and data analysis. However, LLMs are non-deterministic, have uneven competencies, and can lack important context for realistic tasks. For software development, models can typically leverage tight feedback loops. It is often clear if code accomplishes its goal, and the model can also write both code and tests for that code, using the test results to iterate on its work. For data analysis, however, it’s often less clear if the model has done the task well or provided a correct result. How, then, do we make competent data analysis agents? In this talk, we will discuss strategies for creating data analysis agents that produce correct, transparent, and reproducible results. We will use examples from Posit Assistant, Posit’s general-purpose coding and data analysis agent. The intended audience includes scientists or data practitioners interested in using AI in data analysis workflows. First, we will discuss the importance of empirical evaluation. Because LLM capabilities can be difficult to predict, we created a series of evaluations, some using the Python library Inspect, to measure the capabilities of the skills we care about. These evaluations help us make decisions about model choice, tool design, and prompting, as well as identify any critical issues in the models’ abilities to carry out data science tasks. As an example, we will discuss bluffbench, an evaluation that measures LLMs’ ability to interpret plots that conflict with their priors. We will also discuss a developmental benchmark that measures agents’ ability to surface subtle data quality issues across long contexts. Second, we will discuss design choices to make agent-assisted analyses transparent and reproducible. Data analysis involves a variety of tasks, and different tasks require different levels of human awareness, input, and understanding. For example, exploratory data analysis still typically requires input and understanding from the user by nature of the task. Thus, when doing EDA, our agents produce briefer responses and ask the user for more input. For coding tasks with clear goals, however, we can often trust the agents to act more autonomously. Data analysis agents introduce both risks and opportunities for rigorous data analysis. Our aim for this talk is to introduce practical guidance for evaluating and creating data analysis agents that can be integrated into scientific workflows, while preserving accuracy, transparency, and reproducibility. Related work: * Bluffbench and plot interpretation: [Bluffbench repo](https://simonpcouch.github.io/bluffbench/), [Introducing bluffbench](https://posit.co/blog/introducing-bluffbench/), and [How well do LLMs interpret plots?](https://posit.co/blog/llm-plot-interpretation/) * [Introducing Databot](https://posit.co/blog/introducing-databot/) and [Databot is not a flotation device](https://posit.co/blog/databot-is-not-a-flotation-device/). Posit Assistant will be released in March and so does not yet have public documentation. * [Next edit suggestions (code completion) evaluations](https://github.com/posit-dev/nesevals) * Evidence of public speaking ability: * [Is that LLM feature any good? Simon Couch @ posit::conf(2025)](https://www.youtube.com/watch?v=HciRoc9TzMc) * [Getting Started with LLM APIs in R. Sara Altman @ RPharma 2025](https://www.youtube.com/watch?v=1efPTy4TQ4Q) false https://pretalx.com/scipy-2026/talk/UHUVMM/ https://pretalx.com/scipy-2026/talk/UHUVMM/feedback/ Johnson Great Room Talk 2026-07-16T11:25:00-05:00 11:25 00:30 Scientists apply rigorous methods to their research, but rarely to the AI tools they use to write code. We tested different LLM models in combination with domain-specific tools (including MCP servers and skills) to find the optimal combination for writing complex domain-specific code. We created a quantitative proficiency test for Starsim, a disease modeling framework, and evaluated different combinations of models and tools. While Claude Opus outperformed other models, access to tools improved performance more than choosing the best model. Thus, to improve LLM performance on domain-specific problems, we recommend developing a set of tools with the help of quantitative evaluation. scipy-2026-92515-vibes-meet-rigor-evaluating-and-improving-ai-performance-on-complex-scientific-code Data-Driven Discovery, Machine Learning and Artificial Intelligence Cliff Kerr en **Background** Scientists are often decidedly unscientific about choosing AI tools to help them write code. They know these tools are helpful, but except for trying out different models, they rarely perform controlled evaluations to check whether other changes to their AI workflow produce significantly better results. This is because writing and executing these evaluations is typically time-consuming, the results of the evaluations are difficult to interpret and quantify, and AI workflows and tooling are evolving rapidly. Here we describe our process for quantitatively testing our assumptions about how to build a good AI assistant. **Methods** Our team models infectious diseases using [Starsim](https://starsim.org/), a high-performance agent-based modeling library built on NumPy, SciPy, and Numba. Specifically, Starsim includes modules for different diseases, transmission networks, and interventions (such as vaccines). Starsim has been used to model domains ranging from family planning and primary health care to HIV and tuberculosis. Since the diseases themselves are often very complicated, the Starsim models built to model them can also be very complicated. This presents a challenge to AI tools due to limited context windows and out-of-date information. We created a "Starsim exam" [evaluation suite](https://github.com/starsimhub/scipy2026_starsim_ai/tree/main/problems) based on Starsim’s online documentation. This benchmark is administered using [Inspect.ai](http://Inspect.ai) and follows the structure of the [SciCode](https://arxiv.org/abs/2407.13168) benchmark with a modular approach to question building and evaluation via unit tests. Next, we created a set of agent tools to improve domain-specific performance, called [Starsim-AI](https://github.com/starsimhub/starsim_ai). Specifically, we added MCP servers for Starsim and [Sciris](https://docs.sciris.org/en/latest/) (a scientific Python library used widely in the codebase). We also created a set of "skills" for Starsim, which consist of problem-solving and feature-oriented Markdown files covering topics including statistical distributions, simulation construction, and calibration. These skills were created by Claude Code based on the Starsim [tutorials](https://docs.starsim.org/tutorials) and [user guide](https://docs.starsim.org/user_guide). They were then manually reviewed and revised by Starsim core developers for accuracy and completeness. Finally, we ran the evaluation suite using two Anthropic models (Claude Sonnet 4.6 and Claude Opus 4.6), both with and without access to the Starsim-AI tools, and two OpenAI models (GPT-5.2 and GPT-5 mini, which did not have access to the tools). **Results** Performance on the evaluation varied widely among the no-tool models, from 17% with GPT-5 mini to 70% with Claude Opus 4.6. Adding the full skillset in agent mode increased performance to 78% for Sonnet 4.6 and 91% for Opus 4.6. When given unlimited solving time, adding skills reduced task completion time by up to 20%. Conversely, when given limited solving time (2 minutes), Starsim-AI increased Opus 4.6's performance from 13% to 65%. Across models, task performance was strongly correlated with token usage (R²=0.61), but adding skills only marginally increased token usage (1-3%). **Conclusions** For our domain-specific problem, providing custom skills and MCP servers reduced the error rate by a factor of three (from 30% to 9%) and reduced task completion time by 20%. We recommend creating a structured problem set for use with a quantitative evaluation tool, as this can help develop the set of domain-specific tools that most effectively improves LLM performance. false SciPy 2026 submission Starsim-AI Starsim https://pretalx.com/scipy-2026/talk/3GRQ87/ https://pretalx.com/scipy-2026/talk/3GRQ87/feedback/ Johnson Great Room Talk 2026-07-16T13:15:00-05:00 13:15 00:30 Few of us come to scientific computing with an understanding of how to write a system kernel or build a transistor. But we often downplay the benefits of going just one or two layers of abstraction below our comfort zone, strengthening our foundations and expanding our options. This talk explores the meaning, utility, and optimization of vectorized array operations, fundamental to NumPy, from Python bytecode down to x86 assembly. We'll build a physical intuition for how array operations work, when they turn out to be less performant than we might expect, and how to find the right balance between effort and performance for your needs. scipy-2026-92240-when-vectorized-arrays-aren-t-enough-array-optimization-from-bytecode-to-assembly General Nicolas R Posner en **Intended Audience** Scientific Python developers who use NumPy arrays habitually, but find themselves concerned that the efficiency of their code is impacted by implementation details further down the stack of abstractions. **What We'll Cover** - How NumPy's array operations are implemented compared to lists - Pitfalls of naive NumPy use - Other options for numerical array operations in Python - Writing bespoke extensions in Rust - x86 assembly in a nutshell - What is 'vectorization' really? false https://pretalx.com/scipy-2026/talk/GT9Y9U/ https://pretalx.com/scipy-2026/talk/GT9Y9U/feedback/ Johnson Great Room Talk 2026-07-16T13:55:00-05:00 13:55 00:30 JupyterLite takes the simplicity of the Jupyter notebook interface and hosts it entirely in the browser, eliminating the need to setup a JupyterHub, making the Jupyter notebook environment much more accessible to users. In this talk we'll explore how our team harnessed JupyterLite and web components to make the distance between browsing for data and coding against that data 10 seconds and a new tab. scipy-2026-92306-bridging-data-discovery-and-analysis-using-web-components-and-jupyterlite General Christine SmitJon Carlson en We work at the Goddard Earth Sciences (GES) Data and Information Services Center (DISC), one of NASA's earth science data archives. Earth science data at NASA is freely available to anyone with an internet connection. NASA offers high quality, curated, validated datasets representing decades of measurements from a variety of remote sensing instruments and models. Unfortunately, making data available is not the same as making data easy to use. For years, a major sticking point for our users has been transitioning from the in-browser experience of our search engines and visualization tools to compute environments on their own systems. Suddenly users are confronted with data files in weird binary formats with unpredictable metadata, which can be a challenge for a wide range of users, from scientists, students, policy professionals to highly experienced developers. Jupyter is a great tool for making computational workflows more approachable, particularly for new and occasional programmers. Jupyter notebooks provide the perfect vehicle for combining documentation with runnable code examples. Unfortunately, not all users have easy access to their own Jupyter server.. Our team tackled this problem directly, starting with one of our simpler visualization tools, the [Hydrology Time Series Service](https://disc.gsfc.nasa.gov/information/tools?title=Hydrology%20Time%20Series). This tool allows users to plot long time series from hydrology-focused, high temporal resolution data. For some users, the time series plot may be enough for their needs. But if it isn't, we offer a button to jump them directly into a JupyterLite notebook with their selected data loaded into python pandas and ready for further analysis. JupyterLite runs right in their browser, so there's no need for a server or any setup. We think this solution is just about the most seamless jump from a pure GUI data exploration environment to a coding environment that we've seen. In this talk, we'll demo the integration and cover what the website is doing behind the scenes to make this jump happen, bringing the user's data along for the ride. Come join us to see how a little [javascript](https://github.com/gesdisc/jupyter-notebook-from-json-extension/) can enable a whole lot of [python](https://gesdisc.github.io/jupyterlite/lab/index.html). false https://pretalx.com/scipy-2026/talk/AVLJ7K/ https://pretalx.com/scipy-2026/talk/AVLJ7K/feedback/ Johnson Great Room Talk 2026-07-16T14:35:00-05:00 14:35 00:30 dagster-slurm is an open-source Python integration that allows data scientists and research software engineers to run Dagster pipeline assets on both a laptop and Slurm-managed HPC supercomputers without making any code changes. It automatically handles SSH transport, environment packaging via pixi-pack, and Slurm job submission, while streaming logs and scheduler metrics back to the Dagster UI in real time. The talk covers the full workflow, from local development to staging and production deployment on a real HPC cluster, using a live demo with a self-contained Docker Compose environment. It has been validated on VSC-5 in Austria and CINECA Leonardo in Italy. scipy-2026-92392-dagster-slurm-bringing-modern-data-orchestration-to-slurm-managed General /media/scipy-2026/submissions/QVKGLW/image_PzVesz0.webp Hernan PicattoGeorg Heiler en Motivation Scientific and data engineering pipelines often span multiple compute tiers, such as preprocessing on a workstation, model training on an HPC cluster, and downstream analytics on a cloud VM. However, this is typically managed poorly, with the HPC step being a hand-written sbatch script that is disconnected from the rest of the pipeline. This results in no shared lineage, no unified observability, and no automated trigger of downstream work when the job finishes. As a result, research software engineers have to maintain two separate codebases and two mental models of the same workflow. What dagster-slurm does dagster-slurm is a Dagster ComputeResource and PipesClient that enables Dagster Software-Defined Assets to run on Slurm HPC clusters. You can redirect a Python function decorated with @dg.asset to a supercomputer by simply setting ExecutionMode.SLURM, without needing to make any other code changes. The library handles tasks such as SSH connection management, automatic environment packaging, Slurm job submission, and log and metadata streaming back to the Dagster UI. Dagster-slurm is designed for teams that need an orchestrator that handles HPC. Allowing HPC workloads to be integrated into the same asset graph with full lineage, scheduling, and observability. Talk structure (25 minutes) The problem: why HPC and data orchestration are still separate (3 min) Architecture overview: ComputeResource, Dagster Pipes over SSH, and pixi-pack (5 min) Live demo: running an asset locally and then submitting it to a containerized Slurm cluster with real-time log streaming (10 min) Lessons from production use: environment portability, air-gapped clusters, and site-specific authentication (4 min) Roadmap and how to contribute (3 min) The demo uses a self-contained Docker Compose stack that runs on a laptop, with no need for external cluster connectivity. Audience and outcomes This talk is intended for research software engineers, data engineers, and ML practitioners who work with Python pipelines and occasionally need HPC resources. Attendees will learn how to connect an existing Dagster project to a Slurm cluster and understand the design tradeoffs between task-level HPC frameworks and asset-based data orchestration. Links: https://github.com/ascii-supply-networks/dagster-slurm | https://dagster-slurm.geoheil.com | JOSS paper (under review) false https://pretalx.com/scipy-2026/talk/QVKGLW/ https://pretalx.com/scipy-2026/talk/QVKGLW/feedback/ Johnson Great Room Birds-of-a-Feather (Bof) 2026-07-16T16:40:00-05:00 16:40 00:55 This Birds of a Feather session will bring together developers, users, researchers, and educators interested in GPU-accelerated Python. The discussion will explore the current state of the ecosystem, new library developments, and strategies for making GPU acceleration more accessible to a broader scientific audience. Topics may include performance optimization, debugging and profiling, education and training, and opportunities for collaboration across projects and communities. scipy-2026-102432-gpu-accelerated-python Birds of a Feather (BoFs) Katrina Riehl en false https://pretalx.com/scipy-2026/talk/ZNPYX9/ https://pretalx.com/scipy-2026/talk/ZNPYX9/feedback/ Johnson Great Room Birds-of-a-Feather (Bof) 2026-07-16T17:45:00-05:00 17:45 00:55 Generative AI seems like it’s everywhere and attendees of this very conference have built the technical foundations that have enabled its explosive growth. However, unlike the scientific computing software that we typically build, the rapid adoption of generative AI has not been met with the type of rigorous quality control that is required of powerful systems and expected of scientific endeavors. While there are many efforts around assessing the performance of generative AI systems, (e.g., benchmarks, human-in-the-loop AI red teaming, etc.) these methods often lack the rigor and context to make them truly scientific evaluations. In this BoF, we will host a community conversation to discuss the requirements to claim that a generative AI evaluation is scientifically sound while also maintaining subject matter expertise, relevance, and actionability. The SciPy Conference is an excellent forum for this discussion, bringing together scientists, developers, and practitioners. scipy-2026-102434-building-scientific-approaches-to-generative-ai Birds of a Feather (BoFs) Julie Hollek en false https://pretalx.com/scipy-2026/talk/QBWEZ7/ https://pretalx.com/scipy-2026/talk/QBWEZ7/feedback/ Thomas Swain Room Talk 2026-07-16T10:45:00-05:00 10:45 00:30 In Fall 2025, the UConn School of Mechanical, Aerospace, and Manufacturing Engineering launched Open Source Experiences, an elective course developed in partnership with six NumFOCUS-supported projects (napari, BiocPy, Blosc, MNE-Python, mlpack, JuliaHub). The course embedded students directly into active open source communities, where they contributed to the codebases, collaborated with project maintainers, and learned about community-driven open source software development. In this talk, we will share the lessons learned from piloting this collaboration model, and how these experiences benefit students, open source and open science communities, and educators alike. Attendees will take away actionable insights for integrating open source contributions into their own classrooms and programs. scipy-2026-92239-learning-in-the-open-integrating-open-source-contributions-into-the-classroom Scientific Computing in Education Inessa PawsonRyan C CooperMohammad MundiwalaRyan Curtin en The scientific open source community thrives on shared knowledge and welcoming communities, the very system of values that the annual EuroSciPy conference celebrates. At the same time, educators in computational sciences and engineering seek ways to help students move beyond traditional assignments and into experiential learning. Where experiential is a combination of skill-building, networking, and understanding of how science and software happen in the real world. Open Source Experiences was designed to meet both of these needs. In this talk, we will share how we worked with students and open source community mentors to structure a semester-long course where students made valuable contributions to existing scientific Python projects. Students participated in issue triage, bug fixes, documentation improvements, and feature contributions, guided by project maintainers. Through this format, students gained experience with tooling (version control, CI/CD, code formatting, testing), in community practices (contributing guidelines, communication norms), and long-term project planning (design decisions, roadmap alignment), while participating projects gained valuable contributions and new contributors. Student participation and contributions were assessed with regular progress updates. As instructors, we facilitated discussions to guide the Open Source Experience learning process: working on bugs and issues in an open environment, community expectations, GitHub best practices, etc. **Talk outline:** - Course design and goals: balancing academic learning objectives with community needs, assessment strategies. - Collaboration with maintainers: selecting projects, preparing onboarding documentation, setting expectations, and creating a mentorship model that respects both students’ learning and maintainer time. - Student outcomes: reflections on learning gains around technical skills, professional communication, and confidence engaging in open source ecosystems. - Challenges and lessons learned. We’ll also share examples of student contributions and how they augmented both the ecosystem and the students’ portfolios. Whether you’re an educator thinking about how to bring open source into your curriculum or a project leader looking for ways to engage with academic institutions to widen your project’s contributor pipeline, this talk will give you concrete ideas to adapt. false https://pretalx.com/scipy-2026/talk/GBW7DW/ https://pretalx.com/scipy-2026/talk/GBW7DW/feedback/ Thomas Swain Room Talk 2026-07-16T11:25:00-05:00 11:25 00:30 Introducing novel software tools into the classroom is increasingly challenging. Fortunately, the richness of the modern web platform, and the proliferation of free static web hosting, provides a low friction way to introduce powerful software into the classroom. Coupled with the maturity of the Pyodide project, the possibilities of introducing scientific Python powered web-apps into classroom are limitless. This presentation demonstrates these possibilities through a case study of the open-source EngineeringPaper.xyz project that gives students instant access to the SymPy library. The unique interactive capabilities enabled by the web platform, such as math expression editing, will also be discussed. scipy-2026-92373-accessible-python-powered-web-apps-for-the-classroom Scientific Computing in Education Michael Greminger en I've been using Jupyter notebooks for example calculations in my mechanical engineering classes at the University of Minnesota Duluth for many years. However, due to my students' limited coding experience, these Python powered calculations were often impenetrable to my students and provided limited value since I wasn't able to have my students create their own calculations. I simply didn't have the course time available to get them up to speed on Python coding while also covering the core topics of my course, especially with the challenges of getting a working scientific Python stack on the plethora of student computers. The introduction of the Pyodide project, and the power of the modern web platform, have been a game changer in what's possible in terms of bringing powerful Python powered apps into the classroom. This presentation will use my EngineeringPaper.xyz open-source project as a case study in what's possible in terms of bringing intuitive scientific Python powered apps into the classroom. With EngineeringPaper.xyz, I'm now able to have my students create, modify, and submit their own Python powered calculations, using their own devices, with minimal training. This talk will cover the technical stack that powers EngineeringPaper.xyz, which includes Pyodide to run the scientific Python stack in the browser and the MathLive interactive math notation editor used to provide the user an intuitive way to enter mathematical expressions. The talk will also cover the parsing strategy used to convert the LaTeX expressions obtained from MathLive into Python expressions that can be interpreted by the SymPy symbolic math library. In addition to the technical aspects of EngineeringPaper.xyz, this talk will also discuss key usability features that are used to allow students who are technical, but are not necessarily coders, to take advantage of Python powered scientific computing. These principles include using math notation as a common language and leaning into declarative logic rather than imperative logic in order to minimize confusion and tripping points. Finally, the all-important issue of how students submit their work to a learning management system (LMS), such as Canvas, is addressed. A strategy that uses Markdown as an intermediate format and Pandoc to convert this Markdown into the DOCX or PDF files that can be submitted to the LMS is presented. EngineeringPaper.xyz is likely more complex than most scientific Python powered apps for the classroom need to be. However, I think the friction points addressed and the overall approach taken can be instructive for the builders of more narrowly focused apps. These app builders can pick and choose from the technologies and approaches used in EngineeringPaper.xyz. Relevant Links: [EngineeringPaper.xyz GitHub Repository](https://github.com/mgreminger/EngineeringPaper.xyz) [My Previous SciPy 2021 talk](https://youtu.be/KrlqQBH84x4?si=F7flRHXp1026ViX4) [Blog Post Describing EngineeringPaper.xyz's use in the education](https://blog.engineeringpaper.xyz/an-open-source-tool-for-teaching-analytical-calculations-in-engineering-education) false EngineeringPaper.xyz GitHub Repository https://pretalx.com/scipy-2026/talk/8GVHWU/ https://pretalx.com/scipy-2026/talk/8GVHWU/feedback/ Thomas Swain Room Talk 2026-07-16T13:15:00-05:00 13:15 00:30 When early programmers needed to share code on punch cards and magnetic tape in the 1970s, they needed to explain how to use it, warn about bugs, and provide context. The code on its own wasn't enough, so the README file was born. But READMEs have never been entirely utilitarian forms of documentation. Instead they became (and remain) very human. A 1974 README ends with "Good luck!", and in 1978, The Jargon File connected the name itself to Alice in Wonderland, suggesting that "Read Me" should stand beside "Eat Me" and "Drink Me" in a surreal, hidden world. This talk reveals how READMEs have always been where developers get to be human. Be it an exasperated warning from the 1970s, a 2009 README that became a complete fairy tale, or today's projects built solely to help developers add jokes to their docs, the pattern holds across five decades: READMEs are where we connect, welcome, and guide each other. You'll leave with practical principles for writing READMEs that invite contribution and build community, grounded in this history. If you want contributors to your open source project, your README is likely their first impression and invitation. Make it count. scipy-2026-92115-down-the-rabbit-hole-history-of-the-readme-and-why-you-should-care Maintainers and Community Daina Bouquin en Rather than talking about using README files as a mechanism to make it easier for people to contribute, this talk focuses on how README files surface community culture and can make people want to contribute. This talk uses historical examples spanning five decades to reveal patterns that remain relevant: READMEs have always been where developers connect with each other, not just with code. That connection makes people want to contribute. If you want people to contribute to your project, the README is likely their first impression. Make it human. Make it welcoming. Make it a door, not a wall. The history of computing shows us that developers have always known this. They've just expressed it in different ways across the decades. false https://pretalx.com/scipy-2026/talk/GVQECR/ https://pretalx.com/scipy-2026/talk/GVQECR/feedback/ Thomas Swain Room Talk 2026-07-16T13:55:00-05:00 13:55 00:30 Open source maintainers are the lifeblood of the cloud-native ecosystem, balancing the rapid pace of technical innovation with the crucial need for project stability and sustainable community growth. Having served in leadership roles for foundational projects like **XGBoost, KServe, Kubeflow, Argo, and the Kubernetes**, this session moves beyond technical deep-dives to share the hard-won, non-obvious lessons of maintaining and scaling a successful open source project. scipy-2026-92028-building-for-the-road-ahead-transferable-lessons-from-the-front-lines-of-open-source-maintenance Maintainers and Community Yuan Tang en We will explore the maintainer’s journey: from building a neutral foundation for multi-vendor collaboration to managing challenging governance decisions and successfully onboarding new waves of contributors. Attendees will gain a clear, practical framework for: - **Balancing Control and Collaboration**: Deciding when to extend project primitives versus delegating functionality to the wider ecosystem. - **Sustainable Governance**: Creating inclusive contribution pipelines that scale with project maturity. - **Community as Innovation Engine**: Using community feedback and cross-project partnerships (e.g., vLLM, Envoy AI Gateway) to drive a roadmap that is both cutting-edge and enterprise-ready. This is a session for both current and aspiring maintainers looking for honest stories and actionable, transferable strategies to secure the long-term health and impact of their own open-source projects. **Key Takeaways:** - **Actionable Strategies for Community Growth**: Learn proven techniques for converting end-users into contributors and building a diverse maintainer base, leveraging case studies from the Kubeflow and KServe communities. - **Maintainer Decision-Making Frameworks**: Gain insight into the process for critical project decisions, such as adopting new standards (like Kubernetes Gateway API) or managing core vs. extension boundaries, that balance stability with innovation. - **The Power of Open Collaboration**: Understand the practical benefits and challenges of multi-company/vendor neutral collaboration and how it is essential for tackling complex, shared infrastructure problems like Generative AI model serving. false https://pretalx.com/scipy-2026/talk/TFEA7N/ https://pretalx.com/scipy-2026/talk/TFEA7N/feedback/ Thomas Swain Room Talk 2026-07-16T14:35:00-05:00 14:35 00:30 The tidyverse is a collection of R packages designed to facilitate data science. My team and I have been working on it for nearly 20 years, and in this talk, I’ll share some of what we’ve learned about software development and open source community building in that time. It’s very clear that AI is having a profound impact on how we develop software and do data science, so I’ll also offer a look into the (near) future, discussing how we’re updating our thinking about how people will do data science, and speculating on what work is likely to have the biggest impact. scipy-2026-91121-grammars-of-data-lessons-from-20-years-of-the-tidyverse Maintainers and Community Hadley Wickham en My team and I have spent the last almost 20 years building a collection of R packages known as the [tidyverse](https://tidyverse.org/). The tidyverse includes packages like ggplot2 (for visualisation) and dplyr and tidyr (for data manipulation) and is designed to make data science easier to learn by embracing a consistent design across makes. The overall aim of the tidyverse is make data science faster, more effective, more fun, and more accessible to more people. The tidyverse was named and created in 2016, but the core ideas started development in 2006 with ggplot and reshape, predecessors of the core ggplot2 and tidyr packages. We’ve learned a lot about software development and open source community building over those 20 years and I’d love to share some of what we’ve learned with the scipy community. I’ll also talk about how we’re thinking about coding data science today: it’s clear that AI is having and will continue to have a profound impact the practice of data science. What are the implications for open source tool builders? What does it mean for our identities as programmers and data scientists? It’s hard to speculate too much, but I will discuss the changes we’re seeing (and making!) and offer some very near term predictions. false https://pretalx.com/scipy-2026/talk/FAKEUM/ https://pretalx.com/scipy-2026/talk/FAKEUM/feedback/ Thomas Swain Room Birds-of-a-Feather (Bof) 2026-07-16T16:40:00-05:00 16:40 00:55 Open source software has fueled every major scientific discovery of the last two decades. Yet as scientific practice races toward agentic workflows, no-code interfaces, and AI-driven hypothesis testing, the open source infrastructure (and the maintainer communities who keep it alive) remain systemically underfunded and not yet designed for AI-native use. scipy-2026-102433-funding-scientific-open-source-in-the-age-of-ai-new-challenges-and-opportunities Birds of a Feather (BoFs) Dario Taraborelli en Many foundational tools were built for human-in-the-loop workflows and need modernization to support AI applications or data-intensive model training workflows. At the same time, LLMs and agentic frameworks are increasingly becoming the frontend through which scientists access core capabilities provided by open source libraries, forcing many communities to adapt to use cases that were never part of their original roadmap. AI has also dramatically impacted software engineering practices and the ability for open source projects to vet and incorporate community contributions. In May 2026, we launched the Open Source for Science Fund, a new multi-donor initiative designed with the precise goal of sustaining and evolving the open source stack that underpins science in the AI era. The Fund builds on six years of funding through the Chan Zuckerberg Initiative's Essential Open Source Software for Science (EOSS) program, which deployed $58M in funding and supported a significant number of software projects in the scientific Python ecosystem. With this BoF, we want to share early insights from the launch of the Fund and engage the SciPy community in identifying opportunities to design funding programs tailored to the evolving needs of scientists and the maintainer communities that support them" false https://pretalx.com/scipy-2026/talk/8WTNKR/ https://pretalx.com/scipy-2026/talk/8WTNKR/feedback/ Virtual Sessions Birds-of-a-Feather (Bof) 2026-07-16T16:40:00-05:00 16:40 00:55 The scientific Python community, like the rest of the world, faces a set of interlocking crises. Longstanding questions over how to sustainably develop, fund and maintain open-source scientific software, open data, reproducible research and collaborative training are being magnified by a variety of forces from the AI boom, to government disinvestment, to economic disruption. Combining a short panel with audience discussion and Q&A, this virtual BoF will reflect on these challenges and crowdsource ideas for how the SciPy community (including future conferences) can serve as a vehicle for bolstering scientific open ecosystems. _This is a virtual Birds of a Feather section. It will take place on the virtual platform for the conference, Airmeet. All attendees will have access to Airmeet. **NOTE: This session will observe Chatham House rules.**_ Hybrid committee co-chairs Puneet Kollipara and David Nicholson will host and moderate this panel discussion. scipy-2026-102009-virtual-bof-resilient-data-software-science-and-culture Birds of a Feather (BoFs) Puneet KolliparaDavid Nicholson en The scientific Python community, like the rest of the world, faces a set of interlocking crises. In addition to longstanding questions of how to sustainably develop open-source scientific software, we now face attacks on science, data and research infrastructure that would have once been unthinkable. And as if maintainers were not already stretched thin, they must now agree on how to deal with a firehose of pull requests generated using AI. New ways of working have sprung up in response to these crises. These point the way toward building *resilience* into data, software, science and culture. The goal of this virtual BoF is to discuss what all these efforts have in common, to strengthen existing connections and share information. Additionally we will discuss proposing a track on resilient data, software, science, and culture for the SciPy 2027 conference. This BoF will be a panel discussion that brings together the SciPy conference community with a broader set of leaders involved in these efforts across scientific disciplines and open source software ecosystems. Panelists will first introduce themselves and their area of focus. This will be followed by a general discussion and Q&A. We are pleased to welcome these panelists to discuss the following topics: - [Jonny Saunders](https://jon-e.net/), post-doctoral researcher, UCLA; [SciOp](https://sciop.net/), [data preservation](https://www.librarypunk.gay/e/160-sciopnet-feat-jonny-and-jez-part-1/); [NeuroMatch](https://neuromatch.io/) and [decentralized infrastructure](https://arxiv.org/pdf/2209.07493) - [Brianna (Pagán) Corremonte](https://www.briannapagan.com/), technical lead, [Development Seed](https://developmentseed.org/); ["Beyond Open Data"](https://cloudnativegeo.org/beyond-open-data-white-paper.pdf) and [Incentivising open science through powerful free and open tooling](https://meetingorganizer.copernicus.org/EGU26/EGU26-20056.html?pdf) - [Juan Nunez-Iglesias](https://image.coop/people/juan), co-creator of [napari](https://napari.org/stable/), core [scikit-image](https://scikit-image.org/) team member; [Image Cooperative](https://image.coop/) - [Kris Armeni](https://www.kristijanarmeni.net/), research scientist; [civic tech contributor](https://pretalx.com/scipy-2026/talk/AFWXAU/) - [Yanina Bellini Saibene](https://yabellini.netlify.app/about/), community manager, rOpenSci; [creation and reinforcing open software communities in Latin America](https://yabellini.netlify.app/talk/2025_latinr-champions/) This is a virtual Birds of a Feather section. It will take place on the virtual platform for the conference, Airmeet. All attendees will have access to Airmeet. **NOTE: _This session will observe Chatham House rules._** Hybrid committee co-chairs Puneet Kollipara and David Nicholson will host this panel discussion and moderate. false https://pretalx.com/scipy-2026/talk/LKAHLP/ https://pretalx.com/scipy-2026/talk/LKAHLP/feedback/ Memorial Hall Keynote 2026-07-17T09:15:00-05:00 09:15 00:45 Staff Scientist at the Alaska Satellite Facility scipy-2026-97808-keynote-dr-joseph-h-kennedy-snakes-in-the-microwaves-how-python-is-powering-the-golden-age-of-sar Keynotes Joseph H. Kennedy en Synthetic Aperture Radar (SAR) is transforming how we observe our planet. It sees through clouds, smoke, and darkness, measures millimeter-scale changes to Earth's surface from space, and is rapidly becoming a cornerstone of Earth observation. With a decade of Sentinel-1 observations, the launch of NISAR, and fleets of commercial satellites, we're entering the Golden Age of SAR. At the Alaska Satellite Facility, we steward more than 30 PB of freely-accessible SAR data for NASA Earthdata, with the archive expected to exceed 100 PB as calibrated NISAR data becomes available. But turning that flood of data into scientific insight requires far more than storage—it demands an ecosystem of software that enables scientists to discover, access, process, and analyze data at an unprecedented scale. Drawing on examples from the Alaska Satellite Facility and the broader NASA Earthdata ecosystem, I'll explore how the Scientific Python ecosystem, through tools like NumPy, Xarray, Zarr, Jupyter, and countless community-built libraries, has become the foundation powering everything from cloud-native data access and open-source scientific libraries to large-scale processing platforms and “near”-real-time Earth monitoring projects like ITS_LIVE. Along the way, we'll see how the Python community has helped transform SAR from a specialized research tool into a global scientific resource, moving beyond individual images toward continuous streams of Earth observations—and why the next decade of Earth observation will be defined as much by open-source software as by the satellites themselves. false https://pretalx.com/scipy-2026/talk/BKZVXU/ https://pretalx.com/scipy-2026/talk/BKZVXU/feedback/ Memorial Hall Tools Plenary 2026-07-17T10:00:00-05:00 10:00 00:25 A session featuring updates and roadmaps from maintainers of core Scientific Python libraries and tools. scipy-2026-97806-scipy-tools-plenary SciPy Tools en false https://pretalx.com/scipy-2026/talk/REGLJW/ https://pretalx.com/scipy-2026/talk/REGLJW/feedback/ Memorial Hall Talk 2026-07-17T10:45:00-05:00 10:45 00:30 Canvas Chat is a browser-based tool that combines Python's data science stack with large language model connectivity, enabling natural language interaction with data. Built on Pyodide, it runs entirely in the browser with no server-side computation required. Users bring their own API keys for LLM access, while all session data persists locally in IndexedDB. The visual, non-linear interface represents conversations as nodes on an infinite canvas, supporting branching, merging, and stateful exploration of data analysis workflows. This talk demonstrates how browser-based Python plus LLMs can democratize data science by removing infrastructure barriers while preserving privacy and reproducibility. scipy-2026-93245-canvas-chat-non-linear-workflows-for-ai-assisted-data-science Spirit of SciPy Eric Ma en ### Motivation Data scientists face significant infrastructure hurdles when exploring data. Setting up Python environments, managing dependencies, and configuring cloud resources create friction before any actual analysis begins. Meanwhile, large language models have transformed how we think about interacting with code and data, yet most LLM-powered tools require cloud infrastructure and raise privacy concerns. What if we could bring Python's full data science stack into the browser, connect it to LLMs for natural language interaction, and keep everything local and private? ### Canvas Chat - architecture and approach Canvas Chat addresses these challenges through three key design decisions: 1. **Pyodide for browser-native Python**: The entire Python runtime, including NumPy, pandas, and Matplotlib, runs via WebAssembly in the browser. No installation, no server, no compute costs beyond the client machine. 2. **LLM connectivity with local-first privacy**: Users bring their own API keys (OpenAI, Anthropic, Google, Groq, or local Ollama). Session data, conversation history, and analysis state persist in IndexedDB. Nothing is sent to third-party servers beyond the user's chosen LLM provider. 3. **Visual, non-linear workflows**: Unlike traditional chat interfaces, Canvas Chat represents conversations as a directed acyclic graph (DAG) on an infinite canvas. Users can branch from any point, merge multiple context branches, and explore analysis paths in parallel. This matches how data scientists actually think about problems. ### Key capabilities - **Natural language to code**: Users describe what they want in plain English, and the LLM generates executable Python code - **Stateful sessions**: Unlike stateless notebooks, the canvas maintains full conversation history and data lineage - **Multi-modal input**: Images, PDFs, and web content can be incorporated into analysis workflows - **Extensible via plugins**: Custom node types allow domain-specific extensions without modifying core code - **Zero deployment**: A single `uvx canvas-chat` command launches everything ### What attendees will learn 1. How Pyodide enables full Python data science in the browser 2. Architectural patterns for connecting browser-based Python to LLMs 3. Design principles for non-linear, stateful analysis interfaces 4. Privacy-preserving approaches to AI-assisted data science 5. How to extend Canvas Chat with custom plugins for their domain ### Relevance to the SciPy community Canvas Chat represents an unconventional application of the Python scientific stack, repurposing Pyodide for interactive AI-assisted workflows. It addresses a core SciPy value, lowering barriers to scientific computing, while introducing novel interaction patterns that could influence future tool development. The talk will include live demonstrations and practical guidance for attendees who want to experiment with browser-based Python plus LLM workflows. ### Links - Live demo: https://ericmjl--canvas-chat-fastapi-app.modal.run/ - Source code: https://github.com/ericmjl/canvas-chat - Documentation: https://ericmjl.github.io/canvas-chat/ false https://pretalx.com/scipy-2026/talk/YWHVF7/ https://pretalx.com/scipy-2026/talk/YWHVF7/feedback/ Memorial Hall Talk 2026-07-17T11:25:00-05:00 11:25 00:30 Computational narratives like Jupyter, MyST Markdown, R-Markdown, and Quarto are amazing for doing science. You can combine narrative, code, data and images, conducting your analysis while also creating information to share. However, the workflow has been that notebooks are where you do the work, but you need to publish a pdf article to advertise the work, and this is the research output that most people see. That process not only creates extra work, but we're losing key information, amazing graphics, interactive visualizations, and a connection to the code and data. Flattening science into a published pdf sacrifices reproducibility and valuable context for others to build on the research. We’re continuing to share our science in 19th century ways, as if we need to send printed, physical copies of our work to people in the mail. This is both a boring and ineffective way to communicate science and also reduces the visibility and value to the modular components of research. The data, images, and code all have individual value, especially as we think about new ways for humans and machines to build on existing science for new impact. The Open Exchange Infrastructure (OXA, https://oxa.dev) is a community standard for scientific publishing built for modular and computational science. Initial contributors include Stencila, eLife, Posit, PLOS, openRxiv, Curvenote, NeuroLibre, and Creative Commons — representing a new document format that brings together the best of Jupyter Notebooks, Quarto, MyST Markdown, and publishing/archiving standards to enable new scientific publishing experiences and workflows. OXA additionally allows many tools and existing formats to connect with each other and into traditional publishing workflows, like Journal Article Tag Suite (JATS XML) and Manuscript Exchange Common Approach (MECA). This means that what you share is interactive and engaging and your research products, like large scale microscopy images (e.g. OME-Zarr), are first-class citizens where image datasets, notebooks, and other research products are highlighted not hidden. In this talk we’re sharing more on the technical architecture of the format and a pilot between openRxiv (the non-profit organization behind the largest biomedical preprint servers: bioRxiv and medRxiv) and Curvenote (a scientific content management system that also hosts the SciPy Proceedings) to migrate 500k preprints (8.1TB) to OXA and show real-world examples of interactive scientific content, modular attribution, and what’s possible when the pieces are connected and scientific research can be open, engaging and match what’s possible with our current technology - to change the way we share and do science. This isn’t a future vision, this is what is already happening today. scipy-2026-92503-open-exchange-architecture-from-computational-narrative-to-interactive-preprint General Tracy TealRowan Cockett en This talk is for: * People who are scientists creating and sharing research, especially using computational notebooks (e.g. Jupyter Notebooks, Jupyter Book, Quarto, MyST Markdown) * People developing tools related to scientific communications, that could more easily be connected with each other through OXA * People working on formats and standards for computational notebooks and scientific publication Some relevant previous speaking experience includes: - Talk at [SciPy 2023](https://www.youtube.com/watch?v=7nkUcwBgoME) on "Scientific and technical publishing with Python and Quarto" - Talk at [PyData Seattle 2023](https://www.youtube.com/watch?v=CiXhTA6zkjA) on "It's not just code: managing an open source project" - Talk at [posit::conf 2022](https://www.youtube.com/watch?v=ttLnLdU1-CQ) on "These are a few of my favorite things (about Quarto presentations)" false https://pretalx.com/scipy-2026/talk/W9QWGR/ https://pretalx.com/scipy-2026/talk/W9QWGR/feedback/ Memorial Hall Talk 2026-07-17T13:15:00-05:00 13:15 00:30 What is the best way to study materials for modern devices? For example, designing better batteries means understanding how lithium ions move at the atomic level. This, in turn, requires building a model of the electrolyte and the electrodes, and observing how the system evolves along a dynamic trajectory. Until a few years ago, we would have approached this problem by first oversimplifying it into its core components and then using quantum mechanical simulations. However, these calculations are computationally very demanding: for a system like this, it could take hours on a supercomputer just to analyze a single trajectory step! With the AI boom, machine-learning interatomic potentials (MLIPs) have become one of the most promising alternatives. Instead of running expensive quantum-mechanical calculations at every step, we can now perform only a small number of them and use the results as a training set for neural networks. Once trained, the MLIP can look at the complex atomic configuration of a system and immediately predict the energies and forces acting on each atom, without solving the underlying physics equations. This allows the simulation to evolve in milliseconds rather than hours, opening the door to simulations that were previously impractical. Without the Scientific Python ecosystem, the development of machine learning methods in quantum chemistry would have a very hard time, since libraries such as PyTorch, Scikit-learn, and TensorFlow, combined with atomistic workflow tools like the Atomistic Simulation Environment (ASE), form the backbone of these methods. Importantly, most MLIPs are also open-source projects, whether developed by universities (MACE, CHGNet, and M3GNet) or by research groups at large technology companies such as Google DeepMind and Meta FAIR (UMA). In this talk, we will explore how Scientific Python libraries power modern MLIP workflows, from dataset generation and model training to large-scale atomistic simulations. We will introduce the key ideas behind them in an intuitive way and discuss the current state of the field. Finally, we will highlight where current research is heading: from predicting how atoms move to learning the behavior of electrons, which ultimately determine those motions as well as many other fundamental properties, a much more challenging task. scipy-2026-93239-how-is-python-transforming-materials-modeling-with-machine-learning Data-Driven Discovery, Machine Learning and Artificial Intelligence Filippo Balzaretti en false https://pretalx.com/scipy-2026/talk/BQDMZH/ https://pretalx.com/scipy-2026/talk/BQDMZH/feedback/ Memorial Hall Talk 2026-07-17T14:35:00-05:00 14:35 00:30 LLMs are powerful, but their knowledge is frozen — they can't access your private documents or recent information. Retrieval-Augmented Generation (RAG) solves this by searching relevant documents and including them in the prompt, grounding responses in real information. But building a good retrieval system involves many steps: reading diverse file formats, chunking text at sensible boundaries, computing embeddings, and combining search strategies. This talk introduces raghilda, a Python framework that handles the full retrieval pipeline. We'll cover how RAG works, how to build a retrieval system with raghilda, and how to connect it to an LLM with a practical example. scipy-2026-92509-retrieval-augmented-generation-with-raghilda Data-Driven Discovery, Machine Learning and Artificial Intelligence Carson SievertDaniel FalbelTomasz Kalinowski en LLMs are powerful, but their knowledge is frozen — they can't access your private documents or recent information. When asked about topics outside their training data, they either refuse to answer or hallucinate confident-sounding responses. Retrieval-Augmented Generation (RAG) solves this by searching relevant documents and including them in the prompt, grounding responses in real information. While long context windows (100K+ tokens) might seem to make retrieval unnecessary, research on "lost in the middle" effects shows that LLMs lose track of information buried in long prompts. RAG provides precision: the model sees a handful of relevant paragraphs instead of hundreds of irrelevant pages. But building a good retrieval system involves many steps: reading diverse file formats, chunking text at sensible boundaries, computing embeddings, and combining search strategies. Each step has pitfalls — HTML-to-text conversion is messy, naive fixed-size chunking splits code blocks and paragraphs in half, and pure vector search misses exact keyword matches. This talk introduces raghilda, an open-source Python framework that handles the full retrieval pipeline with sensible defaults while keeping every step exposed and replaceable. We'll build a RAG system from scratch, walking through each stage of the pipeline: Ingestion: turning raw documents into a searchable store. We'll cover how to read diverse sources (URLs, PDFs, DOCX files) and convert them to a common format, how to crawl websites to discover pages automatically, how to chunk text at semantic boundaries (headings, paragraphs, sentences) rather than at arbitrary character offsets, why preserving heading hierarchy as context metadata matters for retrieval quality, and how embeddings are computed and stored alongside the text. Retrieval: finding the right chunks given a query. We'll explore why pure vector similarity search isn't enough, how BM25 keyword matching complements semantic search, how attribute filters let you scope queries by metadata (source URL, document type, custom fields), and how these strategies combine into hybrid retrieval. Integration: connecting retrieval to an LLM and measuring how well it works. We'll show how to register a search function as a tool that the LLM calls when it needs information, and demonstrate the difference in answer quality between an augmented and unaugmented model on domain-specific questions. We'll also discuss how to evaluate a RAG system: both the retrieval component and the end-to-end generation, and how tuning chunking parameters, search strategies, and reranking affects downstream answer quality. Throughout, we'll use raghilda to implement each step, showing both the high-level one-liner workflow and the lower-level components so attendees understand what's happening at each stage and how to customize it for their own use cases. - Source code: https://github.com/posit-dev/raghilda - Documentation: https://posit-dev.github.io/raghilda/ false https://pretalx.com/scipy-2026/talk/39NQ3Y/ https://pretalx.com/scipy-2026/talk/39NQ3Y/feedback/ Memorial Hall Lightning Talk 2026-07-17T15:30:00-05:00 15:30 01:00 Lightning talks are 5-minute talks on any topic of interest for the SciPy community. We encourage spontaneous and prepared talks from everyone, but we can’t guarantee spots. Sign ups are at the NumFOCUS booth during the conference. scipy-2026-97787-lightning-talks Lightning Talks en false https://pretalx.com/scipy-2026/talk/DVGCMK/ https://pretalx.com/scipy-2026/talk/DVGCMK/feedback/ Memorial Hall Birds-of-a-Feather (Bof) 2026-07-17T16:40:00-05:00 16:40 00:55 AI tool adoption is outpacing our ability to thoughtfully decide how, when, and whether to use it. Researchers, maintainers, and contributors are reacting in real time both to the use of AI tools in open source development and to the flood of AI-assistance contributions that continue to strain human open source infrastructure. Peer-review programs like pyOpenSci and JOSS, along with maintainer teams across the ecosystem, are being forced to react by creating guardrails and protection systems on the fly. The result of this is a difficult combination of introduced technical debt caused by the unguided use of AI tools in software development, burnout across volunteer teams who are fielding rapid AI-assisted contributions, and polarization around whether AI tools have a productive place in open source community at all. scipy-2026-102438-beyond-the-hype-ai-tools-in-scientific-open-source-in-heritage-gallery-room Birds of a Feather (BoFs) Leah Wasser en pyOpenSci has received support from the Sloan Foundation to better understand the challenges and opportunities that AI tools present for scientific open source. Grounded in the idea that AI represents a collaboration between humans and analytic tools — where human judgment drives which tool, when, and how — we'll facilitate small-group discussions to collect real stories of impacts, from across our collective community. Whether you're a researcher considering AI tools in your workflow, a maintainer fielding AI-assisted contributions, or a contributor navigating new expectations, this session is for you. Help us shape the resources and frameworks we'll develop over the next six months — and learn how to get involved. About pyOpenSci pyOpenSci broadens participation in scientific open source by breaking down social and technical barriers. Our community works together to make participation in open source more accessible to everyone, everywhere. We run an open peer review process for scientific Python software and develop accessible, open learning resources that tackle common challenges—like software development, packaging, and the use of AI tools in scientific open source—in support of open and reproducible scientific discovery. false https://pretalx.com/scipy-2026/talk/QCWPTS/ https://pretalx.com/scipy-2026/talk/QCWPTS/feedback/ Memorial Hall Birds-of-a-Feather (Bof) 2026-07-17T17:45:00-05:00 17:45 00:55 Come join the BoF to do a practice run on contributing to a GitHub project. We will walk through how to open a Pull Request for a bugfix, using the workflow most libraries participating at the weekend sprints use (hosted by the sprint chairs) scipy-2026-102467-scipy-2026-sprint-prep-bof-in-heritage-gallery-room Birds of a Feather (BoFs) en false https://pretalx.com/scipy-2026/talk/UR8WPT/ https://pretalx.com/scipy-2026/talk/UR8WPT/feedback/ Johnson Great Room Talk 2026-07-17T10:45:00-05:00 10:45 00:30 Graduate textbooks in applied mathematics are notoriously inscrutable, dense with symbolic derivations never connected to intuition, application, or executable code. This talk presents a teaching pattern: Motivate, Symbolize, Derive, Lambdify, Simulate, Validate. The infrastructure is stable self-contained marimo notebooks with tests and automated publishing via GitHub Actions. Within the notebook, SymPy handles the symbolic stages; NumPy, SciPy, and matplotlib handle numerics and visualization. We demonstrate the pattern through a complete interactive treatment of Isaacs' Homicidal Chauffeur, a classical pursuit-evasion differential game, and close with an invitation to collaborate on open-source educational content in advanced applied mathematics. scipy-2026-93240-derivations-not-just-simulations-teaching-applied-mathematics-with-scientific-python Scientific Computing in Education /media/scipy-2026/submissions/TBDWJZ/image_KxI4XY0.webp Michael Zargham en **Why: The Gap in Advanced Applied Mathematics Education** The scientific Python ecosystem has transformed computational education. QuantEcon demonstrated that graduate-level economics can be taught through executable notebooks; the Executable Books Project built supporting infrastructure; the Scientific Python Lecture Notes teach scientific programming. These contributions work well when the subject is inherently numerical: the insight is in the computational behavior. Advanced applied mathematics is different. In calculus of variations, optimal control, and differential game theory, the central insights are irreducibly symbolic: coordinate reductions, optimality conditions, conservation laws, geometric classifications of solution structure. A student who runs an ODE solver learns what the system does, not why the solution takes the form it does. The standard textbooks, Kirk's Optimal Control, Bryson and Ho's Applied Optimal Control, and Isaacs' Differential Games, present derivations as static prose to be followed, not arguments to be executed. The gap between following a derivation on the page and computing with it is left entirely to the reader. **What: A Six-Stage Didactic Pattern** We present a six-stage pattern structured around the learner's experience: 1. Motivate — ground the problem in physical intuition and applications before any formalism 2. Symbolize — define state, parameters, and dynamics as SymPy expressions before touching numerics 3. Derive — execute the mathematical argument symbolically; learners witness structural results rather than being asked to trust them 4. Lambdify — convert symbolic expressions to numerical functions via sp.lambdify, eliminating manual transcription and the silent errors it produces 5. Simulate — integrate the lambdified dynamics and explore behavior interactively through marimo sliders 6. Visualize — plot trajectories, reachable sets, and phase portraits to connect symbolic results to physical intuition Above is the learner's arc. The author's responsibilities are separate: verification (does the code correctly implement the mathematics) and validation (is the numerical demonstration provide intuition). SymPy makes verification tractable: symbolic identities become pytest assertions that run in CI. Validation is achieved through the same simulations and visualizations the learner experiences. Crucially, this architecture affords a learner-to-author transition: a learner who forks the repo moves from consuming the author's V&V to owning it, extending derivations, updating tests, and validating through their own simulations. A static PDF cannot support this. A version-controlled repo with CI can. **How: The Toolchain** SymPy provides computer algebra for the Symbolize, Derive, and Lambdify stages. NumPy and SciPy supply the numerical substrate, in particular solve_ivp for trajectory integration. matplotlib handles visualization. marimo provides a reactive notebook environment: cells re-execute automatically when dependencies change, eliminating hidden state and keeping interactive controls consistent with the derivation. pytest and GitHub Actions close the loop: tests verify correctness on every commit and the notebook publishes automatically to GitHub Pages. We demonstrate the full stack through the Homicidal Chauffeur problem (Isaacs, RAND, 1951; Merz, Stanford, 1971), a pursuit-evasion differential game between a fast-but-constrained pursuer and a slow-but-agile evader. The symbolic layer handles the 5-DOF to 2-DOF coordinate reduction, bang-bang optimal control, costate conservation, and Merz's singular surface taxonomy. The numerical layer simulates and visualizes what the analysis established. [Source Code](https://github.com/mzargham/hc-marimo). [Hosted Live](https://mzargham.github.io/hc-marimo/.) false Example Repository Deployed Notebook https://pretalx.com/scipy-2026/talk/TBDWJZ/ https://pretalx.com/scipy-2026/talk/TBDWJZ/feedback/ Johnson Great Room Talk 2026-07-17T11:25:00-05:00 11:25 00:30 Improving automatic speech recognition (ASR) for children is needed to enhance education and early childhood development. When ASR fails for children, reading assessments mis-score, speech therapy tools become unreliable, and many classroom tools cannot be built at all. The ASR gap exists because data sensitivity complicates the collection and sharing of transcribed child audio. **In this presentation, we’ll share how to unblock progress by creating public useful AI infrastructure even when data can’t be shared openly.** We’ll discuss what makes child ASR so hard, how we advanced the field with an AI modeling competition, and best practices for sharing pretrained models. scipy-2026-92276-horton-hears-a-word-building-ai-infrastructure-for-children-s-speech-recognition Scientific Computing in Education /media/scipy-2026/submissions/E8XVHN/image_kajp9l3.webp Katie Wetstone en Better child-centered automated speech recognition (ASR) is needed to unlock new research and tools to help teachers teach and students learn. ASR is largely solved for adults but remains a challenge for children, especially in noisy, real-world learning environments. Children’s speech presents distinct modeling challenges: greater acoustic variability, inconsistent pronunciation, uneven speech and linguistic development, and unpredictable grammar and vocabulary. There are also wide differences across age, accents, and speech tasks. Yet the development of robust ASR models for children is fundamental to universal screening, personalized literacy and reading instruction, speech therapy, and educational games. The applicability of these models extends to communication, commercial, and medical contexts. **This talk will present new, benchmarked ASR models developed through a [crowdsourced AI competition](https://www.drivendata.org/competitions/group/childrens-asr-competition/).** The competition draws on a combined corpus of pre-existing child speech datasets and newly curated, annotated recordings, comprising 560,000 transcribed utterances and 519 hours of child speech. We will discuss how hosting a competition can enable progress in a domain where the data is sensitive, difficult to collect, and difficult to share. **Then, we will break down what we learned from the competition about effective modeling approaches for child ASR.** We will discuss the strengths of various transformer-based architectures, such as Parakeet, Canary, Whisper, and Qwen, as well as fine-tuning strategies to produce transcription outputs suitable for diagnostic and speech-screening applications. We will also discuss why competitions remain useful in the age of AI agents. **Beyond modeling results, we will describe the broader AI infrastructure challenge at the center of this work.** Improving child ASR requires access to large, representative datasets, but children’s speech raises difficult questions around privacy, identifiability, and responsible model release. We will discuss the tradeoffs involved in using private data to evaluate public approaches, collecting demographic information to assess bias while limiting privacy risk, and deciding what parts of an AI system can be made shareable when the underlying data cannot be fully open. **The goal of this talk is to present a pathway to unblocking progress by creating pre-trained models as a public good when the underlying data cannot be shared.** The presentation is suitable for anyone interested in ASR and its use in educational contexts, as well as people in any field working with sensitive data, thorny data ethics questions, or the challenge of building shared AI infrastructure when datasets cannot simply be released publicly. false https://pretalx.com/scipy-2026/talk/E8XVHN/ https://pretalx.com/scipy-2026/talk/E8XVHN/feedback/ Johnson Great Room Talk 2026-07-17T13:15:00-05:00 13:15 00:30 Visualization libraries like Altair are based on the Grammar of Graphics (GoG), a theory of visualization that moved beyond fixed chart types towards a composable graphical language. But while the GoG makes simple charts easy, custom graphics still require low-level libraries like matplotlib. We present GoFish, a grammar of *more* graphics! GoFish formalizes patterns of visual structure (like connecting shapes with lines or spreading them out in space) letting you create diagrams, annotated charts, and infographics piece by declarative piece. In this talk, we'll see some fun and funky GoFish charts, and I'll uncover the hidden structure behind everyday visualizations. scipy-2026-93148-gofish-a-grammar-of-more-graphics General /media/scipy-2026/submissions/KHRTU8/image_3O4zpk0.webp Josh Pollock en Libraries like Altair and Plotly brought the Grammar of Graphics to Python, making it easy to map data to marks (bar, line, area, etc.) and channels (size, color, position, etc.). But when you need annotations, custom layouts, or pictographic designs, you're back to wrestling with matplotlib and manually computing coordinates. GoFish is a new, open-source Python library we’ve developed at MIT for making custom, data-driven graphics. It is MIT-licensed and currently in alpha, but will hit beta before the conference. It's available on pypi as gofish-graphics. While most visualization libraries are built on marks and channels, GoFish is also built around _visual structure_, like spreading shapes out in space, connecting shapes with lines, or containing them in a common region. We call these primitives _graphical operators_. In conjunction with marks and channels, graphical operators allow GoFish users to easily produce a wide range of graphics: richly annotated bar charts and scatter plots; nested charts like scatterpies; polar ribbon charts; and composited images that layer and intersect shapes. They also give us a new understanding of more typical charts like stacked bars, waffles, and ribbons, which turn out to be simple combinations of just a few operators. **About Me** I'm a last-year PhD student at MIT in the VIS group. My research applies programming language theory to visualization design. I presented GoFish as a full paper at the IEEE VIS conference in November, 2025 to a standing-room only crowd. - Paper, website, and code: https://vis.csail.mit.edu/pubs/gofish/. - VIS talk: https://youtu.be/S3LGLxyblpM?si=dlhSoPpHHuXWp7m6&t=660. **Audience and Takeaways** The audience for the talk is anyone who's hit the limits of a library like Altair, Plotly, or seaborn, built a scientific figure in Matplotlib, or is just curious about the theory behind visualization. The audience will leave the talk with both a practical understanding of how GoFish can be used to build visualizations and a new conceptual understanding of how graphics are structured. **Talk Outline** _The Grammar of Graphics and its limits (~5 min)._ I'll introduce the marks-and-channels approach to specifying charts, some of its history, and its use in Python. I'll then frame the core tension: high-level libraries like Altair are easy but restrictive, while low-level libraries like Matplotlib are expressive but tedious. What if there was a better way? _Building up GoFish by example (~15 min)._ I'll start by showing examples of visual structure in familiar charts to build intuition for what graphical operators capture. I'll then introduce GoFish's API piece by piece: first marks and channels, then graphical operators that compose marks into glyphs and charts. Along the way I'll show how users can use libraries like pandas with GoFish for sorting and aggregation; how GoFish's compositional approach naturally supports nested charts like scatterpies; and how selecting marks in an existing chart makes it easy to add annotations and connecting ribbons. _The fun stuff and a call to action (~5 min)._ I'll wrap up with a showcase of cool graphics GoFish enables, and I'll end with an invitation to try GoFish and contribute. We want to help more people create expressive visualizations! false GitHub Repo Website PyPi https://pretalx.com/scipy-2026/talk/KHRTU8/ https://pretalx.com/scipy-2026/talk/KHRTU8/feedback/ Johnson Great Room Talk 2026-07-17T13:55:00-05:00 13:55 00:30 You're staring at a plot in a notebook. A subset of points doesn't look right. You want to select them, inspect them, understand _why_. In a traditional notebook, that means stopping to write more code and re-run cells. The exploration becomes an exercise in programming, not insight. This talk comes in two parts. First, I introduce two primitives: reactive cell execution (marimo) and widgets (anywidget) that bridge Python and the browser. A brush stroke on a scatter plot becomes a Python selection. A slider flows through your analysis. Second, I build intuition for composing these primitives—from quick explorations to reusable, domain-specific instruments that let you craft the interaction to match your scientific question. scipy-2026-93202-ask-more-of-your-notebook-what-can-anywidgets-do-for-you General Trevor Manz en Interactive widgets connect Python objects to browser-based UIs, letting you explore and manipulate data beyond static output. Composing widgets in traditional notebooks, however, means writing callback-based code (event handlers, state management, update coordination), a style that is error-prone and differs from the cell-based, REPL-like style most familiar to notebook users. Reactive execution offers a simpler model. marimo (https://marimo.io) models a notebook as a dataflow graph. When a value changes, dependent cells re-execute automatically. The system ensures consistency. anywidget (https://anywidget.dev) provides a specification for creating custom widgets with Python and JavaScript, giving you access to any browser API from within a notebook. In a reactive notebook environment, these widgets participate in the dataflow graph like any other value. This talk introduces these two primitives and builds up a mental model for working with them. I start with how existing widgets compose in a reactive environment: a slider updates a parameter, dependent cells react, a chart selection filters a dataframe. These are patterns that work out of the box. From there, I show how to compose off-the-shelf widgets with custom ones to build domain-specific interactions, such as inspecting outliers or comparing experimental conditions. These don't need to be polished applications; they can live in a notebook and be shared with collaborators when useful. Attendees will leave with a working understanding of these primitives and practical patterns for building interactive tools that help them and their collaborators make their data feel more tangible. false https://pretalx.com/scipy-2026/talk/38FQ9D/ https://pretalx.com/scipy-2026/talk/38FQ9D/feedback/ Johnson Great Room Talk 2026-07-17T14:35:00-05:00 14:35 00:30 Tiled is a full-fledged data management service designed specifically to help scientists store, find, and access scientific data at scale easily. The concept of data structures is the cornerstone of Tiled; it allows us to abstract the inherent diversity of various file formats and data storage types to a handful of scientifically meaningful representations: arrays, tables, nested hierarchies, and even awkward, ragged, and sparse arrays. Tiled provides a consistent API to such disparate datasets and naturally integrates with the SciPy ecosystem, including NumPy, pandas, xarray, Dask, and more. The users can slice, convert, and retrieve only the data they need, or even subscribe to live streams from external instruments and send updates to a dashboard. Importantly, Tiled supports operations with rich metadata – including search – making the data registered in Tiled discoverable and interactable with minimal overhead, by the human users and AI agents alike. Tiled runs equally well on a private laptop or in a large facility’s data center. Its built-in authentication and authorization mechanisms make the data access controllable and secure. Finally, Tiled is a fully open-source project developed under a multi-institutional governance model, which reflects our commitment to open science and the FAIR principles in scientific computing. In this talk we will introduce Tiled’s architecture, demonstrate its most popular use cases using the native Python client, discuss deployment and integration strategies, and show how it can simplify practical scientific data workflows. scipy-2026-93217-remote-access-to-scientific-data-with-tiled General Yevgen Matviychuk en ## Motivation and Background Scientific datasets, especially from large experimental facilities, are growing in size and complexity. Researchers increasingly face the challenges of securely sharing large volumes of data between institutions while juggling a multitude of storage formats. These obstacles emphasize the need for decoupling the storage infrastructure from the analytical workflows, so that scientists can focus on computation and interpretation rather than data plumbing. Traditional access patterns, where entire files are transferred and parsed locally, strain bandwidth, memory, and compute resources. The recent advent and widespread adoption of agentic workflows further highlight this problem: to operate efficiently, an AI agent often benefits from having a direct access to certain dataset slices enriched with metadata – a requirement, which is difficult to fulfil with the file-centric approach. Tiled was developed within the synchrotron light source community (e.g., National Synchrotron Light Source II and other facilities using the Bluesky ecosystem) to address these challenges, but it is agnostic to the specifics of the application domain. The project aims to provide a unified, high-performance, feature-rich service that lets users interact with their data without making any considerations about the underlying storage formats and infrastructure. It lets users slice, search, and stream only the pieces of data they need – whether arrays, tables, or hierarchical datasets – and treat them as familiar NumPy or pandas objects. ## What is Tiled? Tiled’s core offering is a data access and management service with: * A web server that exposes structured datasets via HTTP APIs. * A Python client that seamlessly integrates with popular tools in scientific computing, such as NumPy, pandas, xarray, Dask, AwkwardArray, etc.; users of h5py or zarr, for example, would find Tiled’s interface familiar. * Support for multiple underlying data sources: filesystems, databases, remote servers, blob storages, or combinations thereof. * Efficient format transcoding and chunked data access: users can retrieve just the subset of data they need, reducing I/O and network costs. * An easily expandable set of supported storage formats (e.g. zarr, parquet, csv, hdf5, etc.) and extensible data structures beyond simple arrays and tables (e.g. sparse, awkward, and ragged arrays). * Integrated caching, both client-side and server-side, to accelerate repeated access and interactive exploration. * Streaming capabilities via WebSockets, enabling real-time data updates and interactive workflows, which is particularly valuable for live experiments, monitoring dashboards, and adaptive analysis pipelines. * Built-in authentication and authorization (authN/authZ) mechanisms, allowing deployments to enforce fine-grained access control. Tiled supports multiple authentication providers and role-based permissions, making it suitable for multi-user facilities, collaborative research groups, and cloud deployments. ## Relevance to SciPy Community and Broader Audience Even though Tiled has originated from and is used widely in the synchrotron light source community, the problems it solves are universal wherever large or complex datasets are involved, from genomics to environmental science to astronomy. Tiled fills a gap by offering a flexible, secure, and convenient data access abstraction layer that complements computational tools. Its integration with the SciPy ecosystem and standards makes it directly applicable to users in practically any scientific domain. false Project Documentation Source Code on GitHub https://pretalx.com/scipy-2026/talk/U7SRHU/ https://pretalx.com/scipy-2026/talk/U7SRHU/feedback/ Johnson Great Room Birds-of-a-Feather (Bof) 2026-07-17T16:40:00-05:00 16:40 00:55 Come share your ideas for next year's SciPy. Participants will have an opportunity to sign up to be on next year's organizing committee. scipy-2026-102466-scipy-2027 Birds of a Feather (BoFs) MadickenGil Forsyth en false https://pretalx.com/scipy-2026/talk/XFA9VF/ https://pretalx.com/scipy-2026/talk/XFA9VF/feedback/ Johnson Great Room Birds-of-a-Feather (Bof) 2026-07-17T17:45:00-05:00 17:45 00:55 Until very recently, producing and using reproducible scientific software environments required advanced knowledge and a strict adherence to best practices (e.g. DOI: 10.25080/majora-212e5952-028). Now, with the advent of modern tooling with lockfile-first workflows (i.e. Pixi and uv), and the emergence of lockfile standards across scientific open source, applications can be made reproducible at the digest level through tooling decisions. As this technology and practices become increasingly common there is an opportunity to define common best practices around lockfile based software development that can further reduce developer overhead and maintenance burden. This Birds of a Feather panel will focus on how experienced developers are leveraging lockfiles across software development, applications, and deployment while providing best practices and practical recommendations, while also highlighting continuing challenges and opportunities for improvement. Google Form for questions for the panel: https://forms.gle/1YP4951Yb9U4r2md6 scipy-2026-102465-lockfile-based-development-and-applications Birds of a Feather (BoFs) Naty ClementiMatthew FeickertRuben ArtsGil ForsythHenry Schreiner en false Google Form for asking the panel questions https://pretalx.com/scipy-2026/talk/WFXBKQ/ https://pretalx.com/scipy-2026/talk/WFXBKQ/feedback/ Thomas Swain Room Talk 2026-07-17T10:45:00-05:00 10:45 00:30 Nobody loves writing release notes... and it only gets worse when multiple institutions are editing the same file. We learned the hard way that using a single file, manual RST editing, and no validation leads to repeated merge conflicts every release cycle. In response, we built Brassy, a CLI tool that replaces single-file changelogs with per-change YAML files, assembles them into formatted release notes, and lints entries in CI. We also built PinkRST (an RST formatter) and a Python-based Sphinx build system to tie our large multi-institution and many repo software documentation together. This talk covers the tools, the integration, and what we learned about getting scientists to _actually_ write documentation. scipy-2026-93249-brassy-palatable-multi-institution-release-notes Maintainers and Community Gwyn Uttmark en We work as part of a multi-institutional team developing a newly open-sourced 17-year-old package for processing geolocated satellite and weather data. The package has dozens of plugin repositories, contributors across institutions, and operational users in the US Navy who depend on it for near-real-time tropical cyclone imagery. Once GeoIPS (Geolocated Information Processing System) was open-sourced, release notes became a huge pain point. Contributors would all edit the same reStructuredText (or at times, markdown) file by hand in different pull requests. There was no auto-enforceable standard format. No linting. Lots of merge conflicts. Consequentially, important changes slipped through undocumented and formatting varied wildly. We built three pieces of infrastructure to fix this, each of which is open-source, pip-installable, and lightweight. First we built Brassy (Build Release Assembler for Sane Software with YAML). Brassy swaps a shared changelog file for individual YAML files with one per change. For each , the contributor fills out a structured template (title, description, category, affected files, linked issues, etc.) generated by Brassy. At release time, Bbrassy assembles the changelog fragments into sphinx-compatible formatted RST. One file per change means near-zero merge conflicts and easy application of a change to this release or the next. Brassy also provides quality of life functionality by generating templates pre-populated with git-tracked file changes, pruning empty sections, and running as a CI linter to catch formatting problems on every pull request before they land. Secondly, we created pinkrst, an opinionated RST formatter in the spirit of Black for Python. It handles tedious autoformatting of reStructuredText for doc8 compatibility (line wrapping, whitespace cleanup, and consistent formatting of lists, headers and codeblocks) of the generated release notes. Third, we developed a more robust Python-based Sphinx build system. GeoIPS previously relied on a complex bash script to build documentation across its core package and many plugin repos. We replaced it with a Python builder that calls Brassy to assemble release notes from YAML directories, runs pinkrst to format the output, generates API docs for multiple packages via sphinx-apidoc, and builds multiple repos into final HTML. This pipeline handles docs for both the core GeoIPS package and any plugin, using shared templates, CI workflows and configuration. Tools alone don't solve documentation problems... For better or worse, people must actually use them! GeoIPS plugin writers are primarily scientists, not software engineers. Like many scientific projects, the codebase grew a lot faster than its docs and did so for for years. We'll talk about what worked: lowering the barrier, clear guidelines on "what" goes "where," catching problems early, and making standards obvious enough that contributors rarely need to ask. This talk is for anyone maintaining a multi-team open-source project . We will cover how per-change changelogs outperform single file release notes in distributed teams, how CI linting of non-code artifacts enforce standards without slowing people down, and do our best to offer practical advice for introducing new tooling into a project where no single team is the “leader.” false https://pretalx.com/scipy-2026/talk/HXFDCX/ https://pretalx.com/scipy-2026/talk/HXFDCX/feedback/ Thomas Swain Room Talk 2026-07-17T11:25:00-05:00 11:25 00:30 Foundational Python libraries provide critical functionality that diverse communities of downstream developers and users depend on. Often, gaps in awareness between a core project and its broader community silently erode trust, collaboration, and sustainability. This talk shares lessons from a community-driven initiative to (re)-connect [napari](https://napari.org/)—a foundational library for multi-dimensional image viewing built on the scientific Python stack—with its ecosystem of over 580 community-developed plugins. Through a working group of core contributors, plugin developers, and end users, the napari plugin sustainability initiative discovered that creating new avenues for communication and collaboration leads to shared ownership of ecosystem progress. scipy-2026-92502-re-connecting-foundational-libraries-with-their-communities-successes-failures-and-surprises-in-building-the-napari-plugin-sustainability-initiative Maintainers and Community Tim Monko en Many scientific Python projects follow a familiar arc: early excitement, rapid adoption, a burst of community-built extensions—and then a slow drift apart. This talk is for anyone maintaining a Python project with a broader community, developing downstream tools, or interested in practical approaches to open-source sustainability. Attendees will learn concrete strategies for community engagement, automated quality tooling, and shared infrastructure that can be adapted to any Python project ecosystem. In late 2025, with support from a [URSSI Early Career Fellowship](https://urssi.us/), [napari](https://napari.org/) launched the plugin sustainability initiative to rekindle the relationship between the core project and its downstream plugin community. A [working group](https://napari.org/stable/community/meeting_schedule.html) brought together core contributors, plugin developers, and users—novice to experienced—across roles, time zones, and disciplines. This talk will share what worked: engaging the global community, openness to community creativity, and creating space for domain scientists to share real workflows. It will also share real challenges: reaching folks who had already disengaged and including voices that don't have bandwidth for regular meetings. The most impactful finding has been how much the community *wants* to shape solutions once given the opportunity. The conversation was never "what should the core team do for us?" but "how can we work on this together?" This shift—from a service relationship to shared ownership—has been the single most valuable outcome. The biggest barriers remain social: not knowing whether contributions were welcome, not knowing who else was working on similar problems, and not having a channel that felt heard. The working group has converged on [three interconnected efforts](https://napari.org/island-dispatch/blog/plugin-sustainability-initiative.html) shaped by community priorities: **1. Automated and human review systems.** We're building automated tooling—inspired by [SciPy's repo-review](https://repo-review.readthedocs.io/en/latest/)—that checks plugin repositories for packaging quality, test coverage, and dependency health. Compatibility checks via [npe2api](https://github.com/napari/npe2api) detect when plugins break against new napari releases *before* users hit the problem. Alongside automation, human peer review modeled on [PyOpenSci](https://www.pyopensci.org/about-peer-review/) will pair experienced community members with plugin developers for domain-aware feedback. **2. Modernized packaging infrastructure.** We're updating the [napari-plugin-template](https://github.com/napari/napari-plugin-template) and [plugin documentation](https://napari.org/stable/plugins/index.html) based on firsthand accounts from working group members who upgraded their own plugins, with a focus on creating beginner-friendly and advanced tracks. This includes guidance on reproducible environments with [pixi](https://pixi.sh/) and [uv](https://docs.astral.sh/uv/), clearer separation of computation from UI code, and curated plugin bundles to address dependency conflicts. **3. Discoverability and stewardship.** We're surfacing maintenance status, compatibility, and quality signals on the [napari hub](https://napari-hub.org/). A plugin donation program would let maintainers hand off plugins to community stewards rather than abandoning them, and a shared GitHub organization will enable collective maintenance. These efforts are works in progress, but we have found bi-directional impact: downstream developers gain improved tooling and documentation, while investing back into the core napari project. Everything is open source and documented for other communities to adapt. Ultimately, investing in listening and shared ownership *while* building technical infrastructure is what engages a broad community and builds trust that spending time in the ecosystem is worthwhile. false https://pretalx.com/scipy-2026/talk/UNFTFU/ https://pretalx.com/scipy-2026/talk/UNFTFU/feedback/ Thomas Swain Room Talk 2026-07-17T13:15:00-05:00 13:15 00:30 Building software is often presented as the ultimate in asynchronous collaboration - open a PR, wait for a review, work on something else, and come back when it's a good time for you. The reality can often be... messier. As someone who lives in UTC+8, works in UTC+10, and collaborates globally, I'll share my experience of why 7AM meetings aren't all bad, how to deal with the itch to respond to reviews on a Saturday morning, and how I finally learnt to listen to my wife and learn to switch off when there was no good reason to be on. scipy-2026-92444-finding-the-right-time-collaborating-across-time-zones Maintainers and Community Charles Turner en I'm notionally a senior developer, but I only finished my PhD four years ago. What this means in practice for me is that I feel a lot of pressure to understand tools & libraries I've only just come across, figure out issues nobody else has (or can), and constantly dig deeper whilst maintaining a productive output. The added complication? I work remotely, a 38 hour drive from an office 2 timezones ahead of me. have a shed at the bottom of the garden where I work. This might seem great as a WFH work-life separator, but I have a gym in there too, so it's also where I exercise and tinker with things. In this talk, I'll outline: - Why there's nothing wrong with a 7AM meeting - so long as you're willing (and able!) to shut the computer off early too. - Why I **don't** bring my laptop into the house. - Why it's harder - not easier - to stop working when the office hours no longer line up. - How a nap in the hammock or a walk with the dog can be the right move for productivity - Why you shouldn't have Github, Slack, or Zulip on your phone - and why I do anyway. - How to forgive yourself for ignoring your own rules and opening a PR at 10PM on a Thursday night - and why you shouldn't berate yourself for it! This is not going to be a technical talk, but one about how to make peace with your compulsion to be useful, how to listen to your wife and switch off when you shouldn't be working, and how the dynamics of open source, time zones, and how the messy nature international collaboration makes it harder to say no to yet another project you don't have time for. false https://pretalx.com/scipy-2026/talk/KNDR8V/ https://pretalx.com/scipy-2026/talk/KNDR8V/feedback/ Thomas Swain Room Talk 2026-07-17T13:55:00-05:00 13:55 00:30 Most scientific python maintainers build for users who will `pip install` the code. In civic tech, your community members are policy researchers, journalists, or NGO advocates who may never touch a Python environment. This cross-disciplinary context changes maintainership: traditional open source practices serve double duty as engineering *and* social infrastructure. I'll share lessons learned in maintaining the [CIB Mango Tree](https://cibmangotree.org), a civic tech Python toolkit for detecting inauthentic behavior in social media. I’ll show how in civic tech context familiar practices, like release cycles and continuous integration, can be repurposed to surface the otherwise invisible developer work to the broader community. scipy-2026-92116-commit-to-community-open-source-practices-as-social-infrastructure-in-volunteer-civic-tech Maintainers and Community Kristijan Armeni en I'll start by briefly introducing the [Civic Tech DC](https://www.civictechdc.org), a non-partisan, non-profit community of volunteer technologists, policy thinkers, researchers, designers, and community leaders passionate about using open-source technology for public good in the Washington, DC area. I'll point out the unique aspect of community design centered around the biweekly in-person project nights. ### The double duty of open source maintainership in civic tech Drawing on my experience as a maintainer of the CIB Mango Tree project, I'll discuss three examples of familiar open source practices. I’ll highlight how in the civic tech context each of these serve a social function in addition to the engineering purpose. **Release schedule as community planning.** A regular and frequent release cycle primarily streamlines code distribution for the users. But there is a community angle to it as well: it boosts the visibility of ongoing volunteers who see their contributions ship when they can't commit long-term. Similarly, versioning code streamlines conversations about project development across diverse team members: saying `v0.10.0` becomes as much a reference to code version by maintainers as well as a community signal by project managers to coordinate around for future plans. **Continuous integration as progress visibility.** Among developers, continuous integration (CI) primarily ensures ongoing code integrity. In our project, CI also helps us with external progress visibility to the broader community beyond maintainers alone. We use CI to build executable previews of the development version. Our project and product managers can thus try out new features right as maintainers put them into the development branch. **Dependency selection as onboarding policy.** Choosing right-sized dependencies is primarily about balancing code complexity and performance, but equally about right-sizing the onboarding ramps for volunteer contributors. Choosing a dashboard framework that does not offer production-grade capabilities but comes with a simpler mental model to navigate makes it easier for new volunteers to get up to speed and contribute. When volunteer bandwidth is fleeting and turnover rate high, this becomes a non-negligible decision factor. ### Learning from the design constraints of volunteer civic tech In civic tech, code and technical choices serve the broader community from the start. The civic tech lens forces a much more explicit and continuous emphasis on the community needs than I anticipated coming from the scientific Python background. This led to realization that collaborative open source practices we all know need not be siphoned away as invisible labor and can form a stronger bridge between the work of the developer and the broader community. false Project Website Technical Documentation Page Project GitHub Repository https://pretalx.com/scipy-2026/talk/AFWXAU/ https://pretalx.com/scipy-2026/talk/AFWXAU/feedback/ Thomas Swain Room Talk 2026-07-17T14:35:00-05:00 14:35 00:30 MNE-Python is open-source software for analyzing electrophysiological data in neuroscience. Like many projects, we struggle to retain maintainers. Finding maintainers in our user community is hard; most have little formal training in programming. To address this, we organized progressive training sprints with open applications and a participation stipend. Currently, we are onboarding four alumni of those sprints as new maintainers. We’ve seen positive outcomes from this approach, but at a high cost. We are now developing a curriculum for future onboarding efforts. We hope to spark discussions with other project leaders about their efforts toward educating and retaining talented maintainers. scipy-2026-92473-on-boarding-and-retaining-maintainer-talent-for-mne-python Maintainers and Community Daniel McCloyEric LarsonBritta Westner en _Background_ MNE-Python [1] is open-source software for analyzing electrophysiological data in neuroscience. We have a broad user base spanning neuroscience research, clinical neurology, and applied neurotechnology. _Problem statement_ Like many open-source software projects, MNE-Python is struggling to retain maintainers and reach a comfortable Truck Factor [2]. This is aggravated by academic incentive systems which devalue open source work compared to scientific publications [3], and the fact that many MNE-Python users are not formally trained in programming. Moreover, MNE-Python’s status as domain software makes it difficult for capable programmers lacking neuroscience backgrounds to fill the maintenance gap: there are too many domain-specific details that one must know to effectively maintain the codebase. Interventions To increase our contributor pool, we organized two New Developer Sprints and one Intermediate Developer Sprint. These fully-remote one-week courses were open to applications from the community, and participants received a stipend. Both types of sprint involved participants pair-programming with each other or with seasoned maintainers. In the New Developer Sprints, participants chose from a list of curated issues, complemented by short presentations from invited senior community members about how they benefitted from being MNE-Python contributors earlier in their careers. For the Intermediate Sprint, participants chose larger contributions in advance and spent the whole week on them, complemented by short presentations on pertinent topics (running and writing tests, building documentation, deprecations, CIs, etc). Currently, we are onboarding four alumni of those sprints as maintainers (and providing stipends during the two-year onboarding period), and writing a reusable curriculum to support future onboarding efforts. When complete, the domain-general parts will be extracted and published separately from the MNE-Python-specific curriculum. _Comparison to previous efforts_ Past contributors and maintainers mostly came from labs where the lab director had a vested interest in MNE-Python, or were recruited at conferences to contribute their methodological developments. In contrast, our current approach has been bottom-up: first training users how to contribute, then upskilling contributors to facilitate repeat contributions, and finally providing intensive training in maintainer-specific skills. This approach also allowed us to prioritize inclusivity in our recruitment, leading to a slight increase in the diversity of our regular contributors and maintainers. On the other hand, the sprints and maintainer onboarding were funded by three separate grants over a six-year period, and were a huge investment of existing maintainers’ time. _Preliminary results_ In our experience, providing education on how to contribute to open source, especially information specific to our project, greatly lowers the threshold for our users to be willing to attempt a contribution. However, the incentive structure of academia still works against retaining our contributors and maintainers long-term. We hope that by publicizing our onboarding curriculum and creating other “contributor ladder” resources, we will empower more users to self-educate about open-source contribution. This will hopefully increase the “input stream” of contributors, and may also increase retention: by making contribution easier through upskilling, hopefully each single contribution becomes less effortful and thus more likely to be attempted. _Open questions to community_ With this contribution, we hope to spark a discussion among open source software maintainers about their efforts toward educating and retaining talented maintainers. _Funding acknowledgment_ This project has been made possible in part by grant numbers 2020-219006 and 2021-237679 from the Chan Zuckerberg Initiative DAF, an advised fund of Silicon Valley Community Foundation, and by NSF POSE award 2449064. _References_ [1]: https://mne.tools/ and https://github.com/mne-tools/mne-python/ [2]: Avelino, G., Passos, L., Hora, A., & Valente, M. T. (2016). A Novel Approach for Estimating Truck Factors. 2016 IEEE 24th International Conference on Program Comprehension (ICPC), 1–10. https://doi.org/10.1109/ICPC.2016.7503718 [3]: Westner, B. U., McCloy, D. R., Larson, E., Gramfort, A., Katz, D. S., Smith, A. M., Delorme, A., Litvak, V., Makeig, S., Oostenveld, R., Schoffelen, J.-M., & Tierney, T. M. (2025). Cycling on the Freeway: The perilous state of open-source neuroscience software. Imaging Neuroscience, 3, imag_a_00554. https://doi.org/10.1162/imag_a_00554 false https://pretalx.com/scipy-2026/talk/J9EHEQ/ https://pretalx.com/scipy-2026/talk/J9EHEQ/feedback/ Thomas Swain Room Birds-of-a-Feather (Bof) 2026-07-17T17:45:00-05:00 17:45 00:55 This session will be a community discussion centered around developing interdisciplinary relationships between academic research institutions and non-academic institutions (industry, government, etc.). Using a new initiative from the Center for Interdisciplinary Exploration and Research in Astrophysics (CIERA) at Northwestern University as a model to build upon, develop, and learn from, we hope to build a shared understanding of how those engaged in scientific and technological development broadly would benefit from such efforts. The initiative – CIERA’s Tech Council – brings together a group of professionals (many of which with academic backgrounds) to serve as scientific collaborators, technical experts, community liaisons, and mentors. Starting from this point, we ask: What does it mean to create a rich and thriving ecosystem around an academic institution that translates technological expertise into scientific progress, increases accessibility of advanced tools and research, and builds community across varying career paths? As the SciPy Conference is a hub for interdisciplinary knowledge and skill sharing, it is a perfect place to hold such a discussion. scipy-2026-102464-the-academy-and-industry-building-interdisciplinary-relationships Birds of a Feather (BoFs) Alexandra ManningsCaleb Krueger en false https://pretalx.com/scipy-2026/talk/CKB9FU/ https://pretalx.com/scipy-2026/talk/CKB9FU/feedback/ Virtual Sessions Social Event 2026-07-17T16:40:00-05:00 16:40 01:05 You'll be randomly paired with another conference attendee for a 5-minute chat. Non-cheesy icebreakers will be provided. Virtual and in-person attendees welcome! Zoom link will be provided in the SciPy 2026 conference Slack team scipy-2026-103032-exclusively-on-zoom-virtual-speed-networking en false https://pretalx.com/scipy-2026/talk/CF3PMY/ https://pretalx.com/scipy-2026/talk/CF3PMY/feedback/