Developed by Kristina Yurlova, Marek Ružička, and Juraj Gazda, WaveLab Studio occupies a deliberately modest but strategically important niche in the simulation software ecosystem. The team is careful to position the tool below production-grade electromagnetic solvers in terms of physical fidelity. Established frameworks such as Meep, gprMax, and openEMS provide high-fidelity finite-difference time-domain modeling of electromagnetic phenomena, while general numerical and scientific machine-learning platforms like FEniCS, DeepXDE, and NVIDIA’s Modulus/PhysicsNeMo support broader partial differential equation and physics-informed neural network workflows. What these systems do not offer, the authors argue, is a compact, low-friction environment in which a user can sketch a heterogeneous scene, inspect it visually, execute it from the command line or a cloud capsule, and receive a standardized package of plots, arrays, and metrics without stitching together several separate scripts.

The technical core of WaveLab Studio is a Python research-software package with three coordinated components: a graphical user interface, a command-line solver, and a set of visualization utilities. The desktop scene builder is implemented with Tkinter, allowing users to set source coordinates and frequency parameters, define material objects, edit geometry, and preview scenes interactively. The solver component, solver_simple_torch.py, runs headless and is built on NumPy and PyTorch, with Matplotlib handling visualization and PyYAML managing configuration. The entire package is distributed under the MIT License, with the current version numbered v0.1.1 and hosted on GitHub.

At the heart of the workflow is a deliberate architectural decision: the YAML file serves as the serialization contract between every interface. A scene file contains a source block storing coordinates, frequency, and amplitude, along with an objects list where each entry specifies a material label, geometric shape, position, size parameters, and optional rotation. A top-level materials mapping can override default parameters such as wave speed, absorption, and transmission. Because the same YAML file can be opened in the graphical interface, inspected with the scene_cli.py tool, executed with the headless solver, and used in a Code Ocean capsule, the tool guarantees that a scenario designed on a desktop produces identical results when run automatically. This cross-interface consistency is the property the authors identify as the tool’s principal contribution.

The default solver operates on a rectangular two-dimensional domain, discretized into a grid whose resolution the user controls through command-line arguments. For each grid point, the algorithm samples the line segment connecting the source to that point and blends material parameters along the segment using soft object-membership masks. The ray-marched field component accumulates a phase term proportional to frequency divided by local wave speed and an exponential attenuation term governed by local absorption, multiplied by a transmission factor. The model then applies a geometric occlusion and shadow map for barrier-like objects, adds a local edge-wave term around obstacle boundaries, and performs an FFT-based smoothing step. An internal quality parameter controls ray sampling density, shadow sampling, smoothing, and edge-effect strength, giving users a continuous dial between speed and visual refinement.

One of the more technically honest aspects of the paper is its treatment of the reference and error metrics. The reference field displayed in figures is not an external physical ground truth but rather the highest-quality internal field produced by the pipeline at its maximum quality setting. The approximated field is computed by the same deterministic pipeline at a lower quality factor, derived from the requested epoch count. The error map, mean absolute error, and maximum absolute error reported by the software are therefore internal consistency measures that indicate how the workflow behaves under different scenes and settings. The authors explicitly state that these metrics are not validation errors against Maxwell-equation solutions, measured data, or independent finite-difference or finite-element solvers. Material names such as concrete, water, and plastic are user-facing labels mapped to scalar parameters and display overlays, and they should be interpreted as graphical and algorithmic scene effects rather than calibrated constitutive electromagnetic constants.

This framing shapes the validity domain of the tool. The solver is a scalar visual propagation model intended for two-dimensional demonstrations. It does not model vector electromagnetic polarization, impedance-matched interface conditions, full material constitutive laws, or perfectly matched absorbing boundaries. The authors argue that this limitation is precisely what makes the software valuable: by keeping the physical model simple, the entire workflow remains fast, transparent, and reproducible, running each illustrative scenario in under three seconds on a CPU-only setup.

To demonstrate the workflow, the repository ships with four YAML scenarios. The first is a free-space baseline with no objects, completing in 2.49 seconds. The second introduces a single concrete obstacle to illustrate shadowing and error-map generation, taking 2.64 seconds. The third presents a heterogeneous multi-material scene with four objects, exercising multi-object interaction in 2.74 seconds, and the fourth compares water and plastic materials to show material-dependent field changes in 2.59 seconds. Each scenario follows the same execution chain: parse the YAML file, build the grid and object masks, run the scalar solver, write a result directory, export field plots, save arrays, and store metrics. Every output set contains the internal reference field, the approximated field, and an absolute error map in a repeated layout, which the authors note is useful for checking whether source position, object geometry, and material labels were preserved across the YAML, command-line, and export stages.

Beyond the default solver, WaveLab Studio includes a preparatory pathway toward physics-informed neural networks. The current release provides the shared scene representation, field-export mechanism, and backend separation needed to prepare neural PDE experiments, but the authors are explicit that they do not claim a validated neural solver. In a future release, the default approximation stage could be replaced by a neural approximation trained with residual, boundary-condition, initial-condition, and data terms, following the general physics-informed neural network framework introduced by Raissi and colleagues in 2019. The present contribution is therefore described as a PINN-ready workflow interface rather than a demonstrated PINN benchmark, a distinction that reflects a growing trend in the literature on physics-informed learning for electromagnetic materials, discontinuous media, and transient two-dimensional fields.

The educational impact of the tool may prove to be its most immediate application. Students can experiment with source position, frequency, material labels, and object geometry without writing a complete simulation program, while the YAML representation exposes the same scene in machine-readable form, helping learners connect visual modeling with reproducible scientific computing practices. In research and thesis-supervision settings, the software supports rapid scenario generation and result packaging: a saved experiment can contain the input scene, numerical outputs, plots, animations, and metrics needed to discuss a simulation result. The authors suggest the tool is well suited to preparing demonstration cases, testing plotting and data-processing scripts, and organizing small scene collections before moving to validated solvers such as Meep, openEMS, or gprMax.

The software is distributed as a Python repository including the GUI entry point, command-line scene tools, example YAML scenes, documentation, smoke tests, and a reproducible Code Ocean capsule that executes the headless path, since the Tkinter interface requires a display server. The code is tested on Linux and Windows-compatible Python environments, and the developers provide support through a contact email listed in the repository documentation.

Looking forward, the team outlines an ambitious development roadmap: benchmark validation against analytical and established solver references, a documented and tested PINN/Modulus backend, improved package modularity, public API documentation, and extension to three-dimensional scene construction with volumetric visualization. For now, WaveLab Studio stands as a demonstration that reproducibility in scientific computing does not always require heavyweight infrastructure. By unifying graphical design, transparent configuration, headless execution, and packaged outputs under a single scene contract, the tool lowers the barrier to entry for wave-propagation experimentation while leaving a clean migration path toward the high-fidelity and machine-learning-based methods that production research ultimately demands. In a field where the gap between classroom demonstrations and research-grade simulation has often been wide, a deliberately simple tool with a rigorous workflow discipline may prove to be exactly the bridge that students and early-stage researchers need.

ELICIPY’s core architecture consists of two tightly linked components. The first is a web application, built on the Streamlit framework, through which experts answer calibration questions—so-called seed questions whose true answers are known—and target questions, whose answers are the quantities of interest. The second is an analysis engine that processes the responses, assigns weights to each expert based on their statistical performance, and aggregates the weighted opinions into a single “decision-maker” distribution. Version 2 keeps this familiar structure but substantially upgrades both sides, and the entire tool is now distributed as a standard, pip-installable Python package with three command-line entry points: elicipy-form for building questionnaires, elicipy for running the core analysis, and elicipy-dashboard for exploring the results.

Perhaps the most intellectually significant addition is the new agreement index, a quantitative measure of how closely the experts’ uncertainty intervals overlap. For each pair of experts, the index compares their stated inter-quantile ranges, computed from the lower and upper bounds of each expert’s interval as a normalized overlap ratio that ranges from minus one to one. A value of one means the two intervals coincide perfectly, zero means they are adjacent but non-overlapping, and negative values flag experts whose ranges are separated, indicating genuine conflict. This matters because aggregated uncertainty in a final estimate can arise from two very different situations: experts who genuinely disagree, or experts who individually hedge with very wide ranges. Distinguishing between these cases allows a decision-maker to understand whether the problem is divergent knowledge or simply cautious phrasing. The software reports the mean, standard deviation, and quantiles of pairwise index values under equal weighting and under other weighting schemes, and in related volcanic hazard work the same quantity has been described as a “Conformity Score.” When applied to a test case based on Cotopaxi volcano in Ecuador, the index clearly exposed pairs of experts whose intervals failed to overlap on some target questions while confirming strong consensus on others.

