[WC] ProCAST simulatie van een waterblok

[JumpStart]

* JumpStart zit met het volgende in gedachten:

Aangezien er op mijn werk een licentie is voor Pro/CAST, leek het me interessant om, als vingeroefening en als variatie op waar ik zelf mee bezig ben, me eens in m'n eigen tijd bezig te houden met eerder genoemd simulatie pakket. (Ik werk als student assistent part-time al met DEFORM 3D, maar ik wil ook eens iets anders proberen...)

Pro/CAST is een wetenschappelijk simulatie pakket, gebaseerd op de zogenaamde 'eindige elementen methode' en het wordt voornamelijk gebruikt voor simulaties van metaalgiet processen.

Het idee dat ik als projectje uit wil werken:

Het simuleren van een koelblok / enkele koelblokken en kijken of dit overeen komt met de realiteit, en eventueel 2 of 3 simulaties doen voor onderlinge vergelijking.

Met Pro/ENGINEER is redelijk snel genoeg een model van een waterblok gemaakt, en daarna begint het lastiger werk om alle randvoorwaarden op te geven voor de simulatie zelf: vloeistofstroming èn warmtegeleiding. Nu is materiaalkeuze simpel: aluminium, koper, of aluminium met koperen basis. Maar er zijn nog andere 'grootheden' waarover ik wat feedback nodig heb.

- Wat is ongeveer de effectieve doorvoer van koelwater ? Hoeveel liter per minuut ? (En nee, dan wil ik niet weten hoeveel de pomp aankan zonder tegendruk.)

- Hoeveel watt aan warmte zal ik introduceren in het systeem ? Ik zit zelf te denken aan 50 of 100 watt oid, waarbij die warmte geintroduceerd wordt onder een heatspreader (P4 en toekomstige hammers).

Ik kan niet "zo maar even" een nieuwe simulatie draaien, omdat die krengen behoorlijk wat rekentijd (kunnen) vergen, en vooral ook behoorlijk veel aan opslag vergen, dus ik moet van te voren keuzes maken. Ik kan niet ALLES proberen. Van te voren afwegen wat interessanter zal zijn:

- Verschil bekijken tussen aluminium en koper ? OF
- Dunne vs dikke bodem ? (heat spreading/afvoeren vs snelle directe koeling) OF
- 'lege' kamer vs kamer met ribbels/putten vs lang vloeistofpad OF
- ...

En ga zo nog maar even door.

Ik sta ook open voor ontwerpen van buitenaf, MITS ze serieus en goed doordacht uitgevoerd zijn!. Een ASCII tekening hier presenteren, daar begin ik niets mee, het moet wel als IGES of als STL file aangeleverd worden. Zeggen deze bestandsformaten je niets, laat dan maar zitten.

( En tenslotte: Het wil nog wel eens gebeuren dat goede voornemens voortijdig stranden, dus ga er niet nu al vanuit dat ik met een geile review kom met simulatie resultaten... Zo ver komt het misschien niet eens, maar ik wil het in ieder geval eens proberen. Het zou kunnen dat ik strakkies alleen maar wat plaatjes en grafiekjes heb van slechts 1 koelblok, zonder verdere vergelijkingen, maar dat zie ik dan wel weer. )

[Selachii]

mail me [e-mail]

[Verwijderd]

Op vrijdag 26 april 2002 01:00 schreef JumpStart het volgende:
- Wat is ongeveer de effectieve doorvoer van koelwater ? Hoeveel liter per minuut ? (En nee, dan wil ik niet weten hoeveel de pomp aankan zonder tegendruk.)

In mijn systeem haal ik ongeveer 150-200L/uur, dus da's ca. 3L/minuut. Overigens zie ik graag het verschil tussen 2L/minuut en 5L/minuut ofzo. Ik heb zelf namelijk het idee dat het maar verdomd weinig scheelt.

- Hoeveel watt aan warmte zal ik introduceren in het systeem ? Ik zit zelf te denken aan 50 of 100 watt oid, waarbij die warmte geintroduceerd wordt onder een heatspreader (P4 en toekomstige hammers).

Mooi zou zijn:
100W op een vierkante centimeter, en 300W op 16 cm² (40x40mm). De eerste simuleert een heel dik overgekloke Athlon core, de tweede een 172W peltier met draaiende processor er onder.

Wat het opervlak van een standaard P4 heatspreader is weet ik zo gauw niet.

Ik kan niet "zo maar even" een nieuwe simulatie draaien, omdat die krengen behoorlijk wat rekentijd (kunnen) vergen, en vooral ook behoorlijk veel aan opslag vergen, dus ik moet van te voren keuzes maken.

Vertel mij wat. Zie onder..

- Verschil bekijken tussen aluminium en koper ? OF
- Dunne vs dikke bodem ? (heat spreading/afvoeren vs snelle directe koeling) OF
- 'lege' kamer vs kamer met ribbels/putten vs lang vloeistofpad OF

Bodemdikte is interessant. Alu vs. koper niet zo, aangezien die voor vrijwel niemand interessant is. De meest selfmade Alu blokken worden gebouwd uit constructiealuminium dat het verdomd slecht doet kwa warmtegeleiding. En het is ook weer voor elk legeringkje anders. Het koper dat er gebruikt word is meestal E-Cu57, da's 99.8% koper. Wat die andere 0.2% voor materiaal is weet ik niet.

Ribbels en putten zijn ook interessant, maar als je alleen als je turbulentie mee gaat nemen in je simulatie. En dat gaat je veel rekentijd kosten...

Het zou kunnen dat ik strakkies alleen maar wat plaatjes en grafiekjes heb van slechts 1 koelblok, zonder verdere vergelijkingen, maar dat zie ik dan wel weer. )

Oh, zelfs dat is vreselijk interessant. Ik wil heel, heel graag een 3D volumeset hebben wat de hitteverdeling door het blok. Welk blok dan ook. Als ik het bij blok A zie, dan kan ik het bij blok B wel voorspellen.


Nu je het hier toch over hebt, ik heb ooit geprobeerd om dergelijke simulaties te doen met mijn radiosity-processor voor m'n 3D engine (deze distribueert energie iteratief). Het blok was gemodelleerd als blokjes van een vaste grootte (1x1x1mm), en de energieuitwisseling gebeurde d.m.v. geleiding.

Dit was leuk, maar de radiosityprocessor was na een nacht rekenenen nog niet op 20% van de form-factor calculations (berekenen hoeveel energie er van elementje A naar elementje B stroomt), en het geheugengebruik zat boven de 3GB. Omdat ik de software zo snel niet gecompileerd kon krijgen voor Sun SPARC (endianness problemen), ben ik er maar mee gestopt. Ik heb er nog wel even aan gedacht om er een Navier-Stokes CFD core in te duwen (komt in 3D engines ook van pas om smoke en fire te simuleren), maar dat kostte me toch iets teveel werk, en die Navier-Stokes CFD simulaties zijn ook lichtelijk tijd- en geheugenconsumerend.

Toch vind ik CFD vreselijk interessant, dus wie weet

[JumpStart]

Op vrijdag 26 april 2002 12:06 schreef Selachii het volgende:
mail me [e-mail]

[afbeelding van een mooi waterblokje]

Kijk eens aan, dit is een stap in de goeie richting!

Echter, als je kaas gegeten hebt van FEM simulaties (Finite Element Method) dan weet je dat het voor een groot deel 'de kunst van het weglaten is'. Dus, hier zijn een aantal aanwijzingen:

- Laat richels en putjes voor het veroorzaken van turbulentie weg. Turbulentie is "duur" in simulatie termen, zowel in rekenkracht, opslag als in 'oplosbaarheid' van de numerieke analyse. Bovendien moet overal minimaal 3 volume elementen 'passen'. Dunne richels dus ook minimaal 3 elementen dik zijn. Dan kan je hoeveelheid elementen echt absurd oplopen als je niet uitkijkt.

- Ditto: laat de gaten voor bevestiging weg. Ik ben niet geinteresseerd in spanningsverdeling en dergelijke, dus ik maak me niet druk over bevestiging. De kleine wijziging zal wel een ietsje andere temperatuursverdeling veroorzaken, maar dat verschil is miniem.

- Maak het waterblok uit één stuk. Ja, een plexiglas deksel is leuk, maar het betekent ook dat ik meer objecten moet introduceren, en interacties tussen objecten moet aangeven, randvoorwaarden enz. enz. Gewoon massief, en voor het gemak het deksel gewoon eraan vast.

- Zorg trouwens ook voor aansluitingen, gewoon twee gaten in het deksel. (Ook weer een overweging van hoeveelheid volume elementen, dus vergeet de 2 stukken buis die nog op de deksel zou moeten zitten.) Eventueel een 'protrusion' van een halve centimeter 'tube', niet dunwandig, om het toch nog mooi te maken.

- Het liefste werken met Pro/ENGINEER, maar ja, dat heeft niet iedereen tot z'n beschikking. IGES en STL files zijn in ieder geval goed te importeren in MESHCast (waarmee de mesh, de volume elementen, gegenereerd worden.)

[JumpStart]

Op vrijdag 26 april 2002 12:10 schreef DaBit het volgende:

[..]

In mijn systeem haal ik ongeveer 150-200L/uur, dus da's ca. 3L/minuut. Overigens zie ik graag het verschil tussen 2L/minuut en 5L/minuut ofzo. Ik heb zelf namelijk het idee dat het maar verdomd weinig scheelt.

Mja, dan doet zich het volgende probleem voor: Ik was van plan om gewoon, als randvoorwaarde op te geven bij de instroom-opening dat er X liter per minuut binnenstroomt, met een temperatuur van Y. (50 ml/sec en 22 °C, daar zat ik aan te denken.)

Natuurlijk zal het uitmaken als ik er ineens 100 ml/sec van maak. Maar dat is niet bepaald realistisch: hogere water doorvoer betekent ook dat het een kortere tijd in de radiator zit. Ik weet dus niet of die 22°C dan nog wel zou kloppen.

[..]

Mooi zou zijn:
100W op een vierkante centimeter, en 300W op 16 cm² (40x40mm). De eerste simuleert een heel dik overgekloke Athlon core, de tweede een 172W peltier met draaiende processor er onder.

Wat het opervlak van een standaard P4 heatspreader is weet ik zo gauw niet.
[..]

Hier zit ik te denken aan een ruwe benadering van 20x20 mm heatspreader, 1 mm dik, met aan de onderkant, in het midden, op 100 mm² een introductie van 100 watt. Dan kan je mooi aan de temperatuur van de heatspreader zien hoe heet je CPU ongeveer zou zijn.

Als je een lompe TEC nadoet, door op groot oppervlak 250+ watt te dumpen, dan kan je niets meer zeggen over CPU temperatuur, want die zit dan niet meer in het systeem.

[..]

Bodemdikte is interessant. Alu vs. koper niet zo, aangezien die voor vrijwel niemand interessant is. De meest selfmade Alu blokken worden gebouwd uit constructiealuminium dat het verdomd slecht doet kwa warmtegeleiding. En het is ook weer voor elk legeringkje anders. Het koper dat er gebruikt word is meestal E-Cu57, da's 99.8% koper. Wat die andere 0.2% voor materiaal is weet ik niet.

Ribbels en putten zijn ook interessant, maar als je alleen als je turbulentie mee gaat nemen in je simulatie. En dat gaat je veel rekentijd kosten...

Inderdaad, zie mijn andere reply. Dikke richels (relatief dan) zijn nog wel te doen, maar omdat er minstens 3 elementen in een afstand binnen het medium moet passen is het erg tricky om 1 mm dikke schotten te plaatsen...

[..]

Oh, zelfs dat is vreselijk interessant. Ik wil heel, heel graag een 3D volumeset hebben wat de hitteverdeling door het blok. Welk blok dan ook. Als ik het bij blok A zie, dan kan ik het bij blok B wel voorspellen.

Dat gaat zeker lukken, al worden het eerder doorsnedes met isothermen dan een volumeset.

[..]

Dit was leuk, maar de radiosityprocessor was na een nacht rekenenen nog niet op 20% van de form-factor calculations (berekenen hoeveel energie er van elementje A naar elementje B stroomt), en het geheugengebruik zat boven de 3GB. Omdat ik de software zo snel niet gecompileerd kon krijgen voor Sun SPARC (endianness problemen), ben ik er maar mee gestopt. [..]

Je software is verre van optimaal, want zelfs met 300.000 volume elementen moet het binnen een paar honderd MB te houden zijn. Pro/CAST kan het iig prima. Pro/CAST draait trouwens op een dual PIIIEB 1 GHz (serverworks HEsl chipset met dual channel PC133 controller en 1 Gb aan registered ECC RAM). Dan is het een kwestie van een paar uurtjes rekenen denk ik.

[Verwijderd]

Op vrijdag 26 april 2002 13:55 schreef JumpStart het volgende:
Natuurlijk zal het uitmaken als ik er ineens 100 ml/sec van maak. Maar dat is niet bepaald realistisch: hogere water doorvoer betekent ook dat het een kortere tijd in de radiator zit. Ik weet dus niet of die 22°C dan nog wel zou kloppen.

Ik ben helemaal niet geinteresseerd in absolute temperaturen. Warmteweerstanden en de verdeling van de warmteweerstand is veel interessanter. En ik zou best wel willen zien hoe de warmteweestand verandert als het debiet opgevoerd word. Mijn voorspelling is dat het niet significant is, maar dat wil ik graag bewezen zien.

Als je een lompe TEC nadoet, door op groot oppervlak 250+ watt te dumpen, dan kan je niets meer zeggen over CPU temperatuur, want die zit dan niet meer in het systeem.

Je ziet wel waar de knelpunten zitten. zoals eerder gezegd: CPU temp is de minst interessante grootheid van alles wat je uit dat pakket kunt krijgen.

Overigens is dan een simulatie van de CPU core en dezelfde CPU met heatspreader voldoende; dan kun je wel je conclusies trekken.

Dat gaat zeker lukken, al worden het eerder doorsnedes met isothermen dan een volumeset.

Ook al prima

Je software is verre van optimaal, want zelfs met 300.000 volume elementen moet het binnen een paar honderd MB te houden zijn.

Vertel mij wat. Elk 'blokje' waren bij mij 24 'elementen', en in mijn systeem kunnen potentieel alle elementen met alle elementen communiceren. De radiosityprocessor is tenslotte voor licht gebouwd in polygon-based scenes. Niet voor dit werk.

Dan is het een kwestie van een paar uurtjes rekenen denk ik.

Da's toch niet zo lang?

[JumpStart]

Op vrijdag 26 april 2002 14:25 schreef DaBit ook weer een hele lap nuttige feedback:

[..]

Het meeste werk zit 'em in het opzetten van de simulatie. En omdat ik voor mijn werk met DEFORM 3D werk zal ik dus of wat tijd moeten roven van een van mijn collega's, of ik moet het allemaal opnieuw uit gaan zoeken voor Pro/CAST.

Als de simulatie eenmaal is opgezet kan ik relatief eenvoudig de randvoorwaarde voor de bodem aanpassen door warmteintroductie aan te passen.

Het probleem erna is ook "between Keyboard and Chair" omdat ik geen Post/CAST kan draaien op mijn eigen computer. Resultaten moet ik dus ook op een PC waar normaal een collega op werkt ervoor gebruiken.

Hoe meer ik erover nadenk, hoe meer ik neig naar het zo eenvoudig mogelijk houden, dus betekent een heatspreader extra moeite die ik liever uitsluit.

Dan blijf ik in m'n maag zitten met welke vrijheidsgraden ik kan spelen...

- 100 watt op 10x10 mm (100 mm²)
- 300 watt op 40x40 mm (1600 mm²)

( En mogelijk 100 watt op 20x20 mm (400 mm²) ook nog)

- 50 ml/sec (3 liter per minuut)
- 100 ml/sec (6 liter per minuut)

- koelblok met dikke (5 mm) basis
- koelblok met dunne (1,5 mm) basis

- Tegenstroom (ingang aan de buitenkant)
- Meestroom (ingang boven de core)

- Vrije stroming, kort breed pad (weinig weerstand)
- Lang smal pad (meer stromingsweerstand)

Alles bij elkaar zou dit genoeg zijn voor 32 simulaties (of 48, als ik 400 mm² ook zou doen), waarbij ik 3 van de 5 vrijheidsgraden relatief snel en eenvoudig zou kunnen aanpassen. De andere 2 vergen ook het compleet opnieuw opzetten van de simulatie, want dat zijn 2 verschillende ontwerpen/modellen.

Kijken naar slechts 2 vrijheidsgraden, dat gaat nog wel lukken. Maar 5 ?? Nee, dat feest gaat niet door. Dus er moeten keuzes gemaakt worden: wat is interessanter om te weten.

[EDIT] Dabit, hier een review die debiet vs temperatuur hebben voor verschillende koelers:

ProCooling.com S370 waterblock round-up.

[JumpStart]

Ik heb zelf ook even zitten klussen, een 'intieme worsteling' met Pro/ENGINEER 2001...





Wat 'specs'

blok afmetingen: 60x60x20 mm
bodemdikte: varieert, minimaal 2 mm
dikte 'deksel': 2 mm
buizen: ext. 10 mm diameter, int. 8 mm diameter.
rondingen: radius 10 mm.

buizen steken 10 mm uit.

De buis in het midden loopt expres door tot halverwege de kamer, stopt niet bij de deksel.

[AproK]

Op zaterdag 27 april 2002 20:30 schreef JumpStart het volgende:
Ik heb zelf ook even zitten klussen, een 'intieme worsteling' met Pro/ENGINEER 2001...

[afbeelding]

[afbeelding]

Wat 'specs'

blok afmetingen: 60x60x20 mm
bodemdikte: varieert, minimaal 2 mm
dikte 'deksel': 2 mm
buizen: ext. 10 mm diameter, int. 8 mm diameter.
rondingen: radius 10 mm.

buizen steken 10 mm uit.

De buis in het midden loopt expres door tot halverwege de kamer, stopt niet bij de deksel.

zeer mooie blokjes
echt veel kan ik niet meer zeggen, want wat ik wou zeggen, is al gebeurt door dabit

edit, probeer anders ook eens van die echte standaard zelf made blokjes, kijken hoe die het doen... (dus de simpele blokjes)

[ajampaniki]

is het ook mogelijk om cad-files te sturen?

[JumpStart]

Op zaterdag 27 april 2002 20:43 schreef ajampaniki het volgende:
is het ook mogelijk om cad-files te sturen?

Om te beginnen kan ik niet een hele reeks blokken doorrekenen. Dus ga er niet van uit dat jou blokkie ook gesimuleerd kan worden. Ik moet tenslotte tijd van mijn collega's roven voor dit eigen 'projectje', dus als ik 2 of 4 simulaties kan doen, dan ben ik al tevreden.

( Het aantal simulaties dat ik zal kunnen doen hangt af van hoe goed, als in: hoe makkelijk en hoe snel, de simulaties van water-stroomt-door-koelblok zijn op te zetten en door te rekenen. Ook het zogenaamde 'post-processing', het analyseren en goed presenteren van de gegevens kan veel tijd in beslag nemen. )

Pro/CAST software, of eigenlijk dus Mesh/CAST, een onderdeel van het pakket Pro/CAST, moet een Pro/ENGINEER file hebben (.PRT bestand) en kan daarnaast, maar dat is minder ideaal, IGES en STL bestanden importeren. Iets anders kan helaas niet.

[Verwijderd]

Is Pro/CAST eigenlijk gebaseerd op een radiosity(achtig) algorithme, of gebruikt het een of ander CFD algorithme?

[JumpStart]

Op zaterdag 27 april 2002 21:00 schreef DaBit het volgende:
Is Pro/CAST eigenlijk gebaseerd op een radiosity(achtig) algorithme, of gebruikt het een of ander CFD algorithme?

AERGHH, daar vraag je me wat... Ik haal de 2 belangrijke methodes altijd door elkaar.

Methode 1 = je mesh ligt vast, vloeistof/gas stroomt van element naar element. Als ik me niet vergis is dit de Eulerische methode.

Methode 2 = je mesh vervormt mee, en moet regelmatig opnieuw gegenereerd worden: "(updated) Lagrangian" formulatie, en dat is dus wat DEFORM 3D toepast, en waar ik dus mee werk.

Pro/CAST is dus in ieder geval Eulerische formulatie. Welke exacte methodes er gebruikt worden voor de vloeistof stroming en de thermische geleiding (die 2 worden los van elkaar opgelost, en dan gekoppeld voor de volgende rekenstap) weet ik niet uit mijn hoofd.

Radeosity is volledig de verkeerde weg, want zowel bij vloeistof stroming als bij warmtegeleiding is het echt niet nodig dat het element aan de ene kant van het object 'contact' heeft met elementen aan de compleet andere kant.

[Verwijderd]

Op zaterdag 27 april 2002 21:15 schreef JumpStart het volgende:
AERGHH, daar vraag je me wat... Ik haal de 2 belangrijke methodes altijd door elkaar.

Methode 1 = je mesh ligt vast, vloeistof/gas stroomt van element naar element. Als ik me niet vergis is dit de Eulerische methode.

Methode 2 = je mesh vervormt mee, en moet regelmatig opnieuw gegenereerd worden: "(updated) Lagrangian" formulatie, en dat is dus wat DEFORM 3D toepast, en waar ik dus mee werk.

Welke methode werkt over het algemeen het beste?

Pro/CAST is dus in ieder geval Eulerische formulatie. Welke exacte methodes er gebruikt worden voor de vloeistof stroming en de thermische geleiding (die 2 worden los van elkaar opgelost, en dan gekoppeld voor de volgende rekenstap) weet ik niet uit mijn hoofd.

Als leek zou ik zeggen: particles of blobs.

Radeosity is volledig de verkeerde weg, want zowel bij vloeistof stroming als bij warmtegeleiding is het echt niet nodig dat het element aan de ene kant van het object 'contact' heeft met elementen aan de compleet andere kant.

Dat is ook zo, en uiteindelijk hebben die elementen in de matrix dan ook een koppeling van 0, en worden dus de matrix uitgeknikkerd. Alleen voordat je zover bent...

Agja, zoals al eerder gezegd: ik had een radiosity processor liggen, en het lijkt me nog steeds dat de methode opzich bruikbaar is. Vooral ook omdat de mesh progressief verfijnd word.


Nog even over dat review:
Dat was wat ik weten wilde, en dat gaat jou ook weer een aantal simulatieruns schelen. Je kunt uit dat review prima conclusies trekken over hoe bepaalde blokontwerpen op flow reageren.

[JumpStart]

Op zaterdag 27 april 2002 21:30 schreef DaBit het volgende:

[..]

Welke methode werkt over het algemeen het beste?
[..]

Als leek zou ik zeggen: particles of blobs.
[..]

Dat is ook zo, en uiteindelijk hebben die elementen in de matrix dan ook een koppeling van 0, en worden dus de matrix uitgeknikkerd. Alleen voordat je zover bent...

Agja, zoals al eerder gezegd: ik had een radiosity processor liggen, en het lijkt me nog steeds dat de methode opzich bruikbaar is. Vooral ook omdat de mesh progressief verfijnd word.


Nog even over dat review:
Dat was wat ik weten wilde, en dat gaat jou ook weer een aantal simulatieruns schelen. Je kunt uit dat review prima conclusies trekken over hoe bepaalde blokontwerpen op flow reageren.

Particles of blobs ?

Nahja, laat maar

Als je puur naar warmte geleiding kijkt, dan moet je radeosity links laten liggen. Het zit ook in de naam, to radiate, uitstralen. Dat is pas van nut als je zeer ruim aan de kamertemperatuur voorbij bent.

Jou waterblok doet alleen aan warmtegeleiding en dus mag je alle interacties tussen elementen die elkaar niet direct raken gewoon negeren.

[JumpStart]

Op zaterdag 27 april 2002 21:30 schreef DaBit het volgende:

[..]

Welke methode werkt over het algemeen het beste?
[..]

Problemen waarbij stroming van belang is hebben (vaak) een vastgelegde ruimte waarin de vloeistof kan komen. Gewoon eenvoudig metaal gieten is een goed voorbeeld. Dit laat zich prima simuleren op basis van een vaste mesh (Euleriaans.) Het vloeistof oppervlak wordt weergegeven door elementen een 'vulgraad' te geven, het oppervlak is alle elementen met vulgraad 50%.

Maar nu, wat doe je als je, bij vervorming, geen vastgelegde ruimte hebt en een object zichzelf 'belast' ? Denk even aan het walsen van plaat. Weet jij van tevoren of de plaat naar boven of beneden zwiept ? Nee. In dit soort gevallen ben je beter af met Lagrangische formulatie. Al dan niet met het periodiek opnieuw genereren van de mesh, als die te veel vervormd raakt. Het verplaatsen van de mesh 'maakt' het vrije oppervlak.

Euleriaanse methode heeft veel meer mesh elementen nodig, maar daarvan hoef je maar één keer alle geometrie vast te leggen (4 of 6 coordinaten per element). Lagrangische methode heeft veel minder elementen nodig, maar moet wel per stap alle coordinaten van het vervormende object opnieuw opslaan (plus een hele nieuwe mesh als er een 'remesh' nodig is.)

Tricky situatie is het wanneer je zowel vrij niet-ondersteund oppervlak als stroming hebt: Denk aan aluminium extrusie. De stroming van het (boterzachte) aluminium door de matrijs heen (om zo profiel te maken) is het beste te doen op Eulerische wijze, maar aangezien je niet weet wat het profiel gaat doen, heb je Lagrangische formulatie nodig. Bij dit soort problemen beginnen ze nu pas door te krijgen dat er hybride technieken nodig zijn die beide mechanismes combineren.

_{Maar dit is een béétje off-topic}

[JumpStart]

Ik denk dat onderstaand blokje al iets tè ver doordraaft in detail... Maar toch een mooie variatie op het eerdere ontwerp:

_{Vanwege wanddikte -> element grootte restricties worden de buisjes waarschijnlijk intern 8 mm Ø en extern 12 mm Ø.}

[Verwijderd]

Hmm, alleen vind ik dit blokje suboptimaal. Uitgaande van de observaties in dat waterblok-review, is dit een blok dat pas bij hoge flow tot zijn recht komt.

Ik zou liever een DD-Maze2 ofzoiets zien als blokontwerp voor simulatie.

Op zaterdag 27 april 2002 22:13 schreef JumpStart het volgende:
_{Maar dit is een béétje off-topic}

Heb je pointers naar literatuur (inet, boeken) over die methodes? Ik vind het erg interessant spul.

In dat programma van je zul je trouwens ook op moeten geven wat de diverse warmteoverdrachtscoefficienten zijn. Kun jij die er gewoon uittrekken? Ik ben erg benieuwd naar de overdrachtscoefficienten tussen koper en water, koper en kokend R134a, dat soort dingen.

[Verwijderd]

DaBit:
Overigens zie ik graag het verschil tussen 2L/minuut en 5L/minuut ofzo. Ik heb zelf namelijk het idee dat het maar verdomd weinig scheelt.

Kijk hier in o.a. het derde en zesde tabelletje:
http://www.procooling.com/reviews/html/waterblock_roundup_part1-page4.shtml

Vier keer grotere flow scheelt ongeveer 1~2 graden.
Sommige (slechtere!) blokken hebben een hogere flow nodig.

Echter: het water moet snel door het blok, maar langzaam door de radiator.
Zie vierde tabel: http://www.overclockers.com/articles481/index05.asp

edit: ik zie nu dat de eerste link al eerder gegeven is.

[JumpStart]

Op zondag 28 april 2002 15:49 schreef DaBit het volgende:
Hmm, alleen vind ik dit blokje suboptimaal. Uitgaande van de observaties in dat waterblok-review, is dit een blok dat pas bij hoge flow tot zijn recht komt.

Ik zou liever een DD-Maze2 ofzoiets zien als blokontwerp voor simulatie.
[..]

Want ???

Water komt direct boven CPU binnen, wordt zelfs met een doorgetrokken buis verder omlaag gebracht, rond het centrum is de basis dikker: 20 mm Ø = 4 mm dik, een kegel van 8 mm hoog, en de rest van de kamer is 50 mm Ø, 2 mm dik, behalve dan die schotten. Die trouwens aan de verre kant van de 'afvoer' laag is, en aan de kant van de afvoer zelf hoog, om de stroming wat meer symmetrisch te houden rond het centrum. Ik blijf nog wel even klussen, hier is creatie nummer zoveel:

Heb je pointers naar literatuur (inet, boeken) over die methodes? Ik vind het erg interessant spul.

In dat programma van je zul je trouwens ook op moeten geven wat de diverse warmteoverdrachtscoefficienten zijn. Kun jij die er gewoon uittrekken? Ik ben erg benieuwd naar de overdrachtscoefficienten tussen koper en water, koper en kokend R134a, dat soort dingen.

Ik denk dat dat zoeken in de biblioheek wordt: ik ben namelijk toch vooral Eindgebruiker, ik heb weinig inzicht in de technische achtergrond.

Wat betreft Pro/CAST, die heeft inderdaad een grote database van interface coefficienten. Ik kan dus gewoon aangeven: dit vlak / deze vlakken zijn water-koper overgang, buitenkant is koper/natuurlijke convectie lucht. (forced convection, perslucht erop, kan ook.) Maar goed, het is wel een pakket dat is gemaakt voor simulaties van metaal gieten, dus ik denk niet dat je R134a in de database aantreft...

[JumpStart]

Ik heb eindelijk de juiste link gevonden... Hier dus de info over Pro/CAST:

The ProCAST suite.

[Verwijderd]

Op zondag 28 april 2002 17:39 schreef augustus het volgende:
Echter: het water moet snel door het blok, maar langzaam door de radiator.
Zie vierde tabel: http://www.overclockers.com/articles481/index05.asp

Hmm, ik heb de neiging om te zeggen dat dit alleen maar scheelt bij niet echt realistische condities zoals een hele lage airflow of gruwelijk hoge coolantflow. Volgens mij krijg je dan last van een aantal bijeffecten waar ik zo geen zicht op heb. Het is namelijk volstrekt onlogisch dat een lagere flow beter zou zijn.

Ik blijf van mening dat de beste situatie de je hebben kunt een temperatuursverschil van 1/inf graden (bij 0 graden is er geen warmtetransport meer) tussen elk punt op het waterblok en elk punt op de radiator. Dan is de dT tussen radiator en ambient het grootste, en zal de warmte het efficientste afgevoerd worden. Maarja, vanaf de andere kant is dat mijn boerenverstandmening, niet gestaafd door enige kennis.

Op zondag 28 april 2002 19:19 schreef JumpStart het volgende:

[..]

Want ???

Als ik die test van procooling lees, dan komt dit type blokken pas tot zijn recht bij een hoge coolant flow. Dat is iets waar je moeite mee gaat krijgen om te simuleren (de mesh die de waterstroom modelleert stroomt erg snel -> kleine iteratiestappen -> lange rekentijd. Of zit ik nu uit m'n nek te bazelen?).

Verder vraag ik me af wat nu precies die koperen 'muurtjes' gaan doen. Ze krijgen zeker geen mooie nette flow langs zich heen, dus vrees ik dat de flow zeker aan de leizijde van de 'muurtjes' minimaal is.

Wat niet wegneemt dat ik erg benieuwd hoe de flow verloopt in dit soort blokken.

Een Maze2 of 3 ofzo heeft de banen zodanig liggen dat de flow door heel het blok voorspelbaar en gegarandeerd is.

Die trouwens aan de verre kant van de 'afvoer' laag is, en aan de kant van de afvoer zelf hoog, om de stroming wat meer symmetrisch te houden rond het centrum.

Ik betwijfel dat dat goed lukt met dit ontwerp. Maar opzich is juist daarom dit ontwerp erg interessant om eens te simuleren.

Ik denk dat dat zoeken in de biblioheek wordt: ik ben namelijk toch vooral Eindgebruiker, ik heb weinig inzicht in de technische achtergrond.

Ik zal een vriend van me eens zijn Fluid Dynamics boek afhandig maken.

Wat betreft Pro/CAST, die heeft inderdaad een grote database van interface coefficienten. Ik kan dus gewoon aangeven: dit vlak / deze vlakken zijn water-koper overgang, buitenkant is koper/natuurlijke convectie lucht.

Kun je niet een paar van die coefficienten uit het pakket trekken en hier posten?

[JumpStart]

" .. en we blijven bezig .."

Meer oppervlak is beter, water langer in koelblok is beter, meer water door koelblok is beter ---> DUS een lang(er) koeltraject.

Dan kom je dus al snel op iets as-symmetrisch uit: spiraal, of iets spiegelsymmetrisch, als dit hier, ontwerp nummer zoveel:

[Verwijderd]

Persoonlijk vind ik deze beter

[Verwijderd]

Als jou dit lukt ( het simuleren van waterblokken, koelcapiciteit etc. ) vind ik het echt knap. Maar ik denk dat het toch veel teveel werk is voor 1 of 2 personen :-/

[JumpStart]

Op dinsdag 30 april 2002 12:38 schreef MasterOverdrive het volgende:
Als jou dit lukt ( het simuleren van waterblokken, koelcapiciteit etc. ) vind ik het echt knap. Maar ik denk dat het toch veel teveel werk is voor 1 of 2 personen :-/

Erhh, je hebt het misschien niet helemaal door, maar ik heb (op de faculteit waar ik studeer/werk) collega's die met Pro/CAST werken. De software is er al !, kennis/werkervaring ook. 3 Jaar geleden heb ik zelfs een workshop Pro/CAST gevolgd, dus ik ben er mee bekend. (Al moet ik wel m'n kennis ervan dringend opfrissen.)

Het is dus niet zo dat ik zelf de software ervoor zou willen schrijven/ontwikkelen: ik kan niet/nauwelijks proggen. Maar waarom zou ik het wiel opnieuw willen uitvinden ?

Ik moet alleen maar (nou ja, 'alleen maar' ?) een model van een koelblok (of meerdere) maken, iets wat me wel lukt met Pro/ENGINEER, en dan het model inlezen, meshen (dat is het opdelen in kleine elementen), voorzien van randvoorwaarden, en dan een dual PIIIEB 1 GHz laten zwoegen.

Dan daarna nog even de 'post processor' opstarten voor het presenteren van gegevens over temperatuursverdeling, drukverdeling, stromingspatroon, enz. enz.

[BaRF]

ff 1/2 offtopic: Dat vind ik nou zo vreemd aan mezelf: ik snap echt de ballen van die babbeling van jou en DaBit, maar om de 1 of andere reden lees ik zulke (bv ook het PhaseChange project) met belachelijke intresse!

[JumpStart]

Op dinsdag 30 april 2002 12:35 schreef DaBit het volgende:
Persoonlijk vind ik deze beter

[Afbeelding]

Dan is deez' nog beter:

Breedte koelkanaal = 4 mm
Tussenwand = 3 mm dik
in- en uitgang = 10 mm Ø.
Basis is 3 mm dik
Kanaal is 15 mm hoog
Deksel is 2 mm dik (niet afgebeeld)
Totale dikte = 20 mm dik (nu dus 18 mm)
Lengte x breedte = 60x60 mm.

[JumpStart]

HA!! Eerste poging is nu aan het rekenen op de PC van mijn collega. Had nog best wel wat voeten in de aarde, want de default settings van het programma waren een beetje aan het protesteren.

(Het programma stopt automatisch met 'instroom' van de te vullen ruimte, als de ruimte 100% gevuld is. Dat is tenslotte de bedoelling bij gietsimulaties, je wil niet dat je gietvorm overstroomd. Maar bij koeling moet het juist wèl doorstromen!)

Wat ik hoop te doen is dat ik zelf met Pro/CAST aan de slag kan als eindelijk de workstation versie weer werkt...

Bovenstaand spiraal-koelblok wil ik doorrekenen, en vergelijken met een 'lege' kamer (zoals die nieuwe koper-alu swifttec krengen dus.)

En verder moet er nog getweaked worden aan de opzet: mesh-count mag flink omhoog omdat de mesh nu nog duidelijk te grof is. Maarrrr, het begin is er !

[JumpStart]

KICK flinke trap omhoog.

ProCAST is werkend, maar wil niet meewerken. Hier zal wel niemand zijn die met ProCAST werkt en weet hoe hetvolgende probleem de wereld uitgeholpen moet worden:

code:

DAT2 koel002
DataCAST Version 3.2.0, Revision 1, Compiled on [...]
Flow analysis requires at least one pressure dirichlet bc.

Hier alvast wat plaatjes uit de 'preprocessor' :

Boven: de 'buitenkant', dus het holle blok puur koper.
Onder: de binnenkant, de ruimte waar dus water doorheenstroomt.




Na de eerste poging (bijna 70.000 nodes en meer dan 400.000 elementen) toch maar even wat conservatiever gedaan met de instellingen en er wat vanaf weten te halen, 32.500 nodes en 150.000 elementen ongeveer.

[Selachii]

Dat blok wat ik bovenaan gepost had is deze week af...uhm, gefreest dus...Ik had hem niet speciaal voor jou gemodeleerd ofzo ik wil best meehelpen met een design voor je maken hoor.

[JumpStart]

Op dinsdag 14 mei 2002 19:13 schreef Selachii het volgende:
Dat blok wat ik bovenaan gepost had is deze week af...uhm, gefreest dus...Ik had hem niet speciaal voor jou gemodeleerd ofzo ik wil best meehelpen met een design voor je maken hoor.

Bedankt voor je aanbod hoor, maar nee. Dit is voor mij gewoon een volledig virtueel experiment, om mijn diep weggezakte ProCAST kennis weer eens op te graven. Ik was niet van plan om aan waterkoeling te gaan beginnen. Tenminste, voorlopig nog lang niet.

[Verwijderd]

Op dinsdag 14 mei 2002 19:20 schreef JumpStart het volgende:

[..]

Bedankt voor je aanbod hoor, maar nee. Dit is voor mij gewoon een volledig virtueel experiment, om mijn diep weggezakte ProCAST kennis weer eens op te graven. Ik was niet van plan om aan waterkoeling te gaan beginnen. Tenminste, voorlopig nog lang niet.

