2.0 -//Pentabarf//Schedule//EN PUBLISH M8AZH8@@pretalx.com -M8AZH8 Introduction to Python and Programming (Room HSEC 3-110) en en 20260713T080000 20260713T120000 040000

Introduction to Python and Programming (Room HSEC 3-110)

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. PUBLIC CONFIRMED Tutorial https://pretalx.com/scipy-2026/talk/M8AZH8/ Intro Matt Davis PUBLISH TBVN9E@@pretalx.com -TBVN9E Interactive computing with marimo and anywidget (Room HSEC 2-138) en en 20260713T080000 20260713T120000 040000

Interactive computing with marimo and anywidget (Room HSEC 2-138)

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 PUBLIC CONFIRMED Tutorial https://pretalx.com/scipy-2026/talk/TBVN9E/ Viz Trevor Manz PUBLISH FVRNKP@@pretalx.com -FVRNKP Create custom image visualization and analysis tools with napari (Room HSEC 2-110) en en 20260713T133000 20260713T173000 040000

Create custom image visualization and analysis tools with napari (Room HSEC 2-110)

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. PUBLIC CONFIRMED Tutorial https://pretalx.com/scipy-2026/talk/FVRNKP/ Viz Tim Monko Ashley Anderson PUBLISH BMPMUR@@pretalx.com -BMPMUR Building A Deep Research Agent (Room HSEC 3-150) en en 20260713T080000 20260713T120000 040000

Building A Deep Research Agent (Room HSEC 3-150)

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! PUBLIC CONFIRMED Tutorial https://pretalx.com/scipy-2026/talk/BMPMUR/ AI/ML Benjamin Batorsky Eric Ma PUBLISH HFWAYG@@pretalx.com -HFWAYG Intro to Safe, Reliable, and Maintainable AI Apps in Python (Room HSEC 3-150) en en 20260713T133000 20260713T173000 040000

Intro to Safe, Reliable, and Maintainable AI Apps in Python (Room HSEC 3-150)

PUBLIC CONFIRMED Tutorial https://pretalx.com/scipy-2026/talk/HFWAYG/ AI/ML Carson Sievert PUBLISH SPXK7T@@pretalx.com -SPXK7T Accelerated Python Math Libraries (Room HSEC 2-110) en en 20260713T080000 20260713T120000 040000

Accelerated Python Math Libraries (Room HSEC 2-110)

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 PUBLIC CONFIRMED Tutorial https://pretalx.com/scipy-2026/talk/SPXK7T/ Accelerated Computing Katrina Riehl PUBLISH 9FQMMN@@pretalx.com -9FQMMN Reproducible CUDA Accelerated Workflows for Scientists with Pixi (Room HSEC 2-138) en en 20260713T133000 20260713T173000 040000

Reproducible CUDA Accelerated Workflows for Scientists with Pixi (Room HSEC 2-138)

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 — from compilers to runtime libraries — 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. PUBLIC CONFIRMED Tutorial https://pretalx.com/scipy-2026/talk/9FQMMN/ Accelerated Computing Matthew Feickert Ruben Arts Katrina Riehl PUBLISH CLBN3Z@@pretalx.com -CLBN3Z One Language to Rule Them All: Developing Reactive, Scientific Web Apps in Pure Python with Tethys Platform (Room HSEC 4-103/5) en en 20260713T080000 20260713T120000 040000

One Language to Rule Them All: Developing Reactive, Scientific Web Apps in Pure Python with Tethys Platform (Room HSEC 4-103/5)

PUBLIC CONFIRMED Tutorial https://pretalx.com/scipy-2026/talk/CLBN3Z/ Other Shawn Crawley PUBLISH GB3N9K@@pretalx.com -GB3N9K Introduction to Causal Inference (Room HSEC 3-110) en en 20260713T133000 20260713T173000 040000

Introduction to Causal Inference (Room HSEC 3-110)

* 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 PUBLIC CONFIRMED Tutorial https://pretalx.com/scipy-2026/talk/GB3N9K/ Other Roni Kobrosly PUBLISH GRTY3K@@pretalx.com -GRTY3K Thinking in Arrays (Room HSEC 2-132) en en 20260714T080000 20260714T120000 040000

Thinking in Arrays (Room HSEC 2-132)

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 PUBLIC CONFIRMED Tutorial https://pretalx.com/scipy-2026/talk/GRTY3K/ Intro Iason Krommydas Jim Pivarski PUBLISH XHCZTH@@pretalx.com -XHCZTH Everything is an Xarray Dataset (Room HSEC 2-138) en en 20260714T133000 20260714T173000 040000

