Acoustic Horn Design – The Easy Way (Ath4)

Jump to Latest
mabat

mabat

Member
Joined 2004
at-horns.eu
Paid Member
Patrick Bateman said:
OK, I figured out what the bug was. It's not due to the "slot.length" parameter. It's due to the "OS.K" parameter.

Basically if you use a formula in it, you'll get holes in your mesh. Here's the offending line:

OS.k = 2.2 - 1.8*cos(2*p)^2
Click to expand...
I can't reproduce it. With your script it works fine on my setup (Ath 4.8, Gmsh 4.6.0). The only problem I see is your dome tweeter definition - something is wrong with the geometry (see the image below, gmsh also reports warnings about that).

Beware that the number of slices (Mesh.LengthSegments = 500) is way too high for ABEC in 3D mode. I assume you use a lower value when generating the ABEC project. Otherwise it generates around 14000 elements and that is most probably too much for ABEC, no matter the power of the PC (for me the upper limit is around 5000 elements to get results in reasonable time).


mesh.PNG
abec-mesh-1.PNG
abec-mesh-3.PNG


-With Mesh.LengthSegments = 100 I get 5061 BEM elements including the tweeter and that should be already manageable.
 
Last edited:
mabat

mabat

Member
Joined 2004
at-horns.eu
Paid Member
One more remark - since the curvature near the throat doesn't change rapidly, you can adjust the z-coordinate step and improve the mesh via the following (changed lines in bold):

Mesh.AngularSegments = 96
Mesh.LengthSegments = 60
Mesh.ThroatResolution = 2.5 ; [mm]
Mesh.InterfaceResolution = 7.0 ; [mm]
Mesh.InterfaceOffset = 5.0 ; [mm]
Mesh.ZMapPoints = 0.3,0.5,0.5,0.95

With this setting it produces 4803 evenly spaced elements which should be just fine. (Probably the InterfaceResolution could be further increased without noticeable loss of accuracy, further decreasing the element count).

mesh-adjusted-2.PNG
mesh-adjusted.PNG
 
Last edited:
maiky76

maiky76

Member
Joined 2004
mabat said:
Great work. It's only a pity that you used the old approach that is limited to using Ath. I think the latest parametric description makes that somewhat obsolete now.
Click to expand...
Why would that be?

I am not sure that all the profiles generated by OSSE can be matched by ROSSE (not considering the baffled case).
I understand that ROSSE only uses 9 - Driver angle and Diameter => 7 parameters so it is easier for optimization but OSSE seems to provide more control from my admittedly limited experience.

BTW I tried to match the OSSE CE260 with ROSSE but I did not manage to get a perfect clone.
Have you tried?
OSSE CE260 vs. ROSSE.png


EDIT:

the parameters:

Code: 
% ROSSE CE260 fitting
 Radius    = 128.4 ; % Outer radius of the waveguide [mm]
 anglCover = 40.57 ; % Nominal coverage angle        [deg]
 r0DRV     = 12.70 ; % Throat radius                 [mm]
 a0DRVangl = 3.886 ; % Throat angle                  [deg]
 k         = 1.935 ; % Throat expansion factor       []
 r         = 0.200 ; % Apex radius factor            []
 m         = 0.823 ; % Apex relative position        []
 b         = 0.336 ; % Bending factor                []
 q         = 4.018 ; % Throat weighting factor       []
 
Last edited:
mabat

mabat

Member
Joined 2004
at-horns.eu
Paid Member
No I haven't tried. The two are very different mathematical descriptions (and there's no closed form for a rolled-back OSSE). All I need to know is that similar acoustic results can be obtained using either of those (and it's of course still possible to use both). The ROSSE is self-contained, easily portable to be used outside Ath.

- I'm still not sure we understand each other. The OSSE by itself is always only a baffle-terminated profile. Mouth rollback is not a part of the formula and for that you need Ath that does it numerically (those are the Rollback.* parameters). This is different with R-OSSE which is a complete, self-contanied analytical description, including a rollback (the Rollback.* parameters are ignored).

The R-OSSE was designed to mimic the numerically rolled-back OSSE.
 
Last edited:
Patrick Bateman

Patrick Bateman

Member
Joined 2006
mabat said:
I can't reproduce it. With your script it works fine on my setup (Ath 4.8, Gmsh 4.6.0). The only problem I see is your dome tweeter definition - something is wrong with the geometry (see the image below, gmsh also reports warnings about that).

Beware that the number of slices (Mesh.LengthSegments = 500) is way too high for ABEC in 3D mode. I assume you use a lower value when generating the ABEC project. Otherwise it generates around 14000 elements and that is most probably too much for ABEC, no matter the power of the PC (for me the upper limit is around 5000 elements to get results in reasonable time).


View attachment 1029078 View attachment 1029081 View attachment 1029082

-With Mesh.LengthSegments = 100 I get 5061 BEM elements including the tweeter and that should be already manageable.
Click to expand...

I did a clean re-installation and the problem seems to have disappeared. Not sure why.
 
maiky76

maiky76

Member
Joined 2004
Patrick Bateman said:
As you wrote this post, I was literally looking on Amazon for a new CPU lol

Now that I figured out what the bug was, I'm running the sims, and Lordy do they take a long time.

I have a six core I5 and it really doesn't cut it for this type of work.
Click to expand...
FYI your model with the mods proposed by Mabat = 1h15min on an AMD5950x/128Gb, CPU usage 85-100% (32 threads) ram usage<28Gb
 
maiky76

maiky76

Member
Joined 2004
Tom Kamphuys said:
I'd like to think that I start to 'see' good waveguides. I eyeball one in desmos and then use an AutoIt script to randomly make waveguides around that.

Would be nice to catch the 'seeing' in something remotely scientific :)
Click to expand...
That's where I am at ATM, defining (or trying...) mathematically what a good WG is i.e. defining the fitness function.

