Conference opening Room: Auditorium Cerebrum

Evaluating and guiding research software by intent: from capability to impact readiness

• Mihaela Duta (University of Oxford)

Room: Auditorium Cerebrum Abstract coming soon.

AI Expert Consultation in the LUMI AI Factory and how it links to RSE work

• Marlon Tobaben (CSC / LUMI AI Factory)

Room: Auditorium Cerebrum In LUMI AI Factory, we are consulting industry customers on HPC AI use cases. In this talk we focus on the meta-level and talk about the general process and then illustrate learnings based on anonymized customer case(s). We try to especially highlight how there are different demands with industry customers in comparison to academic customers and how consulting cases lead to improvements in our service offerings.

Three developers, one department: lessons learned from moving from embedded development to a dedicated RSE group

• Knut Nordanger (SINTEF Community)

Room: Auditorium Cerebrum What happens when a three-person development team moves from being embedded in a domain research group to operating more as a dedicated RSE group within the same department? Four months ago, our group at SINTEF Community made exactly that shift while continuing to support the same applied research environment in the built environment sector. The domain, collaborators, and technical challenges remained largely the same, but the organisational relationship changed. That transition became a useful lens for examining questions that RSE discussions often treat at a general level. What do you lose when you step back from full embeddedness, and what do you gain? When we were part of the domain group, proximity shaped everything: we understood research needs quickly, caught problems early, and moved fast. At the same time, we struggled to protect time for reusable infrastructure, longer-term engineering decisions, and work beyond the next urgent prototype. The new structure creates more room for deliberate software engineering, while raising new questions about how to stay close enough to the domain to build the right things. In this lightning talk, I reflect on four tensions that this transition made visible: domain proximity versus engineering discipline; when a prototype has earned real software engineering investment; how a three-person team maintains breadth across ontology engineering, AI pipelines, and live sensor infrastructure; and what research software sustainability means when your users are also your colleagues. The talk is an open reflection for RSEs thinking about where their group sits, or should sit, relative to the researchers they support.

Converting scientific legacy VB6 research code to modern object-oriented Python code: Why we need more research software engineering

• Ingjerd Krogseth (NILU)

Room: Auditorium Cerebrum In environmental chemistry, understanding of how chemicals move in the environment and end up in animals and humans is fundamental. For this purpose, we do field- and laboratory based research to measure chemical concentrations. But we also design, develop, and apply computer software which can simulate the journey a chemical makes on its way through air, water, and food webs. These models use a large amount of input data on properties of the chemicals, the environment, and the animals, to calculate chemical concentrations in fish, seabirds, or polar bears. However, many of these models are based on legacy code developed over decades. This presentation will present a case-study where a large legacy code-base in Visual Basic 6 for a chemical bioaccumulation model was converted to modern object-oriented Python code in close collaboration between environmental chemists and research software engineers. A particular focus will be put upon the process and the collaboration, highlighting the importance and significance of research software engineering.

From Industry to Academia to Somewhere in Between: An Early-Career RSE's Perspective

• Nguyen Luong

Room: Auditorium Cerebrum Research software engineers entering academia from industry bring engineering practices shaped by production environments. How well these practices transfer to academic research — where constraints are not only technical but also regulatory and organizational — remains underexplored. In this lightning talk, I draw on my experience as an early-career RSE who transitioned from software development to academia, and present a case from my first project to illustrate how industry-learned practices translate in research settings. The project involves optimizing a health foundation model developed in a heavily regulated sandbox environment, where gaining access can take months. Rather than waiting, I engaged early with the research team to find a workable path forward: generating synthetic health data, developing and testing on an external HPC cluster, and applying the results back to the sandbox. Because sandbox resources are scarce and shared, this approach kept development moving without competing for limited infrastructure. The strategy was not arrived at on a whim. It was informed by a project I previously led in industry, where a legacy production system was refactored by incrementally replacing its components with modular, testable code, alongside ongoing feature development rather than in place of it. Existing functionality was preserved at each stage, and stakeholders validated changes before the next phase began, maintaining a balance that addressed technical and stakeholder demands at once. In both cases, the challenge was not purely technical. It required negotiating with stakeholders: understanding what is feasible, communicating trade-offs, and finding workable paths under constraint. These experiences suggest that the value industry-turned-RSEs bring to research extends beyond technical proficiency. Stakeholder communication, pragmatic scoping, and working within imperfect conditions are transferable skills that help bridge research work and sustainable software practice.

