GSOC 2026 Project #34 : University of Texas at Austin - Improving Statistical Efficiency, Methodological Coverage, and Contributor Onboarding in NiMARE

Project Summary: NiMARE is a Python library for coordinate- and image-based neuroimaging meta-analysis. It provides rigorously tested implementations of widely used methods such as ALE and MKDA, enabling reproducible synthesis of large neuroimaging literatures. NiMARE also serves as a long-term maintenance layer for research methods that are often released as one-off academic code, ensuring sustainability, documentation, and integration into a unified statistical framework.

This project has two complementary objectives:

  1. Improve contributor onboarding and development documentation, reducing friction for new developers.
  2. Enhance NiMARE’s statistical capabilities by implementing adaptive early stopping for permutation-based inference (mandatory), and, time permitting, adding Signed Difference Mapping (SDM) and publication bias diagnostics as stretch goals.
  3. These improvements will directly benefit both NiMARE users and downstream platforms such as Neurosynth Compose (2,700+ registered users), which relies on NiMARE for backend statistical computation.

Project Scope (175 Hours)

Weeks 1–2: Contributor onboarding improvements

Weeks 3–8: Algorithm development

Mandatory: Adaptive early stopping for permutation-based inference

Stretch goals: SDM implementation and publication bias diagnostics

Phase 1: Contributor Onboarding Improvements (Weeks 1–2)

Motivation

While NiMARE has an existing contributor guide, elements of the development environment setup and git workflow documentation are outdated. Although there are no known critical bottlenecks, ensuring that documentation reflects current practices reduces barriers for new contributors and minimizes avoidable friction.

Deliverables

Updated contributor guide covering:

Environment setup (Python versioning, dependency management, testing)

CI expectations

Code style and linting requirements

Clear documentation of recommended git workflow for PR submission.

Review and cleanup of outdated sections.

Verification that documentation reflects current repository structure and tooling.

Success Criteria

Documentation validated through a clean setup from scratch.

Clear, reproducible development environment instructions.

No outdated workflow steps.

All changes merged and published in documentation site.

Phase 2: Algorithm Development (Weeks 3–8)

  1. Adaptive Early Stopping for Permutation-Based Inference (Mandatory)

Motivation

Permutation-based Monte Carlo inference is central to ALE and MKDA workflows but can be computationally expensive. Currently, users often rely on fixed iteration counts (e.g., 10,000 permutations), which may be either insufficient or excessive.

This project will implement a fixed-width confidence interval stopping rule for permutation testing in both ALE and MKDA workflows. The objective is to:

Maintain strict type I error control.

Reduce unnecessary computational cost.

Dynamically determine when sufficient precision has been achieved.

Technical Plan

Implement fixed-width confidence interval stopping based on variance stabilization of p-value estimates.

Evaluate whether 10,000 iterations are sufficient or unnecessarily conservative.

Integrate stopping logic into permutation pipelines for ALE and MKDA.

Preserve statistical validity and type I error guarantees.

Validation

Benchmark against fixed 10,000-permutation runs.

Compare convergence behavior.

Confirm preservation of nominal type I error bounds using simulation.

Deliverables

Integrated early stopping implementation for ALE and MKDA.

Unit tests covering convergence logic.

≥85% test coverage maintained.

Benchmarking results documented.

  1. Signed Difference Mapping (SDM) (Stretch Goal)

Motivation

Signed Difference Mapping allows integration of coordinate- and image-based meta-analytic data within a unified framework. Implementing one SDM algorithm would broaden NiMARE’s methodological coverage and support mixed-modality analyses.

Technical Considerations

Requires extension of NiMARE’s Estimator base class.

API changes may be necessary to support SDM-specific data structures.

Must preserve backward compatibility where possible.

Validation

Compare output against existing SDM implementations using available validation datasets.

Confirm statistical consistency with reference results.

Deliverables

One SDM estimator implemented.

Necessary base class modifications.

Comprehensive unit tests.

Documentation describing usage and assumptions.

Risk Mitigation

Any API changes will be versioned carefully.

Backward compatibility impacts will be explicitly documented.

Core NiMARE workflows will be regression tested.

  1. Publication Bias Diagnostic (Stretch Goal)
  • Motivation- Neuroimaging meta-analyses may be susceptible to publication bias. A common diagnostic approach is estimating how many null studies would need to be added to render results non-significant (fail-safe N–style methods).

  • This project will implement a standalone diagnostic module to estimate how many null studies would be required to overturn significance.

  • Technical Challenges

Computational scaling if large numbers of simulated null studies are required.

Efficient simulation strategies may be necessary.

Deliverables

Standalone diagnostic module.

Simulation-based validation.

Unit tests with ≥85% coverage.

Documentation describing assumptions and limitations.

Validation & Testing Standards

  • All new code must meet NiMARE’s testing standards (≥85% coverage).

  • Existing workflows must pass regression tests.

  • Simulation-based validation datasets are available.

  • Continuous integration checks must pass for all PRs.

Risks and Mitigation

Risk

Mitigation Strategy

API instability due to SDM integration

Careful extension of Estimator base class; preserve backward compatibility where possible

Computational scaling for fail-safe diagnostic

Implement optimized simulation strategies; cap simulation growth

Statistical correctness of early stopping

Simulation studies to verify type I error control

The mandatory early stopping implementation is feasible within the timeline. Stretch goals will be pursued sequentially based on progress.

Impact: This project will:

  • Improve computational efficiency in permutation-based inference.

  • Expand NiMARE’s methodological coverage.

  • Strengthen reproducibility and sustainability of neuroimaging meta-analysis.

  • Improve developer onboarding, lowering contribution barriers.

  • Because NiMARE serves as the statistical backend for Neurosynth Compose (2,700+ registered users), improvements will directly affect real-world meta-analytic workflows.

1 Like

Hi,

I am LUO Yu, a junior at Shanghai Jiao Tong University studying Information Engineering. I am writing to express my strong interest in NiMARE Project #34.

My background aligns closely with the technical demands of this project: I work on LLM-driven Agents for science, awarded as Meritorious Winner in the Interdisciplinary Contest in Mathematical Modeling, and built a matrix-computing library. As I have experienced rigorous training in mathematics under the French ‘Classes Préparatoires’, I am comfortable with the statistical validation required for permutation-based inference.

I am currently diving into the ALE/MKDA implementations in NiMARE. I have a strong interest in mathematical statistics, so I am particularly fascinated by the challenge of applying confidence interval-based stopping rules to prune non-significant voxels early. Balancing computational efficiency with rigorous statistical validity is exactly the kind of problem I enjoy solving. To ensure my upcoming proposal aligns perfectly with the project’s goals, are there any specific technical nuances or potential edge cases you would recommend I focus on at this stage?

Best regards,

LUO Yu

Quick update: I’ve just submitted a PR (#984) in GitHub - neurostuff/NiMARE: Coordinate- and image-based meta-analysis in Python · GitHub to address the development installation instructions in issue #718. It’s now passing all CI checks.

Hi,

Quick question — for permutation-based inference, how is stability typically handled when p-values are close to the significance threshold (p ≈ α)?

It seems like stopping criteria might fluctuate a bit in that region.

Thanks!

1 Like

Heyy, I’m Aishwarya J A and I’ve started exploring Project #34.

My background is primarily in building ML systems for healthcare and time-series data (including ECG modeling, federated learning pipelines, and neuromorphic systems), so I’m particularly interested in how NiMARE balances statistical rigor with practical usability and scalability.

After setting up the codebase locally, I’ve been going through the test suite and workflows to understand how datasets, meta-analysis models (like ALE/MKDA), and inference procedures are structured.

From the project description, I noticed that contributor onboarding and methodological coverage are also key goals. I’m especially interested in contributing toward:

  • improving robustness and test coverage (e.g., edge cases in dataset handling and statistical inputs),
  • making workflows easier to extend for new models or datasets,
  • and ensuring reproducibility in practical use cases.

In parallel, I’m also exploring the statistical modules to better understand where efficiency improvements (like permutation handling) can be integrated without affecting correctness.

Does focusing on onboarding + robustness + practical workflow improvements, alongside statistical exploration, align well with the project goals?

1 Like

Hi @luo_yu ,

Apologies I was not being notified on this post. Thank you for your expressed interest. Nimare has a publication you can at least get acquanted with the overview at the beginning and summary at the end: NiMARE: Neuroimaging Meta-Analysis Research Environment | Published in Aperture Neuro

Technical nuances:

  • until recently, I wasn’t testing window’s based distributions.
  • the repository is still below a 1.0.0 release, meaning significant changes to the public facing API can happen
  • ALE is a guassian kernel whereas (M)KDA is binary kernel
  • As a field, we do not use KDA anymore

Something to be aware of: in neuroimaging, while many of our statistics are univariate (treat each individual voxel independently), we care about the spatial distribution of results, and we do run clustering to aggregate individual voxels that are significant. Additionally, the kernel choice here is a sphere, but it could be more biologically constrained to gray matter/follow particular biological constraints more complex than a sphere. See here: Implement hybrid SDM and SDM-PSI meta-analysis estimators with coordinate and image support by Copilot · Pull Request #958 · neurostuff/NiMARE · GitHub (SDM uses a more biologically constrained kernel as the expense of efficiency).

Best,

James

Currently we do not handle it, we do not calculate any uncertainty of the estimate, so any instability is not handled, this is something we could improve upon.

Thanks a lot for your feedback!

I now realize that my validation benchmark focuses too much on voxel-level precision in my submitted proposal, while cluster-level consistency is more critical for neuroimaging inference. I’ve been exploring alternative evaluation strategies, and cluster-level metrics such as the Dice coefficient seem more appropriate.

I’ll go through the materials and issues you mentioned to better understand NiMARE and further refine my approach. I also noted your comment regarding limited testing on Windows, and I will make sure to align my development environment accordingly to ensure better compatibility, for example by implementing a virtual Linux environment, and there’s chance that I’ll change to Mac before May.

Best,
Yu

No need to stop using windows, working with a developer on windows helps point out compatibility issues, I am happy to support a windows development environment.

yes, we do have an emphasis of clusters over individual voxels, we can talk more about that later.

I opened up a couple more issues on NiMARE if you want to check them out: Issues · neurostuff/NiMARE · GitHub

Some are rather short term projects, but the scikit-learn one would likely take a while to implement. I’ll circle back next week to see the proper way to set up a meeting.

I’ve been exploring the NiMARE codebase in detail while working through Studyset and related APIs, and I came across a small design inconsistency that I wanted to get feedback on.

In the Studyset class, there appear to be two implementations of get_analyses_by_coordinate with different signatures and behaviors. The later definition overrides the earlier one, which effectively leaves the first implementation unused. This also results in some inconsistency in how radius-based vs nearest-neighbor queries are handled.

I’ve opened an issue on GitHub to discuss this and propose unifying the API into a single method that supports both use cases in a consistent way.

Happy to contribute a PR once there’s agreement on the direction.

Thanks,

Abiraj Kangotra

1 Like

Thank you for the clarification and for your support on the Windows environment! I’ll make sure to report any compatibility issues I encounter.

I’ll take a closer look at the short-term issues first and try to get more familiar with the workflow. I may study the scikit-learn-related one further as I get more comfortable with the project.

Looking forward to the meeting next week — please let me know when would be a good time to connect.