It is good to see more numerical simulations and I will follow your progress with interest.
ABEC uses flat zero-order elements which are the least accurate requiring higher numbers of elements to achieve a given level of accuracy but they are relatively easy to program and require the least computer resources per element. Generally where you will need to increase resolution in order to reasonably specify the problem with flat triangles are things like the tweeter surrounds and lips. For example, it is well known that diffraction from a non-recessed tweeter will create small but audible differences. This requires resolving with flat triangles if the simulation is to be accurate.
For acoustic BEM simulations the constraints on element size don't work quite like that. They have something like a Nyquist criteria of two elements per wavelength and if violated will produce nonsensical random garbage. Below this hard limit increasing the element density will increase accuracy. A common rule of thumb used by commercial codes is 6 elements per wavelength but this is more for higher order elements.
ABEC uses flat zero-order elements which are the least accurate requiring higher numbers of elements to achieve a given level of accuracy but they are relatively easy to program and require the least computer resources per element. Generally where you will need to increase resolution in order to reasonably specify the problem with flat triangles are things like the tweeter surrounds and lips. For example, it is well known that diffraction from a non-recessed tweeter will create small but audible differences. This requires resolving with flat triangles if the simulation is to be accurate.
Thanks for following along 🙂 BEM is a very useful tool and ABEC/ AKABAK is the most accessible to the diyer. There isn't a huge amount of guidance on it's use so I thought I would try and shed some light on what little I have been able to do so far.
According to the ABEC help file the Edge length should be at a minimum 1/2 x C / Mesh Frequency, which I have taken to be half the speed of sound divided by the highest frequency of interest. Which for the 12KHz in my sims works out to be 14.3mm. Which is why I have stuck to 10mm as the maximum on the front baffle and that seems to have been sufficient. The waveguide goes down to 5mm at the driver (throat) end as without sufficient resolution there the waveguide contour is not preserved.
So I think your comments are a more informed expansion but not really at odds with what I said?
According to the ABEC help file the Edge length should be at a minimum 1/2 x C / Mesh Frequency, which I have taken to be half the speed of sound divided by the highest frequency of interest. Which for the 12KHz in my sims works out to be 14.3mm. Which is why I have stuck to 10mm as the maximum on the front baffle and that seems to have been sufficient. The waveguide goes down to 5mm at the driver (throat) end as without sufficient resolution there the waveguide contour is not preserved.
So I think your comments are a more informed expansion but not really at odds with what I said?
The limit on mesh size quoted in the ABEC manual is to avoid predicting garbage it is not the limit required to reduce the discretization errors to an acceptable level for a reliable simulation. I was trying to point out that your current simulations will contain significant discretization errors. Perhaps this doesn't matter too much at this stage when trying to get on top of things but if it all comes together and the simulations start to look useful then it will become more important.
It's good to have this pointed out as an issue. Can you can offer a way to tell what the problems might be and how much greater resolution will be needed to make them non significant?
I would like to make the simulations as realistic as possible but I am already approaching a point of diminishing returns with resolution in ABEC. With the code you are used to you can probably just use whatever resolution you need and use a faster computer to crunch through it.
In my experience with ABEC beyond 4,000 elements the solve time gets out of hand quickly and 10,000 elements seems to be a practical limit before there will never be a solution found in a realistic time frame. My laptop is faster than my server but I don't like to leave it on overnight that often so it tends to be used for less than 2 hour sims. I have no other need for a monster workstation and I'm not convinced it would be a solution even if I had one.
If I expand the model to cover a complete baffle and woofer (which is in the works) then I am limited to half symmetry and the problem gets twice as bad.
I personally think the simulations are quite useful as they are, I have had the benefit of seeing more of them in various different stages to know that these current ones look much more acceptable.
There have been a few constructions made already where the results from ABEC at similar resolution to this matched reality well enough which gives me hope I'm not chasing ghosts.
Hi Fluid, its moving along nicely. The VCAD import looks like a useful tool for DI.
One thing that should be mentioned is that you are using Fusion and I am using FreeCad for the CAD work. FreeCad can easily capture the horn mouth outline to create a polyline wire with exactly all the edges and vertices. Your Fusion flow is merging multiple straight lines to form a single longer line (missing intermediate vertices). There may be someone familiar with Fusion that knows how to avoid this merge and preserve the polyline.
Depends on the tool flow used. FreeCad appears to be easier than Fusion (I use FreeCad). Since the parts are meshed at different times the only way to transfer the vertices position is by capturing the exact mouth wire (polyline).
This also depends. A horn mounted in an IB must raise the subdomain mouth interface because the mouth is in the IB. ABEC's author gives examples of both horns with flat mouth interface (finite baffle) and raised mouth interface (IB mount). In my models, the horn's subdomain ends at the horn mouth apex. When the horn's subdomain is solved it should only include the horn (hence flat mouth@apex). The wavefront in free space, just outside the horn mouth, might be effected by something on the outside (ie. finite baffle). So you don't want this near mouth area solved before finding what's actually near it. I try to keep the physical boundary and subdomain interface boundary consistent.
That is a key goal, you don't require the same resolution everywhere (ie. back of the case). It's also why it's so important to exactly capture the existing meshed component's (horn mouth) vertices. It allows subsequent meshing of cad files to properly align to those pre-existing vertices.
I use the general ABEC guidelines as a start for items especially near the drive source. Then you can look at your results to see if they are well behaved or just disintegrate beyond some frequency. If there's a problem you'll probably re-mesh a bit finer to see if you're improving things. This is what @fluid has done. At some point it looks well behaved and you call it done.
How would you know when the mesh is fine enough to have an acceptable level of discretization errors. ? Since these are entire speakers, it's not really practical to use the same resolution everywhere.
Thanks for your input Don, without your help I think I would have put this in the too hard box and moved on 😉
There are no controls in the extrude command that allow the polyline to remain. Using another command might be able to accomplish that but I think maybe not. If anyone has any suggestions I am open to try them.
I am still convinced in this circumstance that it does not matter if the baffle and interface are meshed purely at 10mm as this forces the vertices to the correct points. I appreciate that this will not work in every situation and the principal is an important one to be aware of.
Fusion does capture the exact outline through the mesh to BRep conversion it just refuses to keep the single line cuts where they form a straight line with the extrude command. So if that could be solved Fusion would be very easy.
CAD programs are so different in terminology and layout that once you've learned one learning another can be frustrating.
This is the point we seem to disagree on. I don't think the above is true. I just see no reason for that. Boundaries of subdomain interfaces (or the number of subdomains used) are really arbitrary, there are no physical constraints like that. Everything should get solved the same no matter the shape(s). The only constraint in the case of an IB is that everything in the exterior domain must be in front of the plane, that's about all. (What's still not completely clear to me is whether it can be exactly in the plane or not - to be on the safe side I make each element to be on the positive coordinates but I'm not sure it is really necessary.)
Last edited:
In your case given the use of low accuracy elements, the more interesting things occurring at higher frequencies and limited computing resources I suspect there is no chance of achieving "grid independent" solutions in 3D. That is, ones where refining the grid significantly (i.e. halving element dimensions) doesn't change the predicted solution significantly. In the real world with complex engineering parts this tends to be the usual case not the unusual one. The task for an experienced engineer then becomes estimating the level present and understanding how it tends to change the simulated solution away from the wanted resolved solution. This usually requires a separate study where the discretization error is evaluated both globally and locally for a set of simulations where only the grid resolution is varied and everything else is held the same.
Whether a study of the discretization errors is worthwhile depends on what you want to get from the simulations and how reliable that needs to be. It is also influenced by the size of the other types of error present (imprecise boundary conditions, imprecise material properties and the assumptions made by the governing equations). For example, a soft dome will not move as a rigid piston leading to imprecise boundary conditions, the dissipation from foam used to damp horn resonances is not included in the governing equations,...
I suspect at this relatively early stage the important thing is to avoid the assumption that the simulations are accurate which is a common one made by the inexperienced outside formal training. All simulations are inaccurate by definition and the trick is to understand what inaccuracies are present and what they are doing.
I can only say that in these simulations using a flat interface at the same resolution as the baffle and the horn at the point of intersection gave the best results with the least number of odd ripples and spikes that indicate something is going wrong. I started with the interface from Ath but it did not work as well at higher frequencies.
That is quite the put down.
I resemble the second half of the remark although somehow I managed to avoid the first part.
I believe you. With free standing simulations I use flat (or slightly curved) interfaces as well, with good results. But I think this is far more influenced by the actual mesh resolution than by the bounday shape itself. Anyway, I also agree with you that sometimes strange things happen and changing the shape of the interface has an effect - that's a fact. Fortunately, it doesn't matter that much in the end as we are obviously all able to get results that look quite reliable.
I have to say I really enjoy using ABEC now. I like the scripting approach that allows to automate it a lot (a pity it changed to AKABAK where the scripts are gone, it seems (?)).
If you feel a statement of fact is a put down then it is perhaps best l refrain from posting further in your thread. It may be for the best since last time I helped someone on this forum perform a grid independence study they got a bit irritated by the required effort and care which is why I didn't explain directly.
From my experience, he has already reached that point and his results are good enough by now.
Not sure I should still be contributing but I would suggest asking yourself what knowledge you actually possess about the size of the discretization errors in the OPs solutions. How have you estimated the size and the effect on the solution?
The rule of thumb widely used by engineers is "6 elements per wavelength". Type it into google and look at some of the results. Many will be closed papers you probably can't access but a fair few will be open. The OP is using coarser grids than this despite using the least accurate element (flat constant triangle) which almost certainly wouldn't be optimal for his case if there was an option to use higher order elements typically present in larger industrial codes.
I am not suggesting throw it all away because it's a disaster but being a bit less confident and a bit more reasoned about the level of accuracy. It's good stuff but it won't be reliable until the errors in the simulation are understood and their size estimated. Obviously this is more important in industry where potentially costly decisions can be made based on the results of simulations but it is still has relevance to hobby simulations.
All I can say is that I've made probably hundreds of simulations of similar objects with various levels of mesh densities and I'm quite confident that can recognize the moment at which further reduction of element sizes doesn't bring any new useful information for the purpose of the analysis. Changing mesh densities to various levels was one of the first things I tried when I started playing with BEM. That's what I mean when I say "from my experience" here.
Thanks for the clarification which should help the OP and others determine the basis for the confidence. I would again suggest typing "6 elements per wavelength" into google and reading a couple of papers to get a feel for the subject. The first hit for example (I have only read the conclusions being familiar with the subject) is suggesting 10-15% error using 6 elements per wavelength and recommends 2nd order or higher elements in order to converge the error swiftly with resolution (higher order elements reduce the error more when an element is divided compared to low order elements).
You seem to completely ignore the nature of the problem here. We are not talking in general, we are talking about waveguides in baffles, driven by small apertures at the throats. It actually surprises me that someone as experienced as you, apparently, doesn't acknowledge the confidence we have after seeing the results already presented. I'm sure I'm not the only one here who has spent considerable amount of time simulating horns and who already got the idea - it just won't get any significantly better overall. That's about all I want to add to this debate.