Everything is an Xarray Dataset (Room HSEC 2-138)

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! PUBLIC CONFIRMED Tutorial https://pretalx.com/scipy-2026/talk/XHCZTH/ Intro Ian Hunt-Isaak Nick Hodgskin Eniola Awowale PUBLISH 7GVREJ@@pretalx.com -7GVREJ Evening Social: Taco Tuesday at the Market at Malcolm Yards en en 20260714T190000 20260714T230000 040000

Evening Social: Taco Tuesday at the Market at Malcolm Yards

PUBLIC CONFIRMED Tutorial https://pretalx.com/scipy-2026/talk/7GVREJ/ Intro PUBLISH XZLPB3@@pretalx.com -XZLPB3 Shiny for Python: Building Production-Ready Dashboards in Python (PWB 3-152) en en 20260714T080000 20260714T120000 040000

Shiny for Python: Building Production-Ready Dashboards in Python (PWB 3-152)

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. PUBLIC CONFIRMED Tutorial https://pretalx.com/scipy-2026/talk/XZLPB3/ Viz Daniel Chen PUBLISH VW3PAF@@pretalx.com -VW3PAF hvPlot and Panel: Powerful data visualization, exploration, and apps (Room HSEC 4-103/5) en en 20260714T133000 20260714T173000 040000

hvPlot and Panel: Powerful data visualization, exploration, and apps (Room HSEC 4-103/5)

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.). PUBLIC CONFIRMED Tutorial https://pretalx.com/scipy-2026/talk/VW3PAF/ Viz James A. Bednar PUBLISH KHQ3EK@@pretalx.com -KHQ3EK Build a SciPy Coding Assistant with RAG (Room HSEC 3-110) en en 20260714T080000 20260714T120000 040000

Build a SciPy Coding Assistant with RAG (Room HSEC 3-110)

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. PUBLIC CONFIRMED Tutorial https://pretalx.com/scipy-2026/talk/KHQ3EK/ AI/ML Cynthia Ukawu PUBLISH NWPPHA@@pretalx.com -NWPPHA Engineering Better Retrieval for RAG (Room HSEC 3-110) en en 20260714T133000 20260714T173000 040000

Engineering Better Retrieval for RAG (Room HSEC 3-110)

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._ PUBLIC CONFIRMED Tutorial https://pretalx.com/scipy-2026/talk/NWPPHA/ AI/ML Mahima Arora Aarti Jha PUBLISH XSWVVE@@pretalx.com -XSWVVE Deploying and debugging GPU accelerated Python workloads (Room HSEC 2-110) en en 20260714T080000 20260714T120000 040000

Deploying and debugging GPU accelerated Python workloads (Room HSEC 2-110)

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 PUBLIC CONFIRMED Tutorial https://pretalx.com/scipy-2026/talk/XSWVVE/ Accelerated Computing Naty Clementi Jacob Tomlinson Jaya Venkatesh PUBLISH RQQDGA@@pretalx.com -RQQDGA Computational Methods for Simulation using JAX and NumPy (Room HSEC 2-110) en en 20260714T133000 20260714T173000 040000

Computational Methods for Simulation using JAX and NumPy (Room HSEC 2-110)

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. PUBLIC CONFIRMED Tutorial https://pretalx.com/scipy-2026/talk/RQQDGA/ Accelerated Computing Smit Lunagariya PUBLISH VNQPKP@@pretalx.com -VNQPKP Network Analysis Made Simple (HSEC 4-103/5) en en 20260714T080000 20260714T120000 040000

Network Analysis Made Simple (HSEC 4-103/5)

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! PUBLIC CONFIRMED Tutorial https://pretalx.com/scipy-2026/talk/VNQPKP/ Other Eric Ma PUBLISH B8S8PH@@pretalx.com -B8S8PH Microwave Image Processing: Exploring realms of Earth through spaceborne Radars using Python (Room PWB 3-152) en en 20260714T133000 20260714T173000 040000

Microwave Image Processing: Exploring realms of Earth through spaceborne Radars using Python (Room PWB 3-152)

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. PUBLIC CONFIRMED Tutorial https://pretalx.com/scipy-2026/talk/B8S8PH/ Other Shubham Sharma PUBLISH ZFNUEG@@pretalx.com -ZFNUEG Opening Keynote: Thomas Caswell, "Stories in Code" en en 20260715T091500 20260715T100000 004500

Opening Keynote: Thomas Caswell, "Stories in Code"

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. PUBLIC CONFIRMED Keynote https://pretalx.com/scipy-2026/talk/ZFNUEG/ Memorial Hall PUBLISH YZU7X8@@pretalx.com -YZU7X8 SciPy Tools Plenary en en 20260715T100000 20260715T102500 002500

SciPy Tools Plenary

PUBLIC CONFIRMED Tools Plenary https://pretalx.com/scipy-2026/talk/YZU7X8/ Memorial Hall PUBLISH YUVEYH@@pretalx.com -YUVEYH One Problem, Many Projects: How Scientific Needs Built an Ecosystem en en 20260715T104500 20260715T111500 003000

One Problem, Many Projects: How Scientific Needs Built an Ecosystem

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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/YUVEYH/ Memorial Hall Jarrod Millman PUBLISH HBZ9RC@@pretalx.com -HBZ9RC Tying Up Loose Threads: Making your Project No-GIL Ready en en 20260715T112500 20260715T115500 003000

Tying Up Loose Threads: Making your Project No-GIL Ready

PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/HBZ9RC/ Memorial Hall Charlie Lin PUBLISH 8QMU8G@@pretalx.com -8QMU8G AI-Powered Field Inspection: Voice Capture, Data Extraction, and Intelligent Multi-Source Routing en en 20260715T131500 20260715T134500 003000

AI-Powered Field Inspection: Voice Capture, Data Extraction, and Intelligent Multi-Source Routing

## 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 PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/8QMU8G/ Memorial Hall Carolyn Olsen PUBLISH 93ERQP@@pretalx.com -93ERQP Reno: Simplifying Application of Bayesian Inference to System Dynamics en en 20260715T135500 20260715T142500 003000

Reno: Simplifying Application of Bayesian Inference to System Dynamics

# 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 PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/93ERQP/ Memorial Hall Nathan Martindale PUBLISH MCEMT9@@pretalx.com -MCEMT9 From Hello World to Hello LLM: A Python Developer’s Survival Guide en en 20260715T143500 20260715T150500 003000

From Hello World to Hello LLM: A Python Developer’s Survival Guide

PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/MCEMT9/ Memorial Hall Audrey Webb Jasmine Omeke PUBLISH SEYACQ@@pretalx.com -SEYACQ Docling for Multimodal Retrieval en en 20260715T152500 20260715T155500 003000

Docling for Multimodal Retrieval

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) PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/SEYACQ/ Memorial Hall Mahima Arora Aarti Jha PUBLISH 3TBXB8@@pretalx.com -3TBXB8 The future of OCR? Structured text extraction with LLMs en en 20260715T160500 20260715T163500 003000

The future of OCR? Structured text extraction with LLMs

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 PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/3TBXB8/ Memorial Hall Patrick Deziel PUBLISH HZVFJS@@pretalx.com -HZVFJS Lightning Talks en en 20260715T170000 20260715T180000 010000

Lightning Talks

PUBLIC CONFIRMED Lightning Talk https://pretalx.com/scipy-2026/talk/HZVFJS/ Memorial Hall PUBLISH CWCSEB@@pretalx.com -CWCSEB First-Timer Orientation en en 20260715T104500 20260715T111500 003000

First-Timer Orientation

PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/CWCSEB/ Johnson Great Room Julie Hollek Ed Rogers Ariana Mendible PUBLISH 9UQN9C@@pretalx.com -9UQN9C Automated Data Enrichment for Police Accountability: Where Agentic Judgment Earns Its Place en en 20260715T112500 20260715T115500 003000

Automated Data Enrichment for Police Accountability: Where Agentic Judgment Earns Its Place

## 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). PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/9UQN9C/ Johnson Great Room Hongsup Shin PUBLISH UFF7UR@@pretalx.com -UFF7UR Ship It or Skip It? When & How to Upgrade Your Open Source Dependencies en en 20260715T131500 20260715T134500 003000

Ship It or Skip It? When & How to Upgrade Your Open Source Dependencies

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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/UFF7UR/ Johnson Great Room Rebecca Ely Balaji Sundaram Shruti Sapre PUBLISH CV8VEH@@pretalx.com -CV8VEH Assessing the entrepreneurship option in uncertain times en en 20260715T135500 20260715T142500 003000

Assessing the entrepreneurship option in uncertain times

PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/CV8VEH/ Johnson Great Room Jocelyn Graf PUBLISH 77PGCB@@pretalx.com -77PGCB Profiling Python GPU Code en en 20260715T143500 20260715T150500 003000

Profiling Python GPU Code

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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/77PGCB/ Johnson Great Room Bryce Adelstein Lelbach Bradley Dice PUBLISH SUPRRW@@pretalx.com -SUPRRW Electrifying Aviation with Python: An End-to-End Data Pipeline from Test Stand to Analytics en en 20260715T152500 20260715T155500 003000

Electrifying Aviation with Python: An End-to-End Data Pipeline from Test Stand to Analytics

