Hi Frederik,
Good to see that everything seems to work fine.
Just a few comments...
Regarding the mesh-frequency I'd second Don:
i.e. I woud not use 20kHz s mesh frequency in ABEC, if you already checked your mesh as described by Don above. I usually set mesh frequency in the solving script relatively low, if I work with imported meshes from GMSH.
Regarding the infinite baffle or back-enclosure:
The directivity plot of your waveguide after optimization looks very good. Would you mind to show / indicate the stpes away from the OS-waveguide to your optimized contour?
BW,
Christoph
Good to see that everything seems to work fine.
Just a few comments...
Regarding the mesh-frequency I'd second Don:
i.e. I woud not use 20kHz s mesh frequency in ABEC, if you already checked your mesh as described by Don above. I usually set mesh frequency in the solving script relatively low, if I work with imported meshes from GMSH.
Regarding the infinite baffle or back-enclosure:
Yes, you have to deal with this in some way at least. You already introduced an infinite baffle, so this is no issue any more. Nevertheless, you should construct an enclosure around the entire horn, if you do not want to use an infinite baffle. You could as well use a 'trick' suggested in the example file of the Expo400 horn (see example files/BEM)...
You can do this as you suggested in your next contribution. However, there is a direct way in VACS: With a 'Polar Plot' opened in VACS, select 'Graph' and 'Convert Curves --- Contour' and VACS will give you the respective SPL curves.
The directivity plot of your waveguide after optimization looks very good. Would you mind to show / indicate the stpes away from the OS-waveguide to your optimized contour?
BW,
Christoph
I adjusted the mesh frequency both up and down and I see no change in elements before 23kHz. The question then is if this is enough resolution to accurately model my waveguide. I guess this would have to be done by gradually making the mesh coarser or finer and see when the solutions converge?
I see. I don't care if they are jagged near the walls, as long as it doesn't do serious harm to the accuracy in the far field.
I know how you feel, it's not the easiest software to learn. But I think for people like us, who enjoys creating speakers for a hobby, 3D printing waveguides and so on, BEM is a very nice tool. One would rarely design a box without calculating the bass response through TS parameters. We should be able to predict our radiation pattern aswell!
Why is that? Is there any harm done in using a high frequency if ABEC doesn't remesh the geometry? Wouldn't a high mesh frequency usually provide more accurate results for high frequencies?
Great, enclosure around the entire horn in my next non IB attempt then.
Nice, this also makes it easy to get normalized FR curves:
I abandoned the conical section and replaced it with a radius that tangents the throat and the "baffle". Then I played with the radius of the wall section and the throat radius.
Last edited:
Synergized version
While I am not gonna spam this threads with my own designs as this thread should be reserved to ABEC specific questions, I'd like to share how a typical synergy conversion of the promising waveguie contour looks like:
I created 0.5cm x 3cm slots in on the diagonals of the WG like this:
After remeshing with a quite fine mesh around the slots, this is what the polars look like:
Can it be improved? Most likely, and this is what makes ABEC/BEM such an interesting tool. You can easily do 10 iteration a day. And while the specifics, might be a bit off I think the general trends will apply to real life aswell.
Interesting stuff!
While I am not gonna spam this threads with my own designs as this thread should be reserved to ABEC specific questions, I'd like to share how a typical synergy conversion of the promising waveguie contour looks like:
I created 0.5cm x 3cm slots in on the diagonals of the WG like this:
After remeshing with a quite fine mesh around the slots, this is what the polars look like:
Can it be improved? Most likely, and this is what makes ABEC/BEM such an interesting tool. You can easily do 10 iteration a day. And while the specifics, might be a bit off I think the general trends will apply to real life aswell.
Interesting stuff!
I think your results are relevant to this thread, as well as educational for unity horns, I'm definitely interested - thanks.
The plots certainly look plausible in their overall behaviour.
Can you show your mesh, with some sort of scale?
How much time did it take on what hardware?
Best wishes
David
Last edited:
Glad to hear that,
here is the mesh and settings used in Gmesh:
As you can see I activated the option "compute element size from curvature" which automatically refines the mesh around curvature. The slot is 5mm wide, that gives you an indication of the mesh edge lengths.
I didn't time it but that sim took approx 30 min on my 8 core Ryzen running 16 threads. Normally I run with 0.3 mesh scale factor, and with no special refinement and that is solved in approx 5-10 minutes.
Further experiments showed that with no solid face on the backside of the slot facing the midrange driver (the orange surface in the mesh picture above) the diffraction effects almost disappears, except for some slightly less energy directly on-axis around 7kHz which appears as a widening in the polar plot at that frequency when normalized to 0 degrees.
So what is correct? I'd say probably something in between those two cases judging by measurements from measurements of actual implementations with before and after measurements.
Best, Fredrik
Last edited:
Tends to imply that the fine details of the mesh around the curved slot ends probably doesn't matter too much, it is the behaviour into the slot.
That would enable a bit of simplification of your very detailed mesh, and faster solution.
More importantly provides a bit of intuition about what matters, it makes sense but I have never seen it discussed.
Thanks once more, that is very informative.
Best wishes
David
During my experiments with ABEC, I found that it would 'hit a wall' with a lot of the simulations that I did.
At that time, I was doing the work on my laptop. It was a quad core Ryzen with 8gb of ram, that I'd replaced the "stock" hard drive with a fairly cheap SSD.
I doubled the ram from 8GB to 16GB and that helped a lot, at a cost of about $100 IIRC.
Basically I was able to simulate larger models and at higher frequency. There were still situations where the laptop would never finish a sim, but 80% of the time, things were fine.
In order to increase my computing power, I started tinkering with Xeon workstations from about seven years back. Basically you can put together a sixteen core Xeon beast for about $500 if you buy the parts used. I'm too lazy to check, but I believe my Xeon workstation has about 32 or 48GB of RAM.
When I went with a XEON platform, I ran into a NEW problem with ABEC, which is that I started to be constrained by the CPU. Although the XEON has four times as many cores, they're running at a clock speed of about half. And since each core needs it's own allocation of RAM, a sixteen core system needs about 4X as much ram as a 4 core system. That meant that I really need to have about 64-128GB of ram.
So, once again, the system is very very expensive.
Today at work, I was working on some network attached storage, and ran into something that I thought was very interesting:
I haven't been paying much attention to the consumer SSD scene, and they've quietly come out with some INSANELY fast SSDs.
For instance, the aData XPG 240GB SSD is around SIX times faster than the SSD that's in my laptop. The XPG is so darn fast, it's nearly as fast as DDR RAM from about ten years ago.
To me, this is utterly inconceivable; SSDs aren't as fast as ram, but they're getting "in the ballpark."
This is just nuts.
Even crazier, that SSD is a whopping $65 on Amazon. For 240GB.
To put that in perspective, 256GB of DDR4 RAM is $2000!
Now, obviously, RAM is faster than an SSD. By about a factor of four. But, yowza, that SSD is 97% cheaper than buying RAM.
Now, obviously, using a really fast SSD might not be possible. I don't know how ABEC is written. But based on my use, and how my simulations seemed to 'hit a wall', I have a feeling that ABEC is swapping to disk when it runs out of ram.
That would explain why the sim is just motoring along, and then grinds to a halt out of nowhere. Basically ABEC runs out of ram, then has to copy this humongous file to disk, and then has to make a feeble attempt to do the simulation using the disk instead of ram.
Considering that the SSD in my laptop isn't particularly fast, that might explain why ABEC is behaving the way it is. Basically it could grind out a simulation in four to eight hours if it can do it in RAM, but once it has to swap to disk, that timeframe could grow tenfold, from 4-8hrs to 40-80hrs. (Because the RAM is about 10X faster.)
But if you get yourself one of these ultra-fast M2 SSDs, it might be possible to whittle that down to about 12-16 hours.
Some food for thought. I think I'll order one and see how it goes.
At that time, I was doing the work on my laptop. It was a quad core Ryzen with 8gb of ram, that I'd replaced the "stock" hard drive with a fairly cheap SSD.
I doubled the ram from 8GB to 16GB and that helped a lot, at a cost of about $100 IIRC.
Basically I was able to simulate larger models and at higher frequency. There were still situations where the laptop would never finish a sim, but 80% of the time, things were fine.
In order to increase my computing power, I started tinkering with Xeon workstations from about seven years back. Basically you can put together a sixteen core Xeon beast for about $500 if you buy the parts used. I'm too lazy to check, but I believe my Xeon workstation has about 32 or 48GB of RAM.
When I went with a XEON platform, I ran into a NEW problem with ABEC, which is that I started to be constrained by the CPU. Although the XEON has four times as many cores, they're running at a clock speed of about half. And since each core needs it's own allocation of RAM, a sixteen core system needs about 4X as much ram as a 4 core system. That meant that I really need to have about 64-128GB of ram.
So, once again, the system is very very expensive.
Today at work, I was working on some network attached storage, and ran into something that I thought was very interesting:
I haven't been paying much attention to the consumer SSD scene, and they've quietly come out with some INSANELY fast SSDs.
For instance, the aData XPG 240GB SSD is around SIX times faster than the SSD that's in my laptop. The XPG is so darn fast, it's nearly as fast as DDR RAM from about ten years ago.
To me, this is utterly inconceivable; SSDs aren't as fast as ram, but they're getting "in the ballpark."
This is just nuts.
Even crazier, that SSD is a whopping $65 on Amazon. For 240GB.
To put that in perspective, 256GB of DDR4 RAM is $2000!
Now, obviously, RAM is faster than an SSD. By about a factor of four. But, yowza, that SSD is 97% cheaper than buying RAM.
Now, obviously, using a really fast SSD might not be possible. I don't know how ABEC is written. But based on my use, and how my simulations seemed to 'hit a wall', I have a feeling that ABEC is swapping to disk when it runs out of ram.
That would explain why the sim is just motoring along, and then grinds to a halt out of nowhere. Basically ABEC runs out of ram, then has to copy this humongous file to disk, and then has to make a feeble attempt to do the simulation using the disk instead of ram.
Considering that the SSD in my laptop isn't particularly fast, that might explain why ABEC is behaving the way it is. Basically it could grind out a simulation in four to eight hours if it can do it in RAM, but once it has to swap to disk, that timeframe could grow tenfold, from 4-8hrs to 40-80hrs. (Because the RAM is about 10X faster.)
But if you get yourself one of these ultra-fast M2 SSDs, it might be possible to whittle that down to about 12-16 hours.
Some food for thought. I think I'll order one and see how it goes.
I'm guessing you are referring to NVMe-drives (SX8200 in this case)? In that case you have to make sure to have a computer that supports them. The M.2-slot can be both SATA (maximum bandwidth of 600 MB/s) and NVMe (maximum bandwidth of 4000 MB/s).
The Samsung 970 Evo Plus 250 GB is twice as fast during writing and costs the same, at least here in Sweden (70 USD on amazon). For 127 USD you get the 500 GB version which is even faster.
/Anton
Hi Patrick:
I would spend my money on DRAM; once you get into swapping memory to and from storage, your simulation performance will suck even with faster SSD. That SSD you referenced has higher throughput but its latency is about the same so, with a short swap file, that latency might be the critical factor, with only a marginal improvement from the higher throughput.
You may be able to get Optane SSD for your swap file which does have much faster latency but its still expensive. Conventional SSD has internal shift register organization that accounts for its initial latency; Optane is based on an cross point architecture so it can go directly to the desired data.
I would spend my money on DRAM; once you get into swapping memory to and from storage, your simulation performance will suck even with faster SSD. That SSD you referenced has higher throughput but its latency is about the same so, with a short swap file, that latency might be the critical factor, with only a marginal improvement from the higher throughput.
You may be able to get Optane SSD for your swap file which does have much faster latency but its still expensive. Conventional SSD has internal shift register organization that accounts for its initial latency; Optane is based on an cross point architecture so it can go directly to the desired data.
Go with Ivy Bridge - Xeon E5 v2 - for minimal price increase. Some careful Ebay watching should get you 16GB, ECC PC3L sticks at $32 each. Platforms with lots of DDR3 have been the sweet spot for years.
Also, run an ABEC sim that hits the wall, and check HD busy time, RAM load, etc. No point in upgrading an underutilized resource.
Second to that, IF a swap file doesn't work or isn't covering everything, running into a "vritual" harddrive in your RAM is also A LOT faster.
BTW, this is a perfect case for actually renting one of these in the cloud solutions. Especially since ABEC isn't that big
There is a lot to improve on ABEC, I do believe that GPU's are actually much better in solving math problems, but correct me if I'm wrong.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.