UniFlow: An AI-Driven Platform for Expertise Discovery and Cross-Disciplinary Collaboration at UiT The Arctic University of Norway

• Keyvan Sartipzadeh (Simplera AS, UiT)
• Kian Sartipzadeh (Simplera AS, UiT)

Room: Auditorium Cerebrum Cross-disciplinary collaboration in academic institutions is frequently constrained by the difficulty of identifying relevant expertise across organizational and disciplinary boundaries. Without effective discovery mechanisms, potential collaborations remain unrealized, limiting the scope and impact of research and innovation. UniFlow is a software platform being developed by Simplera AS in collaboration with UiT The Arctic University of Norway to address this problem. Users describe their project or idea via a guided natural language interface, and the system returns a ranked set of relevant individuals along with their associated fields, publications, and projects, visualized as an interactive network graph depicting the relationships between people, expertise domains, and research outputs. The underlying architecture employs a hybrid retrieval-augmented generation (RAG) approach, combining keyword-based and semantic search over structured research metadata sourced from the Norwegian National Research Archive (NVA). The AI system is built on European large language models and incorporates prompt engineering, output validation, and safeguard mechanisms aligned with GDPR and the EU AI Act. At the time of writing, system design and implementation are actively underway, with structured user testing planned prior to the conference. Although developed in the context of UiT, the platform is designed to be publicly accessible, enabling researchers, students, and external stakeholders to discover and connect with academic expertise.

Yirgacheffe: a declarative, functional approach to geospatial computation

• Michael Dales (University of Cambridge)

Room: Auditorium Cerebrum In building multiple large geospatial pipelines, I got increasingly frustrated with the amount of bookwork that pollutes the scientific intent of the code. This is both due to spatial bookkeeping, aligning pixels, ensuring map projections match, etc., and for managing hardware resources: chunking data for memory puproses, CPU or GPU paths for extracting parallelism, etc. To this end I've spent the last few years building a library to back the pipelines I build that takes care of both of those concerns, and provides a numpy-like, pandas-like interface for working with raster and vector geospatial datasets when doing spactial analysis. Hiding all the bookwork away means the pipeline code intent is more obviously aligned with the method, and robustness is increased by relying on well tested code behind the scenes. This talk will give an overview of Yirgacheffe's declarative nature, where it can help you with your pipelines, and where it still isn't the best choice and needs more work/help.

From "Works on My Machine" to "Clone and run": Orchestrating Research Apps with Aspire

• Bjarte Aarmo Lund (Bouvet AS)

Room: Auditorium Cerebrum While many programming languages have improved their dependency handling to simplify collaboration, real software projects include multiple interacting components: backend, frontend, database, and worker services. Manually managing connection strings and database instances quickly becomes a significant bottleneck. This talk explores how Aspire helps solve this issue. With Aspire, the entire developer environment is configured as code, featuring connectors for databases (relational, document, and vector), polyglot applications (Python, .NET, and TypeScript), and AI providers (OpenAI, Ollama). Each integration comes with default setups for service discovery, observability, health checks, and resiliency. Because the orchestration is defined as code, it is easily version-controlled and shared; onboarding a new collaborator becomes as simple as cloning the repository and running the Aspire project. In my experience, Aspire significantly lowers the barrier for new collaborators. Furthermore, the telemetry provided by its observability extensions makes a tangible difference in project transparency. To demonstrate this, I will showcase a RAG (Retrieval-Augmented Generation) application built with a local LLM, a vector database, and a decoupled frontend/backend. I will highlight how Aspire’s telemetry helped me diagnose and fix hidden issues in the data flow that would otherwise have been difficult to track.

Bridging the Implementation Gap: Bringing Bayesian Marketing Mix Modeling to Non-Programmers

• Stian Berger
• Margrit Kasper-Eulaers (CAPIA AS)