### 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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/SUPRRW/ Johnson Great Room Sarah Tabor PUBLISH EJSCLM@@pretalx.com -EJSCLM GPU-Accelerated Awkward Arrays with CUDA Python en en 20260715T160500 20260715T163500 003000

GPU-Accelerated Awkward Arrays with CUDA Python

**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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/EJSCLM/ Johnson Great Room Ianna Osborne Ashwin Srinath PUBLISH 7PSPJP@@pretalx.com -7PSPJP FAIRer Data: The case for Data Advertising in the age of Agentic AI en en 20260715T104500 20260715T111500 003000

FAIRer Data: The case for Data Advertising in the age of Agentic AI

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 PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/7PSPJP/ Thomas Swain Room Charles Turner PUBLISH ZTAB8K@@pretalx.com -ZTAB8K Computational Biodiversity Accounting for Agricultural Systems with Python en en 20260715T112500 20260715T115500 003000

Computational Biodiversity Accounting for Agricultural Systems with Python

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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/ZTAB8K/ Thomas Swain Room Hannah Ferriby PUBLISH E8QGYT@@pretalx.com -E8QGYT From LiDAR to action: detecting upland gullies to combat erosion and forest fires en en 20260715T131500 20260715T134500 003000

From LiDAR to action: detecting upland gullies to combat erosion and forest fires

**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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/E8QGYT/ Thomas Swain Room Jim Pivarski PUBLISH 97QQ8D@@pretalx.com -97QQ8D Accelerating Geospatial Analysis with GPUs en en 20260715T135500 20260715T142500 003000

Accelerating Geospatial Analysis with GPUs

## 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)** PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/97QQ8D/ Thomas Swain Room Jaya Venkatesh Jacob Tomlinson Naty Clementi PUBLISH N9YDEL@@pretalx.com -N9YDEL Nepho: A workflow for using mLLMs for atmospheric data plot exploration en en 20260715T143500 20260715T150500 003000

Nepho: A workflow for using mLLMs for atmospheric data plot exploration

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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/N9YDEL/ Thomas Swain Room Bobby Jackson PUBLISH XZGSV7@@pretalx.com -XZGSV7 Adapt: Prototyping a Real-Time, Reproducible Data Analysis Framework for Adaptive Radar Scanning en en 20260715T152500 20260715T155500 003000

Adapt: Prototyping a Real-Time, Reproducible Data Analysis Framework for Adaptive Radar Scanning

PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/XZGSV7/ Thomas Swain Room Bhupendra Raut PUBLISH ZZYN3X@@pretalx.com -ZZYN3X Navigating the Storm: Software Orchestration and Pipelines for AI-Driven Weather Forecasting en en 20260715T160500 20260715T163500 003000

Navigating the Storm: Software Orchestration and Pipelines for AI-Driven Weather Forecasting

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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/ZZYN3X/ Thomas Swain Room Nicholas Geneva PUBLISH TADDJP@@pretalx.com -TADDJP A Lean and Kind OME-Zarr Toolkit for Bioimaging en en 20260715T104500 20260715T111500 003000

A Lean and Kind OME-Zarr Toolkit for Bioimaging

**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) PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/TADDJP/ University Hall Matt McCormick PUBLISH ETT3W9@@pretalx.com -ETT3W9 Xarray DataStructures in Biology – Examples and Best Practices en en 20260715T112500 20260715T115500 003000

Xarray DataStructures in Biology – Examples and Best Practices

## 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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/ETT3W9/ University Hall Ian Hunt-Isaak PUBLISH BG3PSA@@pretalx.com -BG3PSA Discovering Particles: How we analyze petabytes of particle collision data using python en en 20260715T131500 20260715T134500 003000

Discovering Particles: How we analyze petabytes of particle collision data using python

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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/BG3PSA/ University Hall Iason Krommydas Henry Schreiner PUBLISH SX9977@@pretalx.com -SX9977 QDK/Chemistry: A Composable Python Toolkit for End-to-End Quantum Chemistry on Quantum Computers en en 20260715T135500 20260715T142500 003000

QDK/Chemistry: A Composable Python Toolkit for End-to-End Quantum Chemistry on Quantum Computers

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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/SX9977/ University Hall David Williams-Young PUBLISH BFQAPR@@pretalx.com -BFQAPR DerivKit: End-to-End Derivative-Based Inference in Scientific Python en en 20260715T143500 20260715T150500 003000

DerivKit: End-to-End Derivative-Based Inference in Scientific Python

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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/BFQAPR/ University Hall Niko Sarcevic Matthijs van der Wild PUBLISH NEKFB8@@pretalx.com -NEKFB8 Declare, Don't Parse: Composable genomic analysis with GIQL and Oxbow en en 20260715T152500 20260715T155500 003000

Declare, Don't Parse: Composable genomic analysis with GIQL and Oxbow

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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/NEKFB8/ University Hall Nezar Abdennur Conrad Bzura PUBLISH RE9ETJ@@pretalx.com -RE9ETJ Simulation-Informed Machine Learning Workflows for PETase Engineering en en 20260715T160500 20260715T163500 003000

Simulation-Informed Machine Learning Workflows for PETase Engineering

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 PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/RE9ETJ/ University Hall Sai Sanjana Prakash Charlie Hou Justin Kashi PUBLISH QF7KXB@@pretalx.com -QF7KXB Poster Session en en 20260715T180000 20260715T190000 010000

Poster Session

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) PUBLIC CONFIRMED Poster Session https://pretalx.com/scipy-2026/talk/QF7KXB/ University Hall PUBLISH UZB8CN@@pretalx.com -UZB8CN Virtual Poster Session en en 20260715T180000 20260715T190000 010000

Virtual Poster Session

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) PUBLIC CONFIRMED Poster Session https://pretalx.com/scipy-2026/talk/UZB8CN/ Virtual Sessions PUBLISH 7UJUMK@@pretalx.com -7UJUMK Keynote: Amber Case, "Calm Technology and the History of AI" en en 20260716T091500 20260716T100000 004500

Keynote: Amber Case, "Calm Technology and the History of AI"

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. PUBLIC CONFIRMED Keynote https://pretalx.com/scipy-2026/talk/7UJUMK/ Memorial Hall Amber Case PUBLISH B9GAJH@@pretalx.com -B9GAJH SciPy Tools Plenary en en 20260716T100000 20260716T102500 002500

SciPy Tools Plenary

PUBLIC CONFIRMED Tools Plenary https://pretalx.com/scipy-2026/talk/B9GAJH/ Memorial Hall PUBLISH PSQLHP@@pretalx.com -PSQLHP Pun Intended Consequences en en 20260716T104500 20260716T111500 003000

Pun Intended Consequences

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/) PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/PSQLHP/ Memorial Hall Paul Ivanov PUBLISH MEKP9F@@pretalx.com -MEKP9F Scipy, Numpy, Xarray and Python all have a pixi.toml. Why? en en 20260716T112500 20260716T115500 003000

Scipy, Numpy, Xarray and Python all have a pixi.toml. Why?

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 PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/MEKP9F/ Memorial Hall Ruben Arts PUBLISH JMFW8M@@pretalx.com -JMFW8M Instro: An open-source Python library for interfacing with hardware test equipment (in Heritage Gallery) en en 20260716T121500 20260716T130500 005000

Instro: An open-source Python library for interfacing with hardware test equipment (in Heritage Gallery)

PUBLIC CONFIRMED Lunch and Learn https://pretalx.com/scipy-2026/talk/JMFW8M/ Memorial Hall John Hoehner PUBLISH VLD7LX@@pretalx.com -VLD7LX Just throw it away? Class imbalance lessons from molecular machine learning to meatballs en en 20260716T131500 20260716T134500 003000

Just throw it away? Class imbalance lessons from molecular machine learning to meatballs

**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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/VLD7LX/ Memorial Hall Jackie Valeri PUBLISH ECYVWR@@pretalx.com -ECYVWR Compressing LSTM Networks for Scalable Retail Demand Forecasting: A Python-Based Approach to Efficient Time-Series Prediction en en 20260716T135500 20260716T142500 003000

Compressing LSTM Networks for Scalable Retail Demand Forecasting: A Python-Based Approach to Efficient Time-Series Prediction

**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 PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/ECYVWR/ Memorial Hall Ravi Teja Pagidoju PUBLISH GSBQXK@@pretalx.com -GSBQXK Enabling Agentic AI Infrastructure for Scientific Data Ecosystems en en 20260716T143500 20260716T150500 003000

Enabling Agentic AI Infrastructure for Scientific Data Ecosystems

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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/GSBQXK/ Memorial Hall Chirag Shah Utkarsh Mahai Austin Aguilar PUBLISH JVKEV7@@pretalx.com -JVKEV7 Lightning Talk en en 20260716T153000 20260716T163000 010000

Lightning Talk

PUBLIC CONFIRMED Lightning Talk https://pretalx.com/scipy-2026/talk/JVKEV7/ Memorial Hall PUBLISH WMAQPQ@@pretalx.com -WMAQPQ Scientific Python: Ecosystem Coordination & Maintainer Support (in Heritage Gallery Room) en en 20260716T164000 20260716T173500 005500