One way to do it (for me and I am not sure about the order):
1. Implementation conditions
  • Some conditions on the baffle, if any
  • Some condition on the intended application (i.e. Xover with a certain LF driver size, this is where some additional “default” sim data would help)
  • Some conditions on the size of the WG, optional
  • etc.
2. Behavior of the WG
  • Some conditions on the DI, this encompasses and affects coverage angle, tilt etc. so that is the most potent but also most demanding metric i.e. need a lot of iterations
  • and/or some conditions on the PIR, maybe several different designs could yield similar PIR, probably needs additional conditions
  • Some conditions on the ON/LW and/or their relationship (might not be needed depending on the DI target)
  • Polar map conditions i.e. SPL(deg>45deg) < ON-20dB
  • etc.

Fitting a target curve is not difficult but subtler than one might think (which range and what should happen out of that range could be problems) but a LMS method will work within some implementation constrains. The issue there is that one must absolutely be certain that the target is be best possible compromise...

Assuming the we are trying to minimize the fitness function, here are some alternative metrics (no weights are affected in these examples)

fitness = - average_DI_range / std_DI_range will design a flat DI over the range

fitness = -1 /[ abs (average_DI_range - TargetDIvalue) * std_DI_range ] will design a flat DI with DI = TargetDIvalue

fitness = -std_DI_range /[ abs (average_DI_range - TargetDIvalue) ] will design a DI with DI = TargetDIvalue on average but with a tilt, obviously limits are needed on the std_DI or the design won’t be good.

fitness = -std_DI_range * WGDepth /[ abs (average_DI_range - TargetDIvalue) * WGMaxRadius ] will design a DI with DI = TargetDIvalue on average but with a tilt, with the smallest diameter possible and the deepest possible

And so on…, there are infinite variations, the fun is to determine one fitness that would define a decent WG

I am more intrigued by the smoothness definition.
I have been using a standard deviation as a proxy for smoothness and tilt (examples above) but there are cases in which it is not the right metric as it is difficult to balance tilt (OK to a certain extend) and ripples (KO).
Using a linear regression and the coefficient of determination might be used but that’s not that better yet (still not some work tough). Any idea?

Some link to the discussion we had a while back:
https://www.diyaudio.com/community/...he-easy-way-ath4.338806/page-212#post-6433919
 
  • Like
Reactions: 1 user
mabat

mabat

Member
Joined 2004
at-horns.eu
Paid Member
Tom Kamphuys said:
I'd like to think that I start to 'see' good waveguides. I eyeball one in desmos and then use an AutoIt script to randomly make waveguides around that.

Would be nice to catch the 'seeing' in something remotely scientific :)
Click to expand...
I think you already have all you need now. There's no doubt that e.g. the device in #9388 is exemplary. We don't need an explicit metric for that. I mean it would be nice to have one, I'm just not sure it's worth the effort in addition to what we already have.
 
T

Tom Kamphuys

Member
Joined 2020
Of course:

Code: 
R-OSSE = {
 R = 225
 a = 30
 r0 = 12.7
 a0 = 15.5
 k = 1.4390133205801
 r = 0.341596880741417
 m = 0.830868302145973
 b = 0.127310905163176
 q = 4.4141227456741
}

Most of it is encoded in the filename of the images I post.

I've been trying to include the radius of curvature in Desmos (as I read that has something to do with HOM's). No guarantees: https://www.desmos.com/calculator/z8ybyhlfcs?lang=nl
 
  • Like
Reactions: 1 user
mabat

mabat

Member
Joined 2004
at-horns.eu
Paid Member
That can't be correct, Tom. The curvature radius can't start at zero in that example.

I would try this: https://www.desmos.com/calculator/nltso1dner
(blue = curvature, green = radius)

Otherwise it's a very good idea to show the curvature (or the radius). I guess that a good waveguide will have it smoothly changing (and increasing monotonically towards the mouth from the point of the first local minimum).

1646239970316.png
 
Last edited:
You must log in or register to reply here.
Top Bottom