Room: Auditorium Cerebrum Implementation of state-of-the-art Marketing Mix Modeling (MMM) often requires a precarious balance between domain expertise and advanced programming skills. Google’s open-source library, Meridian, provides a robust Bayesian framework for media measurement, yet its reliance on complex Python workflows limits its accessibility to non-programming market analysts. In this talk, we present Citrus Predict, a user interface designed to bridge this technical divide. Meridian involves high-dimensional input parameters and complex Hamiltonian Monte Carlo sampling that can be daunting for the uninitiated. Our tool abstracts these complexities through an intuitive UI, allowing users to upload data, set priors through visual guides, and interpret model outputs without writing a single line of code. We will discuss the architectural challenges of wrapping a heavy-duty TensorFlow-based library for the web and how lowering the barrier to entry fosters better collaboration between data scientists and business stakeholders. By making research-grade software accessible, we empower a broader user base to leverage rigorous statistical methods in their daily decision-making.

Reproducible data science with Nix and DVC

• Jarl Gunnar T. Flaten (SINTEF Nord)

Room: Auditorium Cerebrum Achieving reproducibility in data science can be challenging, as it depends on software reproducibility as well as data reproducibility and ad-hoc parameters/variables. Nevertheless, good tools are being developed that help make it possible. Nix is a package manager that allows users to conveniently define, create, and work with system-level virtual environments within which one can execute data science algorithms such as fitting or training a model. The data versioning tool DVC can be used to keep track of dataset versions and to associate e.g. a training result with the training and validation data used. In this talk, I will describe how we use Nix along with DVC (and git, upon which DVC is built) to achieve pragmatic levels of reproducibility in some of our data science projects, and touch on some of the shortcomings of these tools.

Implementing FAIR data practices for Arctic ecosystem monitoring: Challenges and insights from COAT

• Ingrid Marie Garfelt Paulsen (UiT Arctic University of Norway)

Room: Auditorium Cerebrum The Climate-ecological Observatory for Arctic Tundra (COAT) is an ecosystem-based observation system aiming at real-time detection, documentation and prediction of climate change impacts on Norwegian Arctic ecosystems. To support its mission of sharing research data with the public, facilitating efficient data sharing among COAT researchers, and providing relevant ecological knowledge for local and regional stakeholders, COAT has developed a data portal that hosts ecological and climatic monitoring data from Arctic tundra sites. In this talk, we will share how the COAT data group facilitates the management of ecological and climatic datasets while ensuring they adhere to the FAIR (Findable, Accessible, Interoperable, and Reusable) principles. COAT generates a wide variety of data formats and sizes, including raw sensor data, remote sensing imagery, and derived ecological metrics, spanning diverse Arctic biomes and ecological processes. This presentation will provide insights into the practical challenges and solutions of implementing FAIR data practices in a multidisciplinary research setting.

Portable Research Software for Invasive Marine Species Monitoring with Computer Vision

• Tuomas Rossi (CSC – IT Center for Science)

Room: Auditorium Cerebrum Invasive marine species threaten marine ecosystems and biodiversity across Europe. Preventing their spread requires early detection and rapid response, motivating monitoring using underwater video. However, processing these data at scale becomes computationally demanding. To address this challenge in the EU-funded Horizon Europe [DTO-BioFlow project][1], we are extending the [SUBSIM subsea image analysis platform][2] to support training and inference of computer-vision species detection models across diverse HPC platforms. In this talk, we share our experiences from the research software engineering work behind this effort: refactoring to improve maintainability and stability, and developing CI/CD pipelines to automatically build container images for AMD ROCm, NVIDIA CUDA, and CPU backends. These containers run consistently from laptops through the [EDITO platform][3] (the infrastructure of the [European Digital Twin Ocean][4]) up to [EuroHPC][5] systems such as the [LUMI supercomputer][6]. This approach simplifies user setup and enables reproducible workflows across heterogeneous hardware, while supporting both Jupyter-based interactive use and batch execution on HPC systems. [1]: https://dto-bioflow.eu/ [2]: https://subsim.se/ [3]: https://datalab.dive.edito.eu/ [4]: https://digitaltwinocean.mercator-ocean.eu/ [5]: https://www.eurohpc-ju.europa.eu [6]: https://lumi-supercomputer.eu/

Software engineering with a research mindset - Lessons from both sides of the academy-industry divide

• Radovan Bast (Oceanbox.io)

Room: Auditorium Cerebrum Coming soon.

Packaging and Distributing Scientific Software

• Mridul Seth (European Spallation Source ERIC)