Scientific Python: Ecosystem Coordination & Maintainer Support (in Heritage Gallery Room)

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! PUBLIC CONFIRMED Birds-of-a-Feather (Bof) https://pretalx.com/scipy-2026/talk/WMAQPQ/ Memorial Hall Stéfan van der Walt PUBLISH RKS93M@@pretalx.com -RKS93M Securing the Scientific Python Supply Chain (in Heritage Gallery Room) en en 20260716T174500 20260716T184000 005500

Securing the Scientific Python Supply Chain (in Heritage Gallery Room)

PUBLIC CONFIRMED Birds-of-a-Feather (Bof) https://pretalx.com/scipy-2026/talk/RKS93M/ Memorial Hall Juanita Gomez Jarrod Millman Matthew Feickert PUBLISH UHUVMM@@pretalx.com -UHUVMM Agents for Correct, Transparent, and Reproducible Data Analysis en en 20260716T104500 20260716T111500 003000

Agents for Correct, Transparent, and Reproducible Data Analysis

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) PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/UHUVMM/ Johnson Great Room Sara Altman Simon Couch PUBLISH 3GRQ87@@pretalx.com -3GRQ87 Vibes, meet rigor: Evaluating and improving AI performance on complex scientific code en en 20260716T112500 20260716T115500 003000

Vibes, meet rigor: Evaluating and improving AI performance on complex scientific code

**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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/3GRQ87/ Johnson Great Room Cliff Kerr PUBLISH GT9Y9U@@pretalx.com -GT9Y9U When Vectorized Arrays Aren't Enough: Array Optimization from Bytecode to Assembly en en 20260716T131500 20260716T134500 003000

When Vectorized Arrays Aren't Enough: Array Optimization from Bytecode to Assembly

**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? PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/GT9Y9U/ Johnson Great Room Nicolas R Posner PUBLISH AVLJ7K@@pretalx.com -AVLJ7K Bridging data discovery and analysis using web components and JupyterLite en en 20260716T135500 20260716T142500 003000

Bridging data discovery and analysis using web components and JupyterLite

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). PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/AVLJ7K/ Johnson Great Room Christine Smit Jon Carlson PUBLISH QVKGLW@@pretalx.com -QVKGLW Dagster-slurm: Bringing Modern Data Orchestration to Slurm-Managed en en 20260716T143500 20260716T150500 003000

Dagster-slurm: Bringing Modern Data Orchestration to Slurm-Managed

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) PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/QVKGLW/ Johnson Great Room Hernan Picatto Georg Heiler PUBLISH ZNPYX9@@pretalx.com -ZNPYX9 GPU-Accelerated Python en en 20260716T164000 20260716T173500 005500

GPU-Accelerated Python

PUBLIC CONFIRMED Birds-of-a-Feather (Bof) https://pretalx.com/scipy-2026/talk/ZNPYX9/ Johnson Great Room Katrina Riehl PUBLISH QBWEZ7@@pretalx.com -QBWEZ7 Building Scientific Approaches to Generative AI en en 20260716T174500 20260716T184000 005500

Building Scientific Approaches to Generative AI

PUBLIC CONFIRMED Birds-of-a-Feather (Bof) https://pretalx.com/scipy-2026/talk/QBWEZ7/ Johnson Great Room Julie Hollek PUBLISH GBW7DW@@pretalx.com -GBW7DW Learning in the Open: Integrating Open Source Contributions into the Classroom en en 20260716T104500 20260716T111500 003000

Learning in the Open: Integrating Open Source Contributions into the Classroom

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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/GBW7DW/ Thomas Swain Room Inessa Pawson Ryan C Cooper Mohammad Mundiwala Ryan Curtin PUBLISH 8GVHWU@@pretalx.com -8GVHWU Accessible Python Powered Web Apps for the Classroom en en 20260716T112500 20260716T115500 003000

Accessible Python Powered Web Apps for the Classroom

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) PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/8GVHWU/ Thomas Swain Room Michael Greminger PUBLISH GVQECR@@pretalx.com -GVQECR Down the Rabbit Hole: History of the README and Why You Should Care en en 20260716T131500 20260716T134500 003000

Down the Rabbit Hole: History of the README and Why You Should Care

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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/GVQECR/ Thomas Swain Room Daina Bouquin PUBLISH TFEA7N@@pretalx.com -TFEA7N Building for the Road Ahead: Transferable Lessons from the Front Lines of Open Source Maintenance en en 20260716T135500 20260716T142500 003000

Building for the Road Ahead: Transferable Lessons from the Front Lines of Open Source Maintenance

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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/TFEA7N/ Thomas Swain Room Yuan Tang PUBLISH FAKEUM@@pretalx.com -FAKEUM Grammars of Data: lessons from ~20 years of the tidyverse en en 20260716T143500 20260716T150500 003000

