Liebe Mitleserinnen, Mitleser, Foristinnen und Foristen,
wer sich von Euch in letzter Zeit mit dem Gedanken getragen hat, Mitglied unseres wunderbaren IGDH-Forums zu werden und die vorher an dieser Stelle beschriebene Prozedur dafür auf sich genommen hat, musste oftmals enttäuscht feststellen, dass von unserer Seite keine angemessene Reaktion erfolgte.
Dafür entschuldige ich mich im Namen des Vereins!
Es gibt massive technische Probleme mit der veralteten und mittlerweile sehr wackeligen Foren-Software und die Freischaltung neuer User ist deshalb momentan nicht mit angemessenem administrativem Aufwand möglich.
Wir arbeiten mit Hochdruck daran, das Forum neu aufzusetzen und es sieht alles sehr vielversprechend aus.
Sobald es dies bezüglich Neuigkeiten, respektive einen Zeitplan gibt, lasse ich es Euch hier wissen.
Das wird auch für alle hier schon registrierten User wichtig sein, weil wir dann mit Euch den Umzug auf das neue Forum abstimmen werden.
Wir freuen uns sehr, wenn sich die geneigten Mitleserinnen und Mitleser, die sich bisher vergeblich um eine Freischaltung bemüht haben, nach der Neuaufsetzung abermals ein Herz fassen wollen und wir sie dann im neuen Forum willkommen heißen können.
Herzliche Grüße von Eurem ersten Vorsitzenden der IGDH
"Only periodic solutions to the wave equation are considered,
Schade
Zur Fehlersuche wäre es auch nur so bedingt nützlich, wenn dort ein anderer Solver zugrunde läge.
Zitat von java4ever
Feedback ist immer gerne gesehen. Entweder direkt oder hier über mich, geht auch.
Werde ich mir merken. Mir fällt da gerade nur eine Kleinigkeit ein, das Spiegeln von BE_Spectrum mit einer PolarRange. Wäre ein kleiner Gewinn an Performance.
Zitat von java4ever
Tut es. Entweder manuell oder automatisch.
Das ist der Grund, warum man mit dem Design von Hörnern auch gut Geld verdienen kann.
Apropos automatisch. Du hattest mal ein Optimierungsskript für Waveguides erwähnt. Was ist denn daraus geworden?
Werde ich mir merken. Mir fällt da gerade nur eine Kleinigkeit ein, das Spiegeln von BE_Spectrum mit einer PolarRange. Wäre ein kleiner Gewinn an Performance.
Das kann man doch gemütlich im PostProcessing in VACS machen?
Zitat von nui
Apropos automatisch. Du hattest mal ein Optimierungsskript für Waveguides erwähnt. Was ist denn daraus geworden?
Das läuft soweit, aber mit einer anderen Software.
Ist aber unglaublich komplex da eine sinnvolle Lösung zu bekommen.
Grund 1: Die Auswahl der Parameter.
Nimmt man Beispielsweise mal Interpolationskurve für die Kontur:
Anzahl der Punkte, obere und untere Schranken, Verhindern eines Hinterschnitts, fixierung der Axialen Richtung der Punkte, etc...
Grund 2: Die Anzahl der Parameter
Die Anzahl der Parameter ist praktisch frei variierbar, was es nicht unbedingt einfacher macht.
Grund 3: Die Funktion an sich.
Die Funktion (Ziel vs Ist der Abstrahlung) ähnelt der Eggholder function, hat also viele lokale Minima und ist generell ein Graus zum Optimieren, weil sich Solver gerne festfahren.
Das kann man doch gemütlich im PostProcessing in VACS machen?
Ich würde ganz gerne weniger in Vacs rumfummeln, als noch mehr.
Aber das erinnert mich an eine Frage die ich hatte. Kann in ich die "Direktivität" berechnen lassen? Könnte Frequency response der aktuell ausgewählten Achse minus Power response (adjusted to point source) entsprechen, aber darauf würde ich nicht unbedingt wetten.
Zitat von java4ever
Das läuft soweit, aber
Unterstützt die Optimierung auch achsenasymmetrische konturen?
Hast du Beispielergebnisse? Ist was erfolgreiches oder vielleicht etwas unterhaltsames dabei?
Ich bin jedenfalls interessiert daran.
"Only periodic solutions to the wave equation are considered, thus the time-dependent velocity potential Ψ(p,t) can be reduced to a sum of components each of the form
ψ(p,t) = Reϕ(p)e^(−iωt )"
Heißt in Kurzform: Die e^(-iωt) Periodizität der Lösung an jedem Punkt wird vorausgesetzt (nicht ganz passend, aber passend für das Forum...)
Das heißt im Umkehrschluss aber, dass wir aufgrund dieser Bedingung die statischen Lösungen in eine periodische Animation umwandeln können, erfordert nur viel Rechenaufwand und einen nicht gerade unerheblichen Implementierungsaufwand.
Ok, die Rechnerei ist dann doch etwas aufwändiger, weil n=3, aber ihr wollt euch doch nicht anstellen, oder?
Alle möglichen Problemchen lassen sich durch Felder visualisieren, wenn auch manchmal weniger anschaulich. Kantenbrechung? Feld(er) senkrecht zur Kante, hinter der Kante (von der Schallquelle aus gesehen) gibt es bei Brechung eine Abschattung.
Genauso im Waveguide/Horn: Ein Feld horizontal, ein Feld vertikal, eines auf dem Interface, schon sieht man ziemlich gut, was sich da drin abspielt.
Ich hatte meine Probleme letztlich auch teilweise mit Fields lösen können, aber auch nur teilweise. Ich hab nur die Vermutung aussgesprochen, dass manche Macken und Zusammenhänge mit einer Animationen einfach direkt und offensichtlich werden. Der entscheidende Unterschied in visueller Hilfestellung wäre vielleicht die erste Welle. Wir haben in ABEC und Fields ja eher etwas wie eine relativ stabile periode oder sowas, sowas wie ein Endergebnis, wenn ich das nicht falsch verstanden habe und das wäre ja auch vernünftig.
Wenn ich aber zB Ausschlöschungen auf 0°-Achse einer waveguide relativ zum Mikrofonabstand habe würde mir die erste Welle das vielleicht direkt zeigen. Oder wenn ich meine Interfacenormale, Driving Direction oder meine Subdomains verbockt habe, würde mir das teilweise sofort auffallen, wenn ich sehen könnte, wie die Welle völlig abgefahrenen Blödsinn veranstaltet. Ebenso könnte ich mir anschauen wie lang der akustische Weg einer gefalteten Transmissionline oder (tapped-)horn wirklich ist und ein visuelles Verständnis gewinnen.
Es wäre lediglich ein optisches Tool für weitere Informationen.
Dies lässt sich vermutlich alles irgendwie von Fields oder sonstigen "Messungen" ableiten, aber das alleine überzeugt mich aktuell nicht davon, dass eine weitere Stütze nicht nützlich wäre.
herzlichen Dank für die ausführliche Behandlung der ABEC-Bedienung! Das kommt mir sehr entgegen bei der eigenen SBA-/DBA-Simulation.
Gelegentlich wird die Wanddämpfung erwähnt, die ABEC in der Solvingdatei verarbeitet. Z.B.:
WallImpedance "Damping of Wozi"
RefElements="Wozi"
ImpType=Reflection
Value=0.98
Ich habe keine Angabe zu halbwegs realen Zahlen für Wohnräume im Tieftonbereich gefunden. Welchen Wert kann man Value zuweisen? Gibt es einen einfachen Zusammenhang zwischen Nachhallzeit und diesem Wert?
Die Reflexion ist entsprechend reziprok zum angegebenen Absorptionsgrad (siehe hier):
Die Schallabsorption wird durch den Schallabsorptionsgrad alpha (α) ausgedrückt, welcher einen Wert zwischen 0 und 1,00 haben kann. Null bedeutet keine Absorption (100 % Reflexion) und 1,00 bedeutet vollständige Absorption (0 % Reflexion). Weitere wichtige Indikatoren der Schallabsorption sind:...
Der Schallabsorptionsgrad lässt sich auf zwei unterschiedliche Arten ermitteln - im Hallraum und mit der Kundtschen Rohrmethode. Messungen im Hallraum erfolgen in einem großen Raum mit einem diffusen Schallfeld, damit die Einfallswinkel des Schalls auf die Prüfoberfläche gleichmäßig verteilt sind. Das Messverfahren folgt der internationalen Norm DIN EN ISO 354 und bildet in der Regel die Basis für gesicherte Produktinformationen. (Messungen nach dem entsprechenden US-Standard ASTM C 423 ergeben oft etwas höhere Werte). Die Schallabsorption wird ausgedrückt durch den Schallabsorptionsgrad α oder die Schallabsorptionsklasse (A bis E) gemäß DIN EN ISO 11654.
Ich denke es ist ein guter Anfang, wenn Du mit den an die oben verlinkten Tabellen angelehnten Werten loslegst.
Danke Christoph,
tatsächlich gibt es viele Werte, auch wenn sie teils widersprüchlich sind, vielleicht, weil schwer zuverlässig zu bestimmen.
Für die normalen Wände und den korkbelegten Fußboden kommt man bis 150Hz wohl mit 9.99 als Reflektions- bzw. 0.01 als Absorptionskoeffizient zunächst hin.
Vielen Dank und Gruß, Timo
probiere aktuell mal wieder ein Gehäuse in ABEC zu simulieren.
Möchte einen einfachen Tieftöner in ein Kugelgehäuse mit einem vorgesetzten Breitbänder in ABEC simulieren. (Viertelmodell)
Irgendwie wird mir nach Dim=CircSym nix mehr in "Drawing" angezeigt.
Bin mir außerdem noch unschlüssig, wie ich die Treiber richtig auf das Gehäuse-Mesh setzen kann.
der Solver hat sich nun erstmal ohne Fehlermeldung starten lassen und rechnet jetzt ein paar Stunden. Derweil kann ich noch ein paar Fragen los werden:
- Woher bekommt man den Wert für expoRe und expoLe, wenn man kein Akbak installieren kann? (hab Win10)
- Wenn man für das Gehäuse ein externes Mesh erstellt und die Membran via Edge Length vernetzt ist, welchen Einfluss hat die Meshing Frequency im Solver noch? (würde vermuten keinen)
- Wieso wird vor dem Treiber noch die Fläche der Baffle angezeigt, ist das ein Grafikfehler oder hab ich da was falsch gemacht?
- Wieso wird bei CircSym die Geometrie ausgeblendet? ...
Wenn ich das richtig verstanden habe, müsste dass die Wellengleichung für mein rotationssymetrisches Teil viel schneller Lösen?
-Muss die Rückseite des Treibers zwingend auf der inneren Baffle aufliegen, oder damit abschließen?
Viele Grüße
Inco
PS: Der Link zum Modell auf Dropbox ist weiterhin aktuell.
Geändert von incoggnito2 (26.02.2018 um 19:29 Uhr)
PS:@Mod:Falls es besser ist einen eigenen Thread aufzumachen,dann bitte einfach verschieben.
Nee, Deine Frage passt doch perfekt hier her.
Irgendwie wird mir nach Dim=CircSym nix mehr in "Drawing" angezeigt.
Guck mal hier im Thread nach - Nils hatte an einer stelle darauf hingewiesen, dass es mit der CircSim-Funktion in ABEC noch Probleme gibt. Ich hatte dann davon abgesehen, mit CircSim zu arbeiten. Vielleicht liest er hier mit und kann Dir einen Hinweis geben.
PS: Der Link zum Modell auf Dropbox ist weiterhin aktuell.
Vielen Dank. Ich habe Dein Modell runtergeladen, komme aber frühestens am Wochenende dazu, mich damit zu beschäftigen. Melde mich dann...
Guck mal hier im Thread nach - Nils hatte an einer stelle darauf hingewiesen, dass es mit der CircSim-Funktion in ABEC noch Probleme gibt. Ich hatte dann davon abgesehen, mit CircSim zu arbeiten. Vielleicht liest er hier mit und kann Dir einen Hinweis geben.
OK, falls es noch nicht geht freue mich um so mehr auf eine neue Version mit GPU-Beschleunigung.
Vielen Dank. Ich habe Dein Modell runtergeladen, komme aber frühestens am Wochenende dazu, mich damit zu beschäftigen. Melde mich dann...
Nö, ich hab zu danken
Hab heute morgen die Ergebnisse bis 2khz erhalten... Sieht interessant aus...
Der BB hat wohl noch keinen Saft bekommen... egal der Crossover fehlt sowieso noch...
Lass heute während ich arbeiten bin gleich mal das Netz bis 10kHz rechnen und stell es dann nochmal online... Zieh dir am Woe am besten nochmal die aktuellste Version
Das Ergebnis sieht nicht ganz schlecht aus. (Lasse mich aber gern eines besseren belehren )
Arbeite heute noch an dem Contour-Plot und der Umsetzung der Frequenzweiche.
Ok, ich hoffe du findest meine Fehler ... bekomme immer nur die Antwort vom Tieftöner ... schätze mal, ich mach da irgendwas im LE-Skript falsch.
Würde gerne die zwei hinterlegten Treiber mit einer 6dB Weiche bei 800Hz verheiraten.
Ok, ich hoffe du findest meine Fehler ... bekomme immer nur die Antwort vom Tieftöner ... schätze mal, ich mach da irgendwas im LE-Skript falsch.
So weit ich das sehen kann, ist das LE-Skript ok.
Ich vermite das Problem liegt daran, dass Du 2 'Exterior Subdomains' definiert hast, obwohl TT und HT auf die selbe Subdomaine abstrahlen. Ich habe das hier geändert, indem ich die Definition der Subdomain 3 rausgenommen habe und dem HT die Subdomein 1 zugeordnet habe:
ImpType=Damping
Value= is a floating point value between 0...1.0.
Value=0 means no damping and Neumann boundary conditions, which is the default in ABEC.
Value=1 means 100% damping, which are boundary conditions equivalent to an impedance of a free traveling plane-wave: Zs = ρc.
Ist vielleicht zunächst einfach so beabsichtigt, Du solltest damit jedoch eine ordentliche Resonanz im Kugelgehäuse sehen.
Ich habe auch noch nie den Membranrückseiten eine Dämpfung zugeordnet. Ich weiß nicht, ob dies ein Problem ist, würde dies jedoch selber nicht machen, sondern auschließlich den Gehäuse-Innenwänden eine Dämpfung zuordnen.
Eine 6dB-Weiche schreibe ich Dir noch auf für's LE-Skript...
Ich vermite das Problem liegt daran, dass Du 2 'Exterior Subdomains' definiert hast, obwohl TT und HT auf die selbe Subdomaine abstrahlen. Ich habe das hier geändert, indem ich die Definition der Subdomain 3 rausgenommen habe und dem HT die Subdomein 1 zugeordnet habe:
Das sollte eigentlich kein Problem sein, ist aber eine mögliche Fehlerquelle.
Zitat von Gaga
Leider konnte ich nicht testen, da mein Compi gerade ein Leistungsproblem hat, mache das aber, sobald das gelöst ist.
Bald wirds schneller, versprochen
Zitat von Gaga
Ich habe auch noch nie den Membranrückseiten eine Dämpfung zugeordnet. Ich weiß nicht, ob dies ein Problem ist, würde dies jedoch selber nicht machen, sondern auschließlich den Gehäuse-Innenwänden eine Dämpfung zuordnen.
Dazu ein absolutes Nein!
Denn: Sowohl das Driving der Membran ist eine Geschwindigkeitsrandbedingung als auch die Impedanz...
Das beißt sich und geht nur über krude Vibroakustikansätze.
Hab' das gerade mal für 200 Frequenzen bis 5kHz durchgerechnet (00:05:04, mit Luft nach oben )
Hab' das gerade mal für 200 Frequenzen bis 5kHz durchgerechnet (00:05:04, mit Luft nach oben )
Beste Grüße
Woooow! Ach du heiliges Kanonenrohr! Hast du das also mit einer Beta Version für GPU solving gemacht? WEißt du schon näheres, wann es etwa kommen soll? Kann man auch schon sagen, wie es im Vergleich zu CPU solving ist? Sprich Mittelklasse CPU vs. Mittelklasse GPU? Welche Grafikkarten eignen sich besonders dafür?
Grüße
"Post with a Prost" - Schreibe, wie du mit einem Bier in der Hand reden würdest
Woooow! Ach du heiliges Kanonenrohr! Hast du das also mit einer Beta Version für GPU solving gemacht? WEißt du schon näheres, wann es etwa kommen soll? Kann man auch schon sagen, wie es im Vergleich zu CPU solving ist? Sprich Mittelklasse CPU vs. Mittelklasse GPU? Welche Grafikkarten eignen sich besonders dafür?
Grüße
Hüstel... Ja, es ist eine interne Beta (CPU basiert).
Ich kann absolut nicht voraussagen, wann GPU Solving kommen wird. Dazu gibt es aktuell zu viele Unbekannte.
Wenn GPU Solving kommt, dann vermutlich auch vorerst nur mit eingeschränkten Möglichkeiten, die nach und nach erweitert werden.
Eine Mittelklasse GPU (AMD R9 390X) ist aktuell etwa um Faktor 2-4x schneller, als eine Oberklasse CPU (AMD Ryzen Threadripper 1950X).
Grundsätzlich eignen sich Grafikkarten ab der Mittelklasse dafür. Ab 6GB VRAM wird es sinnvoll.
Anmerkung: Bis das auf jedem GPU Modell ordentlich läuft, dauert es. Vor allem, da wir natürlich nicht einfach jede Generation kaufen können, um da rumzuoptimieren.
Der Wermutstropfen: Es steht noch nicht fest, ob die GPU Möglichkeiten für Free-User überhaupt oder in welchem Umfang freigeschaltet werden, da da doch beträchtlich(!!) Arbeit hintersteckt.
Generell wird vermutlich zweigleisig gefahren: Einmal der "alte" ABEC Solver und einmal ein neuer, der parallel entwickelt wird und auf einer anderen Formulierung beruht.
Bezüglich der CPU-basierten Variante des neuen Solvers sieht es aber gut aus für Free-User.
Noch eine Anmerkung: Der Code wird vermutlich auf AMD Prozessoren nochmal effizienter laufen, als auf Intel Prozessoren, schlicht, weil aktuell keine moderne Intel-Maschine zur Verfügung steht, auf der optimiert werden könnte.