Room: Auditorium Cerebrum Packaging Scientific Software is a broad topic and naturally depends a lot on the languages in use. RSEs work with a wide range from Fortran, Julia, C++ to Python and there wouldn't be "the one" solution that would fix all issues with distributing and consuming these packages. But I would like to use this discussion session to learn and discuss with other RSEs how they manage distribution of their software inside and outside their organisations and the best practices in the context of maintaing reproducible and secure supply chains of our packaged up software. For our work in the Data Management & Scientific Computing centre at European Spallation Source we use Python extensively (or C++ with Python bindings) which naturally leads us to packaging our software as wheels or conda packages, and distributing them via PyPI or conda-forge. We also use pixi to create lock files while managing reproducible environments for our users. We also have had some people working with Julia, which we can package up as a conda package but this shows the problems with building a coherent strategy in a multi language ecosystem. To give some structure to the discussion session we can start with a couple of short lightning talks (~3-5 mins each) which sketches out a rough setup and then we can discuss how to best manage them including topics like: - internal mirrors and hosting to not depend on external infrastructure. - tracking CVEs and third party deps. - Packaging up the whole software setup in a reproducible fashion.

Code, Chaos, and Collaboration: The Quest for Reproducible AI Research

• Elisabeth Wetzer (UiT The Arctic University of Norway)

Room: Auditorium Cerebrum Reproducibility is the cornerstone of scientific progress, yet in machine learning research, it remains an elusive goal. Many senior researchers lack formal training in computational science, leaving the responsibility of code development to junior researchers, often resulting in unstructured, undocumented "code dumps”. In some subfields, the situation is even worse - code is not published at all, and critical implementation details are buried in papers, creating inefficiencies, and barriers to progress. This talk explores the current challenges in reproducible machine learning, from poor code practices to the limitations imposed by conference page limits. I will discuss what makes a "good" research code repository, the role of research software engineers in driving cultural change, and the emerging influence of coding agents in automating code generation. Finally, we’ll ask a provocative question: Should the quality check for a research code repository be whether a coding agent can reproduce the paper? In this talk, I hope to chart a path toward coding practices where reproducibility is the norm, not the exception, and where high-quality research code accelerates innovation across disciplines.

The Importance of Being Reusable

• Johan Mylius-Kroken (UiT - The Arctic University of Norway)

Room: Auditorium Cerebrum Machine learning (ML) has rapidly emerged as one of the most dominant and cross-disciplinary scientific fields of our time. Driven by its immense predictive power, it has achieved widespread public integration. Historically, algorithmic decision-making tools specialized in singular tasks, performing them without significant error and thereby earning societal trust. Today, the public extrapolates this trustworthiness to modern AI and ML. However, unlike traditional algorithms, ML models are largely evaluated on their predictive accuracy on held-out data, frequently failing to report confidence intervals or quantifiable uncertainties. This blind trust masks a profound epistemological shortcoming: current ML practices often fail to adhere to the scientific method. In the chase for high accuracy, the field frequently ignores the underlying causal and latent structures of its models. By largely abandoning hypothesis testing and uncertainty quantification, ML risks leaning toward pseudoscience, generating outputs that are highly correlated but scientifically uninterpretable. Despite these epistemological flaws, machine learning possesses one distinct scientific advantage: high reproducibility. While many traditional sciences are currently hindered by a reproducibility crisis, ML experiments—given the same data and methods—can reliably be recreated by peers. However, simply reproducing an unscientific, black-box result does not magically render it scientific. Furthermore, strict data-sharing is often bottlenecked by privacy concerns, proprietary restrictions, and poor data quality. In the absence of universally accessible data, the rigorous sharing of methodologies becomes paramount. For machine learning to mature from a purely applied predictive tool into a scientifically rigorous discipline, it must fundamentally change its software practices. Replicable science in the AI era demands more than just shared weights; it requires the production and maintenance of reusable, modular, and open-source software. By building transparent codebases, Research Software Engineers empower the scientific community to peer into the black box, rigorously test hypotheses, and ensure that ML's undeniable predictive power is finally matched by genuine scientific trustworthiness.

Extending containers on HPC systems

• Binod Baniya (UiT - The Arctic University of Norway)

