Hi David,
we are working in a small industry and I guess there the market is just not big enough for such kind of software - perhaps that is that reason why there is no superposition solver out there. With CHIEF points you mean non uniqueness issues? As CHIEF method is already a method to avoid it. ABEC is using the dual surface method to avoid non uniqueness problems. I am using Solidworks and GMSH together with ABEC. Solidworks is quite common in the industry, making data exchange easier. But any CAD software will do - one just should use stp or igs to go into GMSH and not stl as it already is kind of a mesh and not a good one. For DIY enthusiast I strongly recommend Fusion 360 - it is a really powerful software package. It comes with nice 3D print export or even FEM vibration analysis and it's free for non comercial use.
As far as I know they are already performing some experimentations with an alpha state GPU based solver - very promissing indeed. I am using such kind of used dual CPU workstations with 32 logical cores and 128GB RAM. Very powerful, but also loud. If you don't have enough RAM, it could help to decrease number of used threads under "Options->Preferences->Processing". Of course it is slowing down the speed, but it brings down the amount of needed memory and you can continue your daily work in parallel. OK, the very best way to save solving time is to optimize your mesh, you really should pay attention to it.
The only penalty are those steps and longer solving time. One can even see those steps in your pictures in post #74 They are only smaller, as you use a higher dense field mesh. The be honest, I also don't pay too much attention to it, I just raise the mesh resolution and then it's ok for me.
Best Regards Andreas
A very good suggestion, I've been trying STL - Thanks. I think @Gaga may have mentioned that as well.
I have noticed quite a variation depending on the algorithms used and there's no shortage of parameters to adjust. I don't have enough experience to have solution intuition when I see the problem(s). But I also think this is a key point and worth spending more effort to build up experience. Thanks.
I don't worry about them either
I am now inclined to think it isn't a real problem, but I just didn't understand the issue so I was cautious.
Yes, once you have a specified number of elements that should more or less determine the solve time.
But I haven't used ABEC yet so I didn't know how many elements to expect from a typical simulation like yours, not quite the issue you were interested in.
Best wishes
David
Probably, I'm still a little surprised - speed is a sufficient bottleneck to justify experiments with a GPU so why not start with an efficient algorithm?
Thanks for the software recommendations, I am just about to buy a new machine to run all this stuff, that will help with the set-up.
Best wishes
David
Yes, you can quickly see the #elements at the very start and this will indicate both the RAM required and solve time on your machine. If its unacceptable you can refactor or restrategize before waiting/wasting hours (days?). On my machine, 4000 elements solves in 17m with 3GB RAM and that's reasonable for me because it allows several iterations in an evening.
I also played with symmetry models, and for a given model and mesh freq [no sym = 8000, 1/2 sym =4000, 1/4 sym=2000, polar sym =?] elements. Not a surprise, as its what you'd expect.
Last edited:
Agreed, the algorithm(s) would need to change because both CPU and RAM requirements are a problem for the current algorithm(s) when the #elements gets large.
Just a general inquiry.
So that's:
Fusion 360(model) > stp file (export) > GMSH (mesh) > msh file (export) > AEBC3 ?
Export stp video:
YouTube
If anyone wants to try with some of my designs here is the .stp of the SB26 diaphragm: Dropbox - SB 26 diaphragm v6.step and here is the 5" vG waveguide: Dropbox - 5x.75 G v5.step
For comparison's sake, here's how I did my sims:
1) create waveguide and radiator in Autodesk 123D (free.) Save the model
as 123D and export the model in STL.
2) Reduce the number of polygons in Meshmixer. This step here was my 'Eureka' moment; Meshmixer is able to reduce models by as much as 90-96%! It's truly incredible how much it can reduce a model. I used to use Meshlab, but Meshmixer does it a million times better. The reason that Meshmixer is so critical is that it saves you from the horrors of manually labeling a thousand polygon faces. Yes, you will still need to label around 200-300 faces, but I can do that in about 30 minutes. Doing it without Meshmixer was a deal breaker, it would've taken all day. If you look at the documentation from RDTeam itself, you can see that at some point they were making their models on graph paper, just like I was a few weeks ago. Meshmixer is a huge timesaver.
3) Import the STL into FreeCad, export it as a STEP file. This is documented here : Convert STL to STEP
4) Import the STEP file into GMSH. Use GMSH to turn the STEP file into a 2D mesh. Export that as a MESH file.
5) Import the mesh file into ABEC.
In the sims that I've done, I've found that I'm spending about 15-30 minutes writing down all the faces of the mesh. For instance, I have to create a group of faces for the "interface" in ABEC, and I have to create a group of faces for the radiator in ABEC. I have to create a group of faces for the "seam" when I'm using symmetry. For instance, if you had a waveguide with symmetry in the X and the Y axis, you have to 'subtract' the faces that correspond to the seam between the four pieces. Once you've done all THAT, what you're left with is the walls of the waveguide.
Everything that I wrote above is dependent on one thing:
When I make a waveguide, I model the INSIDE of the waveguide, and then when I load it up in ABEC I turn it inside-out by reversing the normals on every single face EXCEPT the front of the waveguide. That becomes the "interface" in ABEC.
The file below isn't from the image above, but it gives you the general idea: there is one set of faces, and some of those faces are for the waveguide, some of those faces are for the radiator, some of those faces are for the interface and some are for the seam. The first three are allocated to their stanzas in the file, and the fourth is omitted entirely.
// ************************************************************
//
// ABEC File
// Project Horn 800
//
// ************************************************************
Control_Solver
f1=1000
f2=12000
NumFrequencies=16
Abscissa=log
Dim=3D
MeshFrequency=12000Hz
Sym=z
// Mesh File Setup
MeshFile_Properties
MeshFileAlias=M
Scale=1mm
Rotate = 0, 0, 0
//Shift= 3.5mm, -55mm, 3.5mm
Shift= 0mm, -65mm, 0mm
Subdomain_Properties "Horn-Bell"
SubDomain=1
ElType=Interior
Subdomain_Properties "Exterior"
SubDomain=2
ElType=Exterior
IBPlane=x
// Boundaries
// Here's a list of the reflected parts of the waveguide. This is basically the "seam" that connects
// the four parts of the waveguide together. We exclude these because the waveguide in ABEC is
// "stitched together" from four reflected pieces. Not that these pieces can also be used in "xxx" to
// define the interior
// 3...40 (side Y)
Elements "Bell"
SubDomain=1
MeshFileAlias=M
//MeshFrequency=10kHz
101 Mesh Include ALL Exclude 3...40, 1932...1953, 188...195 SwapNormals
Elements "Driver"
MeshFileAlias=M
Subdomain=1
101 Mesh Include 1932...1953 SwapNormals
Driving "Comp Driver"
RefElements="Driver"
DrvGroup=1001
Elements "Interface"
SubDomain=1,2
MeshFileAlias=M
101 Mesh Include 188...195 SwapNormals
Last edited:
Hi Patrick,
I think I've done that at leat partly in the German forum. Which one would be interesting for you? I did quite a number of variations and be happy to post the ABEC model or stp-file...
Hi Brandon,
I think I've done that at leat partly in the German forum. Which one would be interesting for you? I did quite a number of variations and be happy to post the ABEC model or stp-file...
Hi Brandon,
I have to check, I do not remember actually. I think these were stl-files and I did a new model in F360 based on the dimensions/data of the stl-file. I come back, when i checked it.
The part that I'm having a hard time with is how to define a dome tweeter in ABEC. So I need the solving.txt in particular. I haven't figured out how to model the height of the dome, the thiele-small parameters of the tweeters, etc.
But ideally, a zip file with the following would be perfect:
solving.txt
project.abec
observation fields.txt
observation spectrum.txt
lescript.txt
your mesh file
your step file
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.