Make diffusion model conditioning more flexible

[arrjon]

I introduced a new keyword concatenated_input to the subnet_kwargs in the diffusion model. This keyword controls how inputs—such as parameters, noise, and condition—are fed into the model’s subnet.

Previously, the model assumed all inputs were 1D vectors and concatenated them directly for the default MLP subnet. However, for more flexible architectures—such as subnets designed to preserve or induce spatial structures—this assumption doesn't hold. Now we can also return all inputs separately directly to the subnet.

[codecov]

Codecov Report

Attention: Patch coverage is 84.37500% with 5 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
bayesflow/networks/flow_matching/flow_matching.py	72.72%	3 Missing ⚠️
...ow/experimental/diffusion_model/diffusion_model.py	90.00%	1 Missing ⚠️
...w/networks/consistency_models/consistency_model.py	90.90%	1 Missing ⚠️

Files with missing lines	Coverage Δ
...ow/experimental/diffusion_model/diffusion_model.py	78.83% <90.00%> (-0.31%)	⬇️
...w/networks/consistency_models/consistency_model.py	96.96% <90.90%> (-0.69%)	⬇️
bayesflow/networks/flow_matching/flow_matching.py	90.67% <72.72%> (-2.18%)	⬇️

[vpratz]

Thanks for the PR, I think this is a reasonable idea for advanced use cases. As this is another instance of multi-input networks (even though it's inside the inference network this time, and does not involve the adapter), we might want to include this in the discussion in #517. We might also think about:

• how to pass inputs: named (as a dictionary), or via position (as a tuple like you propose in the PR)
• Consistency in our multi-step models. If we offer this possibility here, we might want to do the same in flow matching and consistency models.

Tagging @LarsKue for comment as well.

[stefanradev93]

One very general approach would be to break free from the fixed names, such as "inference_variables", and actually allow for:

• Marking different simulator outputs as either target variables, summary variables or inference conditions
• Selecting a strategy for how different outputs of the same type are handled (e.g., concatenated, passed as a tuple, or passed as keyword arguments)
  This can be handled with another abstraction, such as SimulatorOutput with a flexible scheme.

[arrjon]

Consistency in our multi-step models. If we offer this possibility here, we might want to do the same in flow matching and consistency models.

I agree @vpratz. I added the same logic to both models. I am open to suggestions how the tensors should be passed to the subnet.

To @stefanradev93 comment: I think, this flexibility is only needed for advanced users. So maybe we should not follow this general approach for now, as the fixed names help users to get started with BayesFlow.

[stefanradev93]

Consistency in our multi-step models. If we offer this possibility here, we might want to do the same in flow matching and consistency models.

I agree @vpratz. I added the same logic to both models. I am open to suggestions how the tensors should be passed to the subnet.

To @stefanradev93 comment: I think, this flexibility is only needed for advanced users. So maybe we should not follow this general approach for now, as the fixed names help users to get started with BayesFlow.

Absolutely, this is definitely a 2.>1.x idea.