I'm sorry but no, I just can't give all away as this actually represents endless hours of my effort. If anyone want to use this (what I see as a culmination of the works so far) for whatever purpose, please contact me on the side.
- This would be a slightly bigger version. All who have tried to play with the calculator know that it is not at all obvious and easy to get results this good. This is a piece of art that's not cheap.
- This would be a slightly bigger version. All who have tried to play with the calculator know that it is not at all obvious and easy to get results this good. This is a piece of art that's not cheap.
Attachments
Last edited:
So I've been trying to use the latest version of the software and it seems to take an unlimited time to do it's thing.
For instance, in the old version, I could crank out a sim in about 40 minutes, and the new version has been grinding away for four hours and stuck at 34%.
I have dual eight-core XEON CPUs and 48gb of ram, so a fairly powerful rig.
One thing that I noticed in Abec, is that the mesh seems to be much finer than in the old version, and I think that me causing the issue.
Here's my config file, if anyone has any clues:
Throat.Diameter = 32
Throat.Profile = OS ; OS | cone
Throat.Angle = 22.5
Throat.Ext.Length = 0
; Throat.Ext.Profile =
Length = 125
GCurve = SF ; SE | SF
; GCurve.Dist =
; GCurve.SE.Exp =
GCurve.SF = 1,1,4,2,8,4
GCurve.XDim = 130
; GCurve.Angle = 30
GCurve.VertScale = 0.5
GCurve.Rot = 0
Term.s = 0.7
Term.q = 0.995
Term.n = 5
Morph.TargetShape = rect ; raw | rect | circ
Morph.CornerRadius = 35
Morph.AddRectWidth = 0
Morph.AddRectHeight = 0
Morph.FixedPart = 0.3
Morph.StretchExp = 3
Mesh.AngularSegments = 36
Mesh.LengthSegments = 20
Mesh.CornerSegments = 6
Mesh.ThroatResolution = 5
Mesh.InterfaceResolution = 5
ABEC.RadiationConditions = IB ;
ABEC.f1 = 750
ABEC.f2 = 12000
ABEC.NumFrequencies = 40
ABEC.MeshFrequency = 1000
ABEC.Source.Shape = spherical ; spherical | flat
ABEC.Source.Radius = -1
ABEC.Source.Curv = 0 ; 1 | -1 | 0
ABEC.Source.Velocity = axial ; radial | axial
ABEC.Polars.Horizontal = true
ABEC.Polars.Vertical = true
ABEC.Polars.Diagonal = true
ABEC.Polars.DiagonalInclination = 0
ABEC.Polars.Dist = 2 ; meters
ABEC.Polars.Step = 7.5 ; degrees
ABEC.Polars.Points = 9
; Output.DestDir = "C:\jun10"
Output.STL = yes
Output.MSH = no
Output.ABECProject = yes
Output.Coords = yes
Output.Coords.Scale = 0.1 ; default = 0.1 for Fusion
; Output.Coords.NumProfiles =
; Output.Coords.Delimiter =
Output.Coords.SeperateFiles = no
Output.Coords.FileExt = csv
For instance, in the old version, I could crank out a sim in about 40 minutes, and the new version has been grinding away for four hours and stuck at 34%.
I have dual eight-core XEON CPUs and 48gb of ram, so a fairly powerful rig.
One thing that I noticed in Abec, is that the mesh seems to be much finer than in the old version, and I think that me causing the issue.
Here's my config file, if anyone has any clues:
Throat.Diameter = 32
Throat.Profile = OS ; OS | cone
Throat.Angle = 22.5
Throat.Ext.Length = 0
; Throat.Ext.Profile =
Length = 125
GCurve = SF ; SE | SF
; GCurve.Dist =
; GCurve.SE.Exp =
GCurve.SF = 1,1,4,2,8,4
GCurve.XDim = 130
; GCurve.Angle = 30
GCurve.VertScale = 0.5
GCurve.Rot = 0
Term.s = 0.7
Term.q = 0.995
Term.n = 5
Morph.TargetShape = rect ; raw | rect | circ
Morph.CornerRadius = 35
Morph.AddRectWidth = 0
Morph.AddRectHeight = 0
Morph.FixedPart = 0.3
Morph.StretchExp = 3
Mesh.AngularSegments = 36
Mesh.LengthSegments = 20
Mesh.CornerSegments = 6
Mesh.ThroatResolution = 5
Mesh.InterfaceResolution = 5
ABEC.RadiationConditions = IB ;
ABEC.f1 = 750
ABEC.f2 = 12000
ABEC.NumFrequencies = 40
ABEC.MeshFrequency = 1000
ABEC.Source.Shape = spherical ; spherical | flat
ABEC.Source.Radius = -1
ABEC.Source.Curv = 0 ; 1 | -1 | 0
ABEC.Source.Velocity = axial ; radial | axial
ABEC.Polars.Horizontal = true
ABEC.Polars.Vertical = true
ABEC.Polars.Diagonal = true
ABEC.Polars.DiagonalInclination = 0
ABEC.Polars.Dist = 2 ; meters
ABEC.Polars.Step = 7.5 ; degrees
ABEC.Polars.Points = 9
; Output.DestDir = "C:\jun10"
Output.STL = yes
Output.MSH = no
Output.ABECProject = yes
Output.Coords = yes
Output.Coords.Scale = 0.1 ; default = 0.1 for Fusion
; Output.Coords.NumProfiles =
; Output.Coords.Delimiter =
Output.Coords.SeperateFiles = no
Output.Coords.FileExt = csv
The mesh throat resolution and mesh interface resolution make a big difference to the number of elements that are created.
I tried a similar thing recently and over 10,000 elements result in being stuck for a long time.
I changed both of those to between 8mm and 10mm and the number of elements reduced to between 2000 and 3000 which made the sim run about 45mins to an hour.
According to my interpretation of the ABEC help calculation an element size of 11mm is still OK to solve up to 15KHz.
The bigger the waveguide the more you have to reduce the resolution to keep the number of elements under control.
What I have been doing (tip from DonVK) to check is to just solve the mesh first and see how many elements are produced if it's too many I adjust the resolution. That only takes a few seconds to solve. The only other parameter that matters a lot for solve time is number of frequencies. Keeping it to a multiple of the number of processors (cores) you have seems to work well.
I tried a similar thing recently and over 10,000 elements result in being stuck for a long time.
I changed both of those to between 8mm and 10mm and the number of elements reduced to between 2000 and 3000 which made the sim run about 45mins to an hour.
According to my interpretation of the ABEC help calculation an element size of 11mm is still OK to solve up to 15KHz.
The bigger the waveguide the more you have to reduce the resolution to keep the number of elements under control.
What I have been doing (tip from DonVK) to check is to just solve the mesh first and see how many elements are produced if it's too many I adjust the resolution. That only takes a few seconds to solve. The only other parameter that matters a lot for solve time is number of frequencies. Keeping it to a multiple of the number of processors (cores) you have seems to work well.
Last edited:
OK, it's much zipper now. I changed the "throat resolution" and "mesh interface" from their default (5mm) to 7mm, and the number of elements dropped from 6,500 to 3,000.
Based on how ABEC was behaving, I get the impression that it may have hit a wall. Perhaps it started swapping to disk, instead of solving in RAM.
48GB is a decent amount of ram, but with 16 CPUs that's only 3GB per cpu, or about as much as if you had a quad core system with 12GB.
Based on how ABEC was behaving, I get the impression that it may have hit a wall. Perhaps it started swapping to disk, instead of solving in RAM.
48GB is a decent amount of ram, but with 16 CPUs that's only 3GB per cpu, or about as much as if you had a quad core system with 12GB.
When I have checked task manger while ABEC is running I don't see it using that much RAM unless the number of elements gets too big. then it runs out of memory and reports it in the solving file.
My laptop is a core i7 with 12 cores and 16GB of RAM with 4000 elements it didn't go much above 8 to 10 GB. That solved in about 90 mins.
My laptop is a core i7 with 12 cores and 16GB of RAM with 4000 elements it didn't go much above 8 to 10 GB. That solved in about 90 mins.
Memory usage dropped like a rock with a coarser mesh. It's at 66% and it's been running for about 30 minutes now. Seven gigs of 48 gigs in use.
So I think your solution was right on the money.
This makes sense, because going from a mesh of 10mm to a mesh of 5mm may increase memory requirements by eight. (Because we're working in three dimensions.)
So I think your solution was right on the money.
This makes sense, because going from a mesh of 10mm to a mesh of 5mm may increase memory requirements by eight. (Because we're working in three dimensions.)
I guess I should explain a bit more on this. The way how meshing works is very different in version 4.5 (much for the better, I believe). First, the mesh resolution should be controlled solely via the Ath script parameters, so the generated mesh handled to ABEC is already in the final resolution needed for the desired frequency range. ABEC has its own meshing algorithm but I strongly recommend not to use it - not that there's anything wrong with it, it's just a bad procedure to follow. You need a fine enough mesh right from the start and prevent ABEC from refining it further (which adds no precision, it just subdivides the existing mesh). That's also the reason why the default value for "MeshFrequency" for ABEC is 1 kHz, which is pretty low - that is to prevent ABEC from making any subsequent (unnecessary) mesh "refinement".
There are several parameters for this -
Mesh.AngularSegments = 36
You should probably increase this, as it has no direct impact on the calculation time as it no longer affects the number of elements directly. I use 100-120 for most cases - I just want to preserve the shape nicely. So don't be afraid to increase this.
Mesh.LengthSegments = 20
This seems about right for most cases.
Mesh.ThroatResolution = 5 and Mesh.InterfaceResolution = 5
These are the crucial parameters. When left at 5 mm, this will lead to a very fine mesh that will take very long calculation time. Increasing these values reduces the mesh resolution and the calculation time strongly but also the precision. The final mesh resolution (i.e. the nominal size of a single mesh element) is depth-dependent - it starts at ThroatResolution at the throat and gradually changes to InterfaceResolution at the mouth.
I usually keep the throat resolution at 5 mm but set the interface resolution to 10 - 12 mm. This will preserve the throat shape but will greatly reduce the calculation time, especially for larger horns. This works well to about 10 - 12 kHz from my experience.
There are several parameters for this -
Mesh.AngularSegments = 36
You should probably increase this, as it has no direct impact on the calculation time as it no longer affects the number of elements directly. I use 100-120 for most cases - I just want to preserve the shape nicely. So don't be afraid to increase this.
Mesh.LengthSegments = 20
This seems about right for most cases.
Mesh.ThroatResolution = 5 and Mesh.InterfaceResolution = 5
These are the crucial parameters. When left at 5 mm, this will lead to a very fine mesh that will take very long calculation time. Increasing these values reduces the mesh resolution and the calculation time strongly but also the precision. The final mesh resolution (i.e. the nominal size of a single mesh element) is depth-dependent - it starts at ThroatResolution at the throat and gradually changes to InterfaceResolution at the mouth.
I usually keep the throat resolution at 5 mm but set the interface resolution to 10 - 12 mm. This will preserve the throat shape but will greatly reduce the calculation time, especially for larger horns. This works well to about 10 - 12 kHz from my experience.
Last edited:
Maybe even more precise explanation of how it works:
The horn surface is cut into several slices (the number is set by Mesh.LengthSegments) and each slice is in fact meshed separately. The resolution doesn't have to be (and won't be in general) constant across the whole slice (depending on its height), but the mesh elements will never cross the slice boundary. So setting the number of slices too big would also result in having a very fine mesh.
I hope this is clearer now a it is quite important subject to understand to be able to get a proper silmulation in a resonable time.
BTW, the slice boundaries are defined with splines, which explains why the number of AngularSegments doesn't affect the number of mesh elements. It has nothing to with it, it just controls how the spline fits. For simple shapes it could be lowered considerably. For sharp edges you need more spline control points. Then setting the Mesh.*Resolution parameters affects how coarse the final mesh will be. This is the beauty of the Gmsh library.
The horn surface is cut into several slices (the number is set by Mesh.LengthSegments) and each slice is in fact meshed separately. The resolution doesn't have to be (and won't be in general) constant across the whole slice (depending on its height), but the mesh elements will never cross the slice boundary. So setting the number of slices too big would also result in having a very fine mesh.
I hope this is clearer now a it is quite important subject to understand to be able to get a proper silmulation in a resonable time.
BTW, the slice boundaries are defined with splines, which explains why the number of AngularSegments doesn't affect the number of mesh elements. It has nothing to with it, it just controls how the spline fits. For simple shapes it could be lowered considerably. For sharp edges you need more spline control points. Then setting the Mesh.*Resolution parameters affects how coarse the final mesh will be. This is the beauty of the Gmsh library.
Last edited:
To illustrate, this si what I would consider a fine enough mesh in general for 10 kHz upper frequency limit (the waveguide is 19" in diameter). You can see all the things just mentioned: The sizes of mesh elements increase from throat to mouth and if you look carefully you can also see the joints between the individual slices - these are the full circles (ellipses in this case) around the surface.
Mesh.ThroatResolution = 5.0 ; [mm]
Mesh.InterfaceResolution = 10.0 ; [mm]
ABEC reports 3329 elements.
Mesh.ThroatResolution = 5.0 ; [mm]
Mesh.InterfaceResolution = 10.0 ; [mm]
ABEC reports 3329 elements.
Attachments
Last edited:
Right at the throat the finite elements get even smaller because of the (generally) closer spacing of the slices. This is handled automatically.
Here the red "driving" surface is meshed at specified throat resolution (5 mm) but the nearby wall resolution is finer than that. This is not a problem as the number of elements around the throat never gets large. It is the mouth area where this number can rise rapidly if you set the elements too small.
Here the red "driving" surface is meshed at specified throat resolution (5 mm) but the nearby wall resolution is finer than that. This is not a problem as the number of elements around the throat never gets large. It is the mouth area where this number can rise rapidly if you set the elements too small.
Attachments
Last edited: