OK, thanks - it helped.
It seems that a "progress" of standing wave null points is not the right one for frequencies over 1kHz. Size of the red area is different...
Project for ABAKAK attached (observations, meshing and frequencies are also modified).
It seems that a "progress" of standing wave null points is not the right one for frequencies over 1kHz. Size of the red area is different...
Project for ABAKAK attached (observations, meshing and frequencies are also modified).
Attachments
Last edited:
You could probably decrease the Meshing length to 5mm or less
This is just a straight pipe that is divided.
One side is a plain source, the other side is an interface to an external doman that is 100% absorbent (as suggested earlier)
Example 2 is the same straight pipe with dividers, this time terminated by a reflective end located in the same domain.
You can notice that the edges don't match
This is just a straight pipe that is divided.
One side is a plain source, the other side is an interface to an external doman that is 100% absorbent (as suggested earlier)
Example 2 is the same straight pipe with dividers, this time terminated by a reflective end located in the same domain.
You can notice that the edges don't match
Last edited:
I'd need to run comparative sims in other tools or methods to verify, but since the 'vanes' or dividers don't extend the full length of the tube, I'd expect some form of diffraction effect to be modelled in that case. However, the 'stepping' of the cancellations should be symmetrical from top to bottom, in my mind at least.
I checked the ABEC manual and the NUC compensation was one of the final additions before it became AKABAK. It should be on by default, so maybe it's an issue of mesh sizing. How big are the gaps between vanes?
I also found this in the 'Normals and Volumes' help section for both apps:
I checked the ABEC manual and the NUC compensation was one of the final additions before it became AKABAK. It should be on by default, so maybe it's an issue of mesh sizing. How big are the gaps between vanes?
I also found this in the 'Normals and Volumes' help section for both apps:
Sorry, is this in reference to the tube model you posted? If so, I was asking more about the model with the curved ‘cells’.
But that’s also interesting. It doesn’t state a lower limit per se, but since the BEM code used in ABEC and AKABAK tolerates small gaps around elements without leakage I’m curious if that’s considered too small fundamentally, or if it’s a function of the mesh size. See the Bogart horn example’s baffle, for example.
I think this is where the careful, empirical use of subdomain dividers comes into play. I’ll load that Bogart model and try it with a stupidly fine mesh to see if there’s visible ‘leakage’, but I think not just based on the placement of the (many) subdomains and interfaces.
Have you tried marking each section of the tube model as a separate subdomain, with interfaces at either end? How about marking the ‘gaps’ inside the dividers or vanes as subdomains too?
Maybe I can explain more clearly; to you and me the dividers in the tube model have a 'thickness' of 1mm, but I don't think the code sees it that way. Instead, it sees a boundary with no thickness, because it doesn't 'see' anything on the other side. A small offset section inside is perhaps one solution since I don't believe you can use coincident or overlapping elements for different subdomains.
Check the help file section on the Boundary Element Method, which shows an 'island' in the domain as a failure case for standard BEM. The NUC method helps fix that, but the 'island' is marked explicitly a separate subdomain in that diagram.
But that’s also interesting. It doesn’t state a lower limit per se, but since the BEM code used in ABEC and AKABAK tolerates small gaps around elements without leakage I’m curious if that’s considered too small fundamentally, or if it’s a function of the mesh size. See the Bogart horn example’s baffle, for example.
I think this is where the careful, empirical use of subdomain dividers comes into play. I’ll load that Bogart model and try it with a stupidly fine mesh to see if there’s visible ‘leakage’, but I think not just based on the placement of the (many) subdomains and interfaces.
Have you tried marking each section of the tube model as a separate subdomain, with interfaces at either end? How about marking the ‘gaps’ inside the dividers or vanes as subdomains too?
Maybe I can explain more clearly; to you and me the dividers in the tube model have a 'thickness' of 1mm, but I don't think the code sees it that way. Instead, it sees a boundary with no thickness, because it doesn't 'see' anything on the other side. A small offset section inside is perhaps one solution since I don't believe you can use coincident or overlapping elements for different subdomains.
Check the help file section on the Boundary Element Method, which shows an 'island' in the domain as a failure case for standard BEM. The NUC method helps fix that, but the 'island' is marked explicitly a separate subdomain in that diagram.
Last edited:
The NUC is only for exterior subdomains, the documentation is pretty clear on that - "NUC does not affect interior domains, and its settings are ignored". And I don't think there's any leakage between channels, no matter how close they are. The field map may be suspitious in this regard but that's probably because one big field mesh is placed over the whole geometry, so if there are more than one subdomains under a single field element, it's somehow merged, but it's just the presentation of the field (I've never used that much).
- "Exterior" in ABEC means it extends to infinity. "Interior" is any volume enclosed by a defined boundary.
- "Exterior" in ABEC means it extends to infinity. "Interior" is any volume enclosed by a defined boundary.
Last edited:
Sorry, maybe I wasn't clear. I know that the NUC is applied only to the exterior condition, but here you guys are simulating interior obstructions that are very small. All elements in BEM require a thickness, but it may be that the elements are close enough together to cause a singularity in this case.
I'm trying to make time to learn to use COMSOL for more complex models so thanks for the chance to do an easy comparison. Since the tube example is nice and simple, here's the equivalent in COMSOL's Pressure Acoustics, Frequency Domain (acpr) 2D mode.
The mesh, auto calculated from the physics model:
Anechoic (sound soft boundary) termination:
Anechoic (wall impedance at a value of 1 alpha):
Rigid termination:
I wasn't sure what the outer tube dimensions of aragorus' model were, so I went with 100 mm length and 0.4 mm diameter. The vanes are the same, 1 mm thick with a 3 mm gap between the 1 m/s normal velocity driven element on the left, and the termination on the right.
I can look at trying to import the same vane-based horn sometime over the next few days?
I'm trying to make time to learn to use COMSOL for more complex models so thanks for the chance to do an easy comparison. Since the tube example is nice and simple, here's the equivalent in COMSOL's Pressure Acoustics, Frequency Domain (acpr) 2D mode.
The mesh, auto calculated from the physics model:
Anechoic (sound soft boundary) termination:
Anechoic (wall impedance at a value of 1 alpha):
Rigid termination:
I wasn't sure what the outer tube dimensions of aragorus' model were, so I went with 100 mm length and 0.4 mm diameter. The vanes are the same, 1 mm thick with a 3 mm gap between the 1 m/s normal velocity driven element on the left, and the termination on the right.
I can look at trying to import the same vane-based horn sometime over the next few days?
Last edited:
There are no such obstructions in what I posted. In my case there are three completely separate interior subdomains.
So what's the conclusion about the tube case? (What aragorus shows is axisymmetric, i.e. we are looking only at the "upper" half. I'm not sure about your model.)
Last edited:
Cool, that makes more sense. However, those separate subdomains have edges that are quite close together.
I'll try and import the ABEC script, and run it in COMSOL too.
The tube comparisons seem to show that the AKABAK/ABEC version posted by aragorus has leakage into the dividers. Even if those are set to be a blocking element in the same subdomain, for the BEM calculation to be considered accurate at those scales we should see a value that is close to zero inside those areas.
From the PDF about the BEM on the R&D Team website:
What we see on the images posted by aragorus is a very high level inside the dividers, relative to the areas outside of it.
I think aragorus has defined a single element plane using all four corners of the main tube nodes. From my understanding of BEM, this causes the code to solve for all points on boundaries within those corners first, then it moves on to the other elements' boundary points.
It then probably tries to fix it by comparison with the larger element's data for inside the dividers, since they're coincident. That's done via the very intensive matrix multiplication which requires lots of RAM for complex models with lots of mesh elements.
There's a small chance that it's getting confused with the smaller elements being close together in miero's examples above 1 kHz.
Here's what happens in AKABAK if I recreate my 100 mm tube in 2D mode. NUC is off, mesh size is 1 mm for the domains, and 0.5 mm bifu with quad ratio = 4 for the observation field.
First up, defining a single element using all four tube corners "1001 1002 1003 1004", then adding the separate driven and anechoic termination (Damping = 1) elements:
To me, it looks like it's adding the values from the calculations from points on the damped element to the reflective element, as a matrix multiplication?
Correcting the elements to create two planes using nodes "1001 1002" and "1003 1004" for the tube outer walls gives this:
Rigid reflective termination, same order - single plane for tube walls first:
The latter set up in each case more closely matches the COMSOL model.
Also interesting is the calculation times. Each of those AKABAK models took over a minute to run for a single frequency, but the COMSOL equivalent in FEA took less than a second - even when I ramped the mesh detail up to 1 mm edge length maximum, using triangular elements.
Here's the tube with an open end condition, not sure what element best represents that in COMSOL yet as I'm just playing with it:
That information is going to be cold comfort in two weeks when my trial runs out
Sorry for the huge images, by the way, rapid screenshotting from a 4K monitor. The new forum software makes that way less obnoxious, luckily.
I'll try and import the ABEC script, and run it in COMSOL too.
The tube comparisons seem to show that the AKABAK/ABEC version posted by aragorus has leakage into the dividers. Even if those are set to be a blocking element in the same subdomain, for the BEM calculation to be considered accurate at those scales we should see a value that is close to zero inside those areas.
From the PDF about the BEM on the R&D Team website:
What we see on the images posted by aragorus is a very high level inside the dividers, relative to the areas outside of it.
I think aragorus has defined a single element plane using all four corners of the main tube nodes. From my understanding of BEM, this causes the code to solve for all points on boundaries within those corners first, then it moves on to the other elements' boundary points.
It then probably tries to fix it by comparison with the larger element's data for inside the dividers, since they're coincident. That's done via the very intensive matrix multiplication which requires lots of RAM for complex models with lots of mesh elements.
There's a small chance that it's getting confused with the smaller elements being close together in miero's examples above 1 kHz.
Here's what happens in AKABAK if I recreate my 100 mm tube in 2D mode. NUC is off, mesh size is 1 mm for the domains, and 0.5 mm bifu with quad ratio = 4 for the observation field.
First up, defining a single element using all four tube corners "1001 1002 1003 1004", then adding the separate driven and anechoic termination (Damping = 1) elements:
To me, it looks like it's adding the values from the calculations from points on the damped element to the reflective element, as a matrix multiplication?
Correcting the elements to create two planes using nodes "1001 1002" and "1003 1004" for the tube outer walls gives this:
Rigid reflective termination, same order - single plane for tube walls first:
The latter set up in each case more closely matches the COMSOL model.
Also interesting is the calculation times. Each of those AKABAK models took over a minute to run for a single frequency, but the COMSOL equivalent in FEA took less than a second - even when I ramped the mesh detail up to 1 mm edge length maximum, using triangular elements.
Here's the tube with an open end condition, not sure what element best represents that in COMSOL yet as I'm just playing with it:
That information is going to be cold comfort in two weeks when my trial runs out
Sorry for the huge images, by the way, rapid screenshotting from a 4K monitor. The new forum software makes that way less obnoxious, luckily.
Last edited:
All of mine are 2D.
I don't seem to be able to build a tube like that in axisym mode in AKABAK. Dropping the plane along the x-axis stops it throwing an 'element size zero' error, but then I get a memory access violation with just two Neumann planes at the rightmost and top edges, and a driven plane at the leftmost, even on a new file with nothing else added.
All other models run just fine.
Are you able to share the 'tulip' style horn geometry as some form of CAD file please @mabat? It's a bit cumbersome redoing all the geometry by hand from the Nodes.txt.
I don't seem to be able to build a tube like that in axisym mode in AKABAK. Dropping the plane along the x-axis stops it throwing an 'element size zero' error, but then I get a memory access violation with just two Neumann planes at the rightmost and top edges, and a driven plane at the leftmost, even on a new file with nothing else added.
All other models run just fine.
Are you able to share the 'tulip' style horn geometry as some form of CAD file please @mabat? It's a bit cumbersome redoing all the geometry by hand from the Nodes.txt.
In the axisymmetric mode you have to omit the bottom element, which is not really there - the geometry is "closed" by rotating the defined elements around the x-axis. That's the whole point of the CircSym mode. So it's actually 3D, but symmetric by definition (and quite fast).
DXF examples attached (exported from Fusion 360, contain splines so may not be readable everywhere).
DXF examples attached (exported from Fusion 360, contain splines so may not be readable everywhere).
Attachments
Last edited:
Yup, aware of that since it causes the element zero error. But skipping that part fails to mesh. It draws the symmetrical product just fine.
Welcome to try it; just four nodes needed (in mm):
0,0,0
100,0,0
100,40,0
0,40,0
Join all but the bottom x-axis edge in circ sym and see if it meshes. I'm curious if it throws an error for anyone else, since it's a little vague.
Thanks for the DXF. I'll try to have a go tomorrow.
Welcome to try it; just four nodes needed (in mm):
0,0,0
100,0,0
100,40,0
0,40,0
Join all but the bottom x-axis edge in circ sym and see if it meshes. I'm curious if it throws an error for anyone else, since it's a little vague.
Thanks for the DXF. I'll try to have a go tomorrow.
I don't understand your coordinates, as only two (axial, radial) are required. It should be: <point_tag> <axial> <radial>
It seems you try to define it as X,Y,Z, which won't work.
I've never encountered any problem with meshing in the CircSym mode. It just subdivides all the line segments.
It seems you try to define it as X,Y,Z, which won't work.
I've never encountered any problem with meshing in the CircSym mode. It just subdivides all the line segments.
Last edited:
They're entered as axial, radial, z in AKABAK's axisymmetrical mode:
The z coordinate is ignored unless you change simulation mode, in which case they get translated.
It renders as you'd expect:
But even using just two coordinate nodes, and a single plane between them causes the error:
I just found out why; it happens if you enable the 'axial' symmetry option:
Although nothing renders in the symmetry view mode to suggest why that would be. No mention of what it's meant to do in the manual, either.
Anyway, hopefully my stupidity helps prevent someone else hitting the same problems
The z coordinate is ignored unless you change simulation mode, in which case they get translated.
It renders as you'd expect:
But even using just two coordinate nodes, and a single plane between them causes the error:
Code:
ERRORS ------------------------
Access violation at address 0000000001E4F6A6 in module 'AKABAK.exe'. Read of address 0000000000000000
Solving abortedI just found out why; it happens if you enable the 'axial' symmetry option:
Although nothing renders in the symmetry view mode to suggest why that would be. No mention of what it's meant to do in the manual, either.
Anyway, hopefully my stupidity helps prevent someone else hitting the same problems