Room: Auditorium Cerebrum Containers have become a robust alternative to traditional environment modules for managing AI workloads on High-Performance Computing (HPC) systems. Optimized solutions, such as the NVIDIA vLLM container from the NVIDIA GPU Cloud (NGC) catalog, offer a streamlined approach by providing pre-configured environments including CUDA, PyTorch, and the NVIDIA Collective Communications Library (NCCL) for optimized multi-node communication. While these images often work seamlessly out of the box, researchers frequently encounter scenarios where additional software dependencies must be integrated into a read-only container image. Modifying large base images for minor software additions can be computationally expensive and difficult to manage. This presentation discusses the use of overlays as an efficient solution to this challenge. We will demonstrate how overlays allow users to persist changes and add custom packages to existing containers without the need for full image rebuilds, thereby maintaining environment portability while providing the flexibility required for specialized research workflows.

Solving differential equations with automated unit checking

• Jakob Peder Pettersen (UiT The Artic University of Tromsø)

Room: Auditorium Cerebrum Most quantities in the physical world are associated with a unit of measurement. Thus, keeping track of the units and dimensions of a quantity is an important part of scientific computing. Yet, enforcing type checking in computer code is still not a universal practice. This is partly due to limitations of the programming environments. Often, software packages exist which support basic arithmetic operations with units of measurement, but not more advanced operations like linear algebra and differential equations. We explain how the ecosystem around **DifferentialEquations** in the Julia programming language supports solving ODEs with units of measurements. Addressing the shortcomings of the current options, we introduce a novel array type compatible with the existing ecosystem. Finally, we discuss remaining challenges and possible further directions for unit-checked scientific computing.

Best of Both Worlds: Scientific Computing Across Multiple Languages — A Julia and Python Case Study

• Johan Mylius-Kroken (UiT - The Arctic University of Norway)

Room: Auditorium Cerebrum In scientific computing, researchers routinely face a fundamental tension: computational performance versus ease of implementation. Python has become the dominant language across most scientific disciplines, and for good reason — its readable syntax, flexibility, and vast ecosystem make it an excellent tool for data manipulation, visualisation, and rapid prototyping. Its accessible GPU interfaces have made it especially central to modern machine learning workflows. Yet Python was not designed for every computational task. High-performance simulations, sequential algebraic operations, and large-scale iterative methods can quickly expose its limitations. For these workloads, many researchers turn to lower-level languages such as C, C++, or Fortran. This works, but it creates a fragmented workflow — one that often sacrifices the interpretability, interactivity, and rich tooling that higher-level languages provide. What if we didn't have to choose? Combining programming languages within a single project is standard practice in software engineering, yet remains underutilised in scientific research. Each language can be assigned the tasks it handles best, while sharing data and functionality across the boundary. This talk advocates for a more deliberate adoption of this approach in scientific workflows, and explores both its possibilities and its practical challenges. As a concrete case study, I present a project combining Julia and Python to study the linear regions produced by a specific class of neural networks. Characterising these regions involves non-trivial computational geometry — computing vertices, convex hulls, and minimal active constraint sets. The regions in deeper network layers depend sequentially on those in earlier layers, making the problem both computationally demanding and structurally complex. Python handles the machine learning components naturally, while Julia takes on the geometrically intensive region-finding computations. This talk will walk through the design decisions behind this multilingual architecture, the interoperability tools that make it practical, and the pitfalls encountered along the way — offering a template that other researchers can adapt to their own projects.

From “It works” to verifiable: refactoring OrthoTargetDB

• Ines Moskal (University of Oxford / Centre for Medicines Discovery)

Room: Auditorium Cerebrum OrthoTargetDB helps researchers explore protein homologs across species by aggregating annotations from over a dozen databases and presenting them as filterable data alongside a phylogenetic tree in an interactive web interface. While the tool’s codebase initially ran end-to-end and produced plausible results, its components shared a mutable global state, lacked tests, and pipeline steps could not be run independently. This made the behaviour difficult to inspect and verify. Refactoring the system revealed hidden errors with the potential to bias downstream analyses. This lightning talk presents how the tool was transformed to make processes and outputs more transparent and verifiable. Key changes included isolating pipeline stages, introducing validation, and restructuring data handling. These improvements not only made hidden bugs visible but also enhanced transparency, reproducibility, and setup speed.

NanoShaperWeb: Molecular Surface and Pocket Detection Made Visual

• Carlo Abate (UiT The Arctic University of Norway)

