The authors present Matter, a code package written in C++ to simulate the flow and mechanics of granular media using the material point method (MPM). In general, the article is well-written with good English and describes a code package which has clear use cases (for example avalanche research and modelling) and clearly benefits the scientific community. The theoretical foundation is sound, and the chosen computational method suits well the intended uses.

The code itself seems to be well thought out in terms of organization and adheres to good coding practices. The package was easy to set up in Windows and VSCode thanks to the clear instructions, and it was simple to run the included example on granular collapse. I modified the example script for a few different cases and animated the results with the help of the included Python post-processing script. Everything ran smoothly without issues.

For the above reasons I am happy to recommend the paper to be published. I have written down a few minor comments below that I’d like the authors to consider first, however, but feel free to only make those changes which you also feel will improve manuscript.

 - Introduction: Positioning Matter better in the context of existing open source MPM solvers for granular media.

• The authors describe some history of modelling granular matter and a large variety of existing open source MPM solvers, but at the moment it is not entirely clear from the Introduction how Matter differs from the other codes (is this the first code that implements the critical state \mu(I)-rheology model, or for example is the material-induced frictional boundary the main novelty?). The authors state that the existing codes “display a limited availability of constitutive laws and rheologies”, which gives a perfect opportunity to mention how Matter improves on the situation.
• The first two paragraphs of the Introduction, which go through the history of different methods for modelling granular media, could be condensed.
• The authors state that Matter is “lightweight yet computationally efficient”. I don’t doubt the claim, but it should be backed up with reasons for why it is so, or at least what the authors mean by computational efficiency. The current code is implemented using the Eigen library with dense grids which the authors state as a possible limitation for large sparse problems, but apart from using Eigen, which is known to be fast, and parallelization using OpenMP I didn’t find in the article reasons for computational efficiency.

Discussing more specifically the advantages Matter provides compared to existing (open source) codes would, in my opinion, strengthen the paper and the impact of Matter further. Highlighting the differences to other codes would also help the reader to understand in which case would it be beneficial to use Matter over, for example, the sparse-memory-encoding GPU framework described by Chen et al. (2025) that the authors cite.

 - Code validation: The authors have done a set of validation tests against analytical solutions which show expected behaviour. Furthermore, the effect of various particle-grid transfer schemes is shown. These provide confidence in the code, but if there exists an “industry standard” code which implements some relevant constitutive laws and rheologies, a comparison in some simple case between the results of that code and Matter would be useful for further validation (I am not familiar enough with the field to say what the code and example should be). However, the already presented validation tests are sufficient.

 - Paper organization: Section 7 on elasto-viscoplastic models currently seems out of place with regards to the rest of the paper. In my opinion it would be clearer if these models were described with the theory and other models available in the code, before validation and examples.

 - Examples: I would like to see estimates of the compute times for the first two examples as well. There are compute times reported in Table 1 for a case similar to the first example (in Figure 9), but they don’t seem to be the same.

 - The source code: Readability of the code is on a good level, although could always be improved for newcomers to the software, for example by being even more explicit about the variable names (as an example, the names of the different plasticity models in “plasticity.cpp”, such as DPSoft, DPVisc, DPMui, could be given more descriptive names or comments in the code on what they are, even though they are stated in the readme.md). But this is just a minor point, and it probably doesn’t make sense to start changing variable names now.

 - Typos and small changes:

• Eq. (3): exponent of first m should be n+1 instead of n?
• Line 172: Check grammar (“time step is adapted for each time step”)
• Line 178: Check grammar
• Eq. (16): Function Ψ seems to not be defined anywhere?
• Eq. (29): Double check if the exponent of the last ε_p in the right hand side should be n instead of n+1.
• Line 293: Double citation. (After checking the References it seems they should be 2008a and 2008b)
• Line 301: The word “conservative”. Do you mean “conserving”?
• Figure 8: Grid lines would be helpful in assessing the results.

This manuscript introduces Matter, an open-source Material Point Method (MPM) solver designed for modeling granular materials undergoing large deformations. The solver includes support for multiple constitutive models, interpolation functions, and particle-grid transfer schemes, and it proposes a novel Material-Induced Boundary Friction (MIBF) approach for boundary interaction. The accessibility, modularity, and broad applicability of the platform make it a valuable potential contribution to the computational mechanics and geomechanics communities.

While the technical scope is strong, the manuscript would benefit from several improvements in theoretical clarity, structure, and usability. I outline below a series of suggestions that I believe would help the authors strengthen the scientific quality and utility of the paper.

Major Comments

Clarify the finite-strain framework (Lines 5, 118). The solver is described as using a finite-strain elastoplastic formulation, but it does not state explicitly that it adopts the multiplicative decomposition of the deformation gradient. This decomposition is an important modeling choice and should be clearly mentioned, with a reference to Lee (1969) or similar foundational work.

Balance the comparison of MPM vs. SPH (Line 20). The introduction highlights the limitations of Smoothed Particle Hydrodynamics (SPH), including computational cost and difficulty enforcing boundary conditions. These challenges also apply to MPM, especially due to the need for particle-grid mapping and frictional contact handling. A more balanced comparison—either through literature references or brief performance benchmarks—would help contextualize the claimed advantages of MPM.

Discuss the implications of mass lumping (Line 114). The manuscript notes that mass lumping introduces energy dissipation, but this issue deserves further attention. In dynamic granular simulations, this dissipation can significantly impact the overall solution quality. It would be helpful to comment on when this effect becomes significant and whether the solver supports alternatives for better energy conservation.

Check the terminology for time integration schemes (Lines 151, Algorithm 1). The manuscript refers to the integration method as “symplectic Euler,” but the scheme shown is a basic explicit Euler update. Since symplectic integrators are typically semi-implicit and conserve Hamiltonian structure, this terminology seems incorrect. Please revise the description or provide justification if the method does retain symplectic properties.

Elaborate on viscoplastic modeling (Section 2.3). The viscoplastic formulation based on overstress regularization is introduced with minimal context. I recommend providing a bit more background on the motivation for using overstress and how it compares to other rate-dependent formulations. It would also help to clarify why this particular approach was selected.

Reorganize Sections 2.3 and 7 for better flow. Section 7 discusses rheology model selection, which is conceptually tied to Section 2.3. To improve readability, I suggest moving Section 7 earlier in the manuscript or merging it with Section 2.3 so that users get the full modeling picture up front.

Correct the formulation of stress invariant (Equation 34). Equation (34) implies a simplified 2D form of the first stress invariant p, but this formulation is misleading. In plane strain, for example, the out-of-plane stress component is non-zero and needs to be included in the calculation of p. Please revise the equation to reflect this (i.e. just write its definition for 3D stress tensor)

Acknowledge von Mises use in undrained soils (Section 7.1). The manuscript states that von Mises is rarely used for soil modeling. While this is true in general, it is worth noting that von Mises is often used for total stress analysis of undrained clays, especially in simplified or conceptual models. Adding this nuance would give a more accurate picture.

Provide guidance on model selection Although the paper supports various types of rheologies, it lacks sufficient guidance on when practitioners should use each one. A short summary of their strengths and appropriate use cases would be very helpful for users.

Comment on interpolation basis functions. Users can choose between quadratic and cubic B-spline shape functions, but no commentary is provided on the trade-offs. It would be useful to briefly explain this aspect.

Elaborate on velocity transfer schemes. The solver supports PIC, FLIP, APIC, and AFLIP schemes, but the manuscript doesn’t explain their relative advantages at the outset. In particular, AFLIP appears to offer good performance for granular flows. If the older schemes are retained for specific reasons (e.g., simplicity, stability), please clarify when users might choose one over the other.

Verify the MIBF scheme (Section 4.3). The MIBF scheme is a potentially valuable contribution, but there’s no verification of it. I recommend including a simple test case that demonstrates its behavior and compares it against standard boundary treatments.

Use correct terminology for verification and validation (Line 70, Section 5). Most of the results in Section 5 are verification exercises (e.g., convergence and numerical consistency), but the term “validation” is used throughout. Unless there are comparisons with experimental or field data, this should be corrected to “verification.”

Clarify how grain diameter in \mu(I) rheology​ is obtained (Line 415). The \mu(I) model uses an intrinsic grain diameter d_g, but the manuscript doesn’t say how this parameter is estimated or calibrated. Is it based on experimental data or empirical fitting? A sentence or two would help users set this parameter appropriately.

Convergence behavior. No refinement study is presented. I encourage the authors to include a basic convergence test to build confidence in the numerical results.

Minor Comments

• Line 30: Replace “a FEM” with “an FEM.”
• Use “computation time” instead of “compute time” throughout.
• Check the consistency of the vector/tensor notation.