HierBEM: A 3D Galerkin BEM library based on deal.II

[Jihuan Tian]

Hello everyone!

My name is Jihuan Tian, an independent researcher in Shanghai, China.

I’ve developed HierBEM, a 3D Galerkin boundary element method (BEM) library written in C++. Built on deal.II, HierBEM uses hierarchical matrices for near log-linear complexity. The numerical quadrature is accelerated by CUDA. I hope HierBEM can be a nice supplement to deal.II with its capability of handling open domains and directly solving physical fields on surfaces with a higher accuracy than FEM.

For more information about HierBEM, please visit the following links:

• Technical features
• Several examples with introduction of math theory and explanation of source code
• GitHub repository
• Documentation in Doxygen

Feedback and thoughts are very welcome!

[Abbas Ballout]

Seems cool. 
Couldn't build Hier because I don't have Cuda configured yet. 
This cmake *might* be useful for you if you are configuring with julia: 
https://github.com/JuliaInterop/libcxxwrap-julia/blob/main/FindJulia.cmake

Abbas

[Jihuan Tian]

Hello Abbas,

Thank you for providing me with the file FindJulia.cmake!

The reason for why CUDA is mandatory in HierBEM is that the numerical quadrature (Sauter quadrature) for double integrals (with singularities) in Galerkin BEM is much more computation intensive than the usually adopted Gauss quadrature for single integrals in FEM.

Take discretization of the hypersingular boundary integral operator as an example. For a double integral on a pair of same quadrangles, the order of the Sauter quadrature should be at least 5. Meanwhile, the 4D integration domain is split into 8 parts. Then the total number of quadrature points is 5^4*8=5000. In comparison, for integration on a hexahedra in FEM, Gauss quadrature of order 3 is usually enough and the total number of quadrature points is only 64. Moreover, the integrand function in Galerkin BEM is more complicated than that in FEM.

Therefore, HierBEM uses hardware acceleration to make the performance of Galerkin BEM tolerable for engineering cases.

Jihuan

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "deal.II User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dealii/T_3LCXoVRA0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dealii+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dealii/a025f9f5-8748-4a8c-94f9-19cfa4fa1a9en%40googlegroups.com.

[Wolfgang Bangerth]

Hi Jihuan:
this is pretty amazing!

> I’ve developed HierBEM, a 3D Galerkin boundary element method (BEM)
> library written in C++. Built on deal.II, HierBEM uses hierarchical
> matrices for near log-linear complexity. The numerical quadrature is
> accelerated by CUDA. I hope HierBEM can be a nice supplement to deal.II
> with its capability of handling open domains and directly solving
> physical fields on surfaces with a higher accuracy than FEM.

First, would you like us to visit HierBEM here?
https://dealii.org/gallery_applications/applications/

Second, are there parts of HierBEM that you think might be of broader
interest and that you would like to contribute to deal.II itself?
Looking at your list of features, I wonder whether for example these
things might be of sufficient interest to others:
* your complex-valued CG/GMRES
* various H-matrix algebra pieces you list under your "Features"
* (some of) the things you currently have in LAPACKFullMatrixExt
* the TableBase::data() function
* many of your tool functions
* classes such as ClusterTree
If some of this became part of deal.II you would also not have to
support that code yourself any more.

In general, looking through your code, it is really nice to see how well
you document everything!

Best
Wolfgang

[Jihuan Tian]

Hello Prof. Wolfgang,

Thanks for your reply and recognition! The deal.II project sets an excellent example in terms of code organization and documentation. It has been a major inspiration for my project.

Sure, it's my pleasure that you visit HierBEM from deal.II applications page.

I absolutely agree with your suggestions about contributing HierBEM's underlying data structures and functions to deal.II. With the following things, I think deal.II users can quickly build their own BEM or BEM/FEM coupled applications without bothering with low level technical details:

• Cluster tree
• Block cluster tree
• H-matrix
• BEM function space
• BEM bilinear form
• Operator preconditioners based on dual mesh
• Preconditioners based on H-matrix Cholesky or LU factorizations
• Complex valued iterative solvers
• All related tool functions which are used by the above facilities.

In the class LAPACKFullMatrixExt, I've encapsulated and added more LAPACK functions, mainly used for SVD, matrix/vector multiplication when the matrix is symmetric or Hermite symmetric, etc. I hope these can be directly merged into deal.II's class LAPACKFullMatrix, so that there will be only one class dealing with LAPACK matrices.

For how to organize these code into deal.II, I would like to hear your opinions.

-- 
Best regards!

Yours sincerely,
Jihuan Tian

[Wolfgang Bangerth]

On 12/18/25 21:11, Jihuan Tian wrote:
> Thanks for your reply and recognition! The deal.II project sets an excellent
> example in terms of code organization and documentation. It has been a major
> inspiration for my project.
>
> Sure, it's my pleasure that you visit HierBEM from deal.II applications page.
>
> I absolutely agree with your suggestions about contributing HierBEM's
> underlying data structures and functions to deal.II. With the following
> things, I think deal.II users can quickly build their own BEM or BEM/FEM
> coupled applications without bothering with low level technical details:
>

> * Cluster tree
> * Block cluster tree
> * H-matrix
> * BEM function space
> * BEM bilinear form
> * Operator preconditioners based on dual mesh
> * Preconditioners based on H-matrix Cholesky or LU factorizations
> * Complex valued iterative solvers
> * All related tool functions which are used by the above facilities.

>
> In the class LAPACKFullMatrixExt, I've encapsulated and added more LAPACK
> functions, mainly used for SVD, matrix/vector multiplication when the matrix
> is symmetric or Hermite symmetric, etc. I hope these can be directly merged
> into deal.II's class LAPACKFullMatrix, so that there will be only one class
> dealing with LAPACK matrices.
>
> For how to organize these code into deal.II, I would like to hear your opinions.

Jihuan:
I think the general recommendation is always "make it into small,
self-contained patches". Start with the simple ones -- say the LAPACK
extensions or the complex-valued solvers. I think these should be relatively
easy to package into pull requests, and it should be straight-forward to
create tests for as well. I think you'll learn from these smaller pull
requests what we tend to look for, and it'll make it easier later on for you
to foresee what we will likely ask for in the larger pieces of functionality.

In any case, like I said, I think it would be fantastic to have even small
parts of this in the library. You've written a lot of interesting
functionality, and it would be fantastic to see that available to the bigger
community!

Best
Wolfgang

[Jihuan Tian]

Hello Prof. Wolfgang,

Thanks for your suggestions! I'll start the integration in an
incremental and manageable way like you said.

Happy new year!

[Jihuan Tian]

Hello Prof. Wolfgang,

Thanks for your suggestions! I'll start the integration in an
incremental and manageable way like you said.

Happy new year!

[Jihuan Tian]

Hello Prof. Wolfgang,

Thanks for your suggestions! I'll start the integration in an
incremental and manageable way like you said.

Happy new year!