Room: Auditorium Cerebrum Molecular surface and pocket analysis supports key tasks in structural biology and drug discovery, from exploring protein cavities to characterizing potential binding sites. This contribution will present a short live demonstration of NanoShaperWeb, a freely accessible web server for molecular surface generation and pocket detection. Starting from a protein structure, the demo will show how a researcher can launch an analysis in the browser, follow the remote computation, inspect detected pockets and molecular surfaces interactively, and download ready-to-use outputs such as pocket structures, surface meshes, logs, and pocket descriptors. We will highlight design choices that matter for scientific web tools: clear inputs, visible job status, reproducible outputs, and enough control for expert users while keeping the workflow approachable for a broader research community.

Tracking study participants

• Jarno Rantaharju (Aalto University)

Room: Auditorium Cerebrum Keeping track of study participants seems like common problem, one that should have an open source solution by now. I could not find a satisfactory one, and built one in Django instead. It has - data sovereignty built in - support for handling several data sources - separation between researchers and data administrator What do you use to solve this problem?

typst: a better alternative to LaTeX

• helene skovlund holst (university of copenhagen)

Room: Auditorium Cerebrum typst is an alternative to TeX/LaTeX in rse, suitable both for smaller markdown-like notes and for writing papers. in this talk i introduce typst and how to get started using it in an rse role. i argue that it offers valuable new tooling that more than makes up for its smaller community, and that it is ready for a research environment for writing papers, documentation, and notes in the research process itself. typst offers a sensible approach to notation and syntax that speeds up writing, especially for mathematical and equation-heavy documents. compile times are substantially lower than TeX/LaTeX, due to a rust codebase not burdened by the technical debt of projects of TeX/LaTeX's size and age. the main issue is the current lack of adoption among journals and paper templates. i discuss those problems and how the community is working on solving them, along with an analysis of the typst company's strategy to gain marketshare. i conclude that typst is a tool capable of replacing both markdown-like and TeX/LaTeX-like documents in a fast and scalable manner.

A unified framework for response theory using different electronic-structure models

• Bin Gao (Hylleraas Centre for Quantum Molecular Sciences, Department of Chemistry, UiT The Arctic University of Norway)

Room: Auditorium Cerebrum In this talk, I will illustrate our recently developed Rust crates, [Tinned][1] and [SymResponse][2] which can serve as versatile tools to aid the implementation of response theory for different electronic-structure models. Response functions and residues are represented as symbolic expressions using tree-like data structure, which can be serialized into JSON and visualized. The visitor design pattern has been used and enables numerical evaluation of those symbolic expressions by users. Response theory at Hartree-Fock, density functional theory, coupled-cluster theory and multi-configurational self-consistent field approach has been implemented into SymResponse [Bin Gao and Magnus Ringholm, J. Phys. Chem. A 2025, 129, 3709-3721], where elimination rules [Kasper Kristensen et al. J. Chem. Phys. 2008, 129, 214103] can also be applied to reduce the computational effort. Both Tinned and SymResponse also offer C and Python interfaces by using [safer_ffi][3] and [PyO3][4]. [1]: https://github.com/bingao/tinned [2]: https://github.com/bingao/symresponse [3]: https://github.com/getditto/safer_ffi [4]: https://github.com/pyo3/pyo3

Working with data from KTH Data Repository in app on SciLifeLab Serve

• Taha Ahmed (KTH Royal Institute of Technology)

Room: Auditorium Cerebrum Reading public data from an online repository is not a big challenge, although doing so programmatically is perhaps not everyone's cup-of-tea. Likewise, setting up a Shiny app or similar on a hosting platform is simple enough for the digitally well-versed, but an insurmountable obstacle for the digitally inexperienced researcher. In this talk I will therefore present part of the KTH Digital Research Handbook that demonstrates how to setup a Shiny app on the ready-to-use platform SciLifeLab Serve[^1] and one way to configure it to semi-dynamically ingest data from a public dataset previously published on the KTH Data Repository[^2], thus illustrating how sharing data openly makes reuse possible. The talk will briefly discuss the various ways that such an integration can be achieved; demonstrate the Shiny app in action; and expound generously on other freely available open science tools. For the dataset in question we will revisit periodicdata[^3], which regular conference-goers might recognize from one of last year's lightning talks. [^1]: SciLifeLab Serve is a platform for app hosting, web-based IDEs, and other tools developed and operated by SciLifeLab Data Centre. https://serve.scilifelab.se [^2]: The KTH Data Repository is KTH's institutional data management repository, launched last year, and is based on InvenioRDM, just like Zenodo. https://datarepository.kth.se Although for demonstration purposes I will be using the sandbox instance. [^3]: periodicdata, R package dataset with properties of the chemical elements. https://github.com/solarchemist/periodicdata

