I have only spent a couple of days modelling ATH horns using ABEC/AKABAC etc and it is painful to say the least. 
I have found https://bempp.com/ and it has a few advantages (to me at least).
1. It has a python library - I code every day in python (usually deep learning research/projects) and am happy to spend a little dev time to speed up this process, not to mention python has some advanced plotting libraries that should make a set of standard plots easy to script and generate...
2. It can use your GPU to calculate!!! For me this is HUGE I have multiple mid-high powered consumer grade GPU's and hate the thought of parallelisation being forced into double digit thread counts.
3. It appears to be faster.
4. it is relatively up to date and mature.
5. It is open source
6. If quick enough it may make sense to create some simple range tests / setup solver routines to find optimum values for variables in the ATH script.
7. I like new projects.
I am looking for people to perhaps have a quick look and see if it makes sense. It would be especially cool of someone comfortable with current workflows would be happy to share some designed and results ot hap[py to run some test designs in their workflow to compare results for sanity checking.
Some links here:
https://www.diyaudio.com/community/...r-dml-design-and-analysis.383567/post-7296243
Repo for collecting and sharing my thoughts, code and hopefully for other to contribute if they wish.
I have found https://bempp.com/ and it has a few advantages (to me at least).
1. It has a python library - I code every day in python (usually deep learning research/projects) and am happy to spend a little dev time to speed up this process, not to mention python has some advanced plotting libraries that should make a set of standard plots easy to script and generate...
2. It can use your GPU to calculate!!! For me this is HUGE I have multiple mid-high powered consumer grade GPU's and hate the thought of parallelisation being forced into double digit thread counts.
3. It appears to be faster.
4. it is relatively up to date and mature.
5. It is open source
6. If quick enough it may make sense to create some simple range tests / setup solver routines to find optimum values for variables in the ATH script.
7. I like new projects.
I am looking for people to perhaps have a quick look and see if it makes sense. It would be especially cool of someone comfortable with current workflows would be happy to share some designed and results ot hap[py to run some test designs in their workflow to compare results for sanity checking.
Some links here:
https://www.diyaudio.com/community/...r-dml-design-and-analysis.383567/post-7296243
Repo for collecting and sharing my thoughts, code and hopefully for other to contribute if they wish.
Last edited:
Collection of links for further research:
https://github.com/mscroggs/bempp-acoustic-tutorials
https://bempp.discourse.group/t/ways-to-define-domains-in-msh-files/223
https://github.com/mscroggs/bempp-acoustic-tutorials
https://bempp.discourse.group/t/ways-to-define-domains-in-msh-files/223
The first version of bempp looked hopeful but the rewrite less so. Perhaps it will evolve into something useful for engineering and one or two of the projects suggest this may be happening but the focus is academic publications. For speakers akabak includes some features bempp lacks like the lumped modelling, half space, coupling (though bempp seems to have included something along these lines since I last looked). Please report back on your experiences since it would be useful to know the real world pros and cons compared to akabak, acousto, abem, and other freely available acoustic bem codes.
Hi andy19191,
Thanks for your ideas and thoughts on bempp. Honestly I have been frustrated with the workflow in designing a waveguide/horn and this ideas is really born out of this as my inner voice is screaming at me there must be a better way. I have used ABEC and AKABAK to model from ATH and some other generated meshes. I will usually script anything I have to do twice because if I have to do it twice I am sure I will have to do it again. I will have a look at some of the others you have shared. Are any of these open source projects or have a built in documented API? Everything I have seen so far have very limited automation capabilities and require a substantial amount of repeated input by the user. I am currently forming a plan as how to best enter into this from a place where simple, well characterised models are used to check how bempp is implemented on the model to ensure correct usage. Once proved to be correct ( or close enough) they would be refined into a tutorial. I will start with some basics like planar pistonic movement and adding waveguides etc. If you have any suggestions for some proto projects I would most thankful. Perhaps a spherical radiator in full, half and quarter space is a good one as well.
Thanks for your ideas and thoughts on bempp. Honestly I have been frustrated with the workflow in designing a waveguide/horn and this ideas is really born out of this as my inner voice is screaming at me there must be a better way.
I have used ABEC and AKABAK to model from ATH and some other generated meshes. I will usually script anything I have to do twice because if I have to do it twice I am sure I will have to do it again. I will have a look at some of the others you have shared. Are any of these open source projects or have a built in documented API? Everything I have seen so far have very limited automation capabilities and require a substantial amount of repeated input by the user. I am currently forming a plan as how to best enter into this from a place where simple, well characterised models are used to check how bempp is implemented on the model to ensure correct usage. Once proved to be correct ( or close enough) they would be refined into a tutorial. I will start with some basics like planar pistonic movement and adding waveguides etc. If you have any suggestions for some proto projects I would most thankful. Perhaps a spherical radiator in full, half and quarter space is a good one as well.abem is a python open source project that seems to have gained no traction. It is a copy of existing fortran code into python and C++ which will be a red flag for some. Nonetheless it looks simple and may do much of what you want albeit a bit slowly. Acousto is a larger project that uses text files so easy enough to drive from python with a bit work. Development may have ceased or a version 3.0 may appear sometime but development is not happening in the open and I got no response when enquiring about collaboration. Elmer had what seemed like the most useful BEM code because of all the other activity in acoustics, fluids and structures going on within the project but it failed a basic symmetry tests when I tried it a few years ago. The lack of interest in supporting it put me off getting involved and fixing it and, indeed, it no longer seems to be part of their current package. There are a fair few other BEM codes around some of which might be worth considering though I haven't looked at them.
Testing bempp before using it looks wise to me because it is a research code and likely to be broken at times by enthusiastic students in a hurry. I would suggest testing the boundary conditions needed and that it converges as it should with refinement against an analytic solution or two. BEM codes have a range of issues with handling singularities much of which bempp avoided by being zeroth order (i.e. the lowest accuracy that can work but requiring the finest grids) but perhaps that got addressed in one of the rewrites (I see they seem to have rewritten yet again in rust!). Check behaviour of field point values as they approach the body, behaviour with thin shapes (e.g. phase plugs), how it handles body resonances. I don't know how much attention real world BEM issues receive within the project so checking is likely to be wise. This is an academic research code not a commercial code and priorities are different.
Testing bempp before using it looks wise to me because it is a research code and likely to be broken at times by enthusiastic students in a hurry. I would suggest testing the boundary conditions needed and that it converges as it should with refinement against an analytic solution or two. BEM codes have a range of issues with handling singularities much of which bempp avoided by being zeroth order (i.e. the lowest accuracy that can work but requiring the finest grids) but perhaps that got addressed in one of the rewrites (I see they seem to have rewritten yet again in rust!). Check behaviour of field point values as they approach the body, behaviour with thin shapes (e.g. phase plugs), how it handles body resonances. I don't know how much attention real world BEM issues receive within the project so checking is likely to be wise. This is an academic research code not a commercial code and priorities are different.
Thanks for that round up of some of the projects you have explored.
I spend most of my time working with research code and libraries under heavy development and have found in more recent years these areas have generally headed in good directions as far as backwards compatibility and extensibility. Being manly maintained by a single person can be a red flag though.
Perhaps the most valuable thing to come out of this may be a set of models and solutions to gauge different approaches...
I spend most of my time working with research code and libraries under heavy development and have found in more recent years these areas have generally headed in good directions as far as backwards compatibility and extensibility. Being manly maintained by a single person can be a red flag though.
Perhaps the most valuable thing to come out of this may be a set of models and solutions to gauge different approaches...
I shall refrain from commenting on the pros and cons of what has happened to the bulk of numerical simulation software in recent decades but an alternative to the current restricted commercial windows only backend for the ath activity is likely to be welcome. However, akabak provides more than BEM when it comes to simulating speakers and so bempp or acousto alone isn't going to be a direct replacement in many cases. Also BEM isn't the most appropriate tool for a fair proportion of the acoustics of relevance to speakers.
My first priorities are for modelling horns/waveguides driven by compression drivers. This allows me to simplify by using the following assumptions.
1. Priorities are for modelling horns/waveguides driven by compression drivers
2. Start of the wavefront is planar (spherical can come later).
3. Primary interest is developing/simulating constant directivity horns.
4. Simulations to be done either in free space ( free standing horn) or on an essentially infinite plane (baffle mounted horn).
5. Output id top generate graphs of interest when developing these types of devices i.e. SPL vs freq @ angle.
1. Priorities are for modelling horns/waveguides driven by compression drivers
2. Start of the wavefront is planar (spherical can come later).
3. Primary interest is developing/simulating constant directivity horns.
4. Simulations to be done either in free space ( free standing horn) or on an essentially infinite plane (baffle mounted horn).
5. Output id top generate graphs of interest when developing these types of devices i.e. SPL vs freq @ angle.
Last edited:
If you are going to assume plane waves at the inlet will a 3d simulation provide any reliable information that is not in a 1D simulation like hornresp? I would have expected the usefulness of 3d simulation over 1d ones to lie in things like addressing the details of the throat/phase plug geometry. The flat zeroth order element of most free BEM codes may be at a disadvantage here in requiring higher grid resolution than ones using more appropriate higher order elements.
The Kirchoff-Helmholtz integral on which conventional acoustic BEM is based requires a closed body. Strictly it must be smooth but there is a treatment for edges and most other cases where it doesn't work in practice. BEM is a somewhat temperamental numerical method. An infinite baffle isn't a closed body and so BEM cannot simulate it directly. However, there are infinite baffle analytical solutions for simple shapes to which the external part of a BEM solution over a closed boundary could be coupled. It will be an approximation but it may significantly reduce the required computer time and storage. I believe akabak includes such a treatment (need to check) but it is unlikely other codes like bempp and acousto do (need to check). If you want to use such an approximation you may have to implement it yourself in bempp which is kind of how open source code is intended to work.
The Kirchoff-Helmholtz integral on which conventional acoustic BEM is based requires a closed body. Strictly it must be smooth but there is a treatment for edges and most other cases where it doesn't work in practice. BEM is a somewhat temperamental numerical method. An infinite baffle isn't a closed body and so BEM cannot simulate it directly. However, there are infinite baffle analytical solutions for simple shapes to which the external part of a BEM solution over a closed boundary could be coupled. It will be an approximation but it may significantly reduce the required computer time and storage. I believe akabak includes such a treatment (need to check) but it is unlikely other codes like bempp and acousto do (need to check). If you want to use such an approximation you may have to implement it yourself in bempp which is kind of how open source code is intended to work.
Thanks for the heads up, you obviously have a much deeper knowledge on these things than I do. I believe I am at the stage where I don't even know how much I don't know yet and really appreciate your comments that highlight some of these areas. I am very much starting from an over simplification as I believe that the best path lays with many small successes and failures that are scope limited, it is not my first time developing software in a complex environment with abstract methods and I am looking forward to slamming into the learning curve.
please alos consider this;
https://mesh2hrtf.org/
very fast multipole bem code by Berlin Technical University, inially designed fot hrtf with many elelements but als generally usuable and
"add-ons for Blender for geometry preprocessing and tools for Python and Matlab for post-processing and visualization purposes"
https://mesh2hrtf.org/
very fast multipole bem code by Berlin Technical University, inially designed fot hrtf with many elelements but als generally usuable and
"add-ons for Blender for geometry preprocessing and tools for Python and Matlab for post-processing and visualization purposes"