Introductie Parallel Rekenen en Domein Decompositie, module...

Rijkswaterstaat/RIKZ

Introductie Parallel Rekenen en Domein Decompositie

Cursus “Domein Decompositie en Parallel Rekenen in SIMONA”

Module 1.

Edwin Vollebregt, VORtech Computing


Inhoud

• Waarom parallel rekenen ?

• Geschiedenis parallel rekenen

• Wat is domein decompositie ?

• Waarom domein decompositie ?

• Geschiedenis par+dd in SIMONA


Waarom parallel rekenen ?

• Parallel rekenen is “het gebruik van meerdere computers/processorentegelijkertijd voor een enkele rekentaak”

Teras – SARA –1024 processoren,

1 TB geheugen


Waarom parallel rekenen ?

• Rekensnelheid: vele handen maken licht werk– De totale inspanning vermindert niet

(meestal zelfs minder efficiënt met meer “handen”)

– De “handen” moeten ieder voor zich wel voldoende kracht meebrengen

• Hoeveelheid geheugen: samen zijn we sterk


Geschiedenis parallel rekenen

• Al vroeg in 20e eeuw onderzocht– zaal met rekenaars voor weersvoorspelling

(Richardson, 1922)

– rekenapparaat met gelijktijdig werkende componenten (V. Bush, 1920)

• Opkomst vector-computers in 70-er jaren– Cray, Cyber, Fujitsu, Nec

• Opmars “massaal parallel rekenen” in 80-er jaren– nCube, CM-2, CM-5, transputers, iPSC, Paragon



• Begin jaren 90:– vectorcomputers veruit het snelst

– vectorcomputers worden enigszins parallel

helder programmeermodel

– veel verschillende “massaal parallelle computers”, architecturen

– diverse programmeermodellen

message passing is lastig



• Halverwege jaren 90:– snelle toename rekenkracht micro-

processoren

– doorbraak PVM: krachtig platform-onafhankelijk message passing programmeermodel

– geschikt voor kleinere/onregelmatigere problemen dan vectorisatie

– bereikbaar voor kleinere beurzen


Huidige status parallel rekenen

• Supercomputers zijn parallelle computers

• Netwerken ordes sneller dan voorheen– the Grid, ambient computing

• Wereldstandaarden in programmeer-stijlen– data parallel: Fortran95 (HPF)– shared memory: OpenMP– message passing: MPI


Aandachtspunten par.rekenen

• Het werk moet worden verdeeld– extra programmeerwerk– er moet voldoende werk zijn om te verdelen

• Er ontstaan afhankelijkheden– volgorde-eisen, eerst fundering dan muren– afstemming, synchronisatie, communicatie

• Keuze par.computer, programmeertaal– performance-aspecten


Wat is domein decompositie ?

• Domein decompositie is “het opdelen van het interessegebied in meerdere domeinen”

• Domein == ruimtelijkgebied

• Meestal in combinatiemet het gebruiken vanmeerdere gekoppeldesimulatie-modellen


Waarom domein decompositie ?

• Implementatieniveau: opdelen rekenwerk t.b.v. parallel rekenen

• Numerieke niveau: mechanisme voor creëren slimme wiskundige oplostechnieken

Gebruikersniveau: modelleerflexibiliteit en performance


Waarom domein decompositie ?

• Combineren verschillende simulatie-modellen en/of roosterfijnheden– alleen hoge resolutie waar dat nodig is– minder restricties aan gestructureerd

rooster– gemakkelijker nesten van modellen– alleen zout-berekening waar dat relevant is,– …

Modelleerflexibiliteit en performance


Geschiedenis par+dd in SIMONA

• 1992-7: onderzoek TU Delft naar parallel rekenen

• 1996: test-versie parallel TRIWAQ in SIMONA

• 1997: testen RIJMAMO 32-48 processoren

• 1998-9: ontwikkeling parallel WAQUA

• 1999: gebruik parallel WAQUA voor Maas-model,parallel TRIWAQ voor Nautilus

• 1999: test-versie DDVERT: verticale verfijning


Geschiedenis par+dd in SIMONA

• 2000: opname parallel rekenen in SIMONA B+O

• 2000: gebruik DDVERT voor Zeedelta

• 2001: test-versie DDHOR: horizontale verfijning

• 2001: opname DDVERT in SIMONA B+O

• 2001: gebruik DDVERT voor Afsluitdijk

• 2002: opname DDHOR in SIMONA B+O

• 2003-…: verdere ontwikkeling DD-functionaliteit


Resumé WAQUA/TRIWAQ


Module 1.



Inhoud

• Toepassingsgebied WAQUA/TRIWAQ

• Simulatiemodel, numerieke technieken

• (Infra-)Structuur SIMONA

• Workflow gebruik WAQUA/TRIWAQ


Toepassingsgebied WAQUA/-TRIWAQ

• Simulatie van waterbeweging en waterkwaliteit in rivieren, estuaria en kustwateren

• Beheer, beleid en onderzoek– operationeel gebruik

stormvloed, havens

– plannen dijkhoogtes,randvoorwaardenboek, 2e Maasvlakte

– ecologie Noordzee


Toepassingsgebied WAQUA/-TRIWAQ

• 2D (WAQUA) en 3D (TRIWAQ) stromingsvergelijkingen met ondiepwater-benadering

• Gericht op beheersgebieden van de Rijkswaterstaat

Allerlei voorzieningen voor praktische toepassingen: droogvallen/onderlopen, sluizen, …


Gebiedsschematisatie


Ondiepwatervergelijkingen

• massabalans, continuïteitsvergelijking

• impulsbalans, impulsvergelijkingen

( ) ( ) 0HU HVt x yζ∂ ∂ ∂+ + =

∂ ∂ ∂

...U g ft x

ζ∂ ∂+ + =

∂ ∂


Numerieke formuleringen

• Kromlijnig rooster (“boundary fitted”)

• Verticaal: flexibele laagverdeling (gedeeltelijk ademend rooster)

• Discretisatie met eindige differentie methode

• Tijdsintegratie met ADI-methode

• Gericht op robuustheid en nauwkeurigheid



Fysische processen/voorzieningen:

• verhang, bodemwrijving, advectie

• dichtheidseffecten, wind

• randvoorwaarden open/gesloten randen

• droogvallen en onderlopen

• kunstwerken: sluizen, overlaten



• De simulatie is opgedeeld in tijdstappen

• Iedere tijdstap bestaat uit fases die volgen uit het ADI-schema

• In de fases worden verschillende stelsels vergelijkingen opgelost (iteratieve solvers)

• Per roostercel wordt een waterstand berekend en 3·#lagen snelheden


(Infra-)Structuur SIMONA

• Omgeving voor het bouwen van simulatie-programmatuur

• Standaard functionaliteiten:– keyword-gebaseerde invoerfiles

– memory management

– uniforme gegevensopslag, archivering

• Eén moederversie, centraal beheer en onderhoud


Structuur SIMONA applicaties

syste

em

mod

ellen

gebr

uiker

s


Workflow gebruik WAQUA/-TRIWAQ

• Bepalen interessegebied, relevante fysische grootheden en processen

• Opzetten gebiedsschematisatie:– ligging open randen

– keuze resolutie, genereren rekenrooster

– invullen fys.parameters, lozingen, sluizen, overlaten , randvoorwaarden, …

pre-processing



• Beoordelen schematisatie m.b.t. metingen, afregelen– waterstanden, stroom-

snelheden, zoutindringing…

– aanpassen bodemruwheid,diepte, geometrie,randvoorwaarden

processing, post-processing



• Gebruiken van schematisatie voor verwachtingen, effect ingrepen, …


Achtergronden van parallel rekenen


Module 1.

Mark Roest, VORtech Computing


Inhoud

• Parallelle computers en clusters

• Performancematen

• Programmeermodellen

• Globaal ontwerp parallel WAQUA/TRIWAQ

• Performance aspecten

• Nauwkeurigheidsaspecten

• Herstructurering van sequentieel WAQUA


Parallelle computers en clusters

• Parallelle computermeerdere processoren (CPU’s) ineen enkel systeem

– shared memory architectuur

– distributed memory architectuur

– distributed shared memory architectuur


Parallelle computers en clusters

