DEV Community: Satwik Sai Prakash Sahoo

Halfway Through GSoC

Satwik Sai Prakash Sahoo — Mon, 20 Jul 2026 05:33:56 +0000

Hey everyone! We have officially hit the halfway mark of the Google Summer of Code (GSoC) 2026 coding period.

These past two weeks have been heavily focused on expanding the Neural Network Builder API beyond just standard NPE (Neural Posterior Estimation) models. I have successfully merged PRs #1904 and #1912 into the gsoc-2026 branch for sbi.

Here is a breakdown of what I worked on, the architectural challenges we solved, and some vital lessons learned about failing fast and role-neutral design.

PR #1904: Integrating the Builder into NLE

In my previous PR, we successfully wired the DensityEstimatorBuilder into NPE trainers. The next logical step was to do the same for Neural Likelihood Estimation (NLE) trainers. However, this brought up an immediate architectural challenge regarding how the builder signs its inputs.

The Role-Neutral `build()` Signature

Previously, the build() method took (batch_theta, batch_x). This made sense for NPE, which estimates the posterior distribution $p (θ ∣ x)$ , meaning $θ$ is the input and $x$ is the condition.

However, NLE estimates the likelihood $p (x ∣ θ)$ . In this case, $x$ is the input and $θ$ is the condition.

If we kept the (batch_theta, batch_x) signature on the base builder, it would be extremely confusing and semantically incorrect for NLE.

The fix? Role-Neutral Signatures.
My mentor Jan Teusen suggested that I should refactor the base builder and DensityEstimatorBuilder methods to accept (batch_input, batch_condition).

Now, the trainers handle the role assignment via the _wrap_builder() closure:

For NPE: build(batch_input=batch_theta, batch_condition=batch_x)
For NLE: build(batch_input=batch_x, batch_condition=batch_theta)

This change cleanly decouples the mathematical model the network represents from the data types the network consumes.

Parameterizing Tests

During review, my mentor also suggested that the NPE and NLE integration tests were essentially "twin" tests doing the exact same thing with different objects, we parameterized them!

TRAINERS = [(NPE_C, posterior_nn, "theta"), (NLE_A, likelihood_nn, "x")]

@pytest.mark.parametrize("trainer,factory", [(t, f) for t, f, _ in TRAINERS], ids=["npe", "nle"])
def test_string_emits_deprecation_warning(trainer, factory):
    prior = MultivariateNormal(zeros(2), eye(2))
    with pytest.warns(FutureWarning, match="deprecated"):
        trainer(prior, density_estimator="maf", show_progress_bars=False)

This saved a ton of code duplication while keeping the coverage identical.

PR #1912: Mixed Density Estimators (MNLE & MNPE)

For datasets containing mixed data types (both continuous and discrete variables), sbi uses Mixed Neural Posterior/Likelihood Estimators (MNPE/MNLE).

To support these, I created a sibling class to our main builder: the MixedDensityEstimatorBuilder.

"continuous_model" over "model"

Our main design choice here was using the field continuous_model instead of just model. This is because the supported mixed architectures include non-flow models like MDN and MADE. Now, a user can explicitly configure the continuous sub-network: MixedDensityEstimatorBuilder(continuous_model="nsf").

Failing Fast is Better Than Failing Late

MNPE requires a MixedDensityEstimator. If a user accidentally passed a standard DensityEstimatorBuilder (e.g., MNPE(density_estimator=DensityEstimatorBuilder())), the code would gladly accept it, train an entire continuous normal flow for hundreds of epochs, and then crash at the very end when it finally checked the returned class type.

Failing at the end of a long training run with a cryptic error is terrible UX.

We added a strict type-check inside the trainer initialization to fail fast:

elif isinstance(density_estimator, _EstimatorBuilderBase) and not isinstance(
    density_estimator, MixedDensityEstimatorBuilder
):
    raise TypeError(
        "MNPE requires a MixedDensityEstimatorBuilder; got "
        f"{type(density_estimator).__name__}. Use "
        "MixedDensityEstimatorBuilder(continuous_model=...)."
    )