The second headline refinement targets the Classical Model—Cooke’s method—the gold-standard technique for performance-based expert weighting since its introduction in the early 1990s. Under the standard formulation, each expert’s calibration is scored by counting how many realizations of seed questions fall into discrete quantile bins, with the ideal expectation that roughly 5 percent of realizations land below the expert’s 5 percent bound, 45 percent within the 5-to-50 percent range, 45 percent in the 50-to-95 percent range, and 5 percent above the 95 percent bound. The trouble, the authors explain, is that this counting is inherently stepwise: a hair’s-breadth shift in an expert’s estimate, or a slight relocation of a seed realization, can abruptly jump an expert’s weight across a bin boundary. Worse, the discrete counting introduces a granularity error—sometimes called integer bias—when the number of seed questions is small or odd, because it becomes mathematically impossible to realize the theoretically balanced 5-45-45-5 percent distribution.

ELICIPY v2 addresses this with two new formulations offered as advanced options alongside the original method. The Balanced Classical Model handles the awkward edge case in which an expert’s stated value coincides exactly with the true realization: instead of forcing the realization into a single bin, it is split evenly between the two adjacent inter-quantile ranges. The Continuous Classical Model goes further by replacing each seed realization with an “influence interval” whose half-width is defined as one over the number of seed questions, scaled by the ratio of the expert’s 90 percent confidence interval width to 0.90. In other words, the smoothing applied to each realization grows with the expert’s own expressed uncertainty and shrinks as the number of calibration questions increases. By computing the fractional overlap of these intervals with the quantile boundaries, the software produces expert performance as a continuous, smooth function of both judgment and data. The authors draw a conceptual analogy to the transition from Voronoi tessellations to natural-neighbor interpolation: just as Voronoi diagrams are discontinuous with respect to input points, the standard Classical Model jumps at bin boundaries, whereas the new approach yields a smooth response surface. Crucially, the method converges back to the standard Cooke’s Method as the number of seed questions grows, meaning it refines rather than replaces the classical framework—particularly valuable in data-scarce settings where only a handful of seed questions are available.

Beyond the mathematics, the update focuses heavily on usability. A new interactive dashboard, launched with a single command, transforms what was once a static set of output files into an exploratory web interface. Users can browse combined cumulative distribution functions and histograms for any target question, toggle between weighting schemes—Cooke weighting, the ERF scheme, or simple equal weighting—within a single chart, hover over data points for precise values, and zoom into distribution tails. The dashboard automatically filters selectable questions to only those with compatible units and scales, steering users away from meaningless comparisons, and every plot or table can be exported as a PNG image or CSV file for downstream analysis. New visualization options, including violin plots and pie charts of median values, aid side-by-side comparison across groups of questions.

The release also rounds out the elicitation workflow itself. Analysts can now import expert weights from an external file, opening the door to weighting schemes derived from other models or institutional criteria. New output files automatically save percentile values from the 1st to the 99th for each target question, in a separate CSV per weighting scheme, and results are organized into tidy subfolders. Recognizing that the original ELICIPY paper recommended experts draft answers on paper before typing them in, the developers added a utility that reads the questionnaire file and generates fillable PDF forms for both seed and target questions. Online forms can now be password-protected to ensure only authorized panelists respond, and a public webpage tracks repository accesses and clones, giving the team visibility into how the tool is being adopted across the community.

The software’s engineering credentials have been formally certified as well. ELICIPY v2 resides in its own GitHub repository, compliant with the standards defined by the European Open Science Cloud Synergy initiative, and the repository was awarded an SQAaaS Gold Badge following a Quality Assessment and Awarding procedure—a signal of the project’s adherence to reproducibility and software quality benchmarks. The tool requires Python 3.10 or later, is released under the GPL-2.0 license, and is supported through a dedicated email address maintained by the Italian National Institute of Geophysics and Volcanology.

The practical stakes are illustrated by the software’s use in real volcanic risk studies. The updated codebase draws its examples from an expert elicitation supporting hazard and risk assessment for Kolumbo volcano in Greece, and earlier versions of the tool underpinned eruption-probability estimates at Cotopaxi and Guagua Pichincha in Ecuador. In these contexts, structured elicitation bridges the gap between sparse geological data and the probability distributions that emergency planners and civil protection authorities need. By quantifying disagreement among experts and smoothing out the statistical artifacts of small calibration sets, ELICIPY v2 aims to make the bridge sturdier. The development was funded through the Italian “Pianeta Dinamico – Working Earth” program, the Italian Department of Civil Protection, and the Hellenic Survey of Geology and Mineral Exploration, with the authors acknowledging the guidance of elicitation pioneers Willy Aspinall and Roger Cooke.

As uncertainty quantification spreads from volcanology into climate impact studies, pandemic modeling, and engineering risk analysis, tools like ELICIPY are quietly becoming part of the scientific infrastructure. Version 2’s blend of statistical refinement, interactive visualization, and standards-compliant packaging suggests that the craft of asking experts the right questions—and weighting their answers fairly—is maturing into a computational science in its own right.