• Cluster, netwerk van werkstationsmeerdere computers verbondendoor een netwerk

– Distributed memory architectuur

– Beowulf cluster: gebouwd uit standaard PC-hardware

• Cluster van parallelle computers– Hybride architectuur


Shared memory architectuur


Distributed memory architectuur


Afwegingen type parallelle computer

• Shared memory architectuur– gemakkelijkste te programmeren

– moeilijk te bouwen – duur, weinig schaalbaar

• Distributed shared memory– schaalbaar, maar soms meer programmeerwerk

nodig voor goede performance

• Distributed memory architectuur– goedkoper, maar altijd meer programmeerwerk

• Beowulf cluster– goedkoopst, merk je in schaalbaarheid


Performance maten I

• SpeedupT1 = tijd op 1 processorTp = tijd op p processoren

– > 1 in geval van versnelling– Lineaire speedup: S(p)=p (of αp)

– Superlineaire speedup: S(p)>p

1( )p

TS pT

=


Performance maten II

• Efficiëntie

(S(p) = speedup, p = aantal processoren)

Schaalbaarheid: E(p) min of meer constant voor grote p

( )( ) S pE pp

=


Performance maten III

Wet van Amdahl

f = fractie parallelle berekening

11(1 )

( )(1 )

pf TT f T

ppS p

f f p

⋅= + − ⋅

=+ − ⋅


Performance maten III


Performance maten IV

• Tijd voor uitwisselen van L bytes:

Tcomm = Tstartup + L/B + Tsync

Tstartup = latency (10-100 μsec)

B = bandbreedte (10 – 100 Mb/sec)

Tsync = synchronisatietijd


Performance maten V

• Contentie= ‘strijd’ om beperkte hardware resources– memory contentie– netwerk contentie (latency en bandbreedte)– I/O contentie

• Load balance= de mate waarin alle processoren evenveel

werk doen– bepaalt de synchronisatietijd


Programmeermodellen I

• Data-parallel

REAL,DIMENSION(10)::x,yx=x+y

– Compiler verdeelt het werk en kan daarbij optimaal profiteren van kennis van de computerhardware

– Relatief eenvoudig te programmeren

Maar:

– Performance vaak slecht


Programmeermodellen II

• Shared memory programmeren– Uitbreiding van data-parallel programmeren

– Extra programmeerconstructies OpenMPvoor globale data-items, synchroniseren

– Programmeur verdeelt het werk – moeilijker te programmeren

Maar:

– Meer controle over performance


Programmeermodellen III

• SPMD, message passing

– Programma wordt meerdere keren opgestart, steeds met andere invoer data

– Communicatie via bijvoorbeeld PVM of MPI

– Programmeur moet data verdelen en communicatie invoegen – relatief lastig

Maar

– Blijkt vaak nodig voor goede performance en schaalbaarheid


Programmeermodellen IV

• Functioneel parallel– Meerdere programma’s (processen) of

threads met elk een eigen functie

– Voorbeelden:• Master-slave programma’s

• Pipelines

– Hardware-matig het soort parallellisme waar vectorcomputers gebruik van maakten


Globaal ontwerp Parallel WAQUA


COPPRE/Partitoner

• Bepaalt opdeling van het rekenrooster– Automatische methoden (STRIP, ORB) of

– Op basis van extern gespecificeerde opdeling – VISIPART / extern pakket

• Creëert SDS-files per deel– Op basis van een file waarin de LDS

beschreven staat


VISIPART

• Hulpmiddel voor het maken van roosteropdelingen

• Verfijnen partitie m.b.v. gemeten run-tijden

• Extra functionaliteitt.b.v. DDVERT


COEXEC/Master

• Leest een configuratiefile

• Start de WAQUA processen

• Verzamelt message-uitvoer van de processen en schrijft deze voorzien van een label naar een enkele file

• Ondersteunt bij communicatie problemen

• Breekt processen af bij echte problemen


COCLIB

• Een bibliotheek van communicatie routines

• Routines zijn gericht op de numeriek wiskundige programmeur

• Slechts één operatie voor uitwisselen tussenresultaten over deeldomein randen: de update operatie of cocupd


COPPOS

