Add `verbose` kwarg to `assemble_hmat` to potentially silence the `@info` on thread number.

[cgeoga]

Hi Luiz--

This is a very simple PR to give users the option to turn off the @info on assembly information. I gather you assemble a matrix once and use it many times, but I often assemble a new matrix for every application and end up building a lot, so that is a lot of redundant print output.

If you don't like this, perhaps I could tweak the PR to at least to @info "Assembling [...]" maxlog=1, so that it only prints once per session?

Great package. Definitely my go-to for a good fast matvec.

[codecov[bot]]

Codecov Report

Merging #30 (9adc1ed) into main (2619f7c) will not change coverage. The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main      #30   +/-   ##
=======================================
  Coverage   71.60%   71.60%           
=======================================
  Files          15       15           
  Lines        1729     1729           
=======================================
  Hits         1238     1238           
  Misses        491      491           

Files	Coverage Δ
src/hmatrix.jl	67.01% <100.00%> (ø)

[maltezfaria]

Hi Chris,

Thanks for the PR.

I agree that printing the number of threads is not helpful if you build several matrices, which could clutter your logging. In principle, I am fine with this option (could you also extend the docstring to document the option in that case?). I think, in the long term, HMatrices should provide better diagnostics and verbosity levels, but I have not found the time to work on this package lately 😓

Alternatively, something that I found useful when using other packages, is to redirect their logging to some place I can control. For instance, you can use with_logging together with NullLogger to simply ignore logging messages:

using Logging
H = with_logger(NullLogger())
    # do stuff, like assembling custom `ClusterTree`s, etc
    assemble_hmatrix(...)
end

The advantage of the solution above is that you could also redirect the log info of HMatrices to e.g. a file for later inspection.

Let me know if you still think the PR is useful, or if the Logging solution above integrates well with your workflow (it is a bit more verbose than simply passing a kwarg to the HMatrix constructor, but it is also more flexible).

[maltezfaria]

@cgeoga I am making some (major) changes to the library, and will probably remove the @info logging anyway in the next release.

In the meantime does the suggestion above, of using Logging, help resolve your issue?