Grammars of Data: lessons from ~20 years of the tidyverse

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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/FAKEUM/ Thomas Swain Room Hadley Wickham PUBLISH 8WTNKR@@pretalx.com -8WTNKR Funding Scientific Open Source in the Age of AI: New Challenges and Opportunities en en 20260716T164000 20260716T173500 005500

Funding Scientific Open Source in the Age of AI: New Challenges and Opportunities

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" PUBLIC CONFIRMED Birds-of-a-Feather (Bof) https://pretalx.com/scipy-2026/talk/8WTNKR/ Thomas Swain Room Dario Taraborelli PUBLISH LKAHLP@@pretalx.com -LKAHLP Virtual BoF: Resilient data, software, science, and culture en en 20260716T164000 20260716T173500 005500

Virtual BoF: Resilient data, software, science, and culture

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. PUBLIC CONFIRMED Birds-of-a-Feather (Bof) https://pretalx.com/scipy-2026/talk/LKAHLP/ Virtual Sessions Puneet Kollipara David Nicholson PUBLISH BKZVXU@@pretalx.com -BKZVXU Keynote: Dr. Joseph H. Kennedy, "Snakes in the Microwaves: How Python is Powering the Golden Age of SAR" en en 20260717T091500 20260717T100000 004500

Keynote: Dr. Joseph H. Kennedy, "Snakes in the Microwaves: How Python is Powering the Golden Age of SAR"

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. PUBLIC CONFIRMED Keynote https://pretalx.com/scipy-2026/talk/BKZVXU/ Memorial Hall Joseph H. Kennedy PUBLISH REGLJW@@pretalx.com -REGLJW SciPy Tools Plenary en en 20260717T100000 20260717T102500 002500

SciPy Tools Plenary

PUBLIC CONFIRMED Tools Plenary https://pretalx.com/scipy-2026/talk/REGLJW/ Memorial Hall PUBLISH YWHVF7@@pretalx.com -YWHVF7 Canvas Chat - non-linear workflows for AI-assisted data science en en 20260717T104500 20260717T111500 003000

Canvas Chat - non-linear workflows for AI-assisted data science

### 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/ PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/YWHVF7/ Memorial Hall Eric Ma PUBLISH W9QWGR@@pretalx.com -W9QWGR Open Exchange Architecture: From computational narrative to interactive preprint en en 20260717T112500 20260717T115500 003000

Open Exchange Architecture: From computational narrative to interactive preprint

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)" PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/W9QWGR/ Memorial Hall Tracy Teal Rowan Cockett PUBLISH BQDMZH@@pretalx.com -BQDMZH How Is Python Transforming Materials Modeling with Machine Learning? en en 20260717T131500 20260717T134500 003000

How Is Python Transforming Materials Modeling with Machine Learning?

PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/BQDMZH/ Memorial Hall Filippo Balzaretti PUBLISH 39NQ3Y@@pretalx.com -39NQ3Y Retrieval Augmented Generation with Raghilda en en 20260717T143500 20260717T150500 003000

Retrieval Augmented Generation with Raghilda

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/ PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/39NQ3Y/ Memorial Hall Carson Sievert Daniel Falbel Tomasz Kalinowski PUBLISH DVGCMK@@pretalx.com -DVGCMK Lightning Talks en en 20260717T153000 20260717T163000 010000

Lightning Talks

PUBLIC CONFIRMED Lightning Talk https://pretalx.com/scipy-2026/talk/DVGCMK/ Memorial Hall PUBLISH QCWPTS@@pretalx.com -QCWPTS Beyond the Hype: AI Tools in Scientific Open Source (in Heritage Gallery Room) en en 20260717T164000 20260717T173500 005500

Beyond the Hype: AI Tools in Scientific Open Source (in Heritage Gallery Room)

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. PUBLIC CONFIRMED Birds-of-a-Feather (Bof) https://pretalx.com/scipy-2026/talk/QCWPTS/ Memorial Hall Leah Wasser PUBLISH UR8WPT@@pretalx.com -UR8WPT SciPy 2026 Sprint Prep BoF (in Heritage Gallery Room) en en 20260717T174500 20260717T184000 005500

SciPy 2026 Sprint Prep BoF (in Heritage Gallery Room)

PUBLIC CONFIRMED Birds-of-a-Feather (Bof) https://pretalx.com/scipy-2026/talk/UR8WPT/ Memorial Hall PUBLISH TBDWJZ@@pretalx.com -TBDWJZ Derivations, Not Just Simulations: Teaching Applied Mathematics with Scientific Python en en 20260717T104500 20260717T111500 003000

Derivations, Not Just Simulations: Teaching Applied Mathematics with Scientific Python

**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/.) PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/TBDWJZ/ Johnson Great Room Michael Zargham PUBLISH E8XVHN@@pretalx.com -E8XVHN “Horton hears a word”: Building AI Infrastructure for Children’s Speech Recognition en en 20260717T112500 20260717T115500 003000

“Horton hears a word”: Building AI Infrastructure for Children’s Speech Recognition

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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/E8XVHN/ Johnson Great Room Katie Wetstone PUBLISH KHRTU8@@pretalx.com -KHRTU8 GoFish: A Grammar of More Graphics! en en 20260717T131500 20260717T134500 003000

GoFish: A Grammar of More Graphics!

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! PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/KHRTU8/ Johnson Great Room Josh Pollock PUBLISH 38FQ9D@@pretalx.com -38FQ9D Ask more of your notebook: what can anywidgets do for you? en en 20260717T135500 20260717T142500 003000

Ask more of your notebook: what can anywidgets do for you?

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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/38FQ9D/ Johnson Great Room Trevor Manz PUBLISH U7SRHU@@pretalx.com -U7SRHU Remote Access to Scientific Data with Tiled en en 20260717T143500 20260717T150500 003000

Remote Access to Scientific Data with Tiled

## 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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/U7SRHU/ Johnson Great Room Yevgen Matviychuk PUBLISH XFA9VF@@pretalx.com -XFA9VF SciPy 2027 en en 20260717T164000 20260717T173500 005500

SciPy 2027

PUBLIC CONFIRMED Birds-of-a-Feather (Bof) https://pretalx.com/scipy-2026/talk/XFA9VF/ Johnson Great Room Madicken Gil Forsyth PUBLISH WFXBKQ@@pretalx.com -WFXBKQ Lockfile-based development and applications en en 20260717T174500 20260717T184000 005500

Lockfile-based development and applications

PUBLIC CONFIRMED Birds-of-a-Feather (Bof) https://pretalx.com/scipy-2026/talk/WFXBKQ/ Johnson Great Room Naty Clementi Matthew Feickert Ruben Arts Gil Forsyth Henry Schreiner PUBLISH HXFDCX@@pretalx.com -HXFDCX Brassy: Palatable Multi-Institution Release Notes en en 20260717T104500 20260717T111500 003000

Brassy: Palatable Multi-Institution Release Notes

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.” PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/HXFDCX/ Thomas Swain Room Gwyn Uttmark PUBLISH UNFTFU@@pretalx.com -UNFTFU (Re)-connecting foundational libraries with their communities: Successes, failures, and surprises in building the napari plugin sustainability initiative en en 20260717T112500 20260717T115500 003000

(Re)-connecting foundational libraries with their communities: Successes, failures, and surprises in building the napari plugin sustainability initiative

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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/UNFTFU/ Thomas Swain Room Tim Monko PUBLISH KNDR8V@@pretalx.com -KNDR8V Finding the right time: Collaborating across Time Zones en en 20260717T131500 20260717T134500 003000

Finding the right time: Collaborating across Time Zones

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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/KNDR8V/ Thomas Swain Room Charles Turner PUBLISH AFWXAU@@pretalx.com -AFWXAU Commit to Community: Open Source Practices as Social Infrastructure in Volunteer Civic Tech en en 20260717T135500 20260717T142500 003000

Commit to Community: Open Source Practices as Social Infrastructure in Volunteer Civic Tech

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. PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/AFWXAU/ Thomas Swain Room Kristijan Armeni PUBLISH J9EHEQ@@pretalx.com -J9EHEQ On-boarding and retaining maintainer talent for MNE-Python en en 20260717T143500 20260717T150500 003000

On-boarding and retaining maintainer talent for MNE-Python

_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 PUBLIC CONFIRMED Talk https://pretalx.com/scipy-2026/talk/J9EHEQ/ Thomas Swain Room Daniel McCloy Eric Larson Britta Westner PUBLISH CKB9FU@@pretalx.com -CKB9FU The Academy and Industry: Building Interdisciplinary Relationships en en 20260717T174500 20260717T184000 005500

The Academy and Industry: Building Interdisciplinary Relationships

PUBLIC CONFIRMED Birds-of-a-Feather (Bof) https://pretalx.com/scipy-2026/talk/CKB9FU/ Thomas Swain Room Alexandra Mannings Caleb Krueger PUBLISH CF3PMY@@pretalx.com -CF3PMY (Exclusively on Zoom) Virtual Speed Networking en en 20260717T164000 20260717T174500 010500

(Exclusively on Zoom) Virtual Speed Networking

PUBLIC CONFIRMED Social Event https://pretalx.com/scipy-2026/talk/CF3PMY/ Virtual Sessions