• Verzamelt resultaten uit SDS-files van de deeldomeinen tot één SDS-file voor het hele domein

• Gebruikt tabellen van COPPRE


Performance Aspecten I

α = synchronisatie overhead

β = numerieke overhead

, ,

, '

' ' 1

1'

1

max ( ')

( ')max ( ')( ')

p calc p comm p

calc p p calc

calcp calc p

calcp

T T T

T T p

T pp T p TT p T p

Tp

α β

= +

=

⎛ ⎞⎛ ⎞⋅ ⎛ ⎞⎜ ⎟⎜ ⎟= ⎜ ⎟⎜ ⎟⎜ ⎟ ⎝ ⎠⎝ ⎠⎝ ⎠

= ⋅ ⋅

∑∑


Performance Aspecten II

• Numerieke overhead– Meer iteraties nodig voor een parallelle

iteratieve solver (β > 1)

– Sneller rekenen door cache-effecten(β < 1)

• Synchronisatie overhead– Minimaal (α =1) werklast gelijkmatig

gebalanceerd

– Langzaamste bepaalt tempo van hele groep


Cache-effecten

• Verbinding CPU-cache is sneller dan CPU-main mem.

• I.g.v. “cache-miss” wel hele “cache-line” tegelijk van mainmem. naar cache

• Kleinere roosters benutten cache-geheugen beter

hogere rekensnelheid


Performance Aspecten III

• Tcomm = Tstartup + L/B per boodschap

• Te minimaliseren door1) Zo min mogelijk boodschappen te sturen

Via numeriek algoritme, verschillendeboodschappen combineren tot een enkele

Via aantal buren per subdomein

2) De omvang van de boodschappen klein tehouden

Via zo kort mogelijke subdomeinranden


Nauwkeurigheidsaspecten I

• Precies zelfde discretisaties in parallelle runs als in sequentiële simulaties

Toch enige verschillen:

• Numerieke resultaten verschillen voor– sequentiële run oudere versie WQ/TRW

– parallelle run sequentiële run


Nauwkeurigheidsaspecten II

• Herstructurering ten behoeve van parallellisatie– Iets gewijzigde implementatie van

droogval-controle

– Viscositeitskruistermen verwijderd

Verschillen tussen niet-parallelle runs met WAQUA-versies voor/na introductie parallel rekenen (eind 2000)


Nauwkeurigheidsaspecten III

• Andere iteratieve procedures in parallelle dan in sequentiële runs– Verschillen te verminderen door groot

aantal iteraties te gebruiken

• Andere afrondfouten in parallelle dan in sequentiële runs– Gevoelige modellen

– Net wel/net niet droogvallen

– Optreden van gelaagdheid


Herstructurering WAQUA I

• Herstructering van programmatuur nodig om– Aantal berekeningen dat gelijktijdig

uitgevoerd kan worden te verhogen

– Aantal communicaties dat nodig is te verlagen


Herstructurering WAQUA IIvoor rij =1,norows

- doe droogval/onderloopcontroles

- bepaal coefficientenimpuls/continuiteitsvgl

- los stelsel op met iteratievemethode en droogvalcontroles

voor rij =1,norows- doe droogval/onderloop

controlescommunicatie

voor rij =1,norows- bepaal coefficienten

impuls/continuiteitsvglcommunicatie

voor rij =1,norows- los stelsel op met iteratieve

methode en droogvalcontroles


Herstructurering WAQUA III

• Optie om stopcriterium voor de continuïteitsvergelijking te baseren op waterstanden i.p.v. stroomsnelheden

• Viscositeitskruistermen zijn optioneel

• Kleine verbeteringen– Opslaan van

roostertransformatiecoëfficienten– Aparte loops voor wind- en

dichtheidsberekeningen


Achtergronden van domein decompositie


Module 1.

Bas van ‘t Hof, VORtech Computing


Inhoud

• Historische achtergrond van domein decompositie

• Ontwikkeling domein decompositie in SIMONA

• Interpolaties in COCLIB, COPPOS, WAQPRE

• Matchen van roosters

• Nauwkeurigheidsaspecten


Historische achtergrond: doelen

• Schwarz: existentiebewijzen

• Techniek voor parallellisatie

