AMBER: Adaptive Mesh Generation by Iterative Mesh Resolution Prediction

We thank the reviewer for their thorough review, and especially their critical assessment of the clarity of writing for our iterative mesh generation procedure. In the following, we will clarify the mentioned points and address the individual concerns raised by the reviewer.

AMBER [is] used to generate meshes for finite element methods for solving stationary PDEs. […] the target is the element sizing field (ESF)

We would like to clarify that AMBER may generate meshes independent of an underlying PDE. In our experiments, four datasets rely solely on geometry, and while the two PDE-specific datasets are stationary, the method is not limited to stationary cases and datasets like Airfoil and Console are created with non-stationary simulations in mind.

While the sizing field describes the element sizes, it is defined on vertices rather than elements, yielding a piecewise‑linear rather than piecewise‑constant field. We detail and justify this choice in Appendix H.3.

[…] at each step is the intermediate used to generate the sizing field but the mesh is thrown away? Then the number of nodes is roughly decided by the c_t parameter? If so what is an example schedule of the {c_t} and how does this typically translate into number of nodes?

AMBER generates a new mesh at each step from predicted sizing fields, using previous meshes only as sampling points to predict the sizing field on. We briefly contrast adaptive mesh refinement methods in the “Related Work” and will further clarify this relationship in the revision.

The $c_t$ parameter is a scalar applied to the predicted sizing field. As mentioned in Table 3 in Appendix D.4, we set it to the golden ratio $1.618^{T-t-1}$ for all experiments, with $c_{T-1}=1$ leading to no scaling for the last generation step. The mesh size scales roughly in $\frac{1}{c_t}^d$, where $d$ is the dimension of the data.

Also in training based on the "residual prediction" it is unclear how the "current discrete sizing field" is generated. Is it the expert sizing field or the previous step prediction?

The current discrete sizing field is generated by projecting the characteristic edge lengths of the elements of the current mesh onto its vertices, as described by Equation 3. We use neither the expert sizing field nor the previous prediction directly. We will clarify this relationship in the revised version of this paper.

I think this misses the point that adaptive meshing is intended to reduce FEM approximation error which is not reported. All baseline M2N/UM2N/ASMR have some actual FE error based metric.

We fully agree that adaptive meshing is intended to reduce FEM approximation error. Most of our datasets are designed to evaluate general‑purpose mesh generation without a specific associated PDE. We assume optimal expert meshes and therefore expect that accurate imitation leads to near‑optimal meshes for downstream simulations.

However, we do have a concrete PDE for both Laplace and Poisson and already evaluate the FEM error indicator norm for the latter in Figure 4. The table below reports mean and two times standard error over five seeds for both datasets for AMBER, the baselines, and the expert heuristic. We provide DCD and element counts for reference.

AMBER achieves lower error indicators than the baseline methods while keeping in the expert’s element budget. The strong correlation between the error metric and DCD across methods further supports the use of DCD as a reliable proxy on datasets where direct FEM error is not available. As AMBER performs best in terms of DCD on all six datasets, its meshes would likely perform well on downstream simulations. Appendix I further supports these findings by showing that AMBER meshes are qualitatively similar to the expert.

Both M2N and UM2N are mesh movement methods that act on a fixed number of mesh elements and require PDE parameters as input. We thus do not consider these methods as baselines. We will make this distinction more explicit in our "Related Work" section in the revision.

[…] no meshing times are provided. […] There are a few reasons the method might be prohibitively slow. […] there is a requirement to; i) construct the hierarchical graph using multiple meshes via nearest neighbours, ii) calculate surface normal edge features, iii) add labels of the ESF for the replay buffer, all these step may incur significant cost.

We decompose AMBER’s runtime into graph construction, hierarchical extension, model forward, and mesh generation. We note that label calculation is only performed during training and has negligible runtime impact. The table below shows how runtimes and relative costs differ between mesh sizes for Poisson (easy/hard).

The mesh generation step is in O(N log N) and dominates runtime compared to the linear graph-related operations, especially for larger meshes. We note that AMBER acts on coarse intermediate meshes, and that the expensive last generation step is also required for the one-step baselines.

For reference, we also provide the average total mesh generation times of AMBER and the expert heuristic for ``Poisson``` (easy/medium/hard) in the table below.

AMBER is slightly faster than the expert for small meshes and shows significantly better scaling as mesh size increases. Similarly, AMBER mesh generation for the 3D tasks takes less than five seconds, while the human experts took 15 to 20 minutes per mesh.

[…] does the framework generalise to a new tasks? Or would it need expert meshes and retraining?

We agree that data efficiency and cross-task generalization are important factors of adaptive mesh generation algorithms.

To test AMBER across datasets, we trained a single model on a combined dataset containing Poisson (hard), Laplace, and Airfoil. We used the same architecture and hyperparameters as in the main experiments and simply concatenated the 20 expert meshes per task into 60 total training meshes. We one-hot encode the task in the node features, and zero out task‑specific features when unavailable. We use a shared replay buffer and do not weight the data. The table below shows the mean and two times standard error of the DCD for this Mixed setup.

The Mixed setup performs on par with AMBER trained on individual tasks, indicating that the same model can learn meshing strategies across different datasets and domains. We leave a general-purpose mesh generation model for future work.

How does the mesh generator consume the per vertex predicted sizing field?

Conceptually, we use the vertex-level sizing fields to create a piecewise linear function via the interpolant of Equation 1. Here, we essentially interpret the sizing field as a linear basis on the vertices and interpolate it onto the full mesh.

Code-wise, we use gmsh’s .pos options to write the sizing field onto the vertices of a background mesh using “Scalar Triangle” for and “Scalar Tetrahedron” formats. We then provide this background mesh to the meshing algorithm. We refer to the def update_mesh() function in the supplementary code submission for technical details.

How are the GNN parameters of different scales of the GNN message treated? Are they shared or are there different parameters for different length scales?

AMBER uses the same MPN to process all meshes. Each message passing layer has its own parameters as described in Section 3, but these parameters are shared across mesh generation steps. Differences in scale and hierarchy are handled purely by encoding distances between vertices as edge features and by one‑hot encoding vertices that belong to the hierarchical mesh.

We want to thank the reviewer again for the detailed questions. We hope that our clarifications and new results, particularly regarding generalization and runtime, address the concerns raised. We will add both to the revised paper. We encourage the reviewer to reach out to us during the discussion if there are further questions.

We would like to thank the reviewer for the positive review, and we appreciate the feedback that the paper is well-structured, has strong evaluations and is mathematically sound.

The reviewer raised one weakness, namely an arXiv paper they linked. We appreciate the detailed research of the related work and want to highlight that the mentioned arXiv paper was only presented at a non‑archival workshop. According to the NeurIPS guidelines, specifically the second question in the FAQ section, such workshop versions do not preclude submission to NeurIPS:

Q: What if I’ve seen similar work in a NeurIPS/ICML workshop?

A: We allow work that has been submitted to non‑archival workshops to be submitted to NeurIPS. To maintain anonymity, do not mention the workshop paper in your review.

The present submission substantially extends prior non-archival work and has not appeared in any archival venue. It includes new theoretical results, a different parameterization of the sizing field, two additional baselines and four additional datasets, as well as more thorough evaluation. We kindly ask the reviewer to assess the submission without considering the arXiv paper.

We thank the reviewer for the questions they raised, and will provide detailed answers in the following.

Using a graph neural network makes sense but then why a MPN and not for instance a GAT?

We thank the reviewer for asking about this comparison. MPNs have been shown to be a more expressive class of GNNs than GATs [1,2] and encompass the function class of several classical solvers [3]. As such, they have been widely used for physical simulations [4, 5] and adaptive mesh refinement [6]. We therefore adopt the MPN architecture for AMBER, as it is a natural and popular choice for processing graphs in physics-based applications.

That said, AMBER predicts a scalar sizing field per vertex, leading to relatively smooth predictions across the graph topology. A GAT with edge features, as used in an ablation in [6], could therefore perform similarly well, and a detailed exploration of alternative GNN architectures would be an interesting avenue for future work.

[1] Veličković, Petar. "Everything is connected: Graph neural networks." Current Opinion in Structural Biology, 2023.

[2] Bronstein, Michael M., et al. "Geometric deep learning: Grids, groups, graphs, geodesics, and gauges." arXiv, 2021.

[3] Brandstetter, Johannes, et al. “Message passing neural PDE solvers”. ICLR, 2022.

[4] Pfaff, Tobias, et al. "Learning mesh-based simulation with graph networks." ICLR, 2020.

[5] Linkerhägner, Jonas, et al. "Grounding Graph Network Simulators using Physical Sensor Observations." ICLR, 2023.

[6] Freymuth, Niklas, et al. "Swarm reinforcement learning for adaptive mesh refinement." NeurIPS, 2023.

did you consider the possibility of conditioning your approach on a user input such as a picture/mask or a specific mesh annotation to enforce -- for instance -- mesh refinement (or simplification) in a user-defined area?

We thank the reviewer for the question and suggestion. The current work does not consider user inputs during runtime, and instead relies on the quality of the expert meshes that the model is trained on.

However, AMBER works by predicting a series of sizing fields, which are scalar functions on the given domain. To integrate user input, one could simply manipulate this sizing field in user-defined regions, e.g., by interpolating between the user’s preferences and AMBER’s suggested sizing field. We show in Figure 4 that AMBER can generate meshes with different numbers of elements by scaling all predictions with a single scalar. To adapt this to user preferences, one could derive a scaling term for each region of the mesh, or even each mesh vertex, from the user annotations.

Figure 4 is somewhat hard to read

We would like to thank the reviewer for pointing this out and will improve the figure and the extended Figure 11 in the appendix in the revised version of the paper.

We hope that our clarifications, especially regarding the non-archival workshop paper posted by the reviewer, address the concerns raised. If there are any remaining questions, we encourage the reviewer to reach out to us during the discussion for further clarification.

Dear Reviewer,

Thank you once again for your thoughtful and constructive feedback.

We hope our responses have addressed your concerns. Given the limited discussion period, we would be grateful if you could briefly confirm whether any issues, in particular regarding the workshop paper you mentioned, remain unresolved. We would welcome the opportunity to address remaining concerns and incorporate the necessary improvements in the revision.

Thank you for your consideration and support.

We thank the reviewer for their detailed and positive review, especially for highlighting the rigour of our experimental setup. In the following, we will briefly address the individual questions and concerns raised.

The current formulation cannot express anisotropic element stretching, a common requirement near boundary layers and shock fronts.

We agree that anisotropic meshing is an important property for adaptive mesh generation approaches. While extending AMBER to anisotropic meshes is out of scope for this work, doing so should be relatively straightforward. Instead of using a frontal Delaunay algorithm for meshing, we would need to use an anisotropic mesh generation algorithm, such as BAMG, which is readily implemented in gmsh. AMBER then needs to provide a tensor instead of a scalar field, which can be realised by adapting its output dimension per vertex and making its GNN architecture equivariant, similar to [1]. We leave this as an interesting avenue for future work.

[1] Bekkers, Erik J., et al. "Fast, Expressive SE(n) Equivariant Networks through Weight-Sharing in Position-Orientation Space." 2024, ICLR

Because GraphMesh and ASMR run only on Poisson, the cross-dataset comparison relies mainly on the authors’ Image baseline.

We fully agree that broader baseline coverage would strengthen the comparison. However, existing methods are constrained to specific settings. For example, GraphMesh only works on polygonal domains and ASMR ties its refinement to an underlying FEM, so they cannot be applied to the full range of tasks supported by AMBER. To still provide meaningful comparisons, we extended the image baseline to 3D CNNs for 3D tasks, introduced Image (Var.) as a more optimized image-based approach, and included AMBER (1‑Step) as a general-purpose GNN-based one-step mesh generation method. We additionally provide example meshes in Appendix I for a qualitative comparison to other methods and the expert.

Only Poisson tasks include an FEM error indicator, while the other five datasets are judged purely on geometric distance.

Most of our datasets only consider expert meshes rather than any specific underlying PDE, and therefore no FEM error indicator is available. These meshes reflect practical engineering scenarios, where the same adaptive mesh may serve multiple downstream simulations without being tied to a single scenario. For example, Console meshes may be used for various stress tests, and Airfoil for different kinds of fluid flow simulations.

For the two tasks that do have an associated FEM, i.e., Laplace and Poisson, we report FEM error indicator norms in the table below. We report the (hard) version of Poisson as it is the most challenging, and also provide the number of elements and the Density-Aware Chamfer Distance (DCD) to the expert mesh. These metrics correspond to Figures 4 and 3 of the main paper, respectively. Values are reported as mean and twice the standard error over 5 seeds. For reference, we also include the error indicator norm and element count of the expert heuristic. All statistics are computed on the test set, while Table 2 in Appendix C reports expert statistics on the training set.

These new results show a high correlation between the error indicator norm and the DCD, suggesting that expert similarity is a good indicator for downstream performance. AMBER achieves a significantly lower FEM error indicator norm than the baselines while remaining close to the expert’s geometry and element budget. AMBER’s strong performance on both FEM-associated datasets, combined with the correlation between error indicator and DCD, indicates that AMBER meshes would likely perform similarly well on different downstream simulations on the other datasets.

Have you tried pre-training on one dataset and fine-tuning on another, or training a single model on all six datasets?

We ran additional experiments on a dataset combining Poisson (hard) Laplace, and Airfoil. The experiment uses the same model- and hyperparameters as all other AMBER experiments in the paper, and simply concatenates the 20 training meshes of all tasks into a total of 60 expert meshes for training. For the node features, we additionally one-hot encode the task and zero out task-specific features that are not available for some tasks. We use a shared replay buffer and do not weight meshes from the datasets. The table below shows the mean and two times standard error of the DCD for this Mixed setup.

We find that there is no significant difference in performance to training individual models, suggesting that AMBER can straightforwardly be applied to datasets comprising multiple different geometry families and meshing strategies. These results open up interesting avenues for future work, such as training a general-purpose foundation model for mesh generation.

What fraction of wall-clock time is spent inside Gmsh vs. the GNN forward pass?

Each AMBER iteration consists of a creating a graph, adding this to a hierarchical graph, forwarding the result through the MPN model, and then generating the next mesh from the predicted sizing field. The fraction of time that each step takes depends on the size of the created mesh. We show results for Poisson (easy) and Poisson (hard) in the tables below.

As meshes become bigger, the graph generation and model forward scale linearly with the size of the mesh, while the mesh generation scales in O(N log N). Since AMBER acts on a series of coarse intermediate meshes, the last generation step is by far the most expensive. A similar generation step is also needed for the one-shot baselines.

How does performance change for T=1,2,4 in both training and inference?

We thank the reviewer for the insightful question. We ran five AMBER with 1-4 mesh generation steps for five seeds on the datasets that we used for the extended results in Appendix G, i.e., Laplace, Beam and Console. We report the DCD in the table below.

The results indicate that as few as two mesh generation steps are sufficient, although three steps perform slightly better. Adding an additional fourth step does not generally improve performance. Note that the MPN’s prediction is independent of the step, and that a model trained on, e.g., four steps can also be evaluated for only two steps, potentially at slight degradation of performance because of some irrelevant data in the training replay buffer.

We hope that our clarifications and newly provided results address the concerns raised. If there are further questions about the paper, we encourage the reviewer to reach out to us during the discussion for further clarification. We also want to thank the reviewer again for suggesting the above experiments, and will include them and their results in the revised paper.

We thank the reviewer for their thorough review and for acknowledging the comprehensive evaluation on our datasets. We address the raised questions below.

It would be helpful to report how the different human experts refining and heuristic mesh quality differs.

We agree on the need to clarify mesh generation and quality. Appendix C details each dataset, and Table 1 summarizes the process. Each dataset uses human or heuristic meshes with strategies tailored to their applications. Poisson and Laplace apply an iterative heuristic based on an estimated FEM error. The other tasks have no single governing PDE associated with them, so their meshes are adapted for practical scenarios where one high‑quality mesh serves multiple simulations. For example, Console considers stress tests and thus refines around inner radii and bends, while Airfoil refines around the airfoil center. We will update the main paper to clarify this relationship.

The lack of experiments on cross-dataset generalization is a missed opportunity […] Is it feasible to train one AMBER model across multiple datasets or a very broad distribution of geometries? […]

We agree with the reviewer that training a single model across multiple datasets is an important experiment. We have now additionally trained an AMBER model using the combined training data of Poisson (hard), Laplace and Airfoil. We use the same experimental setup as in the paper. We append a one‑hot task indicator to the vertex features and zero unused dataset‑specific features. We use a shared replay buffer and do not weight the datasets. The markdown table below presents the Density-Aware Chamfer Distance (DCD) to the expert meshes, which is the metric used in Figure 3. We compare this new Mixed setup to the previous per-task AMBER and report mean and two times standard error across five seeds.

We observe no significant difference from training per‑task models, indicating that AMBER applies directly to datasets spanning multiple geometry families and meshing strategies. We plan to explore broader generalization in future work.

The paper doesn’t explore how the method might perform if the expert examples are suboptimal or inconsistent, or how many expert examples are needed.

AMBER is a supervised approach and thus assumes that the provided meshes are i.i.d. and optimal. It therefore imitates the given data and produces near‑optimal meshes when the data is optimal. Handling imperfect or inconsistent meshes is an interesting direction but beyond this paper’s scope.

Table 10 in Appendix H.4 reports results for more and fewer expert meshes on Laplace. We further evaluate the DCD across five seeds for 5, 10, 15, and 20 training meshes on Laplace, Beam and Console in the table below.

AMBER benefits from more data, but yields accurate adaptive meshes from only 5 training meshes, still performing on par with or better than the best baselines of Figure 3, which are trained on 20 meshes.

Method should directly evaluate simulation accuracy on the more complex 3D tasks and not just the simple Poisson example.

We thank the reviewer for suggesting more FEM evaluations. While most tasks have no concrete PDE associated with them, as mentioned above, we do simulate for Laplace and Poisson.

The tables below show the error indicator norm of the simulation alongside DCD and element count across five seeds for AMBER and different baselines. We provide expert statistics on the test set for reference.

The error indicator norm strongly correlates with DCD, which measures expert similarity, across methods and tasks. This indicates that expert similarity is a good proxy for downstream simulation quality. AMBER consistently attains a lower FEM error indicator norm than baselines while closely matching the expert’s geometry and element budget. Its superior performance and the error–DCD correlation suggest AMBER meshes would perform well in downstream simulation.

Discuss runtime or memory costs as mesh size becomes larger. […] What are the runtime and memory implications of AMBER compared to traditional adaptive meshing?

AMBER uses an MPN with runtime and memory costs linear in mesh size. Each AMBER step builds a graph, integrates it hierarchically, forwards through the MPN, and generates the next mesh from the predicted sizing field. The mesh generation step scales in O(N log N) and dominates cost. Since AMBER acts on coarse intermediate meshes, most of this cost incurs at the last generation step, which is also needed for all other methods. We report detailed AMBER runtimes for Poisson (easy/hard) in the table below to show how runtime costs shift for different mesh sizes.

Graph-related operations require linear memory cost. AMBER’s iterative process acts on coarser intermediate meshes, and the MPN never needs to process the final mesh. During evaluation, intermediate meshes with >100,000 elements fit on a consumer-grade NVIDIA 3090 GPU, allowing for potentially much finer meshes depending on the application.

The paper could discuss the sensitivity of the method to the initial mesh or the number of refinement steps (fixed or adaptive?)

We thank the review for the suggestion to discuss the sensitivity to the initial mesh. We use 3 mesh generation steps for all experiments for AMBER, and compare to a AMBER (1-step) baseline that uses only one step.

We tested the sensitivity to the initial mesh for AMBER and AMBER (1-Step) on Laplace. The table below shows DCD over five seeds for different maximum volumes of the initial mesh elements. The * designates the resolution chosen in the paper. The resolution of AMBER (1-step) was tuned to be optimal while keeping the initial mesh smaller than the expert mesh.

AMBER is robust to initial mesh size, whereas AMBER (1‑Step) requires tuning.

We additionally ran experiments on two and four mesh generation steps on Laplace, Beam and Console across five seeds, and provide the results in the table below.

AMBER performs well with two steps, improves slightly with three, and shows no gain beyond that, though additional steps may help for larger geometries.

An analysis of how long it takes to generate a mesh with AMBER (for a given number of elements) vs. a heuristic or an expert doing it manually would be very informative.

The time to generate an expert mesh depends on the underlying task and the type of expert. For Console and Mold, our human experts took 15-20 minutes per mesh. In contrast, AMBER generates a 3D mesh in <5 seconds. The table below additionally measures runtimes for AMBER and the expert heuristic on Poisson.

We find that Amber has a relatively high overhead for small meshes, but becomes significantly faster than the iterative expert heuristic as meshes become larger.

We thank the reviewer for these suggestions and hope that we addressed all concerns raised. We will include the new results in the revised paper and welcome further questions in the discussion phase.

Dear Reviewer,

Thank you again for your thoughtful and constructive feedback. We truly appreciate the time and effort you have invested in reviewing our work.

We hope our responses have fully addressed your concerns. Given the limited discussion period, we would be very grateful if you could briefly confirm whether our replies resolve the issues you raised. Should any concerns remain or if you have further suggestions, we would welcome the chance to address them and improve the paper accordingly in the revision.

Thank you for your consideration and support.