ghehe LOL had ik niet verw8

cool dat je zonder dat dit nog doet

i worship you!

[Selachii]

Op dinsdag 14 mei 2002 19:20 schreef JumpStart het volgende:

[..]

Bedankt voor je aanbod hoor, maar nee. Dit is voor mij gewoon een volledig virtueel experiment, om mijn diep weggezakte ProCAST kennis weer eens op te graven. Ik was niet van plan om aan waterkoeling te gaan beginnen. Tenminste, voorlopig nog lang niet.

neuh, ik bedoel ook niet met productie, maar met ontwerp...maargoed...kheb het erg druk op het moment. Kzal af en toe wat dingetjes afvuren in deze thread

[JumpStart]

Op dinsdag 14 mei 2002 19:43 schreef Selachii het volgende:

[..]

neuh, ik bedoel ook niet met productie, maar met ontwerp...maargoed...kheb het erg druk op het moment. Kzal af en toe wat dingetjes afvuren in deze thread

Het ontwerp boeit me niet zo heel veel, al is 'klussen' met Pro/ENGINEER ook een goeie oefening. Het wordt ineens haalbaar om te kijken hoe goed een koelblok van zilver zou presteren. Ik hoef immers alleen maar de juiste gegevens van puur zilver in te voeren, en ik simuleer dat ook!.

Met een klein beetje CAD werk heb ik ineens de bodem van het blok 3 mm dikker gemaakt, en weet ik ook, na die ouwe HP 9000 J2240 (zie sig.) te hebben laten zwoegen, hoeveel dat scheelt. Ineens 5 keer zoveel water erdoorheen pompen ? Dat kan ook door het veranderen van 2 getallen.

Kortom, mogelijkheden zijn eindeloos, alleen moet je wel goed kijken naar wat nou het meest interessant is om te simuleren.

[JumpStart]

De allereerste prille resultaten!!!

- De 'core' meet 12x8 mm en krijgt een influx van 1 Mwatt/m² te verwerken. Omrekenen naar mm² betekent dat dat 94 watt is

- De opstelling bestaat uit 79.656 nodes en 460.192 elementen.

- De eerste 6 rekenstappen gingen in 1300 seconden en besloegen slechts 0.003 seconden procestijd. Omdat de grootte van de rekenstappen niet vastligt kan dit nog niets zeggen over hoe lang het gaat duren!

- En misschien heb ik een ongeloofelijke tikfout gemaakt bij het opzetten van de simulatie, want 190 °C lijkt me een béétje aan de hoge kant... We zien wel hoe het zich stabiliseerd. Aan de andere kant, dit is pas op 0.003 seconden, het duurt nog even voordat er een paar seconde procestijd gesimuleerd is.

- (nu zitten we al op 8 stappen, en 0,004 seconden, tegen een stapgrootte van 0,0005 seconde per stap.)



snelle edit

Wat je dus ziet in het plaatje zijn vectors die stromingsrichting aangeven, in de richting van het vlak van de doorsnedes wel te verstaan en de temperatuursverdeling.

Er zijn nogal wat aannames gedaan: Tussen core en koelblok wordt géén barriere gesimuleerd, de core is dus eigenlijk gewoon een stuk extra koper. Koeling aan de buitenkant, overal dus, ook onder, behalve de "core" zelf en de in- en uitlaat, hebben 'koeling aan lucht'.

Waterstroom = 3 liter/uur oftewel 50 ml/sec.
Temperatuur van het binnenstromende water is vastgezet op 25°C, en de begintemperatuur van het koperblok is ook 25°C.

[JumpStart]

En ik me maar afvragen waarom die temperatuur toch zo belachelijk snel steeg ...

(Don't ask, er kwam een getal uitrollen van miljoenen graden, in de eerste mm van het blok, de rest was nog gewoon 25 °C...)

Had ik 100 megawatt ingevuld in plaats van 1 megawatt !

[edit]

Toch maar even opnieuw gestart, nu wel met juiste parameters, en het rekent nu sneller en ziet er geloofwaardiger uit:

code:

NUMBER OF STEPS = 13
SIMULATED TIME = 0.015000 SECONDS
TIME STEP = 0.002000 SECONDS
PERCENT FILLED = 100.000000 %
SOLID FRACTION = 0.000000 %
CYCLE 1 is 0.000000 % COMPLETE
CPU TIME = 2589.120117 SECONDS
SYSTEM TIME = 2.900000 SECONDS
WALL CLOCK TIME = 2599 SECONDS

0,015 seconden procestijd in 2599 seconden is sneller dan de 'fuote' poging # 1.

[Verwijderd]

Owowow, wat vind ik dit leuk om te zien!

Maareuh, kloppen je parameters nu wel? Ik vind de hitte wel erg snel verdwijnen namelijk. Dat strookt niet met mijn ervaring met mijn eigen blokje.

Kun je inzoomen op de plek waar het nu eigenlijk gebeurt?

[JumpStart]

Op donderdag 16 mei 2002 00:07 schreef DaBit het volgende:
Owowow, wat vind ik dit leuk om te zien!

Maareuh, kloppen je parameters nu wel? Ik vind de hitte wel erg snel verdwijnen namelijk. Dat strookt niet met mijn ervaring met mijn eigen blokje.

Kun je inzoomen op de plek waar het nu eigenlijk gebeurt?

Hoo, hoo, rustig DaBit

De 'procestijd', dus niet de rekentijd, maar hoeveel seconden gesimuleerd (denk maar aan 'virtuele tijd'), is nog maar heel klein en er is dus nog absoluut geen sprake van een evenwichtstoestand. De hoogst voorkomende temperatuur zal dus nog wel omhoog gaan.

Onderstaand plaatje is dus pas (al) bij 0,017072 seconden!

Ik ben nu de simulatie nog eens goed aan het napluizen, om te kijken of ik alle randvoorwaarden (boudary conditions) goed heb gezet. Ik had hier en daar een aantal nodes over het hoofd gezien waardoor op enkele punten randvoorwaarden voor snelheid of temperatuur niet geldden.

Straks nog meer plaatjes. nog een plaatje:

code:

NUMBER OF STEPS = 34
SIMULATED TIME = 0.017072 SECONDS
TIME STEP = 0.000016 SECONDS
PERCENT FILLED = 100.000000 %
SOLID FRACTION = 0.000000 %
CYCLE 1 is 0.000000 % COMPLETE
CPU TIME = 6605.430176 SECONDS
SYSTEM TIME = 7.310000 SECONDS
WALL CLOCK TIME = 6630 SECONDS

[Verwijderd]

meer pics! dit begint interessant te worden!
ziet er qua berekeningen zwaar uit. kan je geen delen uit besteden?

[JumpStart]

Op donderdag 16 mei 2002 10:35 schreef Peltier het volgende:
meer pics! dit begint interessant te worden!
ziet er qua berekeningen zwaar uit. kan je geen delen uit besteden?

Nee, dit valt niet te delen. Zowel omdat ProCAST niet voor iedereen beschikbaar is (zachtjes uitgedrukt, een commerciele licentie loopt in de 5 of 6 cijfers per jaar, en een 'educational license' nog altijd 4 cijfers) en omdat de rekenmethode zelf, die gebruikt wordt om de numerieke analyse op te lossen niet parallelliseerbaar is. Met andere woorden, 1 simulatie laat zich in dit geval niet splitsen in meerdere threads / rekentaken.

Vandaag zal ik opnieuw die simulatie starten, deze keer met de optie "sla slechts iedere 50^e stap op" zodat de simulatie lang door kan rekenen zonder dat het eindresultaat in de gigabytes gaat lopen. Of zelfs iedere 100^e stap, of 1000^e... (Met een stapgrootte van tussen de 0,00x seconde tot 0,00000x seconde kan dat geen kwaad.)

[JumpStart]

Het begint ergens op te lijken!

code:

NUMBER OF STEPS = 150
SIMULATED TIME = 0.135321 SECONDS
TIME STEP = 0.001304 SECONDS
PERCENT FILLED = 100.000000 %
SOLID FRACTION = 0.000000 %
CYCLE 1 is 0.000000 % COMPLETE
CPU TIME = 32191.970703 SECONDS
SYSTEM TIME = 15.190000 SECONDS
WALL CLOCK TIME = 32713 SECONDS

... Dit gaat nog wel even duren dus.

Deze simulatie is ietsje anders, namelijk dat het water een instroomtemperatuur heeft van iets minder, namelijk 22 °C in plaats van 25 °C. Daardoor zie je nu ineens wat meer temperatuursverschil.

[JumpStart]

Nog meer plaatjes:

De temperatuursverdeling en de 'heatflux' (dus de vectors geven aan in welke richting de warmte zich verspreidt en hoe snel, langer = sneller) bij 0,212 seconde. Hoogste temperatuur is 36,56 °C. Koelwater komt er in op 22°C, en begintemperatuur koper is 25 °C. De core meet 12x8 mm en brengt 94 watt aan warmte in.



Meest recente opgeslagen stap:

Stap 350, gesimuleerde tijd: 0,968 seconden, hoogste temp 41,30 °C.

[Verwijderd]

<font color="red">Adminbreak:
topictitel gewijzigd op verzoek topicstarter</font><hr>

Hmm, wat ik hier zie gebeuren, is dat ik een redelijke heatflux heb in het koper, maar dat het fout gaat op de overgang koper<->water.

Ook zie ik dat de waterkanalen relatief te dik zijn. Het hele middenstuk van de kanalen voegt niets toe aan de warmteafvoer.

Nou zegt 0.212 seconde simulatietijd natuurlijk nog niet alles...

Simuleert ProCAST ook de turbulentie die ontstaat door de waterflow die keihard op de bodemplaat botst?

[JumpStart]

Op vrijdag 17 mei 2002 15:02 schreef DaBit het volgende:

Hmm, wat ik hier zie gebeuren, is dat ik een redelijke heatflux heb in het koper, maar dat het fout gaat op de overgang koper<->water.

Nou, met de huidige warmteoverdrachtscoëfficient van 10.000 W/m²/K zit ik waarschijnlijk al aan de hoge kant. 3000 tot 6000 is denk ik realistischer.

Ook zie ik dat de waterkanalen relatief te dik zijn. Het hele middenstuk van de kanalen voegt niets toe aan de warmteafvoer.

Dat doet het NU nog niet omdat er nog helemaal geen evenwichtssituatie is ontstaan. Pas veel later zal blijken of het ontwerp een beetje efficient is.

Nou zegt 0.212 seconde simulatietijd natuurlijk nog niet alles...

Sterker, het zegt (nog) niets

Simuleert ProCAST ook de turbulentie die ontstaat door de waterflow die keihard op de bodemplaat botst?

Wel de turbulentie op de schaal van meerdere elementen. Binnen de schaal van elementen (en dan moet je denken aan 1 tot 2 mm ongeveer) niet. Overigens is dat wel in te schakelen, tegen extra rekentijd.

Plaatjes:

Temperatuur en heatflux op stap 400, na 2,03 seconden procestijd



Temperatuur en vloeistof vectors op stap 450, na 3,12 seconden. Hier meteen je antwoord op of er turbulentie optreedt: JA dus, je kan wervelingen zien in de stroming.



Overzichtsplaatje, ook bij stap 450.

[Verwijderd]

Op vrijdag 17 mei 2002 15:24 schreef JumpStart het volgende:
Nou, met de huidige warmteoverdrachtscoëfficient van 10.000 W/m²/K zit ik waarschijnlijk al aan de hoge kant. 3000 tot 6000 is denk ik realistischer.

3000W is een redelijke waarde voor Alu<->water bij een lage, gelijkmatige flow. Wat betreft koper; ik heb geen idee. Het klinkt aan de lage kant, zeker als je uitgaat van een bovengemiddeld turbulente flow.

Dat doet het NU nog niet omdat er nog helemaal geen evenwichtssituatie is ontstaan. Pas veel later zal blijken of het ontwerp een beetje efficient is.

Niet helemaal waar. Je flow is momenteel ook absoluut onrealistisch, wat een vertekent beeld geeft van de warmteverdeling in je kanalen. Ik snap overigens wel waarom die flow zo laag is, daar niet van...

Wel de turbulentie op de schaal van meerdere elementen. Binnen de schaal van elementen (en dan moet je denken aan 1 tot 2 mm ongeveer) niet. Overigens is dat wel in te schakelen, tegen extra rekentijd.

Kun je dat ook selectief inschakelen? Zo net boven de core bijvoorbeeld?

Hier meteen je antwoord op of er turbulentie optreedt: JA dus, je kan wervelingen zien in de stroming.

Ietsjes wel ja...

[JumpStart]

Op vrijdag 17 mei 2002 16:09 schreef DaBit het volgende:

[..]

3000W is een redelijke waarde voor Alu<->water bij een lage, gelijkmatige flow. Wat betreft koper; ik heb geen idee. Het klinkt aan de lage kant, zeker als je uitgaat van een bovengemiddeld turbulente flow.
[..]

Niet helemaal waar. Je flow is momenteel ook absoluut onrealistisch, wat een vertekent beeld geeft van de warmteverdeling in je kanalen. Ik snap overigens wel waarom die flow zo laag is, daar niet van...
[..]

Kun je dat ook selectief inschakelen? Zo net boven de core bijvoorbeeld?
[..]

Ietsjes wel ja...

- Een volgende simulatie krijgt 6000 W/m²/K als warmteoverdrachtscoëfficient mee voor water/koper.

- De flow is wel realistisch, de temperatuursverdeling binnen het water is alleen nog niet in evenwichtssituatie. Ik moet er eens even m'n "Transport Phenomena in Materials Processing" op naslaan om te kijken wat voor soort stroming 50 ml/sec in een 15x4 mm kanaal voor stroming oplevert, laminair of turbulent, en waar de overgangslaag dan ligt.

Die 50 ml/sec is gebaseerd op 3 liter/min, die jezelf suggereerde trouwens

- Nee, helaas kan ik turbulentiebereking (binnen elementen) aan of uit zetten, dat is niet deels te activeren.

Ik zal eens kijken of ik in een van de volgende plaatjes de ordegrootte van de snelheid als kleur weer kan laten geven.

[Verwijderd]

Op vrijdag 17 mei 2002 16:36 schreef JumpStart het volgende:
- De flow is wel realistisch, de temperatuursverdeling binnen het water is alleen nog niet in evenwichtssituatie. Ik moet er eens even m'n "Transport Phenomena in Materials Processing" op naslaan om te kijken wat voor soort stroming 50 ml/sec in een 15x4 mm kanaal voor stroming oplevert, laminair of turbulent, en waar de overgangslaag dan ligt.

Die 50 ml/sec is gebaseerd op 3 liter/min, die jezelf suggereerde trouwens

Ehm, oeps, ik zat aan 3L/uur te denken. M'n koppie er niet helemaal bij gehouden. Excuus

- Nee, helaas kan ik turbulentiebereking (binnen elementen) aan of uit zetten, dat is niet deels te activeren.

Jammer, want binnen de elementen aanzetten levert je een gigantisch berg extra rekenwerk op, terwijl het juist op dat punt het interessantste is.

[JumpStart]

Op vrijdag 17 mei 2002 17:43 schreef DaBit het volgende:

[..]

Jammer, want binnen de elementen aanzetten levert je een gigantisch berg extra rekenwerk op, terwijl het juist op dat punt het interessantste is.

Die 'gigantische berg' valt op zich nog wel mee. Het simulatieprogramma gaat niet volledig naar waarheid een element nog eens opdelen in een x-tal sub-elementen om daarbinnen ook weer vloeistofstroming te berekenen.

In plaats daarvan krijgt ieder element dat met 'fluid' ge'flagged is een extra "mengparameter" mee. Op basis van afschuifsnelheden en snelheidsverschillen op de hoekpunten wordt via weegfactoren dus een soort van diffusie bepaald. Op die manier kan je alsnog de effecten berekenen die turbulentie veroorzaken: de hogere warmteoverdracht, het beter mengen, de extra tegendruk (enz. enz.) zonder dat je het benodigde rekenwerk ziet ver-x-voudigen.

Sla een willekeurig boek open over vloeistof mechanica, en je komt een hele waslijst van dimensieloze getallen tegen zoals het Reynolds getal en het Prandtl getal (enz. enz.) die voorspellen of stroming laminair of (deels) turbulent is.

In feite worden zo dan alsnog de elementen van turbulentieberekening uitgesloten die er niet voor in aanmerking komen.

Hier een plaatje van alleen het vloeistof traject, met daarin de snelheidsverdeling ('velocity magnitude').



Overigens, nu de stroming zich min of meer gestabiliseerd heeft is dat ten goede gekomen aan de zogenaamde 'oplosbaarheid' (rekenkundig) van het probleem. De tijdstap zit nu al geruime tijd op 0,021 seconde, dus nu is iedere opgeslagen 50^e stap ongeveer 1 seconde verder.

[ice-T106]

Kan je de stapgrootte ook wat hoger zetten zodat je niet zolang hoeft te wachten tot er een evenwichts situatie optreed?
Ik vind dit echt heel interressant om te volgen, dit kan echt helpen om waterblok ontwerpen beter te begrijpen.

[Verwijderd]

Hmz, het kan aan mij liggen maar het contact oppervlak tussen de core en de cpu blijft de grootste bottleneck.

Deminishing returns. Je kan ONWIJS veel moeite in het waterblok steken, maar vanaf een gegeven moment kan het blok de geleverde wattages door de cpu MAKKELIJK aan, echter het overbrengen op het blok blijft het lastigste.

Ondanks dat is dit natuurlijk een Gigantisch interessant topic. Een goed waterblok is natuurlijk nooit weg.

[Epsilon]

Op vrijdag 17 mei 2002 19:00 schreef JumpStart het volgende:

Hmm, het kan aan mij liggen, maar ik heb het idee dat er een hotspot ontstaan is aan de zijkanten van het waterkanaal bij de inlet. Ff in een pic laten zien waar ik bedoel:

code:

|  inlet  |
|      |
|      |
|      |
|      |
|\   /|
|!\     /!|
|---------|

Het stukje met de ! is het stukje waar het water erg langzaam stroomt.

[JumpStart]

Op zaterdag 18 mei 2002 12:28 schreef ice-T het volgende:
Kan je de stapgrootte ook wat hoger zetten zodat je niet zolang hoeft te wachten tot er een evenwichts situatie optreed?
Ik vind dit echt heel interressant om te volgen, dit kan echt helpen om waterblok ontwerpen beter te begrijpen.

Nee, stapgrootte verhogen is niet mogelijk. Het programma past stapgrootte namelijk zelf aan, aan hoe 'gemakkelijk' de numerieke analyse is op te lossen.

Wat je als gebruiker opgeeft is de maximaal toegestane stapgrootte en de stapgrootte waarmee het simulatieprogramma mee moet beginnen. De rest is in handen van ProCAST. Is in de huidige stap pas na veel rekenwerk zogenaamde 'convergentie' te bereiken, dan doet ProCAST de volgende stap met de helft van de stapgrootte. En andersom ook: als in de huidige stap heel gemakkelijk convergentie berereikt wordt, dan wordt de stapgrootte automatisch verhoogd.

Waar het uiteindelijk op neerkomt is dat er per stap niet meer verplaatsing op mag treden dan de grootte van het element waar het doorstroomt. Het kleinst voorkomende element plus de daar optredende vloeistofsnelheid bepaalt dus de stapgrootte.

Als je kleinste elementen 0,5 mm groot zijn, dan mag er per stap ook maar 0,5 mm vloeistof door die elementen passeren. Dit valt een beetje te verhelpen omdat ProCAST een soort versnellingsparameter kent, waardoor je dit kan oprekken. (Alles heeft een prijs, voer het te ver op en de uitkomst van je berekening is A) onbetrouwbaar, of is niet eens meer te berekenen.)

Om je een idee te geven: de vloeistof komt er met 0,1 meter per seconde in. Meshgrootte in de ingang is ongeveer 0,8 mm, dus dan ben je al gebonden aan 0,8 mm / ( 100 mm / s ) = 0,008 seconde per stap. Dankzij die versnellingsparameter is de stapgrootte toch nog meer dan 2 keer zo groot.

...

_{Hmmmm, wacht eventjes hoor...}

* JumpStart grijpt de zakjapanner erbij...

<sub>Tik tik tikkerdetik tik tik

Hmmm, OK, dat doen we nog een keer...

Tik tik tikkerdetik tik tik</sub>



AAERGHHH, OK, dan heb ik nu de volgende fout in de opzet van de simulatie ontdekt!!!

DaBit, je hebt dus wèl gelijk gehad, er stroomt maar 18 liter per uur door in plaats van 180! Ik zat de getallen nog eens na te rekeken en toen viel het kwartje. Een orde grootte te laag voor de instroomsnelheid . De binnendiameter, van zowel in- als uitgang, is 8 mm = 50,2 mm². 0,5 cm² x 10 cm/s = 5 ml/sec, en niet de 50 die ik in gedachten had.



Al doende leert men . Ik ga deze simulatie dan maar eens stoppen en 'em opnieuw starten met de juiste vloeistofsnelheid.

[JumpStart]

Op zaterdag 18 mei 2002 13:54 schreef epsilon het volgende:

[..]

Hmm, het kan aan mij liggen, maar ik heb het idee dat er een hotspot ontstaan is aan de zijkanten van het waterkanaal bij de inlet. [knip]

Tjsongejonge, doe ik moeite om plaatjes op 600 pixels breed te houden, gaan andere mensen alsnog de lay-out ver'nueken' .

Maar nu on-topic. Je vergeet de schaal waarop dit plaatsvindt, plus de goede warmtegeleiding van koper. Ja, er staat zeer plaatselijk water (bijna) stil, maar erhh, water geleidt ook warmte als het stilstaat. (Toegegeven, minder dan wanneer het wel 'ververst' wordt.) Dat, plus dat de warmte toch wel over een veel groter oppervlak dan alleen die would-be hotspot verspreid wordt, betekent dat er geen probleem is.

[Verwijderd]

Wat nu als er midden boven de core in het inlaatkanaal een pen (dabit) in de flow zou staan?

code:

 _     _
 ||    ||
 ||    ||
_||_/\_||_
__________

Als ik de plaatjes goed interpreteer dragen de buitenste kanalen amper bij aan de warmteopname. Wat nu als er minder kanalen -maar breder en met pennen- toegepast werden?


edit:
Of wat als je pennen en 'schuine' kanaalwanden zou toepassen?

code:

   _     _    
   ||    || 
   ||    ||     
\_/ \_/\_/ \_/\_
_______________

[JumpStart]

Op zaterdag 18 mei 2002 14:21 schreef augustus het volgende:
Wat nu als er midden boven de core in het inlaatkanaal een pen (dabit) in de flow zou staan?

code:

 _     _
 ||    ||
 ||    ||
_||_/\_||_
__________

Als ik de plaatjes goed interpreteer dragen de buitenste kanalen amper bij aan de warmteopname. Wat nu als er minder kanalen -maar breder en met pennen- toegepast werden?

DaBit, onze Übertweakert, zou ècht niet passen hoor !

_{(Sorry DaBit, maar ik kon het niet laten! )}

Dat het buitenste stuk van de spiraal nog niet aan koelen toekomt komt omdat de simulatie nog niet ver genoeg is. Er zijn nu pas 15 seconden gesimuleerd, en dat is natuurlijk nog niet genoeg om een stabiele temperatuursverdeling te krijgen. (Plus dat ik dus met m'n domme harses de watersnelheid een factor 10 te klein opgaf ... Dat scheelt ook.)

Ik ben al bezig aan een ontwerp dat in het midden een dikkere bodem heeft dan aan de buitenkant, en ook een pen in het midden voor extra contactoppervlak met het instromende water.

Meer plaatjes volgen!

[Edit]: Over wat je zei over schuine kanten, kijk hier nog even goed naar het plaatje, de onderkant van het kanaal is inderdaad afgerond.

http://gathering.tweakers.net/forum/list_message/13366625#13366625

[JumpStart]

Goed, deez' simulatie krijgt een kill -9 [PID] te verwerken. Nu wordt het tijd om zowel het ontwerp van het koelblok als de opzet van de simulatie aan te passen.

Fragmentje uit 'top'

code:

PRI NI   SIZE    RES STATE    TIME %WCPU  %CPU COMMAND
229 20 64468K 62364K run   2946:18 100.00 99.83 procast

Meer gegevens over deze rekentaak:

code:

NUMBER OF STEPS = 1056
SIMULATED TIME = 16.191980 SECONDS
TIME STEP = 0.021538 SECONDS
PERCENT FILLED = 100.000000 %
SOLID FRACTION = 0.000000 %
CYCLE 1 is 0.000000 % COMPLETE
CPU TIME = 176734.718750 SECONDS
SYSTEM TIME = 69.610001 SECONDS
WALL CLOCK TIME = 178690 SECONDS
STEP COMPLETED ON May 18 2002 AT 14:16:16

Laatste opgeslagen stap, detail:

(Even opletten, de vectors zijn vergroot ten opzichte van de andere plaatjes, dus er is geen sprake van plotselinge snelheidstoename.)

Donkerrood = 49,48°C, de buitenkant is rond de 30°C en de watertemperatuur bij binnenstromen (paars) is 22°C

[Verwijderd]

Wat mij nou heel mooi lijkt is als je real time het effect van aanpassingen van een blokje en van de watersnelheid en watertemperatuur e.d. kon zien.
Of i.i.g. snel na de aanpassing i.p.v. real time.

Dan begin je met een 'standaard' blokje:


(Deksel negeer je, want gesoldeerd koper, of geschroefd met rubber afdichting, of ditto perspex verstoren de 'warmteoverdracht' (teveel gereken)).

Je variëert de waterstroom en wateringangstemperatuur en bodemdikte tot de beste situatie.
Daarna ga je experimenteren met de aansluitingen en de vorm van het blokje. Bijvoorbeeld:



En dan moet er een ideaal blokje uitkomen.

[Verwijderd]

Met wat algemene kennis kom je ook al heel ver. Denk dat je door even nadenken al een heleboel blokjes zo kan afstrepen.

Alle bovenstaande blokjes hebben of te weinig contact vlak (bakje met niets) te veel turbulentie (pinnetjes remmen de stroomsnelheid HEEL erg af, en geven alleen locaal turbulentie, verderop leverd het weinig op, of te grote hoeken, alle hoeken zo klein mogenlijk houden of vloeiend anders belemmer je de stroomsnelheid erg significant.

Ik vermoed dat ProCAST niet echt een simpel progje is. vrij cpu intensief dus. massaal testen lijkt vrij lastig. Zoveel mogenlijk elimineren van blokken is een goede oplossing.

[Verwijderd]

Stroomsnelheid is niet zo belangrijk: vier keer zoveel water scheelt maximaal 2 graden! Zie de eerder gegeven link op pagina 1.

Turbulentie lijkt mij wél belangrijk, omdat er dan geen 'koude zone' midden in de waterflow blijft zitten. Daarbij vergroten die pennen het contactoppervlak.
De door mij getekende blokjes zijn slechts 6 mogelijkheden uit 1000-den. Bijvoorbeeld de spiraal, het labyrint, het M-kanaal, etc. en alle variaties daarop, ontbreken.

Ik vrees echter dat realtime wel een KNMI-weercomputer vereist.

Edit:
Mijn idee was dus dat je begint met het standaardblokje en dan stap voor stap veranderingen doorvoert en realtime de effecten zou kunnen zien:
-is de instroom direct boven de core beter dan aan de zijkant of halverwege?
-geven pennen echt een betere warmteverdracht?
-geeft één pen midden boven de core al een verbetering?
-geeft een kanaal een betere warmteoverdracht?

[JumpStart]

Op zaterdag 18 mei 2002 15:54 schreef augustus het volgende:
[..]

Edit:
Mijn idee was dus dat je begint met het standaardblokje en dan stap voor stap veranderingen doorvoert en realtime de effecten zou kunnen zien:
-is de instroom direct boven de core beter dan aan de zijkant of halverwege?
-geven pennen echt een betere warmteverdracht?
-geeft één pen midden boven de core al een verbetering?
-geeft een kanaal een betere warmteoverdracht?

Vantevoren gezond verstand gebruiken, daarmee kom je al een heel eind. Als je je boek natuurkunde warmteleer openslaat, dan weet je dat, ruw genomen, meer oppervlak beter is, en een hogere Delta T ook. Dus een hogere doorstroming betekent dat de warmte aan meer water afgestaan wordt, dus dat het water niet zoveel warmer wordt, dus dat Delta T groter blijft. Een hogere verhouding inhoud/oppervlak is ook gunstiger: liever meer oppervlak bij dezelfde inhoud, enz.

Iedereweg, ik ben 'as we speak' aan het klussen met Pro/ENGINEER om met een nieuw blok op de proppen te komen.

[bredend]

Is het niet mogelijk om met dit programma bepaalde sectoren van het koelblok een lagere prioriteit te geven?
Dus dat je het stuk boven de core goed laat berekenen en de rest van de spiraal wat minder?

[Verwijderd]

Vantevoren gezond verstand gebruiken, daarmee kom je al een heel eind.

Vast en zeker!
Zeker en vast!

Maar het moet toch mooi zijn als je realtime verbetering van het rendement kunt zien door bijv. de aansluiting enkele milimeters te verschuiven; de doorsnede van kanalen te versmallen of te verbreden; pennen toe te voegen -en langzaam te verhogen; de bodemdikte te variëren; de flow te variëren, de wanden ruwer of gladder te maken; kanalen te verlengen; tussenwanden te verbreden; et cetera ad infinitum

Maar daar heb je waarschijnlijk een CRAY voor nodig, en orkaanvoorspellings-software.

#######################################################
A propos!
Hoe bepaal je eigenlijk het rendement van een blokje?
Dabit had een héél ingewikkelde redenatie die ik nog steeds niet begrijp.
Ik denk nog steeds dat de verschiltemperatuur tussen de ingaande waterstroom en uitgaande waterstroom bepalend is. Ofwel meet gewoon hoe snel een paar liter rondgepompt water in temperatuur stijgt (dat is namelijk de praktijksituatie).

[Verwijderd]

Ik heb zomaar een fantasie-filmpje gefröbeld.



Je ziet zogenaamd in realtime hoe de 'dabit' de temperatuur beïnvloed.

Zo'n simulatie -maar dan reëel- van de werkelijkheid is volgens mij mogelijk met een snelle computer en dure software.
En dat probeer je dan met alle variëties tot je het perfecte blokje hebt.

[Verwijderd]

Op zaterdag 18 mei 2002 22:50 schreef augustus het volgende:
Ik heb zomaar een fantasie-filmpje gefröbeld.

[afbeelding]

Je ziet zogenaamd in realtime hoe de 'dabit' de temperatuur beïnvloed.

Zo'n simulatie -maar dan reëel- van de werkelijkheid is volgens mij mogelijk met een snelle computer en dure software.
En dat probeer je dan met alle variëties tot je het perfecte blokje hebt.

Ben je dus wel ff bezig want je beschikt niet over genoeg reken kracht omdat snel te doen. en aangezien het programma niet geshared kan worden oid kan slechts de eigenaar er aan rekenen. verstand gebruiken, lezen, lezen, lezen, inzicht verwerfen en dan pas gaan testen.

[JumpStart]

Op zaterdag 18 mei 2002 22:50 schreef augustus het volgende:
[...]

Zo'n simulatie -maar dan reëel- van de werkelijkheid is volgens mij mogelijk met een snelle computer en dure software.
En dat probeer je dan met alle variëties tot je het perfecte blokje hebt.

Mogelijk ? Misschien, maar je slaat toch de plank mis...

Ja, het zou heel leuk zijn, leuk als in "GAAF, dat zou echt kicken zijn" als je dit real-time zou kunnen doen. Een hoge 'geilheidsfactor' om het zo maar even te noemen. Maar er is geen enkele wetenschappelijke noodzaak om dit realtime te berekenen. Waarom ? Omdat je het resultaat niet metéén hoeft te weten, dat is overbodig/onnodig. Meteen weten heeft dus geen meerwaarde in dit geval, en dus zou je geschift zijn als je er al die 'resources' in zou steken.

Als je zo nodig het effect van verschillende vormen van dabits wil testen, dan kan je dat ook makkelijk doen door een serie van simulaties op te zetten en dan na elkaar doorrekeken. Daar hoef je nooit die belachelijk hoge rekencapaciteit voor te hebben.

En tenslotte ... Je kan dan wel graag willen doorrekenen totdat je het perfecte blokje hebt, maar dan is de hoeveelheid tijd en moeite die je erin steekt zo hoog dat je beter een 2 keer zo grote radiator, of een TEC+heatplate had kunnen kopen, dan had je makkelijker die paar graden winst gehaald. Want ga er wel vanuit dat alleen een andere vorm dabit maar heel weinig verschil in temperatuur zal veroorzaken.

[Verwijderd]

Juistem!
Het lijkt mij gewoon leuk om realtime de effecten van bodemdikte, pennen, kanalen, et cetera op de watertemperatuur te simuleren.

Je tilt bijv. met je cursor de bodem van het blokje op tot er een pen ontstaat en je ziet de temperatuur dalen (of niet dus).

**********************
Je kunt natuurlijk ook alle typen blokjes echt gaan frezen, en vergelijken.
Ik denk dat een blokje met centrale inlaat, en met een kanaal met pennen, het beste is.

[Verwijderd]

Ik wacht vol spanning de realistischere flow resultaten af....

[ajampaniki]

Jezus, ik denk dat dit wel het topic is met de aller, allerlangste posts.

[JumpStart]

Dit is m'n volgende 'slachtoffer' (al heb ik nog een paar kleine dingen aangepast) :

code:

The MODEL contains:

523840 Elements
109508 Nodes
2 Material types

Boundary Conditions Summary:
----------------------------

  1 Temperature Boundary Conditions
  2 Heat Bounday Conditions
  2 Velocity Boundary Conditions

[ice-T106]

Ga je nou niet meer met een "rechte" bodem testen? Dit zou ik eigenlijk wel jammer vinden, het leek me wel leuk om te zien hoe goed de warmte verdeeld zou worden.

[JumpStart]

Op zondag 19 mei 2002 15:56 schreef ice-T het volgende:
Ga je nou niet meer met een "rechte" bodem testen? Dit zou ik eigenlijk wel jammer vinden, het leek me wel leuk om te zien hoe goed de warmte verdeeld zou worden.

Toegegeven, echt goed zichtbaar is het niet, maar als je goed kijkt dan zie je dat de dikte afloopt naar buiten toe: de bodem onder de buitenste vloeistofring is 2 mm dik, 1'tje meer naar binnen 3 mm, 3e = 4 mm enz. In het midden is de bodem 6 mm dik, en de pin erop nog eens 3 mm hoger.

[Edit]

Ik moet beter lezen zie ik... Voorlopig ga ik eerst bovenstaand blokje (proberen te) simuleren. Daarna ? Weet ik nog niet, ik was wel van plan om ook een 'leeg' koelblok (zoals die nieuwe swifttechs) te simuleren. Dat zie ik dan wel weer.

[KifArU]

In deze thread staan wat vragen, die volgens mij makkelijk te beantwoorden zijn met een simpele simulatie.
Zou je eens kunnen kijken of het mogelijk is om 1 "watergang" van een blok te simuleren? Dus eigenlijk een stukje met een lengte van 1 of 2 centimeter uit het blok halen en dit apart simuleren.
Dan kun je vrij snel zien wat het effect is van verschillen in:
- De bodemdikte,
- De wanddikte
- De breedte van de gang (turbulentie/stationaire laag)
- Ribbels in de onderkant van de gang
- Oneffenheden in de wanden
- Stroomsnelheid
- Materiaal

En de warmte-overdracht tussen water en metaal zou snel duidelijk worden.

Dus een aantal simulaties van een klein stukje, wat dus weinig rekenwerk zou betekenen. Bijvoorbeeld:

||```||
||```||
||```||
-------
-------

en

|||```|||
|||```|||
|||```|||
---------
---------

en

||``||
||``||
||``||
------
------

en

||```||
||```||
||```||
-------
-------
-------

en

||```||
||```||
||`^`||
-------
-------


(``` is water)
Of zou dit teveel programmeerwerk kosten?

[JumpStart]

Op zondag 19 mei 2002 18:34 schreef KifArU het volgende:
In deze thread staan wat vragen, die volgens mij makkelijk te beantwoorden zijn met een simpele simulatie.
Zou je eens kunnen kijken of het mogelijk is om 1 "watergang" van een blok te simuleren? Dus eigenlijk een stukje met een lengte van 1 of 2 centimeter uit het blok halen en dit apart simuleren.
Dan kun je vrij snel zien wat het effect is van verschillen in:

[knipperdeknip]

Nee, helaas, zo makkelijk is het niet. Een dikkere bodem betekent op zichzelf een grotere 'warmtebarriere'. En dus is dat ongunstiger. Uit een willekeurig boek over thermodynamica kan je de volgende vergelijking voor warmteoverdracht vinden:

code:

q = k * ( T1 - T0 )
       ---------
         Y

q = warmteoverdracht per oppervlakte eenheid
k = warmtegeleidingscoëfficient ( W/m/K )
T1 = Temperatuur aan de warme kant
T0 = Temperatuur aan de koude kant
Y = Afstand tussen de 2 punten

Als je dus in het sommetje de afstand ( Y ) vergroot, dan wordt de warmteoverdracht per oppervlakte eenheid ( q ) kleiner. Hieruit rolt dus al uit, zonder te simuleren, dat een dikkere bodem minder goed warmte geleidt.

Waarom dan toch die dikkere bodem ? Die dikkere bodem verspreidt de warmte over een groter oppervlak, om afvoer makkelijker te maken. En dat gunstige effect is groter dan het negatieve effect van de dikkere bodem.

Met andere woorden, je kan wel een stukje kanaal appart simuleren, maar daarmee kom je niets te weten over de prestatie van het gehele blok.

[KifArU]

Als ik afga op het laatste plaatje van je simulatie, (uitgaande van een breedte van de core 12 mm) verspreid de warmte bijna niet. Op een breedte van ca. 2 cm zit de temperatuur onder de 30 graden.
Daarom geloof ik niet zo in de theorie van een dikke bodem voor de verspreiding.
De eerste waterkoeling die op internet werd beschreven, (van een pc door een hobbyist) had het water direct over de cpu lopen. Dit was nog een originele pentium, met een volledig keramische behuizing. Om het systeem te kunnen overzetten op een andere cpu, had hij het blok later afgesloten met een koperen plaatje, om tot een blok te komen zoals we dat nu kennen. Bij deze verandering ging zijn cpu-temp duidelijk omhoog. En dat strookt ook met het eerste deel van je verhaal. Dus ik probeer zelf met een zo dun mogelijke bodem te werken.

Lang verhaal, maar deze simulatie lijkt me een mooie manier om dit te testen. Niemand kan deze "warmtespreiding" in zijn blok meten, dus kan het alleen via simulatie.

[JumpStart]

Op zondag 19 mei 2002 23:12 schreef KifArU het volgende:
Als ik afga op het laatste plaatje van je simulatie, (uitgaande van een breedte van de core 12 mm) verspreid de warmte bijna niet. Op een breedte van ca. 2 cm zit de temperatuur onder de 30 graden.
Daarom geloof ik niet zo in de theorie van een dikke bodem voor de verspreiding.
[..]

Beter kijken / beter lezen alsjeblieft!

Dat laatste plaatje is pas na een (gesimuleerde) tijd van iets meer dan 16 seconden ! Er is dus helemaal nog geen sprake van een evenwichtssituatie: de temperatuursverdeling is nog lang niet gestabiliseerd. Pas al er meerdere minuten procestijd gesimuleerd zijn, dan pas kan je uitspraken doen over temperatuursverdeling.

[AleXtc]

Zeg Jumpstart, zou je deze eens door je proggie heeb kunnen laten lopen?

Wij zijn aan het kijken wat nou het beste ontwerp is voor de ultieme waterblok.

Deze vraag komt naar aanleiding van mijn draadje die loopt voor het zelf maken van koelblokken straks. (http://gathering.tweakers.net/forum/list_messages/489493/2?limit=75)

De *.DWG , *.IGS , *.SAT staan bij de link;

Alvast bedankt.

klik op deze Link :)

[JumpStart]

Op maandag 20 mei 2002 01:39 schreef AleXtc het volgende:
Zeg Jumpstart, zou je deze eens door je proggie heeb kunnen laten lopen?

Wij zijn aan het kijken wat nou het beste ontwerp is voor de ultieme waterblok.

[..]

Even voor alle duidelijkheid: Ik kan je niets beloven!

Maar goed, met dat in het achterhoofd, zijn er een aantal dingen die je van te voren zal moet aanpassen, voordat ik een poging kan wagen.

Om te beginnen moet je zo veel mogelijk details weglaten waarvan je redelijkerwijs aan kan nemen dat ze maar heel weinig verschil maken. De gaten en de richel voor sluit-rubber dus weglaten. Ook inlaat en uitlaat dezelfde diameter geven, zodat er geen conflict kan ontstaan tussen in- en uitstroom randvoorwaarden. (Klinkt misschien gek, maar daar kan ProCAST van over de zeik gaan.) Verder moet het object 'netjes' gemaakt zijn. Eerst het blok extruderen uit een vlak, en dan het koeltraject als 'cut' extruderen. Daarna gaten aanbrengen. Waarom ? Als de relaties tussen de vlakken/splines van die IGES file niet exact kloppen... Juist, dan flipt ProCAST.

Als je aan de onderkant van het blok een vlak van 12x8mm 1 mm extrudeert, dan is er makkelijk een 'cpu' aan te geven.

Maar het allerbelangrijkste probleem is toch wel de dikte van de dunste stukken: Die zijn 1 mm, en dat betekent dat er op die plekken elementen gegenereerd worden van slechts 0,33 mm groot. Dan loopt de totale mesh-count echt de pan uit, dus je zal toch echt uit moeten gaan van een minimale dikte van 2 mm.

[AleXtc]

Ai, ok, ik zal wel ff wat netjes flanzen....

Nog wat..... ten eerste; harstikke bedankt dat je de moeite er voor wilt nemen.

tweede; Omdat de randen in het midden 0,5 mm dik zijn krijg jij natuurlijk een probleem. Maar als je nou een factor 10 neemt (het hele blok zodat 0,5 => 5mm) zou het natuurlijk wel gaan , de uitkomst klopt natuurlijk niet maar het komt dan wel in de buurt misschien?

[JumpStart]

Op maandag 20 mei 2002 22:41 schreef AleXtc het volgende:
Ai, ok, ik zal wel ff wat netjes flanzen....

Nog wat..... ten eerste; harstikke bedankt dat je de moeite er voor wilt nemen.

tweede; Omdat de randen in het midden 0,5 mm dik zijn krijg jij natuurlijk een probleem. Maar als je nou een factor 10 neemt (het hele blok zodat 0,5 => 5mm) zou het natuurlijk wel gaan , de uitkomst klopt natuurlijk niet maar het komt dan wel in de buurt misschien?

Het gaat niet om absolute maten, maar relatief ten opzichte van het geheel. Om betrouwbare resultaten te krijgen moet je overal minstens 3 elementen 'dikte' hebben. 2 zou ook nog kunnen, maar dan ben je aan het vragen om problemen. Het blok een factor 10 groter maken lost niets op, de 'meshcount' blijft hetzelfde.

Daarnaast kan je al voelen aankomen dat 0,5 mm dikte ook nog om 2 andere redenen geen goed idee/ontwerp is: Ga maar eens frezen met een miezerig dun wandje van maar 0,5 mm dik dat moet blijven staan. Dat is erg moelijk/lastig. En 0,5 mm is ook niet dik genoeg om voldoende warmte af te voeren naar het bovenste gedeelte van de koper vin. Zo'n dunne wand is niet efficient genoeg meer omdat de bovenkant nauwelijks nog mee kan doen aan warmteafgifte.

[AleXtc]

Op maandag 20 mei 2002 23:01 schreef JumpStart het volgende:

[..]

Het gaat niet om absolute maten, maar relatief ten opzichte van het geheel. Om betrouwbare resultaten te krijgen moet je overal minstens 3 elementen 'dikte' hebben. drie elementen? die snap ik niet helemaal
2 zou ook nog kunnen, maar dan ben je aan het vragen om problemen. Het blok een factor 10 groter maken lost niets op, de 'meshcount' blijft hetzelfde.

Daarnaast kan je al voelen aankomen dat 0,5 mm dikte ook nog om 2 andere redenen geen goed idee/ontwerp is: Ga maar eens frezen met een miezerig dun wandje van maar 0,5 mm dik dat moet blijven staan. Dat is erg moelijk/lastig. Het gaat CNCgefreesd worden
En 0,5 mm is ook niet dik genoeg om voldoende warmte af te voeren naar het bovenste gedeelte van de koper vin. Zo'n dunne wand is niet efficient genoeg meer omdat de bovenkant nauwelijks nog mee kan doen aan warmteafgifte. Hoe dik zou jij adviseren om dus de warmte afgifte te realiseren ?

[JumpStart]

Op dinsdag 21 mei 2002 08:35 schreef AleXtc het volgende:

[..]

_{(erhh, volgende keer iets praktischer quoten??)}

Even een kleine uitleg:

ProCAST is een zogenaamd FEM pakket: Finite Element Method, oftewel: Eindige elementen methode. Dit wil zoveel zeggen dat je je probleem opdeelt in heleboel kleine elementen en per element daar numerieke analyse op loslaat.

Een 'mesh' is de verzameling elementen die samen een object vormen. Hieronder vergroot een gedeelte van de mesh van het koeltraject:



Hier kan je zien dat je minstens 2 elementen in de dikte moet hebben, en liever 3. Anders is de doorstroming niet (goed) te berekenen. Of het nou stroming van water of geleiding van warmte is.

Werk je met relatief dunne secties, dan moet de mesh-dichtheid heel hoog zijn, dus hele kleine elementen, en dan kom je automatisch op een heel groot aantal elementen uit. Meer elementen = langere rekentijd en meer data opslag nodig.

Nieuw plaatje:

Na 500 stappen, gesimuleerde tijd: 2,08 seconden, paars = 22° C, rood = 41 °C.

[_Evert_]

Mooi, weer een stapje verder. Was dit plaatje nou nog van dezelfde simulatie als het vorige plaatje? Want daar was de "core" 49 gr dacht ik, en hier 41gr.

Met andere woorden, en dit zal wel overbodig zijn:
ik neem aan dat je na zeg 2 min simulatietijd, als je de simulatie stopt, wel mooi een grafiekje kan geven van het temperatuursverloop op een bepaald punt, bv de core of het water bij exit of zo.

Mooi project dit hoor! Goed dat je je oefening nog nuttig maakt voor de community op deze manier!

[im_ik]

zou je ook de simulatie 20min kunnen laten lopen ...in een nachtje tijd
en dan exporten als avi file ???

[AleXtc]

Op dinsdag 21 mei 2002 12:06 schreef JumpStart het volgende:

[..]

_{(erhh, volgende keer iets praktischer quoten??)}

Doe ik, Ik snapte het in het begin niet zo

Even een kleine uitleg:



Werk je met relatief dunne secties, dan moet de mesh-dichtheid heel hoog zijn, dus hele kleine elementen, en dan kom je automatisch op een heel groot aantal elementen uit. Meer elementen = langere rekentijd en meer data opslag nodig.

Die simulatie die je nu hebt gedaan, is dat moeilijk om in te voeren?

Anders zou ik wel een poging willen wagen, moet alleen wel het proggie ergens vandaan zien te halen.

Met dataopslag heb ik geen probleem, zat ruimte over. En rekentijd lijkt me ook niet zo'n probleem. (Ik werk 8 uur per dag dus ik kan toch niet achter me pc zitten, m.a.w. hij kan dan mooi rekenen.)

[JumpStart]

Mensen, alsjeblieft, LEES BETER! Een aantal dingen waar naar gevraagd wordt is al lang voorbij gekomen.

Op dinsdag 21 mei 2002 12:16 schreef _Evert_ het volgende:
Mooi, weer een stapje verder. Was dit plaatje nou nog van dezelfde simulatie als het vorige plaatje? Want daar was de "core" 49 gr dacht ik, en hier 41gr.

[..]

Koelblok is anders van ontwerp, warmteoverdrachtscoëfficient tussen koper en water is anders (van 10.000 W/m/K naar 5.000 W/m/K, wat toch iets realitischer is) en het debiet is 10 keer groter, van 5 ml/sec naar 50 ml/sec. (Behalve de warmteoverdracht had je dit al kunnen weten.)

Op dinsdag 21 mei 2002 12:49 schreef im_ik het volgende:
zou je ook de simulatie 20min kunnen laten lopen ...in een nachtje tijd
en dan exporten als avi file ???

Voorbeeldje:

NUMBER OF STEPS = 1056
SIMULATED TIME = 16.191980 SECONDS
TIME STEP = 0.021538 SECONDS
PERCENT FILLED = 100.000000 %
SOLID FRACTION = 0.000000 %
CYCLE 1 is 0.000000 % COMPLETE
CPU TIME = 176734.718750 SECONDS

De huidige 2 simulaties zijn nog zwaarder.

NUMBER OF STEPS = 622
SIMULATED TIME = 1.344904 SECONDS
CPU TIME = 154136.406250 SECONDS

en

NUMBER OF STEPS = 637
SIMULATED TIME = 2.663707 SECONDS
CPU TIME = 154245.890625 SECONDS

Doe zelf even het rekenwerk...

Op dinsdag 21 mei 2002 12:57 schreef AleXtc het volgende:

[..]

Die simulatie die je nu hebt gedaan, is dat moeilijk om in te voeren?

Anders zou ik wel een poging willen wagen, moet alleen wel het proggie ergens vandaan zien te halen.

[..]

Nee, helaas, dit programma is niet als freeware te krijgen. Licentiekosten per jaar zit rond de 4 of 5 cijfers, voor de komma welteverstaan. En nee, zelfs al zou ik willen (maar ik wil liever niet op staande voet ontslagen worden) kan ik je ook niet 'onder tafel' een kopie bezorgen, want het serienummer is op basis van het MAC adres gemaakt. Trouwens, dan moet je een HP-UX machine hebben ook nog eens.

Daarnaast is het een draak van een programma, met heel veel opties, waarvan een gedeelte niet gedocumenteerd is (want niet officieel ondersteund). Ik heb ooit een ProCAST workshop gevolgd, plus 2 collega's die er heel veel mee werken, anders was ik niet in staat geweest om dit op te zetten. Een leek zou er echt niets mee kunnen beginnen.

Nog Meer Plaatjes:

Het oude koelblok, nu wel met juiste instroom en juiste warmteoverdracht. Tijd = 1,28 seconde

Heatflux:



Vloeistofstroming:



Ander (nieuwer) ontwerp, Tijd = 2,08 seconde:

Heatflux:



Vloeistofstroming:

[Verwijderd]

Hmm, de flows die je hier ziet zijn errug grappig.

In het laatste vloeistofstromingplaatje kun je rechts mooi de vortex zien die geproduceerd word door de op een afstand van de wand langsstromende vloeistof. Een mooie visualisatie van wat wij kanoers een 'wals' noemen.

Wat ook opvalt is dat de temperaturen langs de wanden waar de wals optreed lager zijn. Nu is daar ook niet de hoogste energieflux richting water te vinden, maar toch...

Verder vind ik de laag waar de warmte gedissipeerd word naar het water vrij dik. Dat ligt niet aan de simulatie, maar aan 't water.

Als je nu de viscositeit van de vloeistof lager maakt, hoe zou dat de boel beinvloeden? De viscositeit van het mengsel dat er momenteel door mijn systeem vloeit is ca. 80% van die van water. De exacte waarden zou ik op moeten zoeken.

Zou de lagere viscositeit de verminderde warmtegeleiding en -capaciteit van het methanol compenseren?

[KifArU]

En een positief bericht: Erg mooi dat je dit doet. Er zijn maar heel weinig mensen die de mogelijkheid hebben om vragen eens op deze manier aan te pakken. En die hebben er meestal geen zin in. Ook de tijd om dit topic te onderhouden moet inmiddels al flink oplopen.

Nog een paar vragen: Berekent dat programma ook de vloeistofstroming zelf? Of moet je daar ook enorm veel randvoorwaarden voor ingeven?
En ken je ook simpeler pakketten die zoiets kunnen? Dan kunnen de tweakers zelf eens gaan klussen.

En over je sig: Als jullie zoveel van dit werk doen en al een bedrag van 4 of 5 cijfers voor de licentie betalen, waarom schaffen jullie dan geen dual athlon MP aan?

[_Evert_]

En over je sig: Als jullie zoveel van dit werk doen en al een bedrag van 4 of 5 cijfers voor de licentie betalen, waarom schaffen jullie dan geen dual athlon MP aan?

Licentiekosten per jaar zit rond de 4 of 5 cijfers, voor de komma welteverstaan. En nee, zelfs al zou ik willen (maar ik wil liever niet op staande voet ontslagen worden) kan ik je ook niet 'onder tafel' een kopie bezorgen, want het serienummer is op basis van het MAC adres gemaakt. Trouwens, dan moet je een HP-UX machine hebben ook nog eens.

Maar zijn er geen snellere machine's dan degene die je nu hebt dan? Dual 64 bit 236 MHz klinkt niet echt als een nieuw bakkie. Ik kan het mis hebben hoor, totaal geen kennis op dit gebied.
Of zijn deze HP bakkies nog veel duurder (lijkt me haast niet)

offtopic:

Behalve de warmteoverdracht had je dit al kunnen weten

Ja, ik was misschien wat te lui. Maar het is soms niet al te makkelijk je verschillende simulaties te onderscheiden. No offence natuurlijk, hardstikke leuk om dit te volgen.:9

[JumpStart]

Op dinsdag 21 mei 2002 17:36 schreef DaBit het volgende:
[..]

Als je nu de viscositeit van de vloeistof lager maakt, hoe zou dat de boel beinvloeden? De viscositeit van het mengsel dat er momenteel door mijn systeem vloeit is ca. 80% van die van water. De exacte waarden zou ik op moeten zoeken.

Zou de lagere viscositeit de verminderde warmtegeleiding en -capaciteit van het methanol compenseren?

Lagere viscositeit betekent hogere afschuifsnelheden, en dus dunnere grenslagen, en dus betere warmteafvoer van het koper vandaan. Ik zou niet weten of dat gunstige effect zwaarder weegt dan de afname van warmtecapaciteit van water/methanol, maar het zal het in ieder geval ten dele opheffen.

NOG meer plaatjes:

Nu alleen watertemperatuur, op 1,04 seconde (stap 250), op 2,08 seconde (stap 500) en 3,14 seconde (stap 750).

De temperatuurschaal is vastgezet op 22,0 - 29,5 °C in stappen van 0,5.

[Verwijderd]

Jah, die zijn leuk! Het 'stilstaande' water in de 'wals' word opgewarmd, en nog wel tot 29 graden. Hmmz, zou dat water echt niet wegkunnen?

[JumpStart]

Op dinsdag 21 mei 2002 22:56 schreef KifArU het volgende:
[..]

Nog een paar vragen: Berekent dat programma ook de vloeistofstroming zelf? Of moet je daar ook enorm veel randvoorwaarden voor ingeven?
En ken je ook simpeler pakketten die zoiets kunnen? Dan kunnen de tweakers zelf eens gaan klussen.

En over je sig: Als jullie zoveel van dit werk doen en al een bedrag van 4 of 5 cijfers voor de licentie betalen, waarom schaffen jullie dan geen dual athlon MP aan?

De randvoorwaarden:

- Temperatuur van het water bij instromen is 22°C
- Snelheid bij het oppervlak in is 1 m/s (bij 8 mm diameter, dat komt op 50 ml/sec uit)
- Snelheid bij uitgang is ook 1 m/sec.
- Initiële temperatuur water = 22 °C.
- Initiële tempetatuur koper = 25 °C.

Normaal is precies op contact water-koper de snelheid altijd nul, maar er mag in dit geval 'slip' optreden.

Vervolgens is er de randvoorwaarde dat het ding aan de lucht koelt, de buitenkant dus, en dat er 1 megawatt per vierkante meter ( = 1 watt / mm² ) aan warmte inkomt. De rest rekent ProCAST zelf uit.

Wat betreft de centjes: De vakgroep is onderdeel van een universiteit, en dus educatieve instelling. Wij betalen dan ook veel minder dan wat bedrijven moeten betalen voor een jaarlicentie ProCAST (Educational license vs commercial license).

Ja, we hebben ook een Dual PIIIEB 1 GHz en een Dual Athlon MP 1,2 GHz, beide met 1024 MB ram staan. Maar erhhh, niet overal is zomaar even geld voor, zo gaat dat op universiteiten. Bovendien heeft een UNIX machine toch nog een aantal voordelen ten opzichte van de PC ... Stabiliteit en uptime, om maar even iets te noemen.

[JumpStart]

Op dinsdag 21 mei 2002 23:19 schreef DaBit het volgende:
Jah, die zijn leuk! Het 'stilstaande' water in de 'wals' word opgewarmd, en nog wel tot 29 graden. Hmmz, zou dat water echt niet wegkunnen?

De 'slice' loopt precies door het dooie punt heen... Dus daar komt het water moeilijk weg, maar net naast de slice, of het nou er net voor of er net achter is, daar komt het water wel weg.

[JumpStart]

Op dinsdag 21 mei 2002 23:11 schreef _Evert_ het volgende:

[..]

Of zijn deze HP bakkies nog veel duurder (lijkt me haast niet)

[..]

Erhh, een HP9000 J2240 workstation met 1 Gb aan RAM kostte nieuw, 3,5 jaar geleden (toen het werkelijk nog een snel ding was) 90.000,- ouderwetse guldens (!!!). We hebben het niet over een veredelde PC, maar een HP-UX (HP Unix dus) workstation.

[JumpStart]

Okee, en toen was er stap 1000 ( 4,20 seconde ) en stap 1250 ( 5,25 seconde ):

Let op: de schaal staat nog steeds vast op 22,0 - 29,5 °C, maar in deze plaatjes stijgt de watertemperatuur plaatselijk tot buiten deze schaal. (ongeveer 34 °C).

[Verwijderd]

Ehm, JumpStart, er klopt toch iets niet.

Jouw initiele condities waren:
- koper 25 graden
- water 22 graden
- flow 50ml/sec (180L/uur).
- Heat flux 94W = 94J/s.

Daar ga ik er nog een bijvoegen:

- Warmtecapaciteit water 4.1kJ/K/kg.
- Dichtheid 1000kg/m³ (rekent handig)

Per seconde 50ml water, da's dus 50g/sec. Er worden 94J/sec in het water gepompt. Het uitgaand water zal dus 94 / (0.05*4100) = 0.46 graad warmer zijn dan het inkomend water. Hierbij ga ik er even vanuit dat alle warmte in het water terecht komt, wat ik volgens mij ter vereenvoudiging bet mag stellen zonder er ver naast te zitten.

Wat zie ik nu in jouw laatste plaatje, na 5.25 seconden?
Het uitgaand water is 26-27 graden. Da's dus een royale 4-5 graden meer dan wat er in het blok gaat.

Dit kan aan een nog niet stabiele situatie geweten worden, maar dat lijkt me niet erg waarschijnlijk na meer dan 5 seconden.

En de verhouding tussen mijn berekende 0.5 graad en jouw gesimuleerde 5 graden is een mooie factor 10x. Vast geen toeval

[Thyzz]

Vond ook al dat ie nog al erg snel warm werd. zeker als ik naar mijn eigen temps kijk, dan blijft het water wel een heel stuk langer de zelfde temps, of maar een veel kleinere stijging, 1 graad in 3 a 4 minuten in het begin. Die tijd groeit langzaam tot er en constante waarde onstaat natuurlijk.

Nou kan ik het natuurlijk niet exact meten omdat ik mijn CPU niet vanaf het begin op 100% kan houden, maar dit gaat wel heel hard.

[_Evert_]

Ehm, DaBit, er klopt toch iets niet.

Op donderdag 23 mei 2002 15:29 schreef DaBit het volgende:

- Warmtecapaciteit water 4.1kJ/K/kg.
- Dichtheid 1000kg/m³ (rekent handig)

Als deze waarden ingevoegd worden/zijn in de simulaties, mag voor de nauwkeurigheid de warmtecapaciteit van water gezet worden op 4.18 kJ/K/kg.
Jajaja, dit maakt voor je berekening niks uit, dat weet ik. En waarschijnlijk staat het ook wel goed in de simulatie, maar zo niet zou dit zonde zijn, want er gaat veel tijd in zitten, en dan wil je ook wel een zo nauwkeurig mogelijk antwoord.

Waarschijnlijk was dit overbodig, maar better safe than sorry toch?!

Wat ik ook niet helemaal snap: hoe kan het water in bijv de middelste cirkel van het waterblok nou warmer zijn als het water aanhet eind?
Het ziet er nu naar uit dat het water bij entree meteen heel warm wordt (27-28 gr), en naarmate het verder loopt weer kouder wordt?
Betekend dit dat je water daar wordt afgekoeld door je koper? Jaja, dat zou onzin moeten zijn, maar ik kan op je laatste plaatje de kopertemp niet terug zien. Misschien jij (jumpstart) wel.

[JumpStart]

Ik denk (maar daar kom ik binnenkort wel achter) dat de WSHEAR parameter de boosdoener is:

When the WSHEAR flag is set to 1 (en dat is 'ie dus), the no-slip nodes are converted into traction surfaces.

Waarmee wrijving en dus warmteontwikkelijk optreedt.

Als je bedenkt dat er een kanaal van rond de 50 mm² is, waar een denkbeeldige kolom van 1 meter water voorbij komt zetten, dan kan deze truuk (want dat is WSHEAR, een rekentechnisch hulpmiddel) de boosdoener wel eens zijn. De volgende simulatie, dan staat 'ie op 0.

[Verwijderd]

[quote]
Op donderdag 23 mei 2002 15:38 schreef _Evert_ het volgende:
Ehm, DaBit, er klopt toch iets niet.
[..]

Als deze waarden ingevoegd worden/zijn in de simulaties, mag voor de nauwkeurigheid de warmtecapaciteit van water gezet worden op 4.18 kJ/K/kg.
Jajaja, dit maakt voor je berekening niks uit, dat weet ik. [quote]

't ging me meer om het bewijzen dat die 5 graden TD tussen water input en output nooit kon kloppen. In de simulatie staat het wel goed AFAIK.

Wat ik ook niet helemaal snap: hoe kan het water in bijv de middelste cirkel van het waterblok nou warmer zijn als het water aanhet eind?

Dat kan nog wel. In het midden word het opgewarmd. Als het water zich sneller verplaatst dan de warmte door het koper, is zo'n situatie mogelijk.

Waarmee wrijving en dus warmteontwikkelijk optreedt

Een warmteontwikkeling van zo'n 850W (94W = 0.5 graad, 940W is 5 graden)? Lijkt me sterk, maar het zou kunnen...