• Rekenen met gestructureerde roosters

• Koppelen van verschillende modellen

Ω1 Ω1Ω2 Ω2Ω12

Γ2 Γ1

Γ


Historische achtergrond

• Met/zonder overlap

• (Iteratieve) oplosmethoden– Dirichlet/Dirichlet, Dirichlet/Neumann, …

– Schur-complement

– Grofroostercorrecties

Ω1 Ω1Ω2 Ω2Ω12

Γ2 Γ1

Γ


Domein decompositie in SIMONA

• DDVERT – verticale verfijning– verschillend aantal lagen per deeldomein

– alleen relevant voor TRIWAQ

– een enkel horizontaal rooster – simulatie-invoerfile

• DDHOR – horizontale verfijning– zowel voor WAQUA als TRIWAQ

– verschillende horizontale roosters, aparte simulatie-invoerfiles


• k-ε turbulentie en/of transport en/of hydrostatische aanname alleen in sommige deeldomeinen

• k-ε, zouttransport, tstep = 5 min

• k-ε, zouttransport, tstep =1 min

• k-ε, zouttransport, tstep = 0.5 min

• Algebraisch turb, zout constant, tstep = 1 min

• tijdstapkoppeling, WAQUA aanTRIWAQ, x- aan y-roosterlijnen

Toekomst: variatie fysische proces-modellen


Koppeling van WAQUA/TRIWAQ met

• Morfologie

• Slib

• Ecologie

Op basis van zelfde technieken alsvoor parallel rekenen en domeindecompositie

Binnen kader van OMS

• Golven

• Kalman-filter

• …

Toekomst: koppeling tussenverschillende modules


Systeem-overzicht DDVERT


DDVERT: laagverdelingen


Strategie domein decompositie

• Gebruikelijk vanuit wiskunde:– Toevoegen van koppelingsvergelijkingen

– Vaak lagere orde discretisaties nabij subdomeinranden

• Strategie in WAQUA/TRIWAQ:– Toevoegen “guard band” van 3 rijen dik

– Toepassen volledige discretisatie-stencils

– Op basis van geïnterpoleerde waardes


Strategie domein decompositie

• Voor- en nadelen:– minder verstoringen t.o.v. enkel domein

berekeningen

– koppelingsvergelijkingen impliciet in gebruikte interpolatie-formules

– geen last van in rekenhart per subdomein

– minder directe controle over

Numerieke aspecten zijn nog niet grondig onderzocht


k, eps u, v qx, qy

Verticale interpolaties


Systeem-overzicht DDHOR


Horizontale interpolaties


Matchen van roosters


Variabele verfijningsfactoren


Nummering van roosterlijnen


Nauwkeurigheidsaspecten

Nauwkeurigheid blijkt nauwelijks te lijden onder verfijningen (geen reflecties)

Oplossingen lijken lokaal sterk op oplossingen met uniform rooster


Nauwkeurigheidsaspecten


Toepassing(en) van parallel rekenen en domein decompositie


Module 1.



Inhoud

• Gebruik van parallel rekenen voor het Maas-model

• Gebruik van domein decompositie met verticale verfijning voor het Zeedelta-model

• Werkplan voor gebruik van domein decompositie met horizontale verfijning


Parallel rekenen voor het Maas-model

• Maas-model: van Eijsden (km 2) tot Keizersveer (km 247)

• Ontwikkeld o.a. t.b.v. randvoorwaarden-boek 2001, door RIZA-Arnhem

• Afregeling bodemruwheden door HKV-lijn in water op supercomputer Unite

• Toegepast voor bepalen effectiviteit van ingrepen voor de Maaswerken


Omvang van het Maas-model

• Rooster: 107 x 4182 punten, waarvan zo’n 210.000 punten actief zijn (47%)

• Simulatieduur: 10-15 dagen voor een hoogwatergolf. – Opstarten, aanloop-periode, looptijd golf door model

• Tijdstap: 12 of 15 seconden, 55.000-110.000 stappen/simulatie

• Orde 4 biljoen berekeningen/simulatie


Afregelen van het Maas-model

• De ruwheden van het model zijn afgeregeld met een automatische procedure