Now, if a user makes this mistake, the code crashes instantly with clear instructions on how to fix it, saving hours of compute time.

Catching Configuration Drift

We defined _VALID_MIXED_CONTINUOUS_MODELS to validate inputs. However, hardcoding this set means it could drift away from the actual supported models in the factory if another developer adds a model later. To prevent this, I added a test specifically designed to catch configuration drift:

def test_valid_continuous_models_match_builders():
    from sbi.neural_nets.net_builders.mixed_nets import model_builders
    assert _VALID_MIXED_CONTINUOUS_MODELS == frozenset(model_builders)

What's Next?

We are halfway there! The continuous and mixed density estimators are successfully wired into the system. Next up, we will be tackling the remaining likelihood and classifier builders to complete the NN Builder ecosystem.

Thanks for reading, and stay tuned for the next update!

First internal integration of the new API

Satwik Sai Prakash Sahoo — Mon, 29 Jun 2026 17:47:42 +0000

Hello again! The GSoC coding period is in full swing, and weeks 3 and 4 have been absolutely packed with progress.

Following up on the foundational work from my first PR, I have just successfully merged two major PRs (#1877 and #1882) into the gsoc-2026 branch for sbi. These PRs introduce the first concrete builder class and wire it directly into the core Neural Posterior Estimation (NPE) trainers.

Here is a dive into what I built, the technical hurdles, and a very valuable lesson I learned about software architecture along the way.

PR #1877: The `DensityEstimatorBuilder`

The primary goal of this phase was to replace the old, opaque posterior_nn() and likelihood_nn() factory closures with something typed, inspectable, and much more robust.

To solve this, I introduced the DensityEstimatorBuilder. It inherits from the base contract we established in Week 1 and serves as the unified entry point for creating neural networks in sbi. Using the __post_init__ method in Python dataclasses, it immediately validates the model name against a _VALID_DENSITY_MODELS set, failing early if the user provides an unknown architecture.

Major architectural shift

Initially, our plan dictated that the build() method should take a BuildContext object. The idea was that this context would hold all necessary information, including pre-computed z-scoring stats, and pass it neatly down the chain.

However, as I implemented the body of the build() method, my mentor Jan Teusen noticed that the context parameter wasn't actually being used. Every piece of information the builder needed could be derived directly from the raw batch_theta and batch_x tensors.

We realized that forcing the BuildContext into this signature was a premature abstraction.

Instead of holding onto a design just because it was the original plan, we decided to defer the context object entirely until the z-scoring stats are actually pre-computed in a later phase. We updated our roadmap and simplified the build signature.

def build(self, batch_theta: Tensor, batch_x: Tensor):
    pass

It was a great decision to defer the context implementation to work on the breadth first and then move towards depth.

PR #1882: Integrating the Builder into NPE Trainers

With the builder merged, the next step was integration. I updated PosteriorEstimatorTrainer, NPE_B, NPE_C, and MNPE to accept the new DensityEstimatorBuilder instead of relying solely on strings or callables.

To maintain backward compatibility while moving the API forward, a graceful deprecation path was implemented. If a user passes a string (e.g., "maf"), the code still works perfectly, but it now emits a FutureWarning.

if density_estimator is None:
    self._build_neural_net = self._wrap_builder(DensityEstimatorBuilder(model="maf"))
elif isinstance(density_estimator, str):
    warnings.warn(
        "Passing a string for `density_estimator` is deprecated. "
        "Use DensityEstimatorBuilder(model=...) instead.",
        FutureWarning,
        stacklevel=3,
    )
    self._build_neural_net = posterior_nn(model=density_estimator)
elif isinstance(density_estimator, _EstimatorBuilderBase):
    self._build_neural_net = self._wrap_builder(density_estimator)
else:
    self._build_neural_net = density_estimator

Overal feedback on my work

The code review for PR #1882 was intense but incredibly rewarding. My mentor provided feedback on how to write tests that are not just concise, but strong and explicit in their intent.

For example, I originally wrote a test that checked if passing a callable avoided triggering the deprecation warning. But I wasn't actually asserting that no warning was thrown, I was just running the code and assuming silence meant success.

My mentor showed me how to use warnings.catch_warnings() with a strict filter to instantly fail the test if a FutureWarning leaked through:

import warnings

with warnings.catch_warnings():
    warnings.simplefilter("error", FutureWarning)
    inference = NPE_C(prior, density_estimator=builder, show_progress_bars=False)

We also did a deep dive into correct type hinting and managing default arguments. I initially left density_estimator="maf" as the default argument in the NPE_C initialization. My mentor pointed out that this would cause the deprecation warning to fire every single time a user initialized the class without arguments! The fix was to change the type hint default to None and handle the "maf" fallback inside the logic block.

What's Next?

Weeks 3 and 4 were a massive leap forward for the API refactor. We now have a working, integrated builder that correctly handles all continuous density estimators.

Next up, I will be tackling the remaining likelihood and classifier builders. Thanks for following along on this journey, and see you in the next update!

Merging My First PR for GSoC!

Satwik Sai Prakash Sahoo — Mon, 15 Jun 2026 13:12:48 +0000

Hey everyone! The official coding period for Google Summer of Code (GSoC) has begun, and I am thrilled to share that my very first Pull Request (PR) for the sbi (Simulation-Based Inference) repository has been officially merged!

These first two weeks have been packed with writing code, writing tests, and most importantly, going through an incredibly insightful code review process with my mentors.

Here is a breakdown of what I worked on, the technical challenges I faced, and the best practices I learned along the way.

Laying the Foundation (PR #1872)

My GSoC project is focused on refactoring the Neural Network (NN) Builder API. Before we can build the new, shiny network builders, we need a solid foundation. This first PR was all about setting up the necessary data structures and renaming existing protocols to make room for the new architecture.

1. The New `build_context.py`

I created a new file to house the core pieces needed to set up a neural network. This centralizes how the data is prepared before it hits the network:

ZScoreConfig: Tracks how the user wants to preprocess data.
ZScoreStats: Holds the calculated mean and standard deviation for the data.
BuildContext: Bundles everything required to build a network (shapes, device, dtype, and z-score stats) into a single, clean dataclass.
compute_z_score_stats(): A helper function to calculate these statistics directly from the training tensors.

2. Clearing the Naming Space

To make the codebase more intuitive, I had to rename a few core components across 16 different trainer files:

Changed ConditionalEstimatorBuilder to ConditionalEstimatorBuildFn. This clarifies that the protocol is actually a function, not an object, and frees up the "Builder" name for upcoming classes.
Changed _EstimatorConfigBase to _EstimatorBuilderBase, giving it an empty build() method to prepare for the next phase.

Big Takeaways from Code Review

Getting the code working was only half the battle. The review process with my mentor, taught me several advanced Python and PyTorch practices.

Managing Tensor Devices

When creating the BuildContext, the data (x and theta) are passed in as PyTorch tensors. My mentor pointed out that if x and theta accidentally end up on different devices (e.g., one on CPU, one on GPU), it will cause runtime failures. I updated the code to explicitly check that both tensors share the same device and added GPU-specific pytest runs to ensure everything handles device placement gracefully.

Dataclasses and Tensor Equality

I originally set up my statistics classes as @dataclass(frozen=True). However, because they hold PyTorch tensors, this creates a subtle bug. PyTorch's implementation of equality (==) for tensors returns a boolean tensor, not a single boolean value, which breaks the dataclass equality checks.

The fix was simple but crucial:

@dataclass(frozen=True, eq=False)
class ZScoreStats:
    theta_mean: Optional[Tensor] = None
    theta_std: Optional[Tensor] = None
    x_mean: Optional[Tensor] = None
    x_std: Optional[Tensor] = None

By adding eq=False, equality becomes identity-based, completely bypassing the PyTorch tensor comparison crash.

Graceful Deprecation with PEP 562

Since ConditionalEstimatorBuilder was used by the community, we couldn't just delete the name and break everyone's code. Instead of leaving a dummy class, I learned how to use module-level __getattr__ to intercept the import and throw a FutureWarning.

def __getattr__(name: str):
    if name == "ConditionalEstimatorBuilder":
        import warnings
        warnings.warn(
            "`ConditionalEstimatorBuilder` has been renamed to "
            "`ConditionalEstimatorBuildFn`. The old name still works but will be "
            "removed in a future release. Update your import to: "
            "`from sbi.neural_nets.estimators.base import ConditionalEstimatorBuildFn`.",
            FutureWarning,
            stacklevel=2,
        )
        return ConditionalEstimatorBuildFn
    raise AttributeError(f"module {__name__!r} has no attribute {name!r}")

Refactoring Tests

I used Claude Opus to help generate initial test coverage for the new context types. It gave me class-based tests. However, the sbi standard relies heavily on function-based tests and pytest fixtures. I completely refactored the test suite to use @pytest.mark.parametrize to test valid combinations of inputs, ensuring maximum coverage with minimal, highly readable code.

What's Next?

With the foundation types successfully merged into the gsoc-2026 branch, the groundwork is officially laid out! Up next is PR #1877, where I will be adding the actual DensityEstimatorBuilder with dynamic build() dispatching.

Stay tuned for week 3 and 4 updates!

GSoC Community Bonding Period: Getting Ready to Code

Satwik Sai Prakash Sahoo — Thu, 04 Jun 2026 06:51:17 +0000

Hey everyone! Welcome back to my Google Summer of Code (GSoC) journey.

In my last post, I shared the story of how I got into open source and was selected for GSoC with NumFOCUS to work on the Neural Network Builder API Refactor project for sbi (Simulation-Based Inference).

Since the official announcement, the past three weeks have been dedicated to the Community Bonding Period. It is designed to help contributors get to know their mentors, understand the community culture, and familiarize themselves with the codebase and tools.

Here is exactly what I did during these past three weeks to get ready for the main coding phase!

The Kickoff Meeting

We started the bonding period with a great kickoff call on Google Meet. It was a joint meeting that included the mentors for both of the selected sbi projects, the selected GSoC candidates. We were also joined by the mentee who successfully completed the GSoC project for sbi last year!

Everyone introduced themselves, and it was incredibly inspiring to meet the team face-to-face (virtually!) and hear about everyone's backgrounds. Having a former GSoC student there was a huge bonus, as they shared some great insights into what to expect in the coming months.

Setting Up the Machine

A big part of getting started is making sure the development environment is properly configured. During our meetings, we discussed the machine setup in detail to ensure both candidates had everything required to run and test the sbi codebase locally without any hiccups.

Embracing AI Coding Assistants

One of the most interesting discussions we had was about using AI coding assistants. In the modern development world, tools like these are becoming standard, and our mentors actually encouraged us to use them!

However, they emphasized using them carefully and strictly following project guidelines. To help us get the most out of these tools without compromising code quality, the mentors shared some excellent Claude code tutorials and provided us with resources to level up our AI coding skills. It is all about using AI to augment our capabilities, not to blindly write code for us.

Diving into the Codebase and Planning

With the setup out of the way, the rest of the three weeks was all about reading. I spent a lot of time diving deep into the sbi codebase and reading through the documentation properly.

Understanding the architecture is critical for my API refactor project. To keep everything organized and on track, we were provided with a plan.md file. This document serves as our roadmap, outlining exactly what needs to be tackled, the skills required, and the milestones we need to hit.

What's Next?

The community bonding period was incredibly helpful. It gave me the time to get comfortable with the team, set up my workflow, and build a solid foundation before the heavy lifting begins.

Now, the official coding phase is here! I am beyond excited to start pushing commits and working on the Neural Network Builder API Refactor.

Thanks for reading, and stay tuned. I will be sharing more technical updates and lessons learned as I start writing code for GSoC!

How I Got Selected for GSoC: My Journey with sbi

Satwik Sai Prakash Sahoo — Sun, 31 May 2026 19:55:27 +0000

Hey everyone! I am super excited to share that I have been selected for Google Summer of Code (GSoC) with NumFOCUS. I will be working on the Neural Network Builder API Refactor project for the organization sbi (Simulation-Based Inference).

If you are wondering how to get started with open source or what the GSoC process is really like, here is the story of how I got here. Stay tuned, because I will keep updating you on my GSoC journey and sharing my experiences as I get deeper into the project!

Why I Started Open Source

Being a fan of Linus Torvalds, I was always fascinated by open source. Also, I wanted to test my coding skills. I wanted to know: Is my code actually good enough for the real world? In my first year of college, I spent a lot of time doing competitive programming. At the same time, I was teaching myself machine learning and mathematics, working mostly with Python and PyTorch.

Finding the Right Project

When I decided to try open source, I wanted to find an organization that actually matched what I was learning. Because I was already into machine learning and PyTorch, I went looking for something in that space.

That is how I found sbi.

Making my first Pull Request (PR) was a little scary, but the maintainers at sbi were incredibly welcoming. They patiently guided me through my early, beginner-level PRs. Thanks to their feedback, I learned so much about how to write clean, high-quality code.

The GSoC Surprise

After a few months of fixing bugs and contributing, I found out from the maintainers that sbi would be participating in GSoC this year. They encouraged me and appreciated the work I had done over the past few months, for which I will be forever grateful.

But there was one problem: I hadn't researched GSoC at all. I had no idea what the requirements were or how to write a project proposal.

Getting Help with the Proposal

Writing the proposal was tough since it was my first time. Luckily, I didn't have to do it alone.

The maintainers also stepped up to mentor me. They reviewed my proposal drafts, gave me detailed feedback, and helped me improve it step by step until it was ready.

What's Next?

All that hard work and community support paid off, and I got accepted!

The GSoC community bonding period just finished up. In my next blog post, I will share exactly what I did during this bonding period to get ready for the main coding phase.

Thanks for reading, and stay tuned!

DEV Community: Satwik Sai Prakash Sahoo

Halfway Through GSoC

PR #1904: Integrating the Builder into NLE

The Role-Neutral build() Signature

Parameterizing Tests

PR #1912: Mixed Density Estimators (MNLE & MNPE)

"continuous_model" over "model"

Failing Fast is Better Than Failing Late

Catching Configuration Drift

What's Next?

First internal integration of the new API

PR #1877: The DensityEstimatorBuilder

Major architectural shift

PR #1882: Integrating the Builder into NPE Trainers

Overal feedback on my work

What's Next?

Merging My First PR for GSoC!

Laying the Foundation (PR #1872)

1. The New build_context.py

2. Clearing the Naming Space

Big Takeaways from Code Review

Managing Tensor Devices

Dataclasses and Tensor Equality

Graceful Deprecation with PEP 562

Refactoring Tests

What's Next?

GSoC Community Bonding Period: Getting Ready to Code

The Kickoff Meeting

Setting Up the Machine

Embracing AI Coding Assistants

Diving into the Codebase and Planning

What's Next?

How I Got Selected for GSoC: My Journey with sbi

Why I Started Open Source

Finding the Right Project

The GSoC Surprise

Getting Help with the Proposal

What's Next?

The Role-Neutral `build()` Signature

PR #1877: The `DensityEstimatorBuilder`

1. The New `build_context.py`