The preCICE library communicates data between coupled solvers in a parallel, peer-to-peer, and point-to-point way. As back-ends, either TCP/IP or MPI can be used. Communication channels between the processes of both solvers are established using a highly scalable algorithm .

To handle non-matching coupling meshes, preCICE offers different methods for data mapping, including projection-based methods and kernel methods (radial-basis function interpolation) . While some projection methods require mesh connectivity information, kernel methods operate solely on point clouds. Each mapping can be configured to be either conservative (the total values over the interface are conserved for extensive properties, e.g., mass, forces) or consistent (for intensive properties, e.g., temperature, pressure). preCICE supports 2D and 3D Cartesian meshes and surface and volume coupling. In the particular case of this paper, both codes use geographically projected coordinates and can thus apply 2D Cartesian meshes.

To orchestrate the simulation progress of all coupled solvers, preCICE offers different coupling schemes. On the one hand, preCICE distinguishes between serial and parallel coupling: In serial coupling, coupled solvers advance sequentially, one after the other. In parallel coupling, coupled solvers advance concurrently. In both cases, the coupled solvers synchronize and exchange data after each fixed time window. On the other hand, preCICE distinguishes between explicit and implicit coupling. In explicit coupling, each time window is only computed once. In implicit (or iterative) coupling, each time window is repeated, with modified exchanged values, until predefined convergence criteria are met. To this end, solvers need to go back in time, which is typically implemented by checkpointing in the adapter. Implicit coupling increases accuracy and numerical stability. The convergence behavior can be improved with fixed-point acceleration, for instance, with quasi-Newton methods . Accuracy and numerical stability can further be improved by sampling time interpolants during each time window .

Adapters for several important numerical frameworks, such as OpenFOAM , have been developed and are maintained by the preCICE team. Others are provided by the community. The preCICE website maintains a list of all adapters and their development status (https://precice.org/adapters-overview.html, last access: 22 May 2026).

There are different ways to implement preCICE adapters (https://precice.org/couple-your-code-adapter-software-engineering.html, last access: 22 May 2026). Some are directly integrated or patched into the solver's code, for example, the CalculiX-preCICE adapter . Others are developed as stand-alone software packages, either as plugins like the OpenFOAM-preCICE adapter or as orchestration codes that also call the solver like the CAMRAD II-preCICE adapter .

Ice sheets are complex systems, so even a stand-alone ice sheet simulation is already a multiphysics simulation (Fig. ). In ISSM, the cores can be run individually, e.g., to get the stress balance solution only. However, more often, transient runs are conducted, where most cores are solved. The system of equations of ice sheets is not solved in a numerically monolithic way, but in a sequential (segregated) fashion. In ISSM, a typical sequence is: first, the enthalpy balance is solved, then the stress balance, and afterwards, the geometry is evolved. Each core immediately uses the results of the previous cores.

ISSM supports two and three-dimensional meshes. Figure  shows the mesh structure. The basic horizontal two-dimensional mesh is an unstructured triangular grid that covers the horizontal computational domain, including ice-free regions. The 2D mesh is usually static, as there is limited support for adaptive mesh refinement.

For the SSA approximation, the 2D mesh is sufficient. For HO or FS, a three-dimensional mesh is required. The 3D mesh is generated by vertically extruding the 2D mesh in multiple layers. The vertices in the top layer are set at the surface of the ice. The vertices in the bottom layer are set at the base of the ice. The vertices in the layer in between are distributed between the top and bottom vertices, often with smaller spacing at the base. Therefore, the vertical (z) coordinate of the vertices changes in every time step as the thickness of the ice changes. The vertices are connected as truncated triangular prisms or tetrahedra.

ISSM uses the finite element method (FEM) to solve the partial differential equations (PDEs) for each core. The finite element type used can be configured for most cores individually. Linear P1 elements, where nodes are placed exclusively at the vertices, are the default for many cores, but higher-order elements are available.

All cores use the same mesh but generally do not have the same finite element types. The time stepping method and step size are also generally identical for every core with fixed or adaptive time steps, but a few cores, e.g., the hydrology core with the DoCo method , subdivide the steps further. All cores use the same number of CPUs and the same domain decomposition for MPI parallelization. showed that the cores that solve two-dimensional problems (e.g., mass transport, moving front) are significant bottlenecks for scaling as they compute fewer DOFs than the three-dimensional cores (e.g., thermal, stress balance).

ISSM's architecture is well-suited for the development of a generic coupling adapter. Mesh and data access can be implemented based on abstract interfaces for different cores, mesh types, finite element types, etc. Variables are identified by runtime values (strings externally, mapped to enum values internally). With few exceptions, noted when describing the adapter in Sect. , the adapter does not need to include code to handle specific configurations.

Section  outlines the different ways to implement preCICE adapters. As shown in Fig. , the ISSM adapter is implemented as a coordinating wrapper application that calls ISSM (used as a library) as well as preCICE. This approach allows for independent development and a clean architectural separation between solver and adapter, allowing, e.g., easy support for multiple ISSM versions. However, this relies on a relatively stable API of ISSM and might pose maintenance challenges in the future. Additionally, due to the architectural choice of using ISSM as a library (instead of via its command-line interface), some functionalities internal to ISSM are not available. Note that so far, no changes to ISSM or its build process were necessary to support the features of the adapter.

Since ISSM could potentially be coupled with many different codes, the coupling interface is configurable. The most important interfaces for coupling with the environment of the ice are the base and surface. So far, these are the only supported interfaces, see the list of limitations below for other interfaces that may be added later. In the configuration file, the user specifies which part of the mesh forms the coupling interface. The vertices of this part of the mesh are passed to preCICE. Mesh connectivity is added to support mapping schemes like linear cell interpolation (https://precice.org/configuration-mapping.html, last access: 22 May 2026) . The finite element representation of ISSM variables is evaluated at the mesh vertices before writing data to preCICE.

Some precision of high-order finite element types is lost when evaluating variables at the mesh vertices. Instead, the nodes of the finite elements could be used. For best results, this would require multiple coupling interfaces for different finite element types, and mesh connectivity would not be available. The adaptive mesh refinement feature of ISSM is not supported; the mesh must be static. Note that preCICE does provide facilities for mesh refinement (https://precice.org/couple-your-code-moving-or-changing-meshes.html, last access: 22 May 2026), but the adapter does not yet use them.

Specialized ESM couplers support masking of irrelevant areas, e.g., masking land for ocean models. As mentioned above, preCICE does not provide this feature. Additionally, preCICE does not handle non-matching domains very well. This is not a big issue for the use case discussed here, since ISSM and CUAS are interested in approximately the same domain, and both have internal mechanisms to exclude irrelevant areas and avoid wasteful computations. But it may be beneficial for, e.g., ice–ocean coupling to only couple over floating ice or coupling with a global atmosphere model.

3D (volume) coupling is a possible future extension. This would allow, e.g., to couple ISSM with itself to use different meshes for different cores to optimize precision or performance or to use an external thermal solver. However, as ice is transported by the solver, the z coordinate of the vertices changes in every time step. As the interface changes significantly over time, the coupling mesh could be reset to the new locations of the interface, just like for adaptive mesh refinement above. So far, we have not tested whether the computational overhead to update the coupling mesh and corresponding mapping matrices in preCICE is acceptable.

In ISSM, every state variable is identified by a unique name. These names do not follow any consistent convention, and the other coupling participant may use different names. So, it is necessary to map between names in the preCICE configuration file and ISSM names. The configuration file provides such name mappings for read and written variables.

If the ISSM setup uses a 3D mesh, the adapter can perform depth-averaging of a variable before writing it and extruding a variable (i.e., copying the variable values to the other layers of the mesh) after reading using the existing ISSM functionality.

ISSM accepts time series as input variables. For example, the user can set specific values for these variables at the beginning, middle, and end of the simulation. ISSM calls these “transient variables” and temporally interpolates between these values when necessary. However, ISSM does not allow overwriting the user-provided values of such transient variables. Therefore, the adapter requires coupled variables to be set up as non-transient, i.e., with one fixed value that is overwritten with the value read from preCICE during the simulation. This is a purely technical restriction and does not reduce modeling capabilities, since coupling also models input variables that change over time.

In ISSM, most variables are not zero as the simulation starts at some point in time in a defined state. For some variables, e.g., ice thickness, zero is not even valid at all. For non-zero initial values, preCICE requires data initialization (https://precice.org/couple-your-code-initializing-coupling-data.html, last access: 22 May 2026) by writing variables once at the beginning of the simulation. The ISSM adapter assumes that such initialization is necessary for every variable it writes.

For most variables, the adapter can simply write the initial value specified in the ISSM setup. However, users of stand-alone ISSM are not required to specify true initial values for variables that are computed by ISSM before they are used. For velocity, the initial value in the setup is merely used as an initial guess for the non-linear iteration of the stress balance core. Other variables, like rheology parameter B that is computed by the thermal core, do not need to be specified in the setup at all when the corresponding core is active.

For selected variables, the adapter can be configured to compute the true initial value. For example, to initialize velocity, the adapter would run the stress balance core once. But this is not possible for every variable, at least not in a generic way, so proper initial values must be provided by the user of the adapter even when it is not required by ISSM itself.

ISSM can set discrete Dirichlet boundary conditions (mainly called single point constraints in ISSM) for some cores, e.g., velocity (Vx, Vy, Vz) in the stress balance core. The adapter has limited support to set some of these constraints by coupling. In the ISSM code, the constraints are stored differently from normal variables, so generic support for all constraints that ISSM uses is currently not possible. The association between constraints and the core that they apply to has to be hard-coded for each one. For example, the adapter has no way to find out automatically that constraints on velocity are used by the stress balance core. Further complicating the implementation is that manual MPI communication is required in the adapter to synchronize constraints on ghost vertices. For variables, no such extra communication was necessary.

Constraints can currently only be coupled for P1 finite elements. Internally to ISSM, constraints are stored per finite element node, not per mesh vertex. But the coupling mesh is defined at the vertices instead of at the finite element nodes. Supporting constraints on other finite element types would require manual interpolation, whereas for normal variables, the interpolation from different finite element types is handled by ISSM automatically. Additionally, only velocity and pressure constraints of the stress balance core have been implemented so far.

ISSM performs multiple time steps per coupling window, depending on the step size set in the ISSM setup. During a coupling window, the adapter does not perform subcycling as it is defined by preCICE, i.e., it does not read or write intermediate values, only snapshots at the beginning or end. So, coupled variables are constant over one coupling window. The time interpolation features of preCICE mentioned in Sect.  are not currently used. This may be added in the future, but would probably require changes to the ISSM code. In the current version, the coupling window has to be set short enough to capture the dynamics of the system.

Implicit coupling is not supported. The adapter does not create the necessary checkpoints of ISSM, neither in memory nor on disk. Implicit coupling is required for numerical stability in some setups (see Sect. ). Our experiments show no instability with explicit coupling. This is consistent with the internal explicit coupling of ISSM cores explained in Sect. . This is another possible future extension.

We use the synthetic Thule geometry developed for the CalvingMIP project . This setup is based on analytical functions for the bed elevation and yields an ice-sheet geometry that encompasses all major components of an ice-sheet model domain (grounded ice, floating ice, and open ocean). In CalvingMIP it is used to study how different ice sheet models handle calving in a very controlled setup. Instead of fixed thermal and friction conditions as in the original definition, we enable the thermal core of ISSM with surface temperature 250 K and geothermal flux 0.05 W m⁻² to compute basal melt rates to be used by CUAS and we use the default Budd friction law σb=-C2Nqp|vb|1p-1vb with coefficient C=100, exponents p=3 and q=2, and effective pressure N supplied by CUAS. Surface mass balance was increased to 8 m yr⁻¹ IE. The goal is to have a balanced geometry with grounded and floating, fast- and slow-flowing regions to assess the effects of coupling.

The combined model (ISSM + CUAS) spin-up consists of two phases. First, we run the ISSM model for 12 000 years with a time step of 0.1 year to reach a steady state, using an effective pressure equal to the ice overburden pressure. In the second phase, CUAS and ISSM run coupled without melt runoff forcing, exchanging data every 0.1 year (equal to the ISSM time step) for 200 year. This allows CUAS to find its own steady state while keeping ISSM state consistent with the effective pressure computed by CUAS.

For the actual experiment, we add forcing in the form of seasonal and spatially varying meltwater runoff (in addition to the basal meltwater received from ISSM) to CUAS to induce a dynamic system. We ran simulations with low and high runoff. The peak forcing in summer (day 210 of the year) in areas with ice surface below 500 m is 0.2 m yr⁻¹ WE for low runoff and 2.0 m yr⁻¹ WE for high runoff. Over the year, the forcing follows the shape of a Gaussian distribution with parameters μ=210 d and σ=20 d. Spatially, forcing is maximal in areas of low ice surface elevation (hs<500m) and zero in areas of high ice surface elevation (hs>1500m). For medium ice surface elevation, forcing follows a monotone cosine curve, i.e., it increases continuously as the surface elevation decreases. The surface elevation hs is taken at the end of the spin-up, the forcing is not dynamically updated.

The basic coupling configuration, both for spin-up and the following experiment, is shown in Fig. . As described above, CUAS writes the effective pressure that is used by ISSM to determine basal friction. The basal melting rate from ISSM provides a water source for CUAS. Basal temperature, ice thickness, and ice and ocean masks are used to update the active CUAS mask. The temperature threshold for activating the mask is set to 269.15 K. Ice velocity and rheology govern channel opening and closure, represented in CUAS by increasing and decreasing transmissivity, respectively. We use linear cell interpolation to map data between the two meshes. Details on how the coupled variables are used in CUAS are described in Sect. . Simulations are run over two years to assess changes from one year to the next. Data is exchanged daily to accurately capture rapid changes during summer. ISSM uses time steps of 1 d same as the coupling window, CUAS 4 h.

We compare a fully coupled (2-way) run with one in which coupling is performed only in one direction (1-way). In 2-way, ISSM and CUAS exchange all variables as per the coupling configuration described above. In 1-way, ISSM receives the updated effective pressure from CUAS, but CUAS does not receive updated ice geometry from ISSM. This is equivalent to offline coupling: first run CUAS stand-alone, then use the resulting time series as input for a stand-alone ISSM simulation. To ensure comparable aggregate forcing, CUAS receives the steady basal melt field from the end of the spin-up from an input file.

The state at the end of the combined model initialization (spin-up) is presented in Fig. . The ice thickness and basal velocity are selected as the key quantities describing the ice sheet state, while effective pressure and subglacial discharge are selected to describe the state of the subglacial hydrology. The dark gray areas in Fig. a–d (and subsequent maps) indicate the grounded parts of the domain where basal temperatures from ISSM are below the pressure melting point, and ice sheet basal melt is zero (cold base) and hence no active hydrology exists. The ice thickness (Fig. a) in the warm-based area varies over several thousand meters, with low thickness in region A and along the northern and southern grounding lines, as well as the upstream end in region B. The effective pressure (Fig. b) is lowest at the grounding line and reaches magnitudes above 6 MPa. Basal velocities (Fig. c) range from 10 to about 400 m yr⁻¹ with the largest values along the long grounding lines in the north and south. Along those grounding lines, the subglacial discharge (Fig. d) is highest, with a similar pattern of N, vb and D.

For a further investigation of the differences in 1- and 2-way coupling, we present simulations with different magnitude in seasonal forcing. Figure  displays the time series of total water source, Qtot, mean effective pressure, N¯, mean effective transmissivity magnitude, log⁡(Te)‾, and basal velocity magnitude, log⁡(vb)‾ showing 1-way and 2-way coupling and for each full forcing (high) and only 10 % amplitude forcing (low). The imposed runoff forcing is periodic with a one-year period and attains its maximum at day 210, end of July. As model output is written every 10 d, this maximum is not sampled exactly in the second simulation year. The nearest stored time step (day 215), therefore, exhibits a slightly reduced signal amplitude. The effective pressure (Fig. b) has a lower difference between 1- and 2-way coupling for low runoff forcing. In both runoff cases, the 2-way coupling has higher N‾. The timing in N‾ is slightly delayed to Qtot due to the low runoff forcing. The timing of log⁡(Te)‾ (Fig. c) in the low runoff forcing is similar to N‾ and log⁡(vb)‾ (Fig. d). The effect of the coupling is small for low runoff forcing in log⁡(Te)‾, with larger differences outside the peak runoff and higher log⁡(Te)‾ in 1-way. The basal velocity resembles the inverse shape of N‾.

Comparing the results for 1-way and 2-way coupling in ice thickness difference (Figs. a and a), we find distinct differences in the regions A and B: in A the 1-way case exceeds ±50 m, while the 2-way case has small differences. The pattern of ice thickness difference is similar for the 1-way and 2-way coupling, but the magnitude is significantly larger in the 1-way case. For both 1-way coupling and 2-way coupling, we find a reduction in effective pressure compared to the spin-up that does not contain seasonal runoff (Figs. b and b). In both 1-way and 2-way coupling, we have an increase in basal velocity compared to the spin-up (Figs. c and c), with an extreme increase in region A for the 1-way coupling. The discharge (Figs. d and d) is in both cases larger than in the spin-up, but the difference to the spin-up is only moderate in magnitude, except for region B in the 1-way case.

The setup for ISSM is mostly the same as G1000 in . The only modification we made for this paper is to use the default ISSM Budd friction law σb=-C2Nqp|vb|1p-1vb with coefficient C=12.94, exponents p=3 and q=2, and effective pressure N provided by CUAS. The spin-up process is the same as in . During the spin-up, the effective pressure is N=Nopc=ρicegH-max(0,ρwaterg(-zb)) with zb the height of the base above sea level as in . The setup set the lower bound for effective pressure 35 % of ice overburden pressure. This parameter is likely to affect the stability of the coupled system, but investigating its effect in detail is beyond the scope of this work. The resolution of the mesh is around 0.7 km at the shear margins, 10 km at slow-moving ice in the interior, and up to 100 km at open ocean.

The CUAS setup is taken from . We use G600, which has a uniform grid with 600 m resolution, similar to the minimum element size of the ISSM mesh. We use daily surface runoff data (R) from the regional climate model RACMO for the year 2019 in addition to the ice sheet basal melt (M) from ISSM to impose seasonality to the CUAS water source as: 1Q(x,y,t)=M(x,y,t)+0.9R(x,y,t), where we only consider 90 % of the surface runoff to enter the subglacial system. The percentage is arbitrary, but ensures strong seasonality for the coupled simulations. In the year 2019, particularly high melt was measured for the Greenland Ice Sheet . The aquifer layer thickness in CUAS was chosen equal to 1 m, with yield storativity Sy=10-2 and minimal transmissivity Tmin=10-14 m² s⁻¹. Subglacial channel creep opening/closure is parameterized using an ice flow rate factor of A=6.8×10-24 Pa⁻³ s⁻¹ . All remaining parameters are unchanged from those reported in . For defining the initial active mask in CUAS, a threshold of minimum 10 m of ice thickness was chosen. The temperature threshold for activating the mask during simulation is set to 269.15 K. Similar to ISSM, the initial hydraulic head of CUAS is derived from Nopc.

The preCICE coupling configuration is the same as in Sect.  with the exception of using different mapping methods for Sect.  and different coupling schemes for Sect. . Simulations run for 730 d.

For the measurements, we are using the profiling utility integrated into preCICE (https://precice.org/tooling-performance-analysis.html, last access: 22 May 2026). The runtime of initialization is measured at the beginning. Where we report aggregate runtime of solvers or data mapping in the following sections, only the final 365 days are included. This ensures that the analysis includes a full year of seasonal changes but excludes the noisy early-coupling windows in which the states of ISSM and CUAS are not yet aligned. In real use, depending on which parameters are changed between runs, this relaxation phase could be skipped entirely by using restart files. Runtime measurements do not include writing output, as I/O execution times can swing wildly and unpredictably. Adding moderate amounts of data output to both participants should not, on average, significantly impact the analysis. Every experiment is repeated three times, and the results are averaged to reduce variance.

In parallel coupling schemes, every participant has its own exclusive resources. CPUs are assigned according to a ratio α=nISSM/nCUAS where nS is the number of CPUs assigned to solver S. Care is taken to assign packed CPU blocks to participants, i.e., processes used by one participant are as local to the nodes as possible, since each participant communicates more internally than with other participants.

In serial coupling schemes, we conducted experiments with both shared and exclusive resources. Shared resources are used by both solvers in turn. Exclusive resources are used by only one solver and are idle while the other solver computes. That means, except during initialization, half of the CPUs will be almost completely idle. Little energy is wasted, but the cluster resources are nonetheless reserved for the entire run. With shared resources, both solvers always use all allocated CPUs, as it is generally recommended to use all allocated cluster resources unless the region of flat or negative scaling is reached. For better comparisons, we also allocate the same number of CPUs to both solvers when using exclusive resources.

Where we give CPU or process counts below, they have the following meanings for the coupling and resource allocation schemes:

Parallel: total number of processes allocated to both solvers, each solver using a fixed subset.

All experiments are performed on the Albedo cluster of the Alfred Wegener Institute. The compute nodes of the cluster are equipped with 256 GB of RAM and two AMD Rome Epyc 7702 CPUs for a total of 128 CPU cores per node and are connected by 100 GB InfiniBand network. The solvers and dependencies are built with GCC version 12.1.0 and OpenMPI version 4.1.3.

In Earth System Models, initialization time of the solvers and the coupling library is of significant concern. For this scaling analysis, we use nearest neighbor mapping exclusively. Comparison of mapping methods follows in Sect. .

Figure  shows the time required to initialize preCICE. This includes establishing connections between participants and processes, partitioning of the domain, and computation of mapping weights. We do not analyze these parts separately, as it would require too much explanation of preCICE internals, and we are primarily working from the point of view of a preCICE user. For comparison, Figs.  and  show the time required to initialize the solvers. Note that ISSM and CUAS initialize at the same time, so the actual time required is the maximum of both. While the data is quite noisy due to a low number of repetitions and high variance of I/O, general trends can be identified.

ISSM initialization time grows linearly with the number of processes. CUAS is basically constant, trending slightly downward. Solver initialization is dominated by CUAS at low CPU counts. The larger mesh means higher data input requirements. ISSM catches up between 1024 and 2048 processes due to less optimal parallel I/O accesses.

In the range of CPU counts tested, preCICE initialization times also grow linearly with the number of processes, as more communication is necessary to partition the meshes and compute weights. Initializing the coupler and initializing the solvers requires similar time, except in the case of serial coupling with shared resources.

Sharing resources during initialization in serial coupling has a strong negative effect. Naive estimation would suggest the required time doubles for shared resources, since the same amount of work is being done by half the CPUs. However, scheduling conflicts can increase times by an order of magnitude or more. CUAS is especially badly affected, probably due to contention of I/O resources. Parallel and serial exclusive require approximately the same amount of time. The increased effort required to compute and communicate the weights of a more partitioned mesh is counterbalanced by the increased resources.

For parallel coupling, we first needed to determine the optimal distribution of available CPUs among the solvers. This is the ratio of CPUs used by ISSM and CUAS where both solvers take approximately the same time for one coupling window. Figure  a shows the times required to compute a single coupling window with different distributions of 256 total CPUs. The best result is at α=2.2. If both participants scale equally, this would be the ideal distribution for larger numbers of CPUs as well.

However, as Fig.  displays, ISSM does not scale as well as CUAS. This is consistent with the scaling analyses of stand-alone ISSM and CUAS as well, even though the uncoupled and coupled solvers are not directly comparable. Accordingly, with increasing numbers of processes, the duration that CUAS waits for ISSM increases as shown in Fig. . At 256 processes, where the distribution of α=2.2 had the best result, the wait times are close. Note that even here, the wait time is not zero, as the computational effort of each solver varies with the seasons, and both solvers wait in some coupling windows.

These results suggest that more than 256 CPUs should be distributed differently. Figure b shows that for 1024 processes, the ideal distribution would be α=3.0. Figure  shows reduced wait times for this distribution over α=2.2. Note that when running the simulation once at any moderate distribution α and measuring the average solver runtime tX, the equation αopt=tISSM/tCUAS⋅α gives a decent approximation of the optimal distribution. For example, with α=2.2 and the measured solver times tISSM=7.5 s and tCUAS=4.8 s, the estimated optimal distribution is αopt=3.4, which is close to the minimum in Fig. b.

With these preparations, we ran scaling experiments of the coupled system. Figure  shows a comparison of average run times for a coupling window for parallel and serial coupling schemes with different resource allocations.

In the lower range of processes, where both serial and parallel show almost ideal scaling, serial coupling is slightly faster. There is an unexpected bend in the measured times for serial coupling. The same bend is observed in the ISSM solver execution times, but not in CUAS. We were unable to identify the root cause or any difference in the simulation that could explain it, the number of solver iterations is similar between all experiments. A deeper analysis of the ISSM solver is beyond the scope of this work.

Exclusive resources for serial coupling give a small advantage over shared resources, but probably insignificant compared to the difference in initialization times discussed in Sect. . Scaling is basically identical. The changed distribution of CPUs in parallel coupling also gives a small advantage over the original distribution.

preCICE offers a choice of different methods for mapping data between meshes. The methods differ in the order of approximation and computational cost. We ran experiments with a selection of three methods of different order:

nearest neighbor (NN), a first order projection method

The PoU method and basis functions must be parameterized (https://precice.org/configuration-mapping.html, last access: 22 May 2026). Our setup is particularly challenging for the current, relatively recent implementation of PoU in preCICE. As described in Sect. , the ISSM mesh has a wide range of element sizes. However, preCICE currently permits only a single global parameter each for the basis function radius and PoU cluster size. In addition, the fields of an ice sheet model include discontinuities at the calving front and grounding line. Even with the best parameterization we found (C0 compact polynomial basis functions, radius 200 km for mapping from ISSM to CUAS, 10 km from CUAS to ISSM, default values for the other parameters), there is overshooting, e.g., negative ice thickness values all around the ice boundary as in Fig. . Performance measurements are included here with the hope that improvements in preCICE and/or the setup will be implemented. The other methods did not show such problems, detailed analysis of numerical errors is beyond the scope of this work but is covered in , , and .

Figure  shows the total runtime required to initialize preCICE for both participants. This time includes both communication, mesh partitioning, and initializing data mappings. For all methods, initialization of preCICE is around the same order as initialization of the solvers (see Figs.  and ). LCI is about twice as expensive as PoU and almost four times as expensive as NN.

Figure  shows the runtime required to map the data in each coupling window. The cost difference between the mapping directions (ISSM to CUAS or CUAS to ISSM) can be attributed to the number of fields that must be mapped. NN and LCI are very close in cost, whereas PoU is significantly more expensive. However, for all mapping methods, the runtime of a coupling window (see Fig. ) is dominated by the solvers themselves. NN was measured at approximately 9 ms from CUAS to ISSM, 25 ms from ISSM to CUAS, or ∼0.1 % and ∼0.3 % of the total time of a coupling window. LCI was measured only slightly slower, at 10 ms (∼0.1 %) and 29 ms (∼0.4 %). Note that the difference is too small to be reliably measured with this setup. The cost of PoU, on the other hand, is not as negligible, with 58 ms (∼0.7 %) and 380 ms (∼6 %). The detailed profile shows a significant imbalance in the distribution of work, probably due to the uneven mesh resolution. The slowest processes work up to four times longer than the fastest.