• Simulatie verschil t.o.v. metingen (waterstanden, debieten) aanpassing ruwheden nieuwe simulatie

• Orde 50 iteraties

• Op een Unix werkstation zonder parallel rekenen: orde 200 dagen (niveau 1999)


Supercomputer UNITE van SARA

• SGI Origin2000 machine, 128 processoren, “virtueel shared memory”

• Goede performance per processor en krachtig communicatie-netwerk

• begin 1999 geïnstalleerd bij SARA

• porten parallel WAQUA/TRIWAQ tijdelijk lastig, net als gebruik wachtrij-systeem


Parallelle performance voor het Maas-model

• Speedup 22 op 16 prc– van 200 dgn naar 10

– efficiency 1,4:cache effecten


Niet-exclusief gebruik processoren

• UNITE verzint zelf op welke processor rekenprocessen draaien

• Wachten op communicatie trekt processen van andere gebruikers aan!

• Vgl. vergadering: als er een even weg moet, moet iedereen daarop wachten

gebruik “poll” i.p.v. “sleep”, maar dan slechts 1 proces/processor te gebruiken


Effect van ingrepen – de Maaswerken

• Deltawet Grote Rivieren:treffen van maatregelen opdat de overstromingskans langs de grote rivieren < 1/250 p.jaar wordt


Effect van ingrepen - Maaswerken

• Voorgestelde aanpassingen:– verhogen kades,

– verbreden/verdiepen zomer/winterbed,

– aanleggen retentiegebieden, …

• Effectbepaling m.b.v. WAQUA-model van de Maas

• Sinds 1999 zo’n 450 simulaties uitgevoerd


Aandachtspunten parallel rekenen

• Performance afhankelijk van grootte van schematisatie

limiet aan aantal nuttige processoren

hoger voor TRIWAQ dan voor WAQUA

afhankelijk van type parallelle computer,m.n. communicatie-snelheid: latency,bandbreedte

doorlooptijd in relatie tot pre-/post-processing en wachttijd bekijken



• Vaak duurder (in geld) om parallel te rekenen dan sequentieel

efficiency meestal < 1

liever meerdere sommen tegelijkertijd daniedere som parallel

door cache-effecten soms ook efficiency > 1



• Parallel rekenen is moeilijker dan sequentieel rekenen

optimale performance vereist een goedgebalanceerde partitie, handmatig verfijnd

supercomputers gebruiken vaak eenwachtrij-systeem, Linux clusters: nodesselecteren

sommige parallelle computers: slechts 1rekenproces per processor te gebruiken


Domein decompositie voor het Zeedelta model

Hagestein

Tiel

LithHaringvliet

sluizen

Hollandse kust

Noordelijk Delta Bekken


Zeedelta-model

• Ontwikkeld in project Nautilus voor verschillende doeleinden:– Operationele voorspelling (HMR)

– Beleidsondersteuning

– Planvorming

Bijvoorbeeld project “de Kier”, alternatiefbeheer Haringvlietsluizen


Zeedelta model

• Rooster van 470 x 1538 punten, waarvan 155.000 actief (22%)

• Simulatieperiode 10-15 dagen, tijdstap 30 sec (28.800-43.200 stappen)

• 3D-effecten in kustzone: zouttransport, gelaagdheid, k-E turbulentie-model

• 2DH dieptegemiddelde berekening in rivierengedeelte (TRIWAQ 1 laag)


Laagverdeling Zeedelta-model

1 laag

4 lagen

10 lagen

4 lagen

7 lagen


Laagverdeling Zeedelta-model


Combinatie met parallel rekenen

• De deeldomeinen waarin verschillende roosters worden gebruikt mogen ieder worden opgedeeld in stukken– doelstelling: gelijkmatige verdeling van

rekenwerk– zo klein mogelijke grootste rekentijd per

subdomein

• Zeedelta op TERAS-machine: 4 minuten rekentijd per uur simulatie


Voordelen verticale verfijning

• Hogere performance/nauwkeurigheid– uitsparen rekentijd in gebieden waar minder

lagen nodig zijn

• Gebruiken van speciale WAQUA-functionaliteit in rivierdelen:– overlaten, alleen toegestaan igv 1 laag– Nikuradse ruwheidsberekening,– randvoorwaarde met automatische