SciLifeLab’s Order Portals

• Arthur Rosendahl (Uppsala University / SciLifeLab)

Room: Auditorium Cerebrum SciLifeLab is Sweden’s infrastructure for life science research. Many of its _units_ (labs and such) use to manage their orders a Web application built in-house, that has only ever been called the **order portals**. Open source since their inception, the order portals sport a simple and efficient software architecture; an even simpler user interface through which lab workers and researchers can manage orders up to the point where data is delivered; and a few reporting tools. I will discuss the technical architecture, the use cases, and the different challenges associated with this grassroots project.

From For-Loop to Supercomputer: A Hands-On Introduction to Parallel Computing with OpenMP and MPI

• Youssef Wally (The Arctic University of Norway - UiT)

Room: Auditorium Cerebrum Most research code starts the same way: a for-loop over a dataset, processing one item at a time. This tutorial shows how to break that bottleneck; step by step, from a single CPU core all the way to a distributed HPC cluster. Starting from a plain Python loop (SISD — Single Instruction, Single Data), we walk through Flynn's Taxonomy to build intuition about why parallelism works, then implement the same workload four different ways: Python multiprocessing, C++ (sequential), C++ with OpenMP, and C++ with MPI. Each version comes with live benchmarks so attendees can see the speedup for themselves. By the end of the session, attendees will understand: 1) The difference between shared-memory (OpenMP) and distributed-memory (MPI) parallelism 2) When to reach for each tool and when not to 3) The key OpenMP pragma that can parallelise a loop in one line 4) How MPI coordinates work across multiple machines, and why it scales to thousands of nodes All code is provided as ready-to-run scripts. No prior parallel programming experience is required, just basic familiarity with Python and/or C++. This tutorial is particularly relevant to researchers who run computationally expensive pipelines (e.g simulations) and want to make better use of the computing resources available to them, like LUMI.

RSE lessons from Civil Engineers

• Richard Darst (Aalto University)

Room: Auditorium Cerebrum I'm always comparing research engineers to civil engineers - we aren't making this up from scratch, and there are plenty of battle-tested lessons we can take from other fields. I've read the book "Civil engineer’s handbook of professional practice" and have seen so much that is relevant to RSE work, and I will tell you about that. Written outline: https://rkd.zgib.net/blog/rse-lessons-from-civil-engineering/

AI Agents as Research Software Engineers

• Hossein Firooz (Aalto University)

Room: Auditorium Cerebrum Coming soon

Research Software Engineering at UiT - learn from our mistakes

• Gregor Decristoforo (UiT - The Arctic University of Norway)
• Jørn Dietze (UiT - The Arctic University of Norway)

Room: Auditorium Cerebrum Since establishing the Research Software Engineering (RSE) team at UiT, we have tested various strategies to integrate RSE into the university's core infrastructure. While some initiatives have flourished, others have been more challenging. This talk provides an overview of our experiences, intended to help other Nordic institutions navigate similar hurdles. We will focus on how we address the ongoing challenge of funding. Specifically, we will discuss how our current model allows RSEs to move away from daily HPC operations to focus on long-term research collaborations through dedicated service levels and grant applications. We will also look at our efforts to increase campus visibility, such as our weekly help desk at the library run in partnership with the data team, a low-threshold service that has proven very popular. Finally, we will share what hasn't worked for us so far, such as our attempts to engage with startup incubators, and discuss why some successful models from other universities don't always translate to every institution.

Report from Aalto Research Software Engineers

• Richard Darst (Aalto University)

Room: Auditorium Cerebrum I'll give a report of the latest happenings from the Helsinki region.

Nordic-RSE: Quo vadis?

• Luca Ferranti (Aalto University)

Room: Auditorium Cerebrum Nordic-RSE has been up and running for quite some years now, we have had different activities (seminar series, unconference, conferences) and a nice active community. Now the question is: what next? where do we go from here? what do we want to do? How can we better support Research Software Engineers in the nordics? We want YOU to join and help us shape the future of Nordic-RSE! Join this discussion session. People new to Nordic-RSE are particularly welcome, as new faces with fresh ideas are always good for a community growth.

Conference outro Room: Auditorium Cerebrum