GSOC IDEA DISCUSSION 2026 #2570
Closed
SachinDurairaj06
started this conversation in
General
Replies: 1 comment 1 reply
|
Sorry for mentioning again @sethaxen , @OriolAbril and @aloctavodia may i receive your suggestion at the earliest |
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hi everyone,
I’m interested in proposing a GSoC project around improving the Turing.jl → InferenceData export workflow in ArviZ.jl so that datasets produced from Julia sampling are more consistently ready for downstream diagnostics and model-checking workflows.
While working previously on ArviZ.jl documentation (citation fixes) and also contributing to the conda-forge packaging discussion around the modular arviz-base / arviz-stats / arviz-plots structure, I noticed that several ecosystem boundaries depend heavily on how sampler metadata and group structure are exported into InferenceData. In particular, some diagnostic-related metadata from Turing outputs is not always mapped in a way that makes the resulting objects immediately usable in typical ArviZ analysis workflows.
A direction I am considering for GSoC is:
Since this touches both ArviZ.jl export behavior and expectations shared with downstream ArviZ diagnostics workflows, I would really appreciate feedback on whether this fits current priorities and where the biggest gaps currently are.
Tagging @sethaxen , @OriolAbril , and @aloctavodia for suggestions on whether this direction would make sense as a GSoC project and which sampler fields or workflows would be most useful to focus on first.
All reactions