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/processoren tegelijkertijd 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
Geschiedenis parallel rekenen 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
Geschiedenis parallel rekenen Halverwege jaren 90: snelle toename rekenkracht microprocessoren doorbraak PVM: krachtig platformonafhankelijk 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 programmeerstijlen 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 == ruimtelijk gebied Meestal in combinatie met het gebruiken van meerdere gekoppelde simulatie-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 simulatiemodellen 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 Cursus Domein Decompositie en Parallel Rekenen in SIMONA Module 1. Edwin Vollebregt, VORtech Computing
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 ζ ( HU ) ( HV ) + + = t x y impulsbalans, impulsvergelijkingen U ζ + g +... = f t x 0
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
Numerieke formuleringen Fysische processen/voorzieningen: verhang, bodemwrijving, advectie dichtheidseffecten, wind randvoorwaarden open/gesloten randen droogvallen en onderlopen kunstwerken: sluizen, overlaten
Numerieke formuleringen 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 gebruikers modellen systeem
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
Workflow gebruik WAQUA/- TRIWAQ Beoordelen schematisatie m.b.t. metingen, afregelen waterstanden, stroomsnelheden, zoutindringing aanpassen bodemruwheid, diepte, geometrie, randvoorwaarden processing, postprocessing
Workflow gebruik WAQUA/- TRIWAQ Gebruiken van schematisatie voor verwachtingen, effect ingrepen,
Achtergronden van parallel rekenen Cursus Domein Decompositie en Parallel Rekenen in SIMONA 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 computer meerdere processoren (CPU s) in een enkel systeem shared memory architectuur distributed memory architectuur distributed shared memory architectuur
Parallelle computers en clusters Cluster, netwerk van werkstations meerdere computers verbonden door een netwerk Distributed memory architectuur Beowulf cluster: gebouwd uit standaard PChardware 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 Speedup T 1 = tijd op 1 processor T p = tijd op p processoren S( p) = T T > 1 in geval van versnelling Lineaire speedup: S(p)=p (of αp) Superlineaire speedup: S(p)>p 1 p
Performance maten II Efficiëntie E( p) = S( p) p (S(p) = speedup, p = aantal processoren) Schaalbaarheid: E(p) min of meer constant voor grote p
Performance maten III Wet van Amdahl f = fractie parallelle berekening f T p (1 ) 1 Tp = + f T1 p S( p) = f + (1 f) p
Performance maten III
Performance maten IV Tijd voor uitwisselen van L bytes: T comm = T startup + L/B + T sync T startup = latency (10-100 μsec) B = bandbreedte (10 100 Mb/sec) T sync = 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,y x=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 OpenMP voor 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 functionaliteit t.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 T = T + T p calc, p comm, p T = max T ( p') calc, p p' calc α = synchronisatie overhead β = numerieke overhead p max ( ') p' Tcalc( p') T p' calc p T1 = T ( ') p' calc p T 1 p T1 = α β p
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 main mem. naar cache Kleinere roosters benutten cache-geheugen beter hogere rekensnelheid
Performance Aspecten III T comm = T startup + L/B per boodschap Te minimaliseren door 1) Zo min mogelijk boodschappen te sturen Via numeriek algoritme, verschillende boodschappen combineren tot een enkele Via aantal buren per subdomein 2) De omvang van de boodschappen klein te houden 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 II voor rij =1,norows - doe droogval/onderloop controles - bepaal coefficienten impuls/continuiteitsvgl - los stelsel op met iteratieve methode en droogvalcontroles voor rij =1,norows - doe droogval/onderloop controles communicatie voor rij =1,norows - bepaal coefficienten impuls/continuiteitsvgl communicatie 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 Cursus Domein Decompositie en Parallel Rekenen in SIMONA 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 Γ 2 Γ 1 Ω 1 Ω 12 Ω 2 Ω 1 Γ Ω 2 Schwarz: existentiebewijzen Techniek voor parallellisatie Rekenen met gestructureerde roosters Koppelen van verschillende modellen
Historische achtergrond Γ 2 Γ 1 Ω 1 Ω 12 Ω 2 Ω 1 Γ Ω 2 Met/zonder overlap (Iteratieve) oplosmethoden Dirichlet/Dirichlet, Dirichlet/Neumann, Schur-complement Grofroostercorrecties
Domein decompositie in SIMONA DDVERT verticale verfijning verschillend aantal lagen per deeldomein alleen relevant voor TRIWAQ een enkel horizontaal rooster simulatieinvoerfile DDHOR horizontale verfijning zowel voor WAQUA als TRIWAQ verschillende horizontale roosters, aparte simulatie-invoerfiles
Toekomst: variatie fysische proces-modellen 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 aan TRIWAQ, x- aan y-roosterlijnen
Toekomst: koppeling tussen verschillende modules Koppeling van WAQUA/TRIWAQ met Morfologie Slib Ecologie Golven Kalman-filter Op basis van zelfde technieken als voor parallel rekenen en domein decompositie Binnen kader van OMS
Systeem-overzicht DDVERT
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
Verticale interpolaties k, eps u, v qx, qy
Systeem-overzicht DDHOR
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 Cursus Domein Decompositie en Parallel Rekenen in SIMONA Module 1. Edwin Vollebregt, VORtech Computing
Inhoud Gebruik van parallel rekenen voor het Maas-model Gebruik van domein decompositie met verticale verfijning voor het Zeedeltamodel Werkplan voor gebruik van domein decompositie met horizontale verfijning
Parallel rekenen voor het Maasmodel Maas-model: van Eijsden (km 2) tot Keizersveer (km 247) Ontwikkeld o.a. t.b.v. randvoorwaardenboek 2001, door RIZA-Arnhem Afregeling bodemruwheden door HKVlijn 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-/postprocessing en wachttijd bekijken
Aandachtspunten parallel rekenen Vaak duurder (in geld) om parallel te rekenen dan sequentieel efficiency meestal < 1 liever meerdere sommen tegelijkertijd dan iedere som parallel door cache-effecten soms ook efficiency > 1
Aandachtspunten parallel rekenen Parallel rekenen is moeilijker dan sequentieel rekenen optimale performance vereist een goed gebalanceerde partitie, handmatig verfijnd supercomputers gebruiken vaak een wachtrij-systeem, Linux clusters: nodes selecteren sommige parallelle computers: slechts 1 rekenproces per processor te gebruiken
Domein decompositie voor het Zeedelta model Hollandse kust Noordelijk Delta Bekken Hagestein Tiel Haringvliet sluizen Lith
Zeedelta-model Ontwikkeld in project Nautilus voor verschillende doeleinden: Operationele voorspelling (HMR) Beleidsondersteuning Planvorming Bijvoorbeeld project de Kier, alternatief beheer 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 4 lagen 4 lagen 10 lagen 1 laag 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 WAQUAfunctionaliteit in rivierdelen: overlaten, alleen toegestaan igv 1 laag Nikuradse ruwheidsberekening, randvoorwaarde met automatische debietverdeling
Voordelen verticale verfijning Combinatie van verschillende ruwheidsformuleringen 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
Aandachtspunten verticale verfijning 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
Aandachtspunten verticale verfijning 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 bestaande schematisaties, 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 detailmodel 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 interessegebied 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
Aandachtspunten horizontale verfijning 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)
Aandachtspunten horizontale verfijning 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