debietverdeling


Voordelen verticale verfijning

• Combinatie van verschillende ruwheids-formuleringen– Manning in kustgebied, White-Colebrook in

rivieren

• Minder numerieke problemen in rivieren– zouttransport bij sterke bodemgradiënten

• Minder num.problemen bij open randen– randvoorwaarden verkregen uit grover

model: opdrukken met zelfde aantal lagen


Aandachtspunten verticale verfijning

• Onderscheid doelstellingen DDVERT en parallel rekenen

• Roosteropdeling afhankelijk v/d fysica en interesse gebruiker– door deskundige gebruiker op te geven– subdomeinranden uit de buurt van grote

gradiënten– uit de buurt van open randen en speciale

constructies



• Uitbreidingen simulatie-invoerfile m.b.t. laagafhankelijke informatie– per subdomein aparte include-files

• Let op fysische parameters– met name diffusie-coëfficiënt groter in

modellen met minder lagen

• Let op uitvoer SDS-file– geïnterpoleerd naar hoogste aantal lagen/

grootste resolutie



• Combinatie DDVERT + parallel vereist extra inspanning– verdelen processoren over gebieden met

verschillend aantal lagen

– handmatig balanceren roosteropdeling

– rekentijd moeilijker te voorspellen op basis van aantal roosterpunten


Werkplan verticale verfijning

• Ontwikkel schematisaties in eerste instantie met weinig lagen, zonder verfijning– minder complex, sneller rekenen/testen

• Ontwerp geschikte roosteropdeling en laagverdeling per deeldomein– primair op basis van fysica/interesse


Werkplan verticale verfijning

• Implementeer de gekozen opdeling– houd direct rekening met parallel rekenen:

nummering deeldomeinen, naamgeving include-files

• Afregelen model met verfijning– vergelijking met sommen zonder verfijning

is niet altijd mogelijk

– en ook niet altijd relevant, representatie fysische processen afhankelijk #lagen


Domein decompositie met horizontale verfijning

• Verschillende soorten toepassingen

1) on-line koppeling van bestaandeschematisaties, i.p.v. nesten

2) lokaal verfijnen van gebied met speciale interesse

3) roosters maken die anders niet kunnen


Modellentrein


On-line koppeling

+Hogere nauwkeurigheid in het detail-model werkt door in het globale model

+De “randvoorwaarden” voor het detail model worden automatisch aangepast t.o.v. ingrepen

- Extra rekenwerk t.o.v. off-line nesten

- Geen Kalman-filtering van randvoorwaarden voor detail-model


Verfijnen speciaal interesse-gebied

• Selecteren gebied uit bestaande schematisatie

• Genereren 2/3/4 keer fijner rooster

• On-line koppeling, geen gedoe om goede randvoorwaarden te genereren

• Eenvoudig een stuk uitschakelen uit bestaande schematisatie


Roosters die anders niet kunnen

• Vermijden knikken en oprekking

• Vermijden doorlopende roosterlijnen


Aandachtspunten horizontale verfijning

• Meerdere simulatie-invoerfiles voor aparte roosters

• Roosters moeten op elkaar zijn afgestemd

van te voren goed overdenken/ontwerpen

• Aparte siminp-files kunnen afzonderlijk worden ontwikkeld

pas later stukken inactief maken/verfijnen



• Aparte uitvoer SDS-files per rooster– nog weinig voorzieningen voor samen

visualiseren

– hoeveelheid uitvoer per rooster apart te configureren

• Enkele variaties in proces-formulering te gebruiken (ruwheid, …)– andere instellingen moet gelijk zijn voor alle

roosters (tijdstap, wel/geen transport)



• Combinatie met parallel rekenen– per rooster roosteropdeling opgeven voor

inactieve stuk en voor parallel rekenen

aan te maken met VISIPART

– balanceren werklast enigszins omslachtig: meerdere opdelingen samen

– op sommige machines is maar 1 rekenproces per processor toegestaan

Introductie Parallel Rekenen en Domein Decompositie, module...

Documents

Transcript of Introductie Parallel Rekenen en Domein Decompositie, module...