Skip to content

Referee reports # 1, CMAME Sep. 2016 (decision: reject) #19

Description

@labarba

Revised paper submitted to CMAME on 15 March 2016 — Decision: Reject

Editor comments

I regret to inform you that the reviewers of your manuscript have advised against publication, and I must therefore decline it. For your guidance, the reviewers' comments are included below.

Referee # 1 comments

Summary of the problem being solved. This paper considers boundary element method (BEM) formulations of certain problems, namely, Laplace problems and Stokes flow problems that arise in blood flow simulation. Computationally, this formulation requires solving a large dense linear system, most typically solved by Krylov subspace-based iterative methods, of which this paper considers GMRES. The usual performance bottleneck of a Krylov subspace solver is a matrix-vector product ("matvec"). In the target applications, the matrix is special: its entries are K(x, y) evaluated at pairs of points (x, y), where K(x, y) decays rapidly with the distance between x and y. In this case, one may implement fast but approximate matrix-vector products. A classical approach for the target problems is the fast multipole method (FMM) of Greengard & Rokhlin (mid-80s). The FMM has the feature that one may control tradeoff performance and accuracy via a parameter, the so-called
degree of the multipole expansion, denoted by $p$ and roughly corresponding to the order of truncation in a series expansion. (Higher values of $p$ are more accurate but slower.)

With this background, the specific problem this paper tackles is to study the interaction between $p$ and the outer GMRES solver.

Technical contribution. The paper develops an integrated GMRES+FMM method for its target problems that exploits a clever and nontrivial observation from the theory of inexact Krylov methods: as the iterations proceed, the matvec can actually become progressively less accurate without harming the convergence rate of the solver. The idea of the paper is to decrease $p$ as the iterations proceed.

From this idea, the paper studies several model problems to show that it can work and characterizes the time and accuracy tradeoffs, with some interesting FMM-specific observations along the way.

Summary evaluation and recommendation. Though there is a lot of "setup," the idea is both clever and simple, meaning it is likely to work and have an impact. The results are a good first "proof-of-concept" of the feasibility of the proposed technique. The suggested edits that appear below are all minor. As such, I recommend the paper be accepted with just minor revisions.

One major strength of the paper, beyond the idea and its demonstration, is the effort the authors made toward making the results reproducible, including an open-source code repository with sufficient infrastructure to recompute the results and even make the plots. Cool!

  • [ ] 1. One major weakness to me is that the procedure (or schedule) for relaxing $p$ is is not described with enough precision. Section 2.6 sketches a procedure with reference to equations (17)-(19), but I did not find this description sufficiently algorithmic to code up myself or use to interpret what is happening in the results, e.g., in Figure 6. (I suppose the code that accompanies the paper is that algorithmic description. However, I think the paper should also summarize it in a way that does not require referring to that code.)

Detailed comments for the authors. My remaining issues, detailed below, are fairly minor and mostly a matter of editing or questions to consider clarifying in a revision.

  • 2. Section 2.5, near equation (14): $y_c$ should be defined explicitly.
  • 3. Below equation (14), "… resulting in an octree structure." I assume this octree is adaptive, since it only needs to represent points at the surface of the objects? (Just saying "adaptive octree" would be sufficient here.)
  • 4. Section 2.6, equation (17): Is it really the case that $\epsilon_k$ can be as large as 1? In that case, the perturbation is as large as the norm of the operator, which seems surprisingly high.
  • 5. Section 2.6, below equation (16): There is a space missing in the text, "… where $a$ isthe cluster radius …"
  • 6. Various places: I think there is some minor inconsistency in the notation for the number of Gauss points. It is introduced as $K$ (capital-K) but appears in the appendix as $N_k$ and in some figures and results as $k$ (lowercase-k).
  • 7. Section 2.6: As noted in the summary above, the precise procedure for modifying $p$ with respect to equations (17)-(19) is not clear enough to this reviewer.
  • 8. Section 3, Figure 3: The claim of linear scaling in Figure 3 seems unnecessarily qualitative. Rather than using the "eye-norm," which not just fit $N^r$ to the points and report the exponent $r$?
  • 9. Section 3 and 3.1: The results focus immediately on the case of using the FMM to approximate the matrix. For completeness, another quick experiment would be to compare using the exact matrix to the FMM and reporting just the number of iterations in each case. Since the cost of using the exact matrix might be prohibitive due to its quadratic scaling in $N$, just a few cases with "small" values of $N$ (possibly up to $N=10,000$) would be sufficient. The point of such an experiment is to help the reader verify that there is no blow-up in the number of iterations due to approximation.
  • 10. Section 3, Figure 6: How would the residual look if $p$ were fixed at its initial value?
  • 11. Section 3.1, page 10: The paper discusses the relative imbalance of near- and far-field cost. It would be good to show that explicitly, the same way you do later, e.g., Figure 12.
  • 12. Figure 11: In the relaxed scheme, what is the schedule for varying $p$? Is that given by the values listed for $p_{\mathrm{min}}$ in Table 5?
  • 13. Figure 14: Why are the middle tolerances faster than the extremes?
  • 14. Figure 17: Like Figure 14, why do middle values of $N$ require more iterations?

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions