Detailontwerp van de Domein Decompositie in WAQUA en TRIWAQ. Technisch Rapport TR01-06 versie 2.6 (4 april 2014)

VORtech Computing Experts in Technisch Rekenwerk Postbus 260 2600 AG DELFT tel. 015-285 0125 fax. 015-285 0126 [email protected]

Detailontwerp van de Domein Decompositie in WAQUA en TRIWAQ Technisch Rapport

TR01-06 versie 2.6 (4 april 2014)

Datum 4 april 2014 Auteur(s) dr.ir. E.A.H. Vollebregt dr.ir. M.R.T. Roest dr.ir. B. van ‘t Hof

In opdracht van Rijkswaterstaat/RIKZ

Niets uit deze uitgave mag worden verveelvoudigd, opgeslagen in een geautomatiseerd gegevensbestand, of openbaar gemaakt, in enige vorm of op enigerlei wijze hetzij elektronisch, mechanisch, door fotokopie¨ en, opnamen, of op enige andere manier, zonder voorafgaande schriftelijke toestemming van de opdrachtgever danwel VORtech Computing, Postbus 260, 2600 AG DELFT. c VORtech Computing 2014.

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014)

Log-sheet Versie Auteur Datum Opmerkingen 0.8 EV/MR/BH 13-04-2001 concept versie van detail ontwerp voor fase 1 van overeenkomst RKZ-951 (realisatie eerste versie DDHOR). 0.9

EV/MR/BH 16-04-2001 aangepaste concept versie van detail ontwerp voor fase 1 van overeenkomst RKZ-951 (realisatie eerste versie DDHOR).

1.0

EV/MR/BH 27-04-2001 definitieve versie van detail ontwerp voor fase 1 van overeenkomst RKZ-951 (realisatie eerste versie DDHOR).

1.1

EV/MR/BH 30-08-2001 aangepaste versie waarin de feitelijke implementatie is vastgelegd voor fase 2b van overeenkomst RKZ-951 (realisatie eerste versie DDHOR).

1.2

EV/BH

27-11-2001 ddhor-02-w: automatische partitie van randpunten, aanpassing definitie van enclosures. ddhor-03-w: toestaan van half-gekoppelde cellfaces aan uiteindes van interfaces.

1.3

EV

08-03-2002 ddhor-05-w: eliminatie van COCLIB-oud uit WAQPRE en COPPOS.

1.3.1

EV

08-04-2002 ddhor-11-p: kleine correcties Figuur 5.2, en sectie 3.6.5.

2.0

EV/BH/CV

31-08-2003 DDHRVR01: domein decompositie met horizontale en vertikale verfijning.

2.1

EV

10-10-2003 ddhrvr-11-p: verbeteringen aan invulling en gebruik van ISBBOU.

2.2

EV/BH

15-11-2004 Aanpassingen aan de data-analyse in het kader van het droogvalproject.

2.3

EV

23-10-2006 c65666: aanpassingen aan de data-analyse n.a.v. opname niet-hydrostatisch rekenen.

ii

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) Versie Auteur Datum Opmerkingen 2.4 EV 09-11-2006 c65667: aanpassingen aan de data-analyse n.a.v. opname horizontaal turbulentiemodel. 2.4.1

EV

03-01-2008 c77580: kleine wijzigingen m.b.t. samecell interpolatiemethode

2.4.2

EV

10-01-2008 c77580: kleine wijzigingen in areas-file

2.5

EV

14-02-2008 c77580: automatische partitie van subdomeinen van areas-files

2.6

BvtH

01-07-2008 c74231: koppeling op basis van uitgaande info; dataanalyse trscnt

2.6.1

BvtH

11-07-2008 c74231: kleine verbetering van de efficiëntie in het uitgaande-informatie schema

iii


iv

Samenvatting Domein decompositie is een algemene techniek voor het vergroten van de vrijheid van gebruikers van WAQUA en TRIWAQ in het definiëren van gebiedsschematisaties. Bijvoorbeeld biedt het de mogelijkheid om het rekenrooster dat wordt gebruikt te verfijnen in gebieden waarin men sterk is ge¨ınteresseerd, of in gebieden waar zich zeer lokale processen afspelen (rond sluizen en dergelijken). Tegelijkertijd kan met domein decompositie de doorlooptijd voor een simulatie sterk worden teruggebracht doordat fijne vermazing (horizontaal) of een groot aantal lagen (vertikaal) slechts voor een deel van het domein toegepast kan worden in plaats van voor het domein als geheel. In dit rapport presenteren we het detail ontwerp voor WAQUA/TRIWAQ met domein decompositie met horizontale en vertikale verfijning. Het gaat daarbij over de versie van WAQUA/TRIWAQ die in het DDHOR+VERT project is ontwikkeld (opdracht RKZ-1260), waarin horizontale en vertikale verfijning gelijktijdig in een enkele simulatie kunnen worden gebruikt. De inhoud van het rapport is echter niet beperkt tot de uitbreidingen die nodig waren voor deze combinatie. Het doel is namelijk om een overzicht te geven over het totale ontwerp van domein decompositie en (in mindere mate) parallel rekenen in WAQUA/TRIWAQ. Met de huidige domein decompositie versie van WAQUA/TRIWAQ kan de gebruiker delen van verschillende (reguliere/bestaande) gebiedsschematisaties (siminp-files) specificeren en gezamenlijk laten doorrekenen. Hiervoor moeten de buitenranden van de geselecteerde stukken met elkaar samenvallen, maar mogen er wel verschillende roosterfijnheden worden gebruikt. De verfijningsfactoren mogen verschillen tussen x- en y-richtingen en mogen variëren langs een interface. Wel moeten de roosterlijnen uit het grove domein doorlopen in het naburige fijnere domein. In de vertikale richting gelden soortgelijke eisen: het aantal gekoppelde lagen van het fijnere domein mag verschillen per laag van het grove domein, maar de laaginterfaces van het grove domein moeten wel doorlopen in het fijnere domein. Voor het selecteren van de stukken per siminp-file hoeft de gebruiker alleen een roosteropdeling aan te leveren in een format dat consistent is met dat van parallel rekenen en vertikale verfijning. De programmatuur bepaalt op basis hiervan de coördinaten van de buitenranden van de verschillende stukken. Met de roosteropdeling kunnen de geselecteerde stukken van de verschillende siminp-files ook verder worden onderverdeeld ten behoeve van de combinatie met parallel rekenen, en voor het gebruik van vertikale verfijning binnen een siminp-file. Een voordeel van het gebruik van vertikale verfijning binnen een enkele siminp-file is dat de resultaten van verschillende deeldomeinen worden verzameld in een enkele SDS-file, en dat de benodigde communicaties iets sneller worden uitgevoerd. Daar staat tegenover dat in deze


v

SDS-file alle uitvoerdata zijn ge¨ınterpoleerd naar de fijnste vertikale resolutie (grote file), en dat er bij het gebruik van aparte siminp-files meer controles op de consistentie van gegevens van verschillende deeldomeinen worden uitgevoerd. In dit rapport wordt een gedetailleerde beschrijving gegeven van de gehanteerde aanpak voor het realiseren van de domein decompositie en parallelle functionaliteit. Deze beschrijving betreft: • een overzicht van de aanpak voor domein decompositie en parallel rekenen, met betrekking tot numerieke methoden en met betrekking tot de implementatie-aspecten; • de globale systeem-structuur, de gebruikte componenten en hun samenhang, en een algemene beschrijving van de vereiste aanpassingen aan de componenten voor implementatie van domein decompositie; • de uitbreidingen in de numerieke methoden, met betrekking tot waterbeweging, stoftransport en turbulentie, iteratieve procedures, benodigde interpolaties en initialisaties; • een specificatie van de eisen aan de te koppelen roosters per siminp-file en beschrijving van de procedure die is ontwikkeld voor het bepalen van de koppeling; • een beschrijving van de communicatie-bibliotheek, met name ten aanzien van de interne structuur (min of meer object geörienteerd); • de veranderingen aan alle componenten voor het mogelijk maken van horizontale verfijning en voor de combinatie HOR+VERT. Belangrijke keuzen bij het ontwerp zijn: • Een gekoppelde run bestaat uit een of meer (DDHOR-)domeinen die ieder kunnen zijn onderverdeeld in meerdere deeldomeinen en die ieder een inactief gedeelte mogen bevatten. Welke domeinen er in een run zijn wordt opgegeven in de DDHOR-configuratiefile. Ieder domein wordt gedefiniëerd middels een aparte simulatie invoerfile (siminp-file). Per deeldomein kan het aantal lagen en de laagverdeling worden ingesteld (middels aparte include-files in de siminp-file per deeldomein). Het wel of niet simuleren van transport en turbulentie kan ook per domein worden aan/uitgezet. • De gebruiker specificeert deeldomeinen door middel van een areas file aan de partitioner COPPRE, die voor ieder deeldomein een aparte SDS-file aanmaakt. COPPRE wordt voor iedere siminp-file (ieder rooster) afzonderlijk uitgevoerd in de pre-processing fase (waqpre.pl). Bij gebruik van vertikale verfijning binnen een siminp-file worden WAQPRE en COPPRE per deeldomein afzonderlijk uitgevoerd. • Pas bij aanvang van de processing fase (waqpro.pl) zijn de te koppelen roosters bekend. Controles op de consistentie van de invoer per rooster worden daarom door het masterproces COEXEC uitgevoerd.


vi

• Het matchen van de koppelbare randen van verschillende deeldomeinen gebeurt automatisch, de gebruiker hoeft niet op te geven welke deeldomeinen aan elkaar gekoppeld zijn. Het matchen wordt generiek opgezet, en zowel door COEXEC (t.b.v. controles) als WAQPRO (initialisatie van de communicaties) uitgevoerd. • Als rekenmethode wordt voor de waterbeweging een methode op basis van de “uitgaande informatie” per subdomein gebruikt, zowel bij 1:1-koppeling (parallel rekenen) als bij verfijning. Er worden flux-correctie schema’s gebruikt. Verder wordt de methode bepaald door de gebruikte interpolatietechnieken en iteratieve oplosmethoden voor gedistribueerde stelsels van vergelijkingen. • De communicatie-bibliotheek COCLIB bevat krachtige bouwstenen voor interpolatie en voor het herordenen van waardes. Bij het communiceren tussen deeldomeinen van verschillende DDHOR-domeinen wordt een tijdelijk opslagformaat gebruikt, de zogenaamde overlap set. • De collector COPPOS houdt rekening met niet-gebruikte gedeeltes van roosters bij het samenvoegen van SDS-files die samen niet het globale rooster van een siminp-file overdekken.


vii

Inhoudsopgave Log-sheet

ii

Samenvatting

iv

1 Inleiding 1.1 Inleiding domein decompositie 1.2 Historische beschouwing . . . 1.3 Doel van het huidige rapport . 1.4 Indeling van dit rapport . . . 1.5 Gerelateerde documenten . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

1-1 1-1 1-1 1-2 1-2 1-3

2 Globaal ontwerp voor parallel rekenen en domein decompositie 2.1 Toepassingen van domein decompositie . . . . . . . . . . . . . . . . 2.2 Basisprincipes voor domein decompositie in WAQUA/TRIWAQ . . 2.3 Systeem-architectuur voor parallel rekenen . . . . . . . . . . . . . . 2.4 Systeem-architectuur voor domein decompositie . . . . . . . . . . . 2.5 Strategie m.b.t. numerieke aspecten . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

2-1 2-1 2-2 2-3 2-6 2-7

3 Detail ontwerp van de architectuur en de run-procedures 3.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Globale systeem-architectuur DDHOR+VERT . . . . . . . . 3.3 Functie van de runprocedures . . . . . . . . . . . . . . . . . 3.4 Aanpassingen aan waqpre.pl voor domein decompositie . . 3.5 Aanpassingen aan waqpro.pl voor domein decompositie . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

3-1 3-1 3-1 3-3 3-4 3-5

4 Globaal ontwerp numerieke aspecten in WAQPRO 4.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Discretisatie in gekoppelde runs . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Oplossing van de gediscretiseerde vergelijkingen . . . . . . . . . . . . . . . .

4-1 4-1 4-2 4-12

5 Globaal ontwerp communicatiebibliotheek COCLIB 5.1 Uitgangspunten van COCLIB . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Globaal overzicht over COCLIB . . . . . . . . . . . . . . . . . . . . . . . . .

5-1 5-1 5-2

. . . . .

. . . . .

. . . . .

. . . . .

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12

viii

De update-operatie voor parallel rekenen . . . . . . Verschillende vormen van interpolatie . . . . . . . . Interpolatie: basisoperaties en coëfficiëntensets . . . Tijdelijk geheugen in de update-operatie . . . . . . Koppelingscategoriën . . . . . . . . . . . . . . . . . Stramien van de update-operatie . . . . . . . . . . Configuratie van samengestelde conversiemethoden Invulling van communicatie-interfaces . . . . . . . . Glossary . . . . . . . . . . . . . . . . . . . . . . . . Verdere uitbreidingen . . . . . . . . . . . . . . . . .

6 Detail ontwerp aanpassingen WAQPRO 6.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Details van de discretisaties . . . . . . . . . . . . . 6.3 Details van de horizontale interpolatiemethodes . . 6.4 Details van de vertikale interpolatiemethodes . . . . 6.5 Oplossing van de gediscretiseerde vergelijkingen . . 6.6 Iteratie op basis van uitgaande informatie (trssuw) 6.7 Configuratie van de communicaties door WAQPRO 6.8 Administratie van roosterpunt-verzamelingen . . . . 6.9 Overige aspecten in WAQPRO . . . . . . . . . . . . 7 Het 7.1 7.2 7.3 7.4 7.5 7.6

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

matchen van (deel-)roosters voor DDHOR Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specificatie van het globaal discretisatie rooster . . . . . . . . . . . . Specificatie van de guardband; samengesteld gestructureerde roosters Specificatie van de overlap sets . . . . . . . . . . . . . . . . . . . . . . Invulling van de guardband; het matching probleem . . . . . . . . . . Procedure voor het matchen van deelroosters . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . . .

. . . . . . . . .

. . . . . .

. . . . . . . . . .

5-3 5-5 5-6 5-7 5-8 5-9 5-10 5-13 5-14 5-14

. . . . . . . . .

6-1 6-1 6-2 6-4 6-11 6-14 6-20 6-25 6-31 6-38

. . . . . .

7-1 7-1 7-1 7-4 7-6 7-7 7-11

8 Detail ontwerp communicatiebibliotheek COCLIB 8.1 Introductie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Interne werking: entiteiten en datastructuren . . . . . . . . . . . . 8.3 Overzicht van de wijzigingen aan COCLIB t.b.v. DDHOR+VERT 8.4 De gebruikersroutines . . . . . . . . . . . . . . . . . . . . . . . . . 8.5 Interne werking COCLIB: indeling in subroutines . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

8-1 8-1 8-1 8-14 8-16 8-46

9 Detail ontwerp aanpassingen COEXEC 9.1 Inleiding . . . . . . . . . . . . . . . . . 9.2 De structuur van COEXEC . . . . . . 9.3 Het lezen van de invoer . . . . . . . . . 9.4 Uitvoeren van controles . . . . . . . . . 9.5 Informatie naar WAQPRO sturen . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

9-1 9-1 9-1 9-2 9-5 9-7

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .


ix

10 Detail ontwerp aanpassingen COPPRE 10.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Toevoegen van guard bands . . . . . . . . . . . . . . . . . . . . 10.3 Instelbaar maken van de guardbandbreedte . . . . . . . . . . . . 10.4 Toestaan van “SUBDOMAIN=−1” in de areas-file . . . . . . . 10.5 Het eigenaarschap van ongebruikte punten . . . . . . . . . . . . 10.6 Automatische partitie van een subdomein van een decompositie 10.7 Automatische partitie van randpunten . . . . . . . . . . . . . . 10.8 De afhandeling van enclosures in de areas-file . . . . . . . . . . . 10.9 Verschillende ownerships van s/u/v/d-punten . . . . . . . . . . 10.10Voorzieningen voor gedeeltelijk tijdsafhankelijke arrays . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

10-1 . 10-1 . 10-2 . 10-3 . 10-3 . 10-5 . 10-6 . 10-7 . 10-9 . 10-12 . 10-13

11 Detail ontwerp aanpassingen COPPOS 11.1 Inleiding . . . . . . . . . . . . . . . . . . . . . 11.2 Beperkt aantal deeldomeinen . . . . . . . . . . 11.3 Nullen in de conversie tabellen . . . . . . . . . 11.4 Verschillende ownerships voor s/u/v/d-punten 11.5 Toevoegen extra informatie . . . . . . . . . . 11.6 Aanpassen arrays khu en khv . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

11-1 11-1 11-2 11-2 11-2 11-3 11-3

Referenties

11-5

A Data-analyse van TRIWAQ A.1 Data requirements complete time-step . . . . . . A.2 WASSIM-FLOW: Subroutine WASSFF . . . . . . A.3 WASSPU-FLOW: Subroutine WASCSC . . . . . A.4 WASSPU-FLOW: Subroutine WASUXC . . . . . A.5 TRIWAQ-FLOW: Subroutine TRSVIZ . . . . . . A.6 TRIWAQ-FLOW: Subroutine TRSCWI . . . . . . A.7 TRIWAQ-FLOW: Subroutine TRSCUE . . . . . A.8 TRIWAQ-FLOW: Subroutine TRSSUW . . . . . A.9 WASSIM-FLOW: Subroutine WASKNU . . . . . A.10 WASSIM-FLOW: Subroutine WASCVU . . . . . A.11 TRANSPORT: Subroutine WASDFC . . . . . . . A.12 TRIWAQ-TRANSPORT: Subroutine TRSDIF . . A.13 TRIWAQ-TURBULENCE: Subroutine TRSTUR A.14 TRIWAQ-HYDRO: Subroutine WASHDY . . . .

A-1 A-1 A-12 A-15 A-17 A-20 A-22 A-23 A-29 A-48 A-49 A-53 A-57 A-68 A-72

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .


1-1

Hoofdstuk 1 Inleiding 1.1

Inleiding domein decompositie

Domein decompositie is een algemene techniek voor het vergroten van de vrijheid van gebruikers van WAQUA en TRIWAQ in het definiëren van gebiedsschematisaties. Bijvoorbeeld biedt het de mogelijkheid om het rekenrooster dat wordt gebruikt te verfijnen in gebieden waarin men sterk is ge¨ınteresseerd, of in gebieden waar zich zeer lokale processen afspelen (rond sluizen en dergelijken). Tegelijkertijd kan met domein decompositie de doorlooptijd voor een simulatie sterk worden teruggebracht doordat fijne vermazing in het ene deel van het domein kan worden gebruikt samen met grovere vermazing in een ander deel.

1.2

Historische beschouwing

De afgelopen jaren is door Rijkswaterstaat/RIKZ een flinke inspanning gepleegd om domein decompositie voor WAQUA/TRIWAQ te realiseren (zie ook [11]). Allereerst is er in 1999 een testversie ontwikkeld van domein decompositie met vertikale verfijning voor TRIWAQ (“DDVERT”: het aantal lagen kan per deeldomein verschillen). Deze testversie is dermate goed ontvangen dat reeds vrij snel is besloten om hem te operationaliseren. Deze operationalisatie is in juli 2001 afgerond met de opname in SIMONA beheer en onderhoud. Daarnaast is in 2000 een prototype ontwikkeld van domein decompositie met horizontale verfijning (“DDHOR”: de horizontale maaswijdte kan per deeldomein verschillen). Met dit prototype is de technische haalbaarheid alsmede ook de gebruikersvriendelijkheid van de voorgestelde benadering geëvalueerd. In 2001 is een eerste complete versie van WAQUA/TRIWAQ met horizontale verfijning gerealiseerd. Daarbij is de functionaliteit uitgebreid ten opzichte van het prototype DDHOR, bijvoorbeeld voor simulaties met stoftransport en met het k − turbulentiemodel. Verder is de gebruikersvriendelijkheid van domein decompositie met horizontale verfijning sterk verbeterd, met name door het automatisch matchen van roosters in plaats van het opgeven van gekoppelde randen door de gebruiker. De eerste versie DDHOR is in 2001 en 2002 geëvalueerd voor verschillende toepassingen en is eind 2002 opgenomen in SIMONA beheer en onderhoud. Tegelijkertijd is een cursus


1-2

georganiseerd voor gebruikers en ge¨ınteresseerden om de mogelijkheden en het gebruik van domein decompositie en parallel rekenen onder de aandacht te brengen. In het najaar van 2002 is een volgende stap gestart in de ontwikkeling van domein decompositie, namelijk het inwendig in de programmatuur op elkaar afstemmen van de implementaties van horizontale en vertikale verfijning, en het mogelijk maken van beide soorten domein decompositie binnen een enkele simulatie. De daarbij gerealiseerde DDHOR+VERT versie van WAQUA/TRIWAQ is het onderwerp van dit rapport. In 2005 is er een nieuwe ontwikkeling in gang gezet. Hierbij is het mogelijk gemaakt om simulatie van transport (zout) en turbulentie per DDHOR-domein aan of uit te kunnen zetten. Ook wordt onderzoek gedaan naar een nieuwe manier voor het oplossen van het gekoppelde probleem, waarmee op termijn tijdstapkoppeling mogelijk kan worden gemaakt. Dit onderzoek heeft in 2008 een nieuwe koppelingsmethode opgeleverd, waardoor het gebruik van horizontale verfijning nauwelijks extra iteraties meer met zich meebrengt.

1.3

Doel van het huidige rapport

Het uiteindelijke doel van dit rapport is om een beschrijving te geven van de manier waarop domein decompositie en parallel rekenen in WAQUA/TRIWAQ zijn gerealiseerd. Dit betreft enerzijds het geven van een overzicht van de gevolgde benadering, uitgangspunten, principiële ontwerpbeslissingen en van de globale structuur van het complete simulatiesysteem “WAQUA/TRIWAQ met domein decompositie”. Aan de andere kant betreft het ook het geven van gedetailleerde informatie over de uitwerking van de gekozen strategie in de uiteindelijke implementatie. Het voorliggende ontwerp zou moeten kunnen worden gebruikt om een beeld te krijgen van het totale systeem. Maar vooral is het ook bedoeld om een uitgangspunt te bieden bij de implementatie van de nieuwe functionaliteit, als referentie voor verder programmeerwerk aan en voor operationalisatie van de gerealiseerde programmatuur. In eerdere versies van dit rapport (tot en met versie 1.3.1) was het doel om alleen de uitbreidingen voor realisatie van DDHOR te beschrijven. De manier waarop parallel rekenen en DDVERT zijn ge¨ımplementeerd werd daarbij als bekend verondersteld. Dit heeft zijn weerslag in de huidige versie van het document. Deze versie heeft daarom nog niet als doel om een compleet overzicht te geven over alle vormen van domein decompositie en parallel rekenen.

1.4

Indeling van dit rapport

De rest van dit rapport is als volgt ingedeeld: Hoofdstuk 2 geeft een overzicht over de aanpak voor domein decompositie en beschrijft de globale systeem-architectuur: de samenhang tussen de verschillende componenten. Ook wordt een overzicht gegeven van de aansturing van het systeem door gebruikers.


1-3

De systeem-architectuur wordt verder uitgewerkt in Hoofdstuk 3. Hierbij komen ook de run-procedures waqpre.pl en waqpro.pl aan de orde. Vervolgens geven hoofdstukken 4 en 5 een overzicht van de numerieke aspecten van domein decompositie in WAQPRO, en van de opzet van de communicatie bibliotheek COCLIB. Daarbij vormen de gewenste numerieke methoden van WAQPRO min of meer de functionele eisen aan COCLIB. Hoofdstuk 6 geeft extra details van de numerieke aspecten van domein decompositie in WAQPRO. Daarbij wordt onder andere aandacht besteed aan de gebruikte interpolatiemethodes. Een speciale module in WAQPRO betreft het uitzoeken hoe de roosters van verschillende DDHOR-domeinen op elkaar aansluiten. Dit zogenaamde matchen van roosters wordt in Hoofdstuk 7 beschreven. Deze component wordt zowel door COEXEC als WAQPRO gebruikt. Vervolgens worden de verschillende componenten voor parallel rekenen en domein decompositie in detail besproken. Dit zijn achtereenvolgens het detail ontwerp van COCLIB (hoofdstuk 8), het master-programma COEXEC (hoofdstuk 9), de partitioner COPPRE (hoofdstuk 10), en de collector COPPOS (hoofdstuk 11).

1.5

Gerelateerde documenten

De huidige versie van deze ontwerpbeschrijving richt zich door zijn ontstaansgeschiedenis voornamelijk op het gebruik van meerdere siminp-files (horizontale verfijning). De achtergronden van parallel rekenen en domein decompositie met vertikale verfijning worden verder toegelicht in het cursusmateriaal van de cursus “Domein decompositie en Parallel rekenen in SIMONA”, met name het cursusboek voor Module 3 [7]. Gedetailleerdere informatie over vertikale verfijning is te vinden in het detail ontwerp [11] van de DDVERT functionaliteit zoals die is geoperationaliseerd in SIMONA. Een overzicht van WAQUA/TRIWAQ met domein decompositie kan ook worden verkregen via de verschillende vormen van gebruikersdocumentatie: • de User’s Guide for parallel WAQUA/TRIWAQ and for Domain Decomposition [12]; • de Quick Reference Guide WAQUA [5]; • het cursusmateriaal van de cursus “Domein decompositie en Parallel rekenen in SIMONA”, met name het cursusboek van Module 1 [6]. Voor meer algemene informatie over parallel rekenen, domein decompositie en over de in dit document gehanteerde terminologie is het reeds genoemde cursusmateriaal een goed startpunt, met name Module 1 van de cursus.


2-1

Hoofdstuk 2 Globaal ontwerp voor parallel rekenen en domein decompositie 2.1

Toepassingen van domein decompositie

WAQUA en TRIWAQ zijn numeriek wiskundige modellen voor simulatie van de ondiepwatervergelijkingen in twee (WAQUA, dieptegemiddeld) en drie ruimtedimensies (TRIWAQ). Deze modellen bestaan uit de gebruikte differentiaalvergelijkingen, de ruimte en tijdsdiscretisaties, de solvers voor stelsels van algebra¨ısche vergelijkingen, en een veelheid aan implementatiekeuzes. Centraal in de numerieke benadering van de ondiepwatervergelijkingen in WAQUA en TRIWAQ staat het gebruik van een gestructureerd rooster. De meeste gebruikte discretisaties voor de differentiaalvergelijkingen zijn gebaseerd op de eindige differentiemethode, die een sterk regelmatig rooster vereist. Daarnaast worden ook eindige volume benaderingen toegepast die ook zijn gebaat bij het gebruik van gestructureerde roosters. De kustgebieden die worden gesimuleerd hebben daarentegen willekeurig complexe geometriën. Daarom zijn er diverse voorzieningen in WAQUA/TRIWAQ ge¨ımplementeerd: onderverdelen van het rechthoekige rooster [1 . . . M ]×[1 . . . N ] in land en water (trappetjesranden), kromlijnige roosters (boundary fitted coordinates), en een flexibele laagverdeling voor de vertikale richting in TRIWAQ (ademend rooster). Ook met de genoemde voorzieningen blijven er beperkingen volgen uit het gebruik van eindige differentiebenaderingen en gestructureerde roosters: • er moet veel rekenwerk worden verzet om de ondiepwatervergelijkingen te simuleren met de gewenste resolutie. Daarom is het gebruik van parallelle computers voor de simulatie met WAQUA/TRIWAQ gewenst. • wanneer men hoge resolutie wil hebben in een klein gedeelte van een gesimuleerd gebied dan werkt dit door in de rest van het rooster, ook wanneer kromlijnige roosters worden gebruikt. Het is daarom gewenst om in de een of andere vorm horizontale en vertikale roosterverfijning te kunnen gebruiken.


2-2

• in verschillende situaties is het moeilijk om een werkelijke geometrie af te beelden op een enkel kromlijnig rooster: driehoekig eiland, netwerk van riviertakken. Het is daarom gewenst om voor verschillende gedeeltes van een te simuleren gebied aparte roosters te kunnen maken en die dan in een enkele simulatie te kunnen doorrekenen. Heel in het kort staat hier dat parallel rekenen en domein decompositie nodig zijn voor het sneller kunnen uitvoeren van grootschalige berekeningen, voor het uitsparen van rekenwerk, en voor het vergroten van de modelleerflexibiliteit voor gebruikers. Parallel rekenen is vrijwel volledig ge¨ımplementeerd voor WAQUA en TRIWAQ. Vrijwel alle simulaties kunnen worden uitgevoerd op een parallelle computer, ook alle simulaties die gebruik maken van domein decompositie. Alleen specifieke functionaliteit zoals de gebruikersroutine en de Lagrangiaanse tijdsintegratie zijn niet beschikbaar in parallelle runs. Voor domein decompositie is de situatie iets complexer, omdat er heel veel verschillende mogelijkheden zijn met betrekking tot modelleerflexibiliteit. In het kort komt het erop neer dat met de huidige versie “DDHOR+VERT” van WAQUA/TRIWAQ met domein decompositie verschillende gebieden gekoppeld kunnen worden gesimuleerd als de roosters netjes op elkaar aansluiten. De roosterlijnen van een grover domein moeten doorlopen in het fijnere buurdomein, zowel in het horizontale vlak als vertikaal (laaginterfaces). Daarbij is het systeem behoorlijk flexibel ten aanzien van bijvoorbeeld verfijningsfactoren of de lokale geometrie nabij de interfaces tussen verschillende domeinen. Ook mogen transport en turbulentie onder voorwaarden per rooster worden aan- of uitgezet. Daarentegen moeten andere instellingen wel identiek zijn in alle deeldomeinen: tijdstap, iteratieparameters, e.d. De complete beschrijving van de mogelijkheden en beperkingen van domein decompositie in WAQUA/TRIWAQ wordt in de gebruikershandleiding gegeven.

2.2

Basisprincipes voor domein decompositie in WAQUA/TRIWAQ

In dit rapport gaan we in op de vraag “hoe bouw je een versie van WAQUA/TRIWAQ die de hierboven beschreven mogelijkheden realiseert ?”. Deze vraag heeft vele verschillende kanten, kan op totaal verschillende manieren worden aangepakt. In dit rapport kiezen we er daarbij voor om eerst de voor ons belangrijkste uitgangspunten op een rij te zetten.

2.2.1

Afschermen van parallel rekenen voor gebruikers en numerieke programmeurs

Een belangrijke randvoorwaarde (functionele eis?) bij de initiële ontwikkeling van parallel TRIWAQ is geweest dat gebruikers en programmeurs die op het gebied van parallel rekenen niet deskundig zijn met het systeem moesten kunnen (blijven) werken. Deze randvoorwaarde geldt onverkort bij de verdere ontwikkeling naar domein decompositie, en is een belangrijk criterium voor de vergelijking van verschillende ontwerpalternatieven. Verschillende keuzes


2-3

in de huidige opzet van WAQUA/TRIWAQ met domein decompositie zijn hierop terug te voeren.

2.2.2

Zelfstandige rekenprocessen, geen aannames over omgeving

Een tweede basisprincipe dat wordt gehanteerd is dat rekenprocessen in een gekoppelde simulatie zo min mogelijk aannames mogen maken over de omgeving waarin ze worden gebruikt. Het hoort voor een rekenproces niet uit te maken of er in totaal drie of acht subdomeinen zijn, of dat hij informatie verkrijgt van twee of vier “buren”. Het zou zelfs niet mogen uitmaken als de informatie uit een database wordt verkregen in plaats van uit een ander rekenproces, zolang de verkregen informatie dezelfde is. Kortom, rekenprocessen moeten beschrijven welke invoer ze verwachten en welke uitvoer ze produceren, en mogen verder niet afhankelijk zijn van de omgeving. Dit principe is min of meer voortgekomen uit de initiële eis om ook parallelle computers met gedistribueerd geheugen te kunnen gebruiken, en uit de wens om zo veel mogelijk aan te sluiten bij de bestaande programmatuur (m.n. het memory management van SIMONA). Inmiddels is echter duidelijk dat het ontkoppelen van het rekenproces en de omgeving waarbinnen dat wordt gebruikt op zichzelf belangrijk is, met name voor het beheersen van de complexiteit van programmatuur voor gekoppelde simulaties.

2.2.3

Heldere componenten op basis van generieke principes

Een derde wezenlijke eigenschap van de huidige domein decompositie programmatuur is dat verschillende functies in duidelijk afgebakende programma’s of modules zijn ondergebracht, en dat deze programma’s/modules generiek zijn opgezet. In de randprogrammatuur is zo min mogelijk kennis verwerkt van de applicatie (WAQUA/TRIWAQ) of het applicatiedomein (ondiepwatermodellering) waarvoor de randprogrammatuur initiëel is ontwikkeld. Dit is voortgekomen uit de wens om de programmatuur ook voor andere applicaties te kunnen gebruiken en uit de wetenschappelijke context van de eerste versie van parallel TRIWAQ. De heldere scheiding tussen de modules en de generieke technieken ervan zijn een belangrijke factor in de beheersbaarheid en uitbreidbaarheid van de huidige programmatuur.

2.3

Systeem-architectuur voor parallel rekenen

De globale architectuur die wordt gehanteerd voor gekoppelde simulaties wordt ge¨ıllustreerd aan de hand van de systeemstructuur voor parallel rekenen, zie Figuur 2.1. Een aantal belangrijke aspecten van deze systeemstructuur is als volgt: 1. Het externe gedrag van parallel WAQUA/TRIWAQ is hetzelfde als van de sequentiele versie, in die zin dat een enkele globale invoer (SDS-)file wordt geconverteerd in een enkele globale uitvoerfile. De eindgebruiker hoeft hierdoor in principe niet meer te weten van parallel rekenen dan hoeveel subdomeinen er worden gebruikt, de details van


Data Input File

2-4

Data Description File

Partitioner

Comm. Library WAQUA

WAQUA

WAQUA

WAQUA

WAQUA

WAQUA

Executive

Collector

Output File

Figuur 2.1: Globale systeemstructuur voor parallel WAQUA/TRIWAQ. de parallellisatie zijn grotendeels verborgen. Ook kan parallel rekenen hierdoor worden gebruikt in combinatie met alle standaard pre- en postprocessing programma’s. 2. De partitioner is ge¨ıntroduceerd om het rekenrooster te verdelen in min of meer evengrote stukken, en om in overeenstemming hiermee de gegevens van de initiële globale


2-5

SDS-file te distribueren over de deeldomeinen. Hij zorgt ervoor dat ieder rekenproces een SDS-file krijgt toegewezen die vrijwel volledig aan het format van sequentiëel WAQUA/TRIWAQ voldoet. De collector doet het tegenovergestelde, voegt de uitvoerdata per deeldomein samen tot een globale uitvoerfile. Het distribueren en collecteren van de gegevens is strikt gescheiden van het rekenen door de rekenprocessen. Dit zorgt ervoor dat er binnen een rekenproces geen verwarring kan ontstaan tussen de globale en lokale dimensies van allerlei soorten arrays. Het distribueren en collecteren is gebaseerd op een krachtig mechanisme voor het beschrijven van datastructuren. De precieze inhoud van een SDS-file wordt beschreven in een invoerfile (data description file), zodat applicatie-programmeurs nieuwe datastructuren kunnen toevoegen zonder aanpassingen aan de partitioner en collector. 3. De executive (het masterproces) heeft slechts een zeer beperkte functie. Hij zorgt voor het opstarten van de rekenprocessen, voor het verzamelen van de diagnostische uitvoer in een enkele file, en voor het signaleren en afhandelen van problemen met de rekenprocessen. 4. De WAQUA/TRIWAQ rekenprocessen zijn ieder apart instantiaties van het volledige programma, inclusief file I/O, initialisaties, e.d. Het gezichtspunt dat hierbij wordt gebruikt is dat van het koppelen van verschillende simulaties, in plaats van dat een enkele simulatie wordt opgesplitst. Ten behoeve van deze koppeling is het oorspronkelijke programma uitgebreid, onder andere met een nieuw type randvoorwaarde en met communicatie van waardes bij subdomeinranden. Verder wordt de oorspronkelijke programmacode volledig hergebruikt. Het gezichtspunt van gekoppelde zelfstandige simulaties wordt in praktijk gebruikt voor het realiseren van domein decompositie en voor on-line koppelingen. Voor zulke koppelingen is het nuttig als de rekenprocessen zo min mogelijk aannames maken over de omgeving waarbinnen ze draaien. Mede hierom hebben de rekenprocessen in een parallelle run slechts beperkte informatie over de overall-structuur van de berekening. 5. De communicatie tussen de verschillende rekenprocessen is strikt gescheiden van de berekeningen in het programma. Aan de ene kant is dit gedaan vanwege portabiliteit, opdat het precieze communicatiesysteem van de parallelle computer kan veranderen zonder grote gevolgen voor het parallelle programma. Een belangrijkere reden voor het introduceren van een aparte communicatiebibliotheek is echter het verstoppen van details voor applicatie-programmeurs. Bijvoorbeeld de boekhouding van de precieze vorm van subdomeinranden en buurprocessen voor applicatie-programmeurs. De communicatiebibliotheek is gebaseerd op krachtige generieke mechanismes, hiermee wordt volledige vrijheid bij het opdelen van grillige rekenroosters ge¨ımplementeerd. In deze aspecten zijn de basisprincipes van de vorige paragraaf te herkennen. Verder zijn hiermee de bouwstenen van de parallelle programmatuur genoemd: de partitioner COPPRE, de executive COEXEC, de rekenprocessen WAQPRO, de communicatiebibliotheek COCLIB,


SDS−d1−1

....

SDS−d1−n1

SDS−dN−1

WAQUA

WAQUA

2-6

....

SDS−dN−nN

Comm.Library WAQUA

....

WAQUA

Executive

SDS−d1−1

....

SDS−d1−n1

SDS−dN−1

....

SDS−dN−nN

....

Collector

Collector

SDS−d1

SDS−dN

Figuur 2.2: Globale systeemstructuur voor domein decompositie (processing-fase “waqpro.run”). en de collector COPPOS. In de volgende paragraaf wordt dit verder uitgewerkt voor domein decompositie.

2.4

Systeem-architectuur voor domein decompositie

Figuur 2.2 geeft een overzicht van de systeemstructuur waarmee domein decompositie wordt gerealiseerd in WAQUA/TRIWAQ. Het gaat daarbij specifiek om de processing fase, d.w.z. het uitvoeren van de daadwerkelijke simulatie, nadat de modelinvoer van de gebruiker is gecontroleerd en geconverteerd naar een aantal binaire SDS-bestanden (d.i. de pre-processing fase). Er zijn een aantal duidelijke overeenkomsten tussen de structuur van domein decompositieberekeningen van Figuur 2.2 en die van parallelle berekeningen (Figuur 2.1): • een gekoppelde berekening bestaat uit meerdere rekenprocessen, die ieder hun eigen invoer- en uitvoerfiles hebben. Zowel in domein decompositie- als in parallelle berekeningen zijn dit binaire SDS-bestanden. • de rekenprocessen worden opgestart en enigszins gemanaged door de executive: detecteren van “core-dumps” en verzamelen van schermuitvoer van de rekenprocessen.


2-7

• de rekenprocessen werken met elkaar samen door gegevens uit te wisselen via de communicatiebibliotheek. De verschillen tussen de twee plaatjes zijn als volgt: • in parallelle runs wordt het opdelen van de globale SDS-file voor het gehele domein door de partitioner tot de processing fase gerekend, in domein decompositie berekeningen zit het opdelen in de pre-processing fase. In het eerste geval wordt het partitioneren/decomponeren zo veel mogelijk verborgen voor de gebruiker, in het tweede geval heeft de gebruiker hier logischerwijs meer bemoeienis mee. • in parallelle runs horen alle rekenprocessen bij een enkel globaal domein, in domein decompositie runs kunnen er meerdere domeinen zijn. De term “globaal domein” wordt gebruikt om het gebied van een enkele model-invoerfile (siminp-file) mee aan te duiden. In veel gevallen is dit ook equivalent met een enkel rekenrooster. Na afloop van het rekenen door de rekenprocessen wordt de uitvoer per globaal domein, per siminp-file, gecollecteerd naar een “globale SDS-file”. • in parallelle runs bestaat het communiceren uit het één-op-één kopiëren van roosterwaardes van het ene rekenproces naar het andere, in geval van domein decompositie kan hierbij interpolatie worden toegepast.

2.5

Strategie m.b.t. numerieke aspecten

De in de vorige paragrafen gepresenteerde systeem-architectuur is onlosmakelijk verbonden met een bepaalde manier van benaderen van de numerieke aspecten van domein decompositie. Het meest wezenlijk in deze beschouwing van de numerieke aspecten is dat de discretisaties van de differentiaalvergelijkingen nabij de interfaces tussen verschillende domeinen niet (direct) worden opgeschreven in termen van roosterwaardes van de verschillende domeinen, maar dat in plaats daarvan per domein alleen wordt gewerkt met (ge¨ınterpoleerde) waardes op het rooster van het eigen domein. In “echte” roosterpunten die in de buurt van koppelingsranden liggen worden de gebruikelijke discretisaties toegepast alsof de interface niet bestaat. Een aantal van de waardes die daarbij worden gebruikt wordt echter door middel van interpolatie verkregen. Dit principe wordt ge¨ıllustreerd in Figuur 2.3. Het is een belangrijke truc voor het beheersbaarmaken van het complete numerieke model met domein decompositie. Door deze aanpak is er bij de berekeningen voor een enkel rooster namelijk geen informatie nodig over de naburige roosters, zoals verfijningsfactoren e.d. De “echte” roosters per globaal domein moeten in de huidige versie van WAQUA/TRIWAQ met domein decompositie precies op elkaar aansluiten. In het horizontale vlak moeten de hoekpunten van roostercellen van een grover domein precies samenvallen met hoekpunten van roostercellen van het fijnere domein, en in de vertikale richting moeten de laaginterfaces van het grove domein aansluiten op laaginterfaces van het fijne domein. Op het wiskundige niveau is de opdeling van het totale te simuleren gebied dus niet overlappend, op het discrete niveau wordt zogenaamde minimale overlap gebruikt.


2-8

Figuur 2.3: Roosters van twee domeinen met 1:2 verfijning, met de interpolatiepunten per domein omcirkeld. Op de interfaces tussen twee domeinen worden de roosterpunten van het fijne domein als de “echte” roosterpunten beschouwd. Hier worden de differentiaalvergelijkingen gediscretiseerd, zulke punten worden verder discretisatiepunten genoemd. De roosterwaardes op de interface van het grove domein worden verkregen via interpolatie, de bijbehorende roosterpunten worden daarom interpolatiepunten genoemd. De verzameling van alle echte (discretisatie) roosterpunten van alle domeinen samen vormt het globale discretisatie-rooster. Dit rooster is zelf niet eenvoudig gestructureerd, maar is wel samengesteld uit eenvoudig gestructureerde roosters. De eenvoudig gestructureerde roosters per deeldomein worden uitgebreid met een zogenaamde guardband voor het opslaan van de ge¨ınterpoleerde waardes nabij interfaces met andere deeldomeinen. Hiervoor worden waar nodig alle arrays van het deeldomein met een paar extra rijen en kolommen uitgebreid. Deze guardband zorgt ervoor dat de berekeningen van een deeldomein compleet kunnen worden uitgevoerd op basis van de arrays van het eigen deeldomein, dat er onderweg geen interactie met de andere deeldomeinen is. Alleen moeten van tijd tot tijd de waardes in de guardband van de eigen arrays worden gekopiëerd, de guardband moet consistent worden gehouden met de originele waardes uit de overeenkomstige roosterpunten van buurdomeinen. Het algoritme per WAQUA/TRIWAQ rekenproces bestaat daarom uit het afwisselend uitvoeren van berekeningen voor het eigen deeldomein en uitwisselen van waardes bij subdomeinranden met buurdomeinen. De communicatie tussen en interpolatie van waardes van de verschillende rekenprocessen/deeldomeinen wordt volledig afgeschermd binnen de communicatiebibliotheek. Op deze manier heeft de introductie van horizontale en vertikale verfijning slechts vrij beperkte consequenties voor de rekenprogrammatuur, en wordt de domein decompositie-functionaliteit gerealiseerd als directe uitbreiding van de principes die voor parallel rekenen worden gehanteerd. Tenslotte wordt opgemerkt dat de gehanteerde benadering van aparte arrays per deeldomein en uitwisseling tussen de deeldomeinen niet alleen van belang is voor het beheersbaar houden van de berekeningen van de rekenprocessen zelf, maar dat deze benadering ook bij uitstek geschikt is voor het gebruik op “distributed memory” parallelle computers. De rekenprocessen kunnen eenvoudig op verschillende computers worden opgestart en via het netwerk met elkaar communiceren. Daarbij is de grof-korrelige afwisseling tussen rekenen commu-


2-9

nicatiestappen cruciaal voor het bereiken van goede performance, ook voor diverse “shared memory” parallelle computers.


3-1

Hoofdstuk 3 Detail ontwerp van de architectuur en de run-procedures 3.1

Inleiding

In het vorige hoofdstuk is een introductie gegeven van de manier waarop parallel rekenen en domein decompositie zijn ge¨ımplementeerd in WAQUA/TRIWAQ. Daarbij zijn met name een aantal uitgangspunten en principiële keuzes gepresenteerd, en is de opdeling van het totale systeem in componenten beschreven. In dit hoofdstuk duiken we meer de diepte in. Er wordt in detail ingegaan op het verloop van een run met domein decompositie zoals dat in de verschillende runscripts ge¨ımplementeerd is, en de plek van de verschillende programma’s (COPPRE, COEXEC, COPPOS) daarin. Daarbij wordt ook aangegeven welke invoerfiles en argumenten er gebruikt worden om een domein decompositie run aan te sturen.

3.2

Globale systeem-architectuur DDHOR+VERT

De globale systeem-architectuur waarmee de bovenstaande numeriek-wiskundige benadering wordt gerealiseerd is weergegeven in Figuur 3.1. In dit ontwerp levert de gebruiker een simulatie-invoerfile (inp) per gedeelte van het totale gebied dat wordt gemodelleerd. Deze gedeeltes worden “(globale) domeinen” en ook “(gestructureerde) roosters” genoemd. In de figuur wordt gesuggereerd dat er N domeinen zijn die de namen d1, . . . dN hebben, maar in de praktijk zal de gebruiker vrij zijn om zinvolle namen zoals kust en rym te gebruiken. Daarnaast levert de gebruiker per domein een zogenaamde areas-file area toe waarin het domein wordt opgedeeld in verschillende stukken. Deze stukken worden “deeldomeinen” of “subdomeinen” genoemd. In de areas-file wordt tevens opgegeven welke deeldomeinen van een domein meedoen in de DDHOR-berekening. Via de areas-file kan de gebruiker bepaalde gedeeltes uit de siminp-file markeren als nietactief in de DDHOR-berekening. Op deze manier kunnen stukken uit een bestaande gebieds-


inp-d1

area-d1

inp-dN

3-2

area-dN

waqpre.run

waqpre.run

WAQPRE

WAQPRE

.... SDS-d1

SDS-dN

COPPRE

COPPRE

SDS-d1-1

....

SDS-d1-n1

....

SDS-dN-1

SDS-dN-nN

cfg

waqpro.run COEXEC WAQPRO

....

WAQPRO

WAQPRO

....

COCLIB SDS-d1-1

....

....

SDS-d1-n1

SDS-dN-nN

....

COPPOS

COPPOS

SDS-d1

SDS-dN

msg

Figuur 3.1: Globale systeem-structuur voor de domein decompositie versie met horizontale en vertikale verfijning. schematisatie worden weggesneden en vervangen door een verfijnd detailmodel. Het gebruik van de partitioner COPPRE biedt verder de mogelijkheid tot het opdelen van het actieve gedeelte van een rooster in meerdere stukken, ten behoeve van de combinatie van DDHOR met parallel rekenen en domein decompositie met vertikale verfijning. Het aantal deeldomeinen mag verschillen per domein (aangegeven via aantallen n1 en nN) en mag 1 zijn in het geval dat het gehele rooster van een domein moet worden gebruikt in de gekoppelde berekening. De gebruiker laat per domein afzonderlijk de preprocessing fase uitvoeren via de runprocedure waqpre.pl en controleert of deze voor alle domeinen correct is verlopen. Binnen waqpre.pl wordt voor iedere verschillende laagverdeling (aangegeven met k1,. . . ,kM in de figuur) WAQPRE gedraaid om een SDS-file te verkrijgen met de juiste laagverdeling. Vervol-


3-3

gens wordt COPPRE gebruikt om daaruit de SDS-files te genereren voor deeldomeinen die met die laagverdeling moeten worden doorgerekend. Uiteraard mag het aantal verschillende laagverdelingen per domein anders zijn. Alhoewel de invoerfiles per domein afzonderlijk kunnen worden gemaakt en getest, moet de gebruiker wel goed letten op de consistentie van verschillende gegevens. Ten eerste moeten de roosters op de interface precies op elkaar aansluiten. Ten tweede wordt gelijkheid van verschillende tijdstap- en iteratieconstanten geëist. Tenslotte moeten allerlei andere invoerparameters min of meer aansluiten in de verschillende domeinen: dieptegegevens, wind-invoer, fysische constanten, etcetera. Vervolgens biedt de gebruiker de gecreëerde deel-SDS-files aan aan de processing fase via de runprocedure waqpro.pl. In het geval van domein decompositie met horizontale verfijning geeft hij daarbij ook een koppelings-configuratiebestand cfg op. Bij vertikale verfijning wordt, net als bij parallel rekenen, het configuratiebestand gegenereerd door het runscript. De processing fase bestaat allereerst uit het inlezen van het koppelings-configuratiebestand door de “executive” COEXEC en het hiermee ophalen van de coördinaat-gegevens van open randen en subdomein-interfaces uit de deel-SDS-files. COEXEC bepaalt uit de coördinaatgegevens welke koppelingen er bestaan tussen de verschillende deeldomeinen en controleert of de aangeleverde gegevens worden toegestaan door de rest van de DDHOR programmatuur. Informatie over de gedetecteerde koppelingsranden wordt weggeschreven naar het meldingenbestand msg. Door middel van de optie -check only van de runprocedure kan de gebruiker desgewenst opgeven dat de run hierna moet worden gestopt. Na de controles door COEXEC bestaat een domein decompositie run uit het opstarten door COEXEC van evenveel WAQPRO-processen als er deeldomeinen zijn. De WAQPROprocessen openen ieder hun eigen deel-SDS-file en voeren de simulatie uit voor het betreffende deeldomein. Gedurende deze simulatie wisselen ze onderling frequent gegevens uit over de stromingstoestand op subdomein-randen en voor het coördineren van de verschillende iteratieve procedures. Deze communicatie omvat in geval van roosterverfijningen ook interpolaties en wordt gerealiseerd met behulp van de communicatie-bibliotheek COCLIB. Merk op dat met matchen van roosters zowel in COEXEC gebeurt ten behoeve van de consistentiecontrole, als ook in WAQPRO voor het initialiseren van de communicaties. Omdat dezelfde functionaliteit op twee plekken wordt uitgevoerd, is deze ondergebracht in een aparte module die zowel door COEXEC als door WAQPRO wordt aangeroepen. Simulatieresultaten worden in eerste instantie geschreven naar de deel-SDS-files. Na afloop van de gekoppelde simulaties worden de resultaten per domein verzameld in een enkel SDSbestand door de collector COPPOS. Hierbij worden nullen geschreven in de gedeeltes van resultaat-arrays voor niet-gebruikte stukken van het rooster. Bovendien worden de resultaten ge¨ınterpoleerd naar een rooster met de fijnst voorkomende laagverdeling.

3.3

Functie van de runprocedures

Voor het aansturen van de preprocessing en processing-fases van het WAQUA-systeem worden de runprocedures waqpre.pl en waqpro.pl gebruikt.


3-4

In sequentiële simulaties bestaat waqpre.pl min of meer uit het aanroepen van het programma waqpre.exe (aanmaken van een binaire SDS-file vanuit een tekstuele siminp-file), en waqpro.pl uit het opstarten van waqpro.exe (uitvoeren van een simulatie op basis van een gegeven SDS-file). De functie van de runprocedures is daarbij vooral het bieden van een prettige manier van aansturen van de kale executables. Bijvoorbeeld wordt een tijdelijke werkdirectory aangemaakt, worden standaardfiles gelokaliseerd, wordt gecontroleerd of de opgegeven invoerbestanden aanwezig zijn, wordt de gevraagde buffergrootte doorgegeven en worden faciliteiten aangeboden voor interactieve runs zowel als voor batch-opdrachten. In het verlengde van deze aspecten zijn de runprocedures uitgebreid voor parallel rekenen en domein decompositie. Parallel rekenen wordt daarbij beschouwd als iets dat zich volledig binnen de processing fase afspeelt en dat grotendeels verborgen hoort te zijn voor de gebruiker. De runprocedure waqpro.pl heeft hiervoor extra opties gekregen waarmee het aantal processoren en eventueel de gewenste partitiemethode kan worden ingesteld, en verzorgt verder grotendeels automatisch het opstarten van de hulpprogramma’s COPPRE, COEXEC, COPPOS en het communicatiesysteem MPI. Domein decompositie heeft wel een duidelijke zichtbaarheid voor de gebruiker en heeft daarom ook effect op de preprocessing fase (waqpre.pl). Ten behoeve van domein decompositie kan aan de runprocedure waqpre.pl een roosteropdeling ofwel areas-file worden opgegeven. Voor vertikale verfijning kan het aantal lagen per deeldomein worden gespecificeerd. Uit een enkele siminp-file en aparte include-files voor elk verschillend aantal lagen (of laagverdelingen) worden dan door het herhaald opstarten van WAQPRE en COPPRE aparte SDS-files gegenereerd voor alle deeldomeinen. Ook kan er per subdomein uit de areas-file een partitiemethode en aantal parts worden opgegeven voor de combinatie met parallel rekenen. Het is niet nodig dat de verzameling deeldomeinen het oorspronkelijke domein geheel overdekt: er mogen stukken uit het oorspronkelijke domein weggesneden worden ten behoeve van een (DDHOR-)koppeling aan een ander model. Bij het gebruik van horizontale verfijning wordt per siminp-file de benodigde SDS-files gegenereerd voor alle daaruit afgeleide deeldomeinen, via afzonderlijke runs met waqpre.pl. Zodra alle SDS-files aanwezig zijn wordt de gehele gekoppelde run ineens opgestart met waqpro.pl. Een verschil met parallel rekenen en DDVERT is daarbij dat in DDHOR berekeningen de informatie door de gebruiker via een configuratie-file wordt aangeleverd in plaats van via argumenten aan de runprocedure.

3.4

Aanpassingen aan waqpre.pl voor domein decompositie

De runprocedure waqpre.pl herkent het gebruik van domein decompositie met vertikale verfijning aan het voorkomen van de constructies %KMAX% en %DOM% in de inputfile, behalve als deze onderdeel uitmaken van het commentaar in de inputfile. Als vertikale verfijning wordt gebruikt eist de runprocedure dat de parameters -ndom, -decomp, -kmax, -exp en -buf prt worden ingevuld (de laatste heeft een defaultwaarde en hoeft niet te worden opgegeven). De


3-5

afhandeling in de runprocedure bestaat dan uit het voor alle deeldomeinen uitvoeren van WAQPRE en COPPRE op basis van de globale siminp-file en de betreffende include-files. Als de constructies %KMAX% en %DOM% niet voorkomen in de siminp-file, dan kan er nog steeds sprake zijn van domeindecompositie, namelijk met horizontale verfijning. In dat geval kan het runscript niet aan de invoerfile zien of een gewone berekening (sequentiëel of parallel) of DDHOR berekening gewenst is, en moet uit de argumenten worden afgeleid of aan de gebruiker worden gevraagd wat de bedoeling is. Als hij een DDHOR berekening wenst uit te voeren dan zijn de argumenten -decomp, -exp en -buf prt nodig. De vraag over het al dan niet gebruiken van DDHOR kan worden omzeild door het opgeven van de optie -decomp of -ndom ‘‘-gt 1’’ bij het opstarten van waqpre.pl (wel DDHOR berekening) of -ndom 1 (geen DDHOR berekening). Het argument -ndom is niet strikt nodig in pure DDHOR-berekeningen omdat geen loop over de deeldomeinen nodig is, en omdat het aantal parallelle subdomeinen voor COPPRE volgt uit de opgegeven roosteropdeling. Het argument -ndom van de runprocedure wordt in DDVERT berekeningen doorgegeven aan COPPRE om specifieke controles voor DDVERT uit te voeren. In geval van een DDHOR berekening wordt een eventueel opgegeven waarde door runprocedure genegeerd, net als een eventueel opgegeven argument -kmax. Het eenmalig draaien van WAQPRE en COPPRE is in de runprocedure uitgewerkt via interne variabelen isddh en isddv met waardes 0 en 1 (geen/wel DDHOR/DDVERT berekening). COPPRE bevat een voorziening waarmee een door de gebruiker gemaakte opdeling voor domein decompositie verder kan worden gesplitst voor de combinatie met parallel rekenen. In COPPRE kan hiervoor één subdomein worden aangeduid. In waqpre.pl is dit uitgewerkt voor DDHOR voor het geval dat de areas-file slechts één actief subdomein bevat. Voor DDVERT kan er per subdomein 1..ndom een partitiemethode (-partit) en aantal parts (-npart) worden gespecificeerd. In dat laatste geval roept waqpre.pl COPPRE eerst ndom keer aan om de uiteindelijke roosteropdeling te bepalen, waarbij optie PARTONLY wordt gebruikt, en vervolgens nog ndom keer om alle subdomein SDS-files te genereren, met gebruik van optie ONLYPARTS.

3.5

Aanpassingen aan waqpro.pl voor domein decompositie

Bij het gebruik van parallel rekenen moet de gebruiker het aantal parts opgeven en eventueel een partitioneringsfile. Uit het opgeven van een waarde voor npart die groter is dan 1 leidt het runscript af dat parallel rekenen wordt gebruikt. In dat geval worden COPPRE gedraaid, wordt COEXEC gebruikt om WAQPRO-processen op te starten en wordt na afloop COPPOS gedraaid. De invoer voor COEXEC wordt gegenereerd op basis van de waarde van npart. Bij domein decompositie met vertikale verfijning moet de optie ndom opgegeven worden. Als deze optie is opgegeven gaat het runscript er van uit dat domein decompositie met vertikale verfijning wordt gebruikt, tenzij ook nog een configuratiefile voor horizontale verfijning wordt


3-6

opgegeven. In dat laatste geval gaat de configuratiefile voor, en wordt dus verder uitgegaan van domein decompositie met horizontale verfijning. Het aantal domeinen wordt dan bepaald uit het aantal runid’s in de configuratiefile. In alle gevallen waarin sprake is van domein decompositie worden COEXEC en COPPOS gebruikt. Indien alleen vertikale verfijning wordt gebruikt, dan wordt de invoer voor COEXEC gegenereerd op basis van de waarde van ndom. Bij horizontale verfijning heeft de gebruiker zelf al een configuratiefile voor COEXEC opgegeven. De specificatie van een gekoppelde run via een invoerfile is nodig omdat er meerdere runid’s en experimentnamen tegelijkertijd moeten worden opgegeven en doorgegeven aan het master-proces COEXEC, wat lastig is te organiseren op basis van parameters van de runprocedure. Daarnaast biedt een configuratie-file de mogelijkheid om extra informatie over de processen of de koppelingen op te geven, hoewel dat op dit moment niet wordt gebruikt. In de configuratie-file specificeert de gebruiker welke domeinen (runid’s) in de gekoppelde run van toepassing zijn (volledig uitschrijven van alle gebruikte subdomeinen is minder gewenst, zie paragraaf 9.3.2). Daarbij wordt dan steeds een naam, runid, experimentnaam en executable-naam opgegeven. Alle runid’s die in deze file worden gevonden worden gebruikt om COPPOS aan te sturen. Hiervoor wordt geëist dat het keyword RUNID en de waarde-string op dezelfde regel staan. De experimentnaam die COPPOS nodig heeft wordt op dezelfde manier bepaald. Daarbij wordt bij de eerste runid de eerste experimentnaam gebruikt, en wordt gecontroleerd dat er evenveel experimentnamen als runid’s zijn gevonden. De buffergroottes per (deel-)domein worden afgeleid uit de opgegeven executable-namen via de conventie “waqpro.exe.bf<siz>”. Het argument -runid van de runprocedure waqpro.pl wordt in sequentiële, parallelle en DDVERT simulaties verder gebruikt voor de naamgeving van de message-file en voor het controleren of SDS-files bestaan. In DDHOR berekeningen is de functie van runid vooral de naamgeving van de run als geheel, en wordt de naam van de message-file analoog bepaald (waqpro-m.). Controleren op het bestaan van SDS-files is echter niet langer mogelijk, omdat aan de runprocedure niet bekend is welke subdomeinen van een rooster actief zijn en welke niet. Merk echter op dat er ook in parallelle en DDVERT runs niet wordt gecontroleerd op het bestaan van alle deel-SDS-files, en dat in dat geval alle files automatisch bestaan wanneer waqpre.pl en COPPRE correct zijn geëindigd. Op het bestaan van de “000-files” per domein wordt wel een controle uitgevoerd. Voor domein decompositie is bovendien de optie -check only toegevoegd, waarmee siminpfile overstijgende controles kunnen worden uitgevoerd zonder dat de simulatie direct aansluitend wordt opgestart.


4-1

Hoofdstuk 4 Globaal ontwerp numerieke aspecten in WAQPRO 4.1

Inleiding

Het programma WAQPRO implementeert de numeriek wiskundige modellen WAQUA en TRIWAQ voor simulatie van de ondiep-water vergelijkingen. Deze modellen bestaan uit de gebruikte differentiaalvergelijkingen op het continue niveau, de gehanteerde discretisaties, de oplosmethoden die worden gebruikt voor de resulterende stelsels van algebra¨ısche vergelijkingen en een veelheid aan implementatiekeuzes. In dit hoofdstuk bespreken we deze aspecten in de context van gekoppelde runs, dat wil zeggen voor simulaties waarin parallel rekenen en/of domein decompositie wordt gebruikt, met horizontale en/of vertikale verfijning. De nadruk ligt daarbij op het geven van een globaal overzicht. De details van de aanpak voor parallel rekenen en domein decompositie worden in Hoofdstuk 6 gegeven. In dit hoofdstuk beschrijft paragraaf 4.2 de algemene discretisatie-strategie voor gekoppelde runs. Daarbij wordt speciale aandacht besteed aan de terminologie voor verschillende soorten roosters en soorten roosterpunten, aan het bereiken van massabehoud in gekoppelde runs (zowel voor de waterbeweging als voor het transport van opgeloste stoffen), en aan de verschillende interpolatiemethoden die kunnen worden gebruikt. Ook wordt het gebruik van tijdsafhankelijke maskers toegelicht, waarmee problemen kunnen worden voorkomen in geval van droogval nabij de koppelingsrand. Daarna gaat paragraaf 4.3 in op de iteratieve procedures voor parallel rekenen en domein decompositie. Daarbij komen onder andere aan de orde de koppelingsmethode voor de continu¨ıteitsvergelijking (op basis van uitgaande informatie) en het flux-correctieschema voor het stoftransport in WAQUA/TRIWAQ.


o = o = o

k + k + k

o = o = o

k + k + k

o = o = o

= k + o

: : : :

4-2

u-punt - snelheid up, schotje kfu v-punt - snelheid vp, schotje kfv s-punt - waterstand sep d-punt - diepte dp

Figuur 4.1: Detail van een rekenrooster met “s/u/v/d”-punten: waterstands-, u- en vsnelheids- en dieptepunten. De doorgetrokken lijnen markeren de randen van roostercellen, de gebroken lijn geeft aan welke vier punten met dezelfde (m, n)-coördinaten worden aangeduid (dit is de zgn. WAQUA staggered grid conventie).

4.2 4.2.1

Discretisatie in gekoppelde runs Globaal discretisatierooster, guardband per domein

In een gekoppelde simulatie (parallel, vertikaal en/of horizontaal verfijnd) met WAQUA/TRIWAQ wordt een simulatie uitgevoerd op een aantal gekoppelde domeinen, die precies op elkaar aansluiten. Op elk van de domeinen wordt een discretisatie rooster gedefiniëerd, zie Figuur 4.1. Deze roosters worden (eenvoudig) gestructureerd genoemd omdat ze kunnen worden afgebeeld op een rechthoekig rooster. De domeinen kunnen vervolgens, middels partitioneroosters, ring, worden verdeeld in een aantal deel- of subdomeinen, elk met zijn gestructureerd deeldomeinen, discretisatie rooster. De domeinen vormen samen het globale domein. De combinatie van alle subdomei- gebruikte discretisatie roosters wordt globaal discretisatie rooster genoemd. Merk op dat dit nen niet eenvoudig gestructureerd hoeft te zijn ondermeer als gevolg van verfijning, zie Figuur 4.2. In elk van de roosterpunten van het globaal discretisatie rooster moeten de vergelijkingen van het turbulentiemodel en/of de behoudsvergelijkingen voor massa, impuls en transport worden benaderd met een discrete vergelijking. In de meeste roosterpunten kan de gewone WAQUA/TRIWAQ discretisatie worden gebruikt, maar dichtbij de koppelingsranden is dat niet altijd mogelijk. De reden hiervoor is dat in de gediscretiseerde impuls- en/of continuiteitsvergelijkingen waterstanden en snelheden uit omringende roosterpunten voorkomen, en dat die roosterpunten niet voor hoeven te komen in het globale discretisatie rooster. In deze roosterpunten wordt de volgende strategie gebruikt om tot een discretisatie te komen: het discretisatie rooster per domein wordt uitgebreid met de roosterpunten die nodig zijn voor de discrete vergelijkingen, maar in de toegevoegde roosterpunten worden de impuls- en/of continu¨ıteitsvergelijkingen niet gediscretiseerd. In plaats daarvan worden de waterstanden en snelheden in deze roosterpunten verkregen door interpolatie van waarden in roosterpunten die wel tot het “echte” rooster behoren. guardband De uitbreidingen van de verschillende discretisatie roosters worden guardbands genoemd. De roosters plus guardbands worden de gestructureerde (deel-)roosters per (deel-)domein genoemd. De verzameling van alle gestructureerde roosters wordt het samengesteld gestructureerde rooster genoemd. In de programmatuur is weinig te merken van het bestaan van dit


4-3

o

+

o

+

o

+

o

+

o

+

o

+

o

+

o

=

+

=

+

=

+

=

+

=

+

=

+

=

+

=

o

+

o

+

o

+

o

+

o

+

o

+

o

+

o

=

+

=

+

=

+

=

+

=

+

=

+

=

+

=

o

+

o

+

o

+

o

+

o

+

o

+

o

+

o

=

+

=

+

=

+

=

+

=

+

=

+

=

+

=

o

+

o

+

o

+

o

+

=

+

=

+

o

k

o

k

=

+

=

+

o

k

o

k

o

+

o

+

o

+

o

=

+

=

+

=

+

=

o

+

o

+

o

+

o

=

+

=

+

=

+

=

o

+

o

+

o

+

o

=

+

=

+

=

+

=

o

+

o

+

o

+

o

=

+

=

+

=

+

=

o

+

o

+

o

+

o

Figuur 4.2: Het globale discretisatierooster voor een situatie met 1:2 verfijning: verzameling van alle “echte” roosterpunten. De grootte van de symbolen geeft aan tot welk domein ze behoren. samengesteld gestructureerde rooster. Elk rekenproces berekent slechts de waterstanden en stroomsnelheden in een van de deeldomeinen, op een van de gestructureerde deelroosters. De deeldomeinen worden aan elkaar gekoppeld door de informatie die ze uitwisselen op zogenoemde communicatiemomenten. Daarbij wordt de benodigde interpolatie voor het overzetten van gegevens van het ene naar het andere gestructureerde rooster binnen de communicatiebibliotheek uitgevoerd.

4.2.2

Interpolatie- en discretisatiepunten, discretisatiestencils

De discretisaties nabij en op de interfaces tussen verschillende domeinen worden aldus verkregen door de gewone veld-discretisaties toe te passen, waarbij de gebruikte informatie uit een aantal van de omringende roosterpunten verkregen is door middel van interpolatie van de waarden uit een ander domein. De roosterpunten waarvan de waarden niet worden verkregen als oplossing van een discrete differentiaalvergelijking, maar uit interpolatie van waarden discretisa- uit andere roosterpunten, worden interpolatiepunten genoemd. De punten waarin wel een tie- vs. differentiaalvergelijking wordt gediscretiseerd heten discretisatiepunten. Ten behoeve van 1:1 interpola- aansluitende roosters (o.a. bij parallel rekenen) wordt ook de term kopiëerpunten ge¨ıntrodutiepunten ceerd voor punten in de guardband van een deeldomein waarvoor de waarde wordt verkregen door kopiëren van de waarde van een buurdomein. De verzameling van roosterpunten die gebruikt worden bij de discretisatie van een differentiaalvergelijking in een bepaald punt wordt wel het discretisatiestencil genoemd. De discretisatiestencils per berekening bevatten essentiële informatie ten aanzien van de vereiste communicaties. Figuur 4.3 geeft als voorbeeld de toepassing van het stencil van de impulsvergelijking in TRIWAQ. De gebruikte symbolen zijn gedefiniëerd in Figuur 4.1. Het middelste


4-4

= |

|

=

= =

k k = +=+ = k k = | | =

|

| =

=

=

k =+ k

k

=+ =

=

k

= |

| =

Figuur 4.3: Links: globaal discretisatierooster met 1:2 verfijning. Midden en rechts: grove en fijne rooster met bijbehorende guard band en met een discretisatiestencil voor de uimpulsvergelijking (TRIWAQ). punt in de stencils is het punt waar de vergelijking wordt benaderd. Dit punt is steeds gemarkeerd door er een wat groter teken in te zetten. De precieze stencils per berekening in WAQUA/TRIWAQ worden uitgewerkt in Hoofdstuk 6.

4.2.3

Massabehoud, eigenaarschap van de interfaces

De discretisatie is massabehoudend wanneer op de koppelingsranden het debiet eenduidig is bepaald, en wanneer dat debiet ook (aan beide zijden) wordt gebruikt bij het opstellen van de continu¨ıteitsvergelijking. De discretisatie van de transportvergelijking is behoudend wanneer op de koppelingsranden de fluxtermen eenduidig zijn bepaald. Merk op dat de interface zelf door de snelheidspunten loopt (zie bijvoorbeeld Figuur 4.3). Eenduidigheid van debieten en fluxen wordt bereikt met behulp van duidelijke afspraken over het eigendom van de cellfaces op de interface. In geval van roosterverfijning wordt interface is de interface zelf steeds tot het fijnste domein gerekend. In het grove domein bestaat de van fijne interface zelf dus uit interpolatiepunten en wordt de fijnroosterflux, na conversie, gebruikt in domein de behoudswetten voor cellen van het grove rooster. De conversie van fijnroosterdebieten en -fluxen naar grofroosterwaardes is zeer eenvoudig, bestaat uit niets anders dan optellen van de fijnroosterwaardes. In geval van één-op-één aansluitende roosters hoort de interface bij het linker of onderste deeldomein. De reden hiervoor is praktisch van aard: hierdoor is het in parallelle runs steeds zo dat alle vier de roosterpunten (s/u/v/d) met dezelfde (m, n) coördinaat (array index) van een enkel subdomein ofwel allemaal discretisatiepunten ofwel allemaal interpolatiepunten zijn (zie Figuur 4.1). Dit werd voorheen op grote schaal uitgebuit, bijvoorbeeld door bij het partitioneren per arraysoort slechts een enkele distributietabel aan te maken. In het DDVERT project is echter al gebleken dat gebruik van de fijnroosterflux in sommige gevallen tot betere


4-5

4

4

4

2

2

4

4

4

2

2

4

4

3

3

3

−1 −1 3

3

3

−1 −1 3

3

3

m

n+1

n

m+1

Figuur 4.4: Links: discretisatierooster van het fijne domein, verdeeld in drie subdomeinen. Midden: details van de opdeling rond het hoekpunt (waterstandspunt “+”, u-punt “-”, v-punt “|”, dieptepunt “o”). Rechts: zelfde opdeling in termen van subdomeinnummers (zwart=4, rood=2, blauw=3, interpolatiepunt=−1). resultaten leidt dan wanneer het eigenaarschap wordt gebaseerd op (m, n)-coördinaten. Verder leidde het distribueren van data op basis van (m, n)-coördinaten in de partitioner COPPRE in geval van horizontale verfijning tot problemen met restarten van sommen. Daarom is in het DDHOR+VERT project de hierboven beschreven strategie rigoreus ingevoerd, is het fijne domein altijd eigenaar van de interface gemaakt. Het is de bedoeling dat deze strategie ook volledig wordt doorgevoerd voor de dieptepunten op de interface. In het DDHOR-project werden de dieptepunten van het grove domein op de eigenaar- interface ook als “echte” dieptepunten beschouwd (discretisatiepunten). Het lijkt nodig om schap van deze dieptepunten als interpolatiepunten te gaan behandelen, met name voor het horizontaal dieptepun- k − turbulentiemodel. Het is nog niet duidelijk wat voor consequenties deze wijziging heeft ten voor de initialisaties van de communicaties in berekeningen met horizontale verfijning.

4.2.4

Eigenaarschap van s/u/v/d-punten binnen een domein

Naast de afspraken die worden gemaakt over het toewijzen van punten aan domeinen, moet er ook worden nagedacht over het onderverdelen van een domein in subdomeinen (combinatie dom.dec. met parallel rekenen). Zoals in Hoofdstuk 5 wordt betoogd is deze onderverdeling nodig om te weten welk rekenproces er verantwoordelijk is voor het versturen van waardes in discretisatiepunten. In de DDHOR-versie van WAQUA/TRIWAQ werd dit eigenaarschap gekoppeld aan een enkel array POWNER uit de partitioner. In roosterpunten (m, n) die voor de waterstanden een interpolatiepunt zijn maar niet voor de snelheden of dieptepunten werd een eigenaar ingevuld via een vast algoritme: eerst naar rechts kijken (m + 1, n), als daar geen eigenaar is dan naar boven (m, n + 1), anders naar rechtsboven. Dit leverde een zogenaamd “maximaal eigenaarschap” op, met een unieke eigenaar per roosterpunt (m, n), voor alle roosterpunten waarvoor dat van belang is. In het DDHOR+VERT project is een complicatie gevonden met deze manier van werken, zie Figuur 4.4. In deze figuur wordt een domein getekend met een teruggevouwen hoek,


4-6

met DDHOR-interfaces aan de linker- en onderzijdes van het domein. De complicatie is nu dat v-snelheidspunt (m, n) per sé aan een ander subdomein moet worden toegekend dan usnelheidspunt (m, n). Het blauwe subdomein met nummer 3 kan namelijk de berekeningen voor het v-punt niet uitvoeren, omdat dit subdomein geen kolom bevat in de irogeo-tabel waar het v-punt bij hoort. Omgekeerd kan het zwarte subdomein 4 niet voor het u-punt rekenen. Deze complicatie maakt dat er geen uniek “maximaal eigenaarschap” voor de arrayindices kan worden gedefiniëerd, maar dat er in plaats daarvan aparte ownerships bestaan voor s/u/v/d-punten. Het eigenaarschap van u/v/d-punten wordt wel weer via een vast algoritme gekoppeld aan het eigenaarschap van s-punten dat in de POWNER-array is opgegeven. Als powner(m, n) = −1 dan is de owner van u-punt (m, n) gelijk aan powner(m + 1, n) rechts, de owner van v-punt (m, n) is powner(m, n + 1) boven, en de owner van d-punt (m, n) is de eerste waarde van rechts, boven en rechtsboven die groter is dan 0. Merk op dat het eigenaarschap binnen een domein alleen een onderverdeling betreft van de discretisatiepunten. Het ownership is alleen van belang voor het versturen van waardes, terwijl er voor interpolatiepunten juist alleen waardes worden vervangen/ontvangen. Dit wordt handig uitgebuit, door een enkel array te gebruiken om zowel het onderscheid discretisatie/interpolatie als het ownership binnen een domein te coderen. De code −1 wordt steeds gebruikt voor interpolatiepunten, 0 voor “loze” punten in een array, en waardes p > 0 worden gebruikt voor discretisatiepunten.

4.2.5

Discretisatie van de continu¨ıteitsvergelijking bij horizontale verfijning

Traditioneel worden er bij domein decompositie methodes vaak alleen waardes uit discretisatiepunten gebruikt. Bijvoorbeeld voor de benadering van de waterstandsgradiënt in snelheidspunten op de interface. Een methode hiervoor is om de benadering te construeren uit de “echte” waterstanden van de verschillende domeinen (in discretisatiepunten). Dit kan echter een complexe berekening worden, met name wanneer rekening moet worden gehouden met verschillende verfijningsfactoren, met droogvallen en onderlopen en met knikken in de interfaces tussen (sub)domeinen. Het gebruik van informatie van verschillende roosters bij het discretiseren van vergelijkingen rond de interface leidt dus tot extra complexiteit. Daarom is in WAQUA/TRIWAQ de algemene strategie ingevoerd voor domein decompositie waarbij per discretisatiepunt de gewone veld-discretisaties worden toegepast, waarbij bij interfaces via interpolatie verkregen waardes worden gebruikt. Hiermee wordt er per rekenproces slechts informatie van het eigen rooster gebruikt. Merk op dat de manier van interpoleren van bijvoorbeeld de waterstanden mee bepaalt welke koppeling er precies wordt gebruikt. In 2008 is er voor de gekoppelde continu¨ıteits- en impulsvergelijkingen, voor de berekening van nieuwe waterstanden en u-stroomsnelheden, een nieuwe strategie ge¨ımplementeerd. Hieruitgaande in wordt afgeweken van het hierboven beschreven principe voor het maken van koppelingen. informatie In de nieuwe strategie wordt het principe van “uitgaande informatie” gebruikt. Deze strategie


4-7

bepaalt op een algebra¨ısche manier wat de uitgaande karakteristieken van de gediscretiseerde differentiaalvergelijkingen zijn, en levert daarop gebaseerde informatie aan het naburige domein. Dit levert een snellere convergentie op van de iteratieve procedures die nodig zijn voor de domein-decompositiekoppeling en is daarom beter dan de eerdere koppeling die op ge¨ınterpoleerde waardes was gebaseerd. De koppelingsmethode op basis van uitgaande informatie gaat uit van de volgende koppelingscondities: • op de interface, d.w.z. in de snelheidspunten, tellen de debieten van het fijne domein op tot het debiet van het overeenkomstige snelheidspunt van het grove domein; • op de interface van het fijne domein, d.w.z. in de snelheidspunten van het fijne domein, is de ge¨ınterpoleerde waterstand van het grove domein gelijk aan de waterstand van het fijne domein. De waterstand in snelheidspunten is niet direct beschikbaar. Hiervoor wordt de gewone upwind-methode gebruikt. Deze gebruikt de waterstand in de eerste roostercel buiten ieder domein. Die roostercel wordt hiermee tijdelijk een discretisatiepunt voor de waterstand. Ook moet het debiet op de interface van het grove domein berekend worden. Het bijbehorende snelheidspunt wordt tijdelijk een discretisatiepunt van het grove domein, waarin de impulsvergelijking moet worden gediscretiseerd. Merk op dat gelijkheid van waterstanden wordt gevraagd in de interfacepunten van het fijne domein. Dat is nodig om het correcte aantal vergelijkingen te krijgen. Verder wordt hiermee variatie van de waterstand langs de interface mogelijk gemaakt. Daarbij wordt de variatie die het fijne domein aan het begin van een halve tijdstap heeft onthouden en opgelegd aan de oplossing aan het einde van de halve stap. Met deze koppelingsvergelijkingen ligt de totale oplossing vast, en is het aan de solver om deze oplossing te berekenen. Zodra de oplossing van de vergelijkingen berekend is wordt weer op de oude strategie teruggestapt. De extra discretisatiepunten voor de waterstand worden weer als guardband/interpolatiepunten beschouwd, en de waterstand wordt overschreven door een waarde die met interpolatie is bepaald. Dit wordt wel met zorg gedaan, zodanig dat debieten en doorstroomhoogtes precies op de interface die voor massabehoud gelijk aan elkaar moeten zijn niet worden veranderd door communicaties.

4.2.6

Updaten van de guardband, vervanggebieden

De grootste discretisatiestencils komen voor in het transportgedeelte van TRIWAQ. Deze stencils maken dat de guardband tenminste drie rijen en kolommen van roostercellen rond het eigen deeldomein moet bevatten. In de andere berekeningen van WAQUA/TRIWAQ wordt de guardband niet geheel gebruikt. Het is dan ook niet nodig om bijvoorbeeld alle waterstanden in de gehele guardband consistent te maken met de discretisatiewaardes van buurdomeinen. Hiermee kan een substantiële hoeveelheid kopiëerwerk of communicatie worden uitgespaard: per iteratie van de


4-8

transportsolver in TRIWAQ hoeft slechts de helft van de guardband te worden geupdated, per iteratie voor de impulsvergelijking in TRIWAQ moet twee keer een-derde worden geupdated (vanwege het gebruikte red-black iteratieschema), en in de solver voor de continu¨ıteitsvergelijking moet er per iteratie 1/6 van de guardband consistent worden gemaakt. Bovengenoemde besparingen in de hoeveelheid communicatie zijn cruciaal voor het verkrijgen van goede schaalbaarheid op parallelle computers, voor het verkrijgen van goede performance bij gebruik van grotere aantallen subdomeinen/processoren. Daarom is er bij de ontwikkeling van parallel WAQUA/TRIWAQ voor gekozen om per communicatie-call (de “update”-operatie) aan te geven welk gedeelte van de guardband up-to-date moet worden gemaakt. Dit gebeurt door aan de update de naam van een “communicatie-interface” door te geven. De communicatie-interface wordt bij de initialisaties van WAQPRO gedefiniëerd aan de hand van een stencil, de verzameling van punten waar het stencil moet worden toegepast (bijvoorbeeld de u-punten in Figuur 4.3), en de verzameling punten waarin de arraywaardes zijn gedefiniëerd (bijvoorbeeld de waterstandspunten in geval van het array sep van waterstanden). Het “vervanggebied” van de communicatie-interface bestaat dan uit alle waterstandspunten van de guardband die worden bereikt door toepassen van het stencil in alle u-punten van het eigen deeldomein. Een probleem met het gebruik van communicatiestencils is wel dat het administreren van welke stencils wanneer nodig zijn lastig is. Mede om deze data-analyse te vereenvoudigen is in het DDHOR+VERT project het gebruik van zogenaamde redundante berekening uit parallel WAQUA/TRIWAQ verwijderd. Verder kan bij het testen van nieuwe functionaliteit ook eerst overal het maximale stencil worden gebruikt (updaten van de gehele guardband). Als kleinere stencils tot andere rekenresultaten leiden dan is er een fout gemaakt, dan wordt er te weinig gecommuniceerd.

4.2.7

Interpolatiemethoden, interpretatie van variabelen

In de voorgaande paragrafen is in grote lijnen besproken hoe de discretisatie nabij en op de interfaces wordt bepaald: de gewone velddiscretisatie c.q. het gewone discretisatiestencil wordt toegepast, en waardes voor ontbrekende roosterpunten worden ingevuld via interpolatie. Massabehoud wordt verkregen door de interface zelf aan het fijne domein toe te kennen en eenduidigheid van de fluxen op de interface te garanderen. De beschrijving van de discretisaties bij interfaces met roosterverfijning is hiermee echter nog niet compleet. Ze wordt in sterke mate be¨ınvloed door de interpolatieformules die worden gebruikt. Bij het construeren van interpolatieformules is de interpretatie van variabelen van belang. Variabelen die worden beschouwd als gemiddelde in een roostercel of op een cellface, worden anders ge¨ınterpoleerd dan de variabelen die als samples worden gezien. Het belang van de interpretatie van variabelen wordt ge¨ıllustreerd met het volgende voorbeeld. Wanneer bij een 1:3 verfijning de fijnroosterwaterstanden ge¨ınterpoleerd worden naar het grove rooster, komt een grofroostercel overeen met 3×3 fijnroostercellen. Wanneer de waterstanden als samples van een continue functie worden beschouwd, dan wordt door de meest voordehandliggende interpolatieformules gewoon de waarde van het middelste roosterpunt gevonden. Wanneer echter voor een interpretatie als celgemiddelde waterstand wordt gekozen, is de ge¨ınterpoleerde


4-9

waarde gelijk aan het gemiddelde van de negen fijnroosterwaterstanden, gewogen naar de oppervlakte van de controlevolumes. Hierbij moet worden aangemerkt dat de interpretaties van variabelen niet overal in de simulatieprogrammatuur eenduidig zijn doorgevoerd. Dat wil zeggen dat bepaalde termen in differentiaalvergelijking worden gediscretiseerd op een manier die een hogere orde van nauwkeurigheid heeft wanneer de variabele wordt ge¨ınterpreteerd als celgemiddelde waarden, en andere termen met een benadering die een hogere orde heeft bij interpretatie als samples. Dit is geen groot probleem omdat de twee interpretaties pas in tweede orde nauwkeurigheid van elkaar verschillen. Het heeft echter wel tot gevolg dat de formele orde van nauwkeurigheid van de gebruikte discretisaties misschien lager is dan wordt aangenomen. Het feit dat er binnen WAQUA/TRIWAQ niet zeer strikt de hand wordt gehouden aan de interpretatie van variabelen als samples of celgemiddelden, geeft wel enige vrijheid in de te kiezen interpolaties. Met uitzondering van de debieten en transportfluxen precies op de interface, die in ieder geval als ge¨ıntegreerde resp. gemiddelde waarden moeten worden gezien (om massabehoud te kunnen garanderen), kunnen alle variabelen zowel ge¨ınterpoleerd worden met een methode die gebaseerd is op een gemiddelde-interpretatie, als met een methode die gebaseerd is op een sample-interpretatie.

4.2.8

Horizontale interpolatie voor de diverse grootheden

Voor het realiseren van interpolaties van 3D velden in geval van horizontale èn vertikale verfijning bij een interface kiezen we ervoor om steeds eerst vertikaal te interpoleren en daarna horizontaal te interpoleren. Dat is praktisch omdat een subdomein bij vertikale interpolatie steeds slechts te maken heeft met een enkel buurdomein, terwijl er bij horizontale interpolaties informatie van meerdere buren nodig kan zijn. In het eerste geval kan dus direct na het ontvangen van een boodschap worden ge¨ınterpoleerd, in het tweede geval moet worden gewacht totdat alle boodschappen binnen zijn. Verder levert het scheiden van horizontale en vertikale interpolaties op zich geen verlies van nauwkeurigheid op. Bilineaire interpolatie Een bekende interpolatiemethode voor 2D velden is bilineaire interpolatie. In deze methode worden de gegeven discretisatiewaardes beschouwd als samples in de overeenkomstige discretisatiepunten. Hiermee is de methode geschikt voor allerlei grootheden zoals waterstanden, stroomsnelheden, transportconcentraties e.d. Bij de toepassing van deze methode in WAQUA/TRIWAQ moeten diverse keuzes worden gemaakt: • van welke coördinaten wordt uitgegaan (fysische (x, y) of logische (m, n)-coördinaten)? • welke vier discretisatiepunten worden gebruikt voor een interpolatiepunt, zie Figuur 4.5 (links)? • hoe wordt omgegaan met niet-rechthoekige bronroostercellen? • hoe wordt omgegaan met interpolatiepunten buiten het bronrooster, zie Figuur 4.5 (rechts)?

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) subdomeininterface

4-10 subdomeininterface

Figuur 4.5: Illustratie van moeilijkheden bij het uitwerken van de bilineaire interpolatiemethode. Links: welke zwarte discretisatiepunten moeten worden gebruikt voor het rode interpolatiepunt? Rechts: wat te doen als er geen vier discretisatiepunten zijn? • welke randvoorwaarden moeten worden meegenomen? Met betrekking tot de eerste vraag wordt er in de huidige versie van WAQUA/TRIWAQ met domein decompositie steeds voor gekozen om de logische (m, n)-coördinaten te gebruiken. Dit wordt verder uitgewerkt in paragraaf 6.3, samen met de andere genoemde punten. Celgemiddelde interpolatie Het nadeel van bilineaire interpolatie voor waterstanden is dat ze interacties introduceert tussen verschillende rijen van het rekenrooster bij het berekenen van nieuwe waterstanden uit de continu¨ıteitsvergelijking, zie paragraaf 4.3.5 en Figuur 4.9 (rechts). Uitgaande van een gemiddelde-per-cel interpretatie van waterstanden is een voordehandliggend alternatief om stuksgewijs constant te interpoleren. De waterstand in een interpolatiepunt van het grove rooster wordt dan berekend als het gemiddelde van de waterstanden van de overeenkomstige discretisatiecellen van het fijne rooster, gewogen naar de oppervlakte van die discretisatiecellen. In een interpolatiepunt van het fijne rooster kan gewoon de waarde van het grove rooster worden gekopiëerd. Strikt genomen zou er bij stuksgewijs constante interpolatie van getransporteerde stoffen gewogen moeten worden met de volumes van roostercellen in plaats van de oppervlaktes. De volumes zijn echter tijdsafhankelijk en leiden daarmee tot het steeds moeten communiceren van coëfficiënten en herberekenen van interpolatiegewichten. Dit wordt vooralsnog niet gedaan, de getransporteerde stoffen worden op dezelfde manier ge¨ınterpoleerd als de waterstanden. Merk op dat dit niet tot massaverlies leidt, omdat massabehoud volgt uit de gebruikte transportfluxen op de interface die massabehoudend worden ge¨ınterpoleerd. Tijdsafhankelijke maskers voor droogval en onderlopen Een complicatie die in eerdere versies optrad bij de interpolatie van waterstanden en transportconcentraties, zowel bij celgemiddelde als bilineaire interpolatie, is dat er bij de interpolatie weinig rekening werd


4-11

gehouden met droogvallen en onderlopen. Er werd alleen gekeken naar de permanente nat/droogstatus van punten, en de tijdsafhankelijke status werd genegeerd. Dit leidde er in verschillende situaties toe dat waardes uit droge cellen invloed hebben op ge¨ınterpoleerde waardes. Dat bleek met name kwalijk te zijn bij de interpolatie van waterstanden: in een droog punt kan de waterstand substantieel hoger zijn dan in de omringende punten, en meenemen van deze waardes leidt tot een kunstmatige waterstandsgradiënt. In een model van de haven van Breskens worden bijvoorbeeld droge punten gemodelleerd door middel van een zeer hoge bodemligging (50m hoger dan de rest van de bodem). De waterstanden en de bodemligging werden vervolgens in interpolaties gebruikt, wat er toe leidde dat er in een aantal guardband punten een zeer hoge waterstand werd gevonden, met een net iets lagere bodem. Dit leidde tot een grote waterstandsgradiënt en het steeds verder toenemen van de stroomsnelheid. Vergelijkbare problemen zijn opgetreden bij het simuleren van de Oosterschelde en het Rammegors. Dit probleem is in het project DDHOR+VERT opgelost door bij het interpoleren informatie mee te nemen over de actuele nat/droogstatus van punten. Hierbij is het masker dat aangeeft welke discretisatiepunten in interpolaties mogen worden gebruikt tijdsafhankelijk gemaakt. Wanneer er roosterpunten droogvallen, wordt de waterstand aldaar niet meer meegenomen in de interpolatie. De interpolatiematrix moet op zo’n moment worden herberekend. Een vergelijkbaar probleem dat mogelijk zou kunnen optreden ten gevolge van het voorkomen van overlaten op of nabij interfaces is dat de interpolatie van snelheden en waterstanden in de buurt van overlaten onnauwkeurig is, omdat deze velden discontinu zijn in de buurt van een overlaat. Bij het testen van het prototype DDHOR zijn er echter geen problemen gevonden ten gevolge van het voorkomen van overlaten in de buurt van een koppelingsrand [3]. Daarom zijn in de huidige programmatuur geen speciale maatregelen uitgewerkt voor eventuele problemen. Mochten die later toch optreden dan kunnen de interpolatiemethoden worden aangepast, bijvoorbeeld door alleen de waarden aan een kant van de overlaat te gebruiken. Constant-per-cellface interpolatie Berekende snelheden kunnen worden beschouwd als samples, maar ook als cellface-gemiddelde waarden. Dat wil zeggen dat de snelheid de gemiddelde snelheid is over een zijwand van een controlevolume. In dat geval is het logisch om een interpolatiemethode te gebruiken waarin in de richting haaks op de cellface lineair wordt ge¨ınterpoleerd, terwijl langs de cellface stuksgewijs constante interpolatie wordt gebruikt. De achtergrond van deze interpolatie wordt in Figuur 4.6 ge¨ıllustreerd. Maximum-interpolatie van schotjes De schotjes-arrays kfu en kfv zijn in de guardband nodig voor de discretisatie van de impulsvergelijking, en tevens als hulpvariabele voor de interpolatie van snelheden. Een complicerende factor hierbij is dat de schotjesvariabelen maar twee mogelijke waarden hebben: wel een schotje (0) of geen schotje (1). Bovendien moet worden voorkomen dat de stroomsnelheid ongelijk aan nul is op cellfaces die zijn afgesloten. Die situatie wordt voorkomen wanneer voor de schotjesvariabelen in de guardband van het grove rooster het maximum genomen wordt van alle bij de interpolatie betrokken schotjes van


4-12

Figuur 4.6: Illustratie van de interpolatie van u-snelheden bij interpretatie als gemiddelden per cellface: lokaal constante interpolatie langs cellfaces en lineaire interpolatie in de richting haaks op de cellfaces. het fijne rooster Zo wordt alleen dan een schotje in een interpolatiepunt geplaatst wanneer in alle betrokken discretisatiepunten een schotje staat.

4.3

Oplossing van de gediscretiseerde vergelijkingen

In paragraaf 4.2 is besproken hoe de discretisaties van WAQUA en TRIWAQ nabij koppelingsranden worden bepaald. De discretisaties leiden in de meeste gevallen tot stelsels algebra¨ısche vergelijkingen waarvoor iteratieve oplosprocedures worden toegepast. In deze paragraaf wordt een overzicht gegeven van de manieren waarop deze iteratieve methoden worden aangepast voor gekoppelde berekeningen. De aandacht gaat daarbij vooral uit naar de aanpassingen voor domein decompositie; de solvers zelf en de parallellisatie ervan zijn uitvoerig beschreven in [7]. Er zijn zes soorten stelsels van vergelijkingen van belang, met in totaal acht verschillende iteratieve procedures: 1. de impulsvergelijking in WAQUA en TRIWAQ (trscue, waslgs, trsjam); 2. de gekoppelde impuls- en continu¨ıteitsvergelijkingen in WAQUA/TRIWAQ (trssuw, trsumo, trscnt); 3. de transportvergelijking in WAQUA en TRIWAQ ((trsdif, waspnd, trsjac);


4-13

4. de vergelijkingen van het verticaal k, -turbulentiemodel in TRIWAQ (trstur, trsdgs), niet beschikbaar voor WAQUA; 5. de vergelijkingen van het dieptegemiddelde (horizontale) k, -turbulentiemodel in WAQUA/TRIWAQ (trshke, trstrd); 6. de vergelijkingen voor de niet-hydrostatische drukcorrectie in TRIWAQ (washdy, trsbcg), niet beschikbaar voor WAQUA.

4.3.1

Jacobi-koppelingen op subdomeinranden

Een aantal verschillende solvers is geparallelliseerd door “Jacobi-vergelijkingen” te gebruiken op subdomeinranden. Deze strategie kan ook worden omschreven als binnen het subdomein de sequentiële solver toe te passen, met in de guardband de waardes van buurdomeinen van de vorige iteratie. In parallel WAQUA/TRIWAQ wordt deze strategie gebruikt in: • de “red-black Jacobi” solver voor de impulsvergelijking in TRIWAQ (trsjam), • de “line Gauss-Seidel” solver voor de impulsvergelijking in WAQUA (waslgs), • de “red-black Jacobi” solver voor de transportvergelijking in TRIWAQ (trsjac), • de “flow-following Gauss-Seidel” solver voor het verticale k − turbulentiemodel in TRIWAQ (trsdgs). In de red-black Jacobi methodes wordt er twee keer per iteratie gecommuniceerd, zodat de iteratiemethode in parallelle runs exact dezelfde iteranden berekent als in sequentiële runs. Deze solvers kunnen relatief eenvoudig worden uitgebreid voor domein decompositie. Het belangrijkste verschil is dat er bij het communiceren nu ook wordt ge¨ınterpoleerd, maar dat is vrijwel onzichtbaar in de rekenroutines. Daarnaast zijn er twee aspecten die speciale aandacht vereisen. • de hierboven beschreven strategie levert bij gebruik van horizontale of vertikale verfijning geen massabehoud op in het transportgedeelte van TRIWAQ; • bij gebruik van horizontale verfijning moeten in de red-black Jacobi methodes de waardes voor rode èn zwarte guardbandpunten worden ge-updated. Voor het garanderen van massabehoud wordt er bij gebruik van domein decompositie in de transportgedeeltes van WAQUA en TRIWAQ een flux-correctieschema gebruikt. Dit schema wordt besproken in paragraaf 4.3.2. Het probleem met de rood-zwart communicatie in DDHOR berekeningen is dat er bij de interpolatie naar een “rood” guardbandpunt van het ene subdomein zowel rode als zwarte discretisatiepunten kunnen worden gebruikt, en voor een zwart interpolatie punt idem dito. Dit hangt af van de verfijningsfactoren en van de interpolatiemethodes die voor snelheden en transportconcentraties worden gebruikt. Na een halve iteratie, waarin alleen de waarden in


4-14

rode (resp. de zwarte) discretisatiepunten zijn aangepast, kunnen daarom de waarden in sommige rode (resp. zwarte) interpolatiepunten nog consistent (valide) zijn, terwijl de waarden in sommige zwarte (resp. rode) interpolatiepunten inconsistent (invalide) zijn geworden. Welke waarden in de communicatie aan het einde van elke halve iteratie moeten worden vervangen, moet daarom in de initialisatiefase worden bepaald middels een communicatie. Vervolgens worden er speciale communicaties (interfaces) geconstrueerd voor de rood-zwart iteraties.

4.3.2

Het fluxcorrectieschema voor de transportvergelijking

Bij de berekening van transportconcentraties is, net als bij de berekening van waterstanden, massabehoud van belang. In (sequentiëel) TRIWAQ wordt dit bereikt door conservatieve discretisatieformules te gebruiken en door de daaruit voortkomende lineaire stelsels tot op machinenauwkeurigheid op te lossen. Hiervoor wordt een red-black Jacobi-methode gebruikt, zie paragraaf 4.3.1. In geval van domein decompositie met vertikale of horizontale verfijning wordt massabehoud bereikt door het eenduidig bepalen wat de transportflux op koppelingsranden is, zie paragraaf 4.2.3. In het DDVERT-project is gebleken dat hierbij het beste de transportflux van het fijnst verroosterde deeldomein genomen kan worden. Het is echter niet gewenst om extra te gaan communiceren in de transportsolver, en ook niet om de transportflux in het grove domein een iteratie te laten achterlopen bij die in het fijne domein. Daarom is in het DDVERT-project een zogenaamd flux-correctieschema ontwikkeld [4, 11]. In het flux-correctie schema wordt de transportflux berekend uit de concentraties op het eigen rooster. Op de interfaces moet deze flux echter niet met de eigen concentraties worden berekend, maar uit de fluxen van het buurdomein. De grofroosterflux is de som van een aantal fijnroosterfluxen. Het verschil tussen de zelf berekende grofroosterflux en de ontvangen ge¨ınterpoleerde grofroosterflux (som van verschillende fijnroosterfluxen) wordt toegevoegd aan het rechterlid van het stelsel. Deze fluxcorrectie wordt steeds op het laatst beschikbare iteratieniveau berekend. Om de fluxcorrectie te berekenen worden bij het discretiseren aparte coëfficiënten-arrays gevuld voor subdomeinrandpunten. Het is in principe mogelijk om de transportsolvers te herstructureren zodat de fluxen centraal komen te staan, zie de voorstellen hiervoor in [11]. Daarbij wordt gebruik gemaakt van de observatie dat de totale stencils uit figuren 6.6 en 6.7 zijn op te vatten als de combinatie van een discrete behoudswet en berekeningsstencils voor de transportfluxen, zoals te zien is in Figuren 4.7 en 4.8.

4.3.3

De BJ-TWGE methode

In twee solvers van WAQUA/TRIWAQ wordt voor de parallellisatie het BJ-TWGE schema gebruikt (“block-Jacobi with two-way Gaussian Elimination”, zie bijv. [7]), namelijk in: • de “double-sweep” solver voor de transportvergelijking in WAQUA (waspnd), • de “linearisatie en double-sweep” solver voor de k- vergelijking van het horizontale turbulentiemodel in TRIWAQ (trstrd).


k

1) =

+

3)

2) =

4-15

+

-

=

+

+

-

= k + -

+

k

+

k

+

: : : :

khu/qx/u-flux khv/qy/v-flux rp khu

Figuur 4.7: Discretisatiestencil voor de transportvergelijking in WAQUA (trsdif), weergegeven als combinatie van drie deelstencils. Links: behoudsvergelijking; midden: berekening u-flux; rechts: berekening v-flux. k

1) =

+ k

3) +

2) =

+

-

+

-

+

=

+

-

+

-

+

k +

= k + -

: : : :

khu/qxk/u-flux khv/qyk/v-flux rp khu

Figuur 4.8: Discretisatiestencil voor de transportvergelijking in TRIWAQ (trsdif), weergegeven als combinatie van drie deelstencils. Links: behoudsvergelijking; midden: berekening u-flux; rechts: berekening v-flux. In deze twee gevallen is er sprake van pentadiagonale of tridiagonale stelsels vergelijkingen per rij, die in sequentiële runs in een keer met de double-sweep methode kunnen worden opgelost. Bij de parallellisatie van WAQUA/TRIWAQ is hiervoor de BJ-TWGE methode ontwikkeld, zie [7]. De BJ-TWGE methode kan niet worden gebruikt bij subdomeinranden waar horizontale verfijning wordt toegepast. In de transportsolver van WAQUA wordt daarom bij DDHORranden met verfijning teruggevallen op de Jacobi-koppeling, zie paragraaf 4.3.1. In het verlengde van parallel WAQUA wordt hierbij een flux-correctieschema gebruikt voor het forceren van massabehoud. Het is ondertussen wel eenvoudig geworden om massabehoud te garanderen, namelijk door het flux-correctieschema voor horizontale verfijning ook te gebruiken voor ddhor-1:1 en parallelle subdomeinranden.

4.3.4

Iteratiemethode voor de continu¨ıteitsvergelijking bij horizontale verfijning

In het eerste prototype van parallel TRIWAQ is Jacobi-koppeling gebruikt voor het oplossen van de waterstanden per subdomein. Omdat dit tot een sterke toename van het aantal iteraties leidde is de BJ-TWGE methode ontwikkeld. In het eerste prototype voor DDHOR is een nieuwe Jacobi-koppeling ge¨ıntroduceerd voor randen waar horizontale verfijning werd gebruikt [2]. Deze is bij de operationalisatie verfijnd met een soort preconditionering, die ook als een soort flux-correctieschema kan worden gezien. Toch functioneerde die methode niet heel goed, waardoor de performance van DDHOR tegenvallend was. Ten behoeve van een eventuele uitbreiding van de programmatuur richting domein decompositie met verschillende tijdstappen per domein is er gezocht naar flexibele koppelingsme-


4-16

chanismes. Daaruit is de methode van uitgaande informatie ontstaan. Deze wordt momenteel gebruikt voor het koppelen en iteratief oplossen van de continu¨ıteitsvergelijking per domein. Deze methode kan worden opgevat als een generalisatie van de BJ-TWGE-methode. De werking van de methode van uitgaande informatie is globaal als volgt: • Ieder subdomein veegt één diagonaal van de tridiagonale stelsels per rij. Hij begint daarbij waar mogelijk bij een fysieke rand en veegt naar de interface toe. • Uit de coëfficiënten van de vergelijking voor het interfacepunt kan worden afgeleid wat de uitgaande informatie is. Dit is informatie die het subdomein zelf kan bepalen zonder dat informatie van het buurdomein daar van invloed op is. • De uitgaande informatie wordt uitgedrukt in een verhouding van de interface-waterstand en het interface-debiet, en kan zo tussen de subdomeinen worden gecommuniceerd. • Het grove domein kan uit de informatie van hemzelf en van het buurdomein de toestand op de interface berekenen en stuurt deze naar het fijne domein. • Met de (exacte) oplossing op de interface kan het stelsel verder worden geveegd c.q. opgelost. • Wanneer er meer dan twee (sub-)domeinen in een rij aan elkaar gekoppeld zijn dan zijn er (sub-)domeinen met “dubbel gekoppelde rijen”. Dan wordt aan een zijde een Jacobi-koppeling c.q. onbetrouwbare randvoorwaarde toegepast. • In dit geval wordt ook een stelsel met homogene randvoorwaarden geveegd. Uit de oplossing van de double sweep volgt een betere schatting voor het punt waar de Jacobikoppeling is gebruikt. Met de oplossing van de homogene vergelijking wordt hier een correctie voor gemaakt. Verdere details over deze methode worden gegeven in paragraaf 6.6. Deze methode levert bij 1:1-koppeling in het horizontale vlak dezelfde oplossing op als in sequentiële runs wordt bepaald. Bij horizontale verfijning worden iets andere koppelingscondities gebruikt, zie ook paragraaf 4.2.5. Deze koppelingscondities garanderen massabehoud, aansluiten van de waterstanden op de interface, en zorgen ervoor dat de variatie van de waterstand langs de interface van het fijne domein behouden blijft.

4.3.5

Uitbreiding van de convergentiecontrole per rij

Een verfijning in de solver voor de continu¨ıteitsvergelijking in WAQUA en TRIWAQ is dat het stopcriterium per rij wordt geëvalueerd in plaats van dat voor alle rijen evenveel iteraties worden uitgevoerd. Tridiagonale stelsels worden uit de berekening genomen wanneer deze opgelost zijn voordat alle andere tridiagonale stelsels zijn opgelost. Dit mechanisme kan niet zomaar in DDHOR-berekeningen worden gebruikt omdat horizontale verfijning kan leiden tot interactie tussen verschillende rijen van een enkel deeldomein. Dit is evident in de situatie


4-17

subdomeininterface

Figuur 4.9: Links: opdeling in deeldomeinen met 1:2 en 1:3 verfijning die interactie oplevert tussen alle tridiagonale stelsels van alle deeldomeinen. Rechts: zelfde alles-met-alles interactie ten gevolge van bilineaire interpolatie. van Figuur 4.9. Daarnaast ontstaan vergelijkbare interacties door het gebruik van bilineaire interpolatie voor de waterstanden. Het stopcriterium per rij moet zo veel mogelijk worden gehandhaafd, omdat er in de solver voor de continu¨ıteitsvergelijking in WAQUA voor sommige rijen veel meer iteraties nodig zijn dan gemiddeld over het hele rooster. Dit is een van de grootste knelpunten in parallel WAQUA en kan worden aangepakt met andere linearisatietechnieken. Hetzelfde stopcriterium per rij wordt ook in de transportsolver van WAQUA gebruikt. Ook hier moet het worden gehandhaafd. In dit geval is er namelijk voor een groot aantal rijen helemaal geen iteratieproces nodig, alleen waar er meer dan twee subdomeinen bij een rij zijn betrokken moet er worden ge¨ıtereerd. Een efficiënte uitbreiding voor horizontale verfijning is nu om de een rij uit de berekening te halen wanneer het lokale stelsel is opgelost in het eigen domein en in de gekoppelde stelsels van beide aangrenzende domeinen. Het is hierbij mogelijk dat een stelsel uit de berekening wordt genomen omdat het is opgelost, maar later weer in de berekening wordt opgenomen, omdat de oplossing in het aangrenzende domein in een latere iteratie toch te veel is aangepast.


5-1

Hoofdstuk 5 Globaal ontwerp communicatiebibliotheek COCLIB 5.1

Uitgangspunten van COCLIB

De communicatiebibliotheek COCLIB is oorspronkelijk ge¨ıntroduceerd in parallel TRIWAQ om de gegevensuitwisseling tussen rekenprocessen strikt af te scheiden van de berekeningen van de simulatie. Enerzijds vanwege portabiliteit, opdat het parallelle programma zonder grote aanpassingen kan worden gebruikt op een parallelle computer met een afwijkend communicatiesysteem. Anderzijds ook om de details van het communiceren, zoals proces-ID’s en message-tags te verstoppen voor applicatieprogrammeurs. Ook de boekhouding van de precieze vorm van subdomeinranden en van de verschillende buurdomeinen wordt door COCLIB verstopt voor applicatieprogrammeurs. Hiermee wordt vrijwel volledige vrijheid bereikt bij het verdelen van het rekenrooster over verschillende processoren. Met name voor het administreren van de precieze verstuur- en vervanggebieden bij gebruik van grillig gevormde subdomeinranden zijn krachtige generieke mechanismes ontwikkeld. Bij de verdere uitbreiding van WAQUA/TRIWAQ met domein decompositie zijn een aantal van de bovenstaande eigenschappen tot uitgangspunten verheven: • Rekenprocessen zouden zich alleen moeten bezighouden met welke informatie ze zelf nodig hebben voor hun berekeningen (wat en wanneer), en niet moeten geven om wie die informatie toelevert of hoe dat in z’n werk gaat. Dit maakt rekenprocessen minder afhankelijk van de omgeving waarbinnen ze worden uitgevoerd. • De functie van COCLIB is het volledig verzorgen van het hoe en het met wie van de datauitwisseling tussen verschillende rekenprocessen in een gekoppelde run. Hieronder valt in het geval van domein decompositie ook het uitvoeren van de benodigde interpolaties. Dit gebeurt op basis van specificaties van het wat van de rekenprocessen. • COCLIB is gebaseerd op generieke en krachtige concepten, gebruikt zo min mogelijk specifieke kennis van WAQUA/TRIWAQ. Het zou niet moeten voorkomen dat COCLIB “weet” dat het bepaalde dingen moet gaan doen (“magisch”), in plaats daarvan doet


5-2

COCLIB alleen maar die dingen die het op de een of andere manier verteld wordt te doen. • Het aansturen van COCLIB vanuit WAQUA/TRIWAQ gebeurt zo veel mogelijk in voor de gebruiker (applicatieprogrammeur) begrijpelijke termen. Ook moet de manier van aansturen goed aansluiten bij het gewenste gebruik van COCLIB door de applicatie. De gebruiker moet zo veel mogelijk zijn eigen arrays kunnen doorgeven aan COCLIB op momenten dat die arrays beschikbaar zijn, in plaats van dat de gebruiker zich in bochten moet wringen om COCLIB te kunnen gebruiken. COCLIB is verder uitgebreid bij de parallellisatie van het RRSQRT Kalman filter voor WAQUA/TRIWAQ. Die uitbreidingen betreffen faciliteiten voor het koppelen van verschillende in plaats van gelijksoortige rekenprocessen. Daaruit is het volgende uitgangspunt gedestilleerd: • Rekenprocessen zijn zodanig geprogrammeerd en op elkaar afgestemd dat ze “weten” wanneer ze welke informatie moeten versturen en ontvangen. Je kunt niet zomaar aan een rekenproces vragen “geef mij ...”. In het geval van parallel rekenen/domein decompositie volgt het “weten” uit dat ieder proces hetzelfde algoritme afdraait. Tenslotte gelden onverkort de doelstellingen van efficiënte communicatie en gemakkelijke overdraagbaarheid naar verschillende computerplatformen. De bovenstaande doelstellingen en uitgangspunten kunnen worden beschouwd als de functionele eisen aan de communicatiebibliotheek. In het vervolg van dit hoofdstuk bespreken we op hoofdlijnen het ontwerp van COCLIB waarmee deze eisen worden gerealiseerd.

5.2

Globaal overzicht over COCLIB

In de huidige versie van COCLIB worden twee soorten communicatie-operaties onderscheiden die elk voor specifieke doeleinden worden gebruikt. 1. de update-operatie, waarbij informatie op subdomeininterfaces wordt uitgewisseld met buurdomeinen; 2. globale operaties, waarbij (subgroepen van) alle processen informatie aan elkaar toesturen, hetzij direct danwel via een bijdrage aan een globale reductie-operatie zoals het bepalen van het maximum van de waardes die door alle processen worden ingebracht. Een derde soort die bij de parallellisatie van het Kalman filter is ge¨ıntroduceerd wordt gevormd door: 3. de avail- en obtain-operaties, waarbij (gedeeltes van) velden een richting uit worden gecommuniceerd (van het ene rekenproces/de ene groep van processen naar het andere/de andere groep).


5-3

De globale operaties staan redelijk los van de update-operatie en van de rest van COCLIB. Daarentegen zijn de avail-, obtain- en update-operaties gerelateerd aan een heel scala aan COCLIB voorzieningen waarmee de gebruiker ervoor zorgt dat gegevens op de juiste en meest efficiente wijze van het ene rooster naar het andere worden overgezet. Te configureren zaken zijn: • index sets en stencils/interfaces; • coëfficiëntensets; • enkelvoudige conversiemethodes; • een tijdelijk opslagformaat (de “overlapset”); • koppelingscategoriën; • samengestelde conversiemethodes. Deze abstracte entiteiten worden in dit hoofdstuk een voor een beschreven en gemotiveerd aan de hand van de taak die de update moet uitvoeren en met de vorige paragraaf gegeven uitgangspunten. De avail- en obtain-operaties worden niet verder toegelicht, maar kunnen in veel gevallen worden beschouwd als de verstuur- en ontvanggedeeltes van de update-operatie. Merk op dat de update-operatie een bepaald soort symmetrie veronderstelt tussen de rekenprocessen, op gelijksoortige rekenprocessen is geënt, terwijl avail/obtain van nature zijn gericht op asymmetrische communicaties. Dat kan overigens ook om gelijksoortige rekenprocessen gaan. Denk bijvoorbeeld aan een domein decompositie berekening waarin er steeds slechts een van de domeinen een iteratie uitvoert en gegevens toelevert (avail’t) aan de naburige domeinen.

5.3

De update-operatie voor parallel rekenen

De centrale operatie van COCLIB voor parallel rekenen en voor domein decompositie is de update-operatie. Deze zorgt voor het uitwisselen van informatie rond subdomeinranden met buurdomeinen. Deze paragraaf geeft een overzicht van wat daarbij komt kijken in het geval van parallel rekenen, waarbij informatie één-op-één wordt overgezet van het ene subdomein naar het andere. Aan de hand van dit geval worden verschillende COCLIB-concepten ge¨ıntroduceerd, met name “index sets”, “stencils”. Het huidige overzicht sluit aan bij de beschrijving van discretisatiestencils en van de guardband in paragraaf 4.2. De update-operatie kan goed worden begrepen aan de hand van rekenroosters zoals in WAQUA/TRIWAQ worden gebruikt, maar is feitelijk generieker. Uitgangspunt zijn rekenprocessen die allemaal hun eigen array hebben dat op de een of andere manier een ruimtelijke structuur (rekenrooster) vertegenwoordigt. De arrayelementen zijn in drie groepen verdeeld: “eigen” indices, “niet-eigen” indices en “loze” elementen (zie onder). Het doel van de updateoperatie is nu om de waardes in “niet-eigen” elementen van het array ingevuld te krijgen, en om waar nodig de “eigen” elementen van het array naar de buurprocessen te versturen.


5-4

In WAQUA/TRIWAQ zijn de eigen indices van arrays de discretisatiepunten van een subdomein, de niet-eigen indices zijn punten in de guardband van een subdomein, en loze punten zijn oninteressante punten voor het subdomein: inactieve punten (landpunten), en actieve punten (water) ver buiten het eigen subdomein. De update-operatie zorgt voor het consistent maken van de guardband met de waardes in discretisatiepunten van buurdomeinen, zie paragraaf 4.2.6. Een eis aan de update-operatie is dat het mogelijk is om ook een gedeelte van de guardband te updaten, om een deelverzameling van alle niet-eigen punten van een array te kunnen gebruiken. Een cruciale stap in het werken met arrays die op mogelijk complexe wijzen abstracte structuren representeren is het introduceren van zogenaamde “logische coördinaten”. De gebruiker mag hierbij kiezen wat hij voor coördinatensysteem wil hanteren, kan bijvoorbeeld kiezen voor 3D coördinaten (d, m, n) met d het domeinnummer van een DDHOR-berekening en (m, n) de coördinaten van het roosterpunt binnen dit domein. Ook is het in principe mogelijk om strings als coördinaten (identificatie) te gebruiken. Een groot voordeel van integer coördinaten voor WAQUA/TRIWAQ is echter dat hierop eenvoudig verschillende stenciloperaties kunnen worden toegepast. Dit wordt onder anderen gebruikt om het te updaten gedeelte van de guardband te selecteren: “zoek alle niet-eigen array-elementen (guardbandpunten) waarvoor de logische coördinaat voldoet aan (m, n) = (m, ˜ n ˜ ) + (δm, δn)”, met (m, ˜ n ˜ ) de logische coördinaat van een eigen array-element (discretisatiepunt) en (δm, δn) een van de offsets van het opgegeven stencil. Met behulp van de logische coördinaten en de communicatiestencils kan de programmeur/gebruiker op een eenvoudige manier communicatietabellen laten maken voor verschillende soorten arrays. Bijvoorbeeld zowel voor “fullbox” als “mnmaxk”-arrays, en desgewenst ook voor arrays voor randpunten. Ten behoeve van performance worden de tabellen eenmalig aangemaakt en bewaard; het mogelijk tijdrovende uitzoekwerk voor de communicaties wordt alleen in de initialisatiefase van WAQUA/TRIWAQ gedaan. Tijdens het rekenen kunnen de verschillende arraysoorten (de zogenaamde “index sets”) en communicatietabellen (“interfaces”) door middel van hun naam aan de update-operatie worden doorgegeven. Dit is uitermate prettig gebleken bij het gebruik van COCLIB, het voorkomt bijvoorbeeld dat “handles” of arrays van communicatietabellen overal als subroutineparameter aan moeten worden doorgegeven. Een stap verder is om de status van punten (eigen/niet-eigen/loos) en de logische coördinaten los te koppelen van de benaming “arraysoort”. In de praktijk komt het namelijk vaak voor dat de bijbehorende “index sets” in verschillende combinaties worden gebruikt. Dus niet alleen een arraysoort voor informatie op het horizontale rooster (array(1:mnmaxk)), maar ook als “arraydimensie” voor het 3D rooster (array(1:mnmaxk,1:kmax)). De naam “index set” verwijst ernaar dat er ook niet altijd een koppeling met arrays hoeft te bestaan. De opgegeven informatie kan dus worden gezien als de beschrijving van een algemene “verzameling van indices”, bijvoorbeeld de indices waarmee een array kan worden geadresseerd. De gebruiker wenst dan dat de definities voor het horizonale rooster eenvoudig kunnen worden hergebruikt voor het 3D rooster. Hiervoor staat COCLIB toe dat nieuwe index sets kunnen worden gedefiniëerd als Cartesisch product van bestaande sets: “mnmaxk*kmax”. Deze


5-5

nieuwe set kan nu weer worden gezien als beschrijving van de arraysoort voor arrays voor het 3D rooster.

5.4

Verschillende vormen van interpolatie

Zodra er in een domein-decompositieberekening roosterverfijning wordt gebruikt kunnen de waardes van het ene subdomein niet meer direct in een ander subdomein worden gebruikt, maar moeten ze eerst op een geschikte manier worden ge¨ınterpoleerd. In paragraaf 4.2.7 is aangegeven dat er daarbij veel verschillende methoden van toepassing zijn, en dat dit mede afhankelijk is van de interpretatie die aan de waardes wordt toekend. Bij de uitwerking van interpolatiemethodes spelen verder de gebruikte coëfficiënten een belangrijke rol. Dit zijn bijvoorbeeld de coördinaten van “discretisatie”- en “interpolatiepunten” in de “bron” en “doelroosters” van de interpolatie-operatie, maar ook weegfactoren zoals de oppervlakte en het volume van roostercellen. Verder is in paragraaf 4.2.7 aangegeven dat niet alle discretisatiepunten dezelfde status hebben. Voor het meenemen van randvoorwaarden en van droogvaleffecten in interpolaties is het nodig om te kunnen sturen in welke discretisatiewaardes er wel/niet in interpolaties worden gebruikt. In een aantal gevallen blijken deze coëfficiënten tijdsafhankelijk te zijn. In WAQUA/TRIWAQ hangt dit vooral samen met de variatie van de waterstand (doorstroomhoogte, laagdiktes, masker nat/droog), bij de koppeling van TRIWAQ en SIMPAR zijn de coëfficiënten de tijdsafhankelijke posities van de deeltjes. Ook het interactiepatroon kan hierdoor in de tijd veranderen. Voor de koppeling van TRIWAQ en SIMPAR is dit evident, maar ook treedt dit op bij bepaalde vormen van domein decompositie. In TRIWAQ kunnen lagen van verschillende subdomeinen ten opzichte van elkaar bewegen als er lagen met een vaste dikte en sigmalagen aan elkaar worden gekoppeld. Verder kan het droogvallen leiden tot een ander interactiepatroon. In andere gevallen blijken de coëfficiënten juist eenvoudiger te kunnen worden beschreven dan voor ieder roosterpunt apart. Bijvoorbeeld als er in TRIWAQ met vertikale verfijning overal alleen sigmalagen worden gebruikt dan zijn de interpolatiegewichten constant in de ruimte, zijn de gewichten identiek voor alle roosterpunten in het horizontale vlak. Een ander onderscheid tussen verschillende situaties waarin interpolatie moet worden toegepast zit in het aantal buren dat bij de interpolatie is betrokken. In geval van TRIWAQ met vertikale verfijning is er voor interpolatie naar een enkel guardbandpunt (m, n) slechts informatie van één enkel buurdomein nodig, in geval van horizontale verfijning hoeft dit niet zo te zijn. Dit hangt samen met de logische “richtingen” waarin er wordt gecommuniceerd en ge¨ınterpoleerd. Als de interpolatie in dezelfde richting of in hetzelfde vlak gebeurt als de richting waarin het rooster is opgedeeld dan kan er informatie van meerdere buurdomeinen nodig zijn voor een enkel interpolatiepunt, wanneer de twee richtingen haaks op elkaar staan dan is er per interpolatiepunt steeds interactie met een enkel buurdomein.


5.5

5-6

Interpolatie: basisoperaties en co¨ effici¨ entensets

Dàt interpolatie in de update operatie wordt opgenomen volgt uit het uitgangspunt dat rekenprocessen vooral moeten denken in termen van hun eigen grootheden, en dat ze zo min mogelijk te maken moeten hebben met wie ze precies gekoppeld zijn. De vraag is hóe alle hierboven beschreven vormen van interpolatie in COCLIB kunnen worden ingepast: op een generieke manier, en configureerbaar in voor de gebruiker begrijpelijke termen. Daarbij is een extra wens dat de interpolatieroutines van COCLIB ook in de preprocessor WAQPRE en in de collector COPPOS kunnen worden gebruikt, voor vertikale verfijning in TRIWAQ, zonder dat er daarbij informatie uitgewisseld wordt met andere rekenprocessen. De manier die wordt gevolgd voor interpolaties in COCLIB bestaat er allereerst uit dat er verschillende “basisoperaties” worden aangeboden die kunnen worden gevoed met “coefficiënten”. Een basismethode beschrijft een bepaalde formule of een bepaald soort gedrag, bijvoorbeeld “bilineair”, en geeft aan welke coëfficiënten daarbij moeten worden ingevuld. In het geval van de bilineaire methode van COCLIB zijn dat de 2D coördinaten van de discretisatiepunten, de 2D coördinaten van de interpolatiepunten, en de “maximale afstand”, een parameter die wordt gebruikt in het bepalen welke discretisatiepunten voor een bepaald interpolatiepunt in aanmerking mogen worden genomen. Bij de meeste basisoperaties bestaan er verschillende routines die een aantal terugkerende bewerkingen uitvoeren: 1. bepalen van het interactiepatroon, het “ijlheidspatroon van de interpolatiematrix”, 2. bepalen van de interpolatiegewichten, de “matrixelementen”, 3. en uitvoeren van de interpolatie zelf, een “matrix-vector product”. Deze opsplitsing wordt gemaakt om werk uit te kunnen sparen als informatie niet veranderd is. Zolang de coëfficiënten niet veranderen kunnen steeds dezelfde interpolatiegewichten worden gebruikt, en als alleen bepaalde coëfficiënten veranderen dan kan het interactiepatroon worden hergebruikt. In een aantal gevallen worden de bewerkingen voor meerdere basisoperaties door een enkele routine ge¨ımplementeerd. Dat geldt met name voor het interpoleren zelf, waar min of meer hetzelfde matrix-vector product voor veel verschillende basisoperaties van toepassing is. Niet alle basisoperaties leiden echter tot een interpolatiematrix; het belangrijkste tegenvoorbeeld is de “max-operatie” voor het communiceren van schotjes, hierbij wordt wel een ijlheidspatroon maar geen gewichten gebruikt. Tenslotte is voor een eerste begrip van interpolaties in COCLIB vooral de manier van omgaan met coëfficiënten van belang. Hierbij is ervoor gekozen om “verversbare coëfficiëntensets” te definiëren. De gebruiker definiëert eerst de structuur van een buffer voor het bewaren van de coëfficiënten, en kan daarna zo vaak hij wil deze buffer vullen met nieuwe waardes. Hij stelt hiermee steeds nieuwe waardes beschikbaar voor gebruik in interpolaties (een soort van avail-operatie). Deze waardes worden automatisch verstuurd naar buurdomeinen zodra ze voor het eerst nodig zijn voor het berekenen van interpolatiegewichten. Omdat de coëfficienten steeds alleen nodig zijn in de buurt van subdomeininterfaces is de opslagstructuur hier sterk op afgestemd, wordt er gebruik gemaakt van de structuur van communicatie-interfaces.


5-7

Zodra coëfficiënten zijn ververst worden ook de ervan afhankelijke interpolatiegewichten automatisch herberekend. Hiervoor wordt er bij de coëfficiënten een versienummer opgeslagen dat steeds wordt opgehoogd zodra ze worden ververst. De vervolgacties onthouden voor welk versienummer ze zijn uitgevoerd en worden opnieuw gedaan zodra het versienummer is veranderd. Dit kan worden omschreven als “lazy execution”, pas uitvoeren van vervolgacties op het moment dat daarom wordt gevraagd. Ook de benamingen “object geörienteerd” en “pull mechanisme” zijn relevant: het interpolatiegedeelte in de update-routine “vraagt” aan een matrix zijn waardes, en de matrix controleert van zichzelf of hij nog up-to-date is. Dit is een prettig mechanisme voor veel programmeerwerk binnen een rekenproces: een vragende routine krijgt gewoon de benodigde gegevens zonder rekening te hoeven houden met alle eigenschappen van het object dat hij ondervraagt. Het prettige van coëfficiëntensets voor de programmeur/gebruiker is dat hij bij het aanroepen van de update niet zo precies in de gaten hoeft te houden welke coëfficiënten er worden gebruikt. De programmeur geeft alleen aan welke interpolatiemethode er moet worden gebruikt, en in de interpolatiemethode is opgeslagen welke coëfficiëntensets van toepassing zijn. De gebruiker mag de coëfficiënten zo vaak verversen als hij wil (meerdere keren per tijdstap of in een iteratieproces) of de coëfficiënten gebruiken in verschillende updates of interpolatiemethodes, de coëfficiënten worden niet vaker gecommuniceerd, en de interpolatiegewichten niet vaker herberekend dan nodig is.

5.6

Tijdelijk geheugen in de update-operatie

Een complicatie bij het gebruik van interpolaties in de update-operatie is dat de gegevens die het ene proces verstuurt in het algemeen niet passen in de datastructuur van het andere proces. Dat is een logisch gevolg van het zo min mogelijk afstemmen van een rekenproces op de context waarbinnen het wordt gebruikt. De consequentie is dat COCLIB geheugen moet reserveren voor de waardes van buurprocessen, voor het opslaan van de waardes voordat de interpolatie kan worden uitgevoerd. Merk overigens op dat interpolaties in COCLIB steeds door het ontvangende proces worden uitgevoerd. In geval van horizontale interpolatie is er geen goed alternatief omdat er informatie (veldwaardes) van meerdere buurprocessen tegelijk nodig is. Bij vertikale interpolatie zou de interpolatie wel door het versturende proces kunnen worden uitgevoerd. Dat is echter niet praktisch omdat er bij interpolatie vaak coëfficiënten nodig zijn van beide betrokken rekenprocessen, die dan apart van de veldwaardes moeten worden gecommuniceerd. Het reserveren van geheugen is vrij gemakkelijk voor de interpolaties die gebruikt worden bij vertikale verfijning. Hier kan er namelijk direct worden ge¨ınterpoleerd zodra er een boodschap is ontvangen van een enkel buurproces. De boodschap vertelt zelf hoeveel getallen hij bevat en hiervoor wordt een tijdelijk bufferarray gemaakt. De boodschap wordt uitgepakt naar de buffer, er wordt ge¨ınterpoleerd, en de buffer kan worden opgeruimd. Verder is het interactiepatroon tussen de punten van het eigen rooster en het buurrooster zeer eenvoudig gestructureerd. Dit stramien heeft als prettige eigenschap voor de gebruiker dat hij in een rekenproces slechts weinig te maken heeft met de roosters van buurdomeinen.


5-8

In geval van horizontale verfijning is de situatie meer complex. De ontvangen gegevens van een buurproces passen nu totaal niet meer op de eigen data structuren, en bij de interpolatie is vaak informatie nodig van verschillende buurprocessen en zelfs van het ontvangende proces zelf. COCLIB heeft nu niet meer voldoende informatie om te bepalen hoeveel geheugenruimte nodig is en hoe die ruimte moet zijn gestructureerd. In plaats daarvan moet de gebruiker zelf een nieuwe index set (arraysoort) definiëren, waarin alle punten worden opgenomen die in de communicatie nodig zijn. De beschrijving van de index set bestaat uit de logische coördinaten en de status van roosterpunten op (“eigen/niet-eigen/loos”). Deze wordt gebruikt voor het leggen van een relatie tussen de elementen van deze index set en de index set van de gebruiker’s array met veldwaarden, en voor het automatisch bepalen van geschikte communicatie-interfaces. Behalve voor de communicatie is de nieuwe index set ook van belang voor het opgeven van de coëfficiënten voor de horizontale interpolaties. De nieuwe index set wordt opgegeven bij het definiëren van een horizontale interpolatiemethode. De update-operatie begint dan met het alloceren van een tijdelijk array met gewenste afmetingen en overzetten van de gebruikersdata hiernaartoe. Dit overzetten wordt “reshapen” genoemd, er wordt een “reshape-operatie” voor gebruikt. Dan worden de gebruikelijke acties toegepast op het tijdelijke array: versturen en ontvangen van data. Zodra alle berichten zijn ontvangen worden tenslotte de uitgestelde interpolaties uitgevoerd en worden de berekende waardes teruggezet (gereshaped) naar het array van de gebruiker. De hier terloops ge¨ıntroduceerde relatietabellen en reshape-operaties spelen een belangrijke rol binnen COCLIB. Dit kan worden uitgelegd aan de hand van een analogie met index sets en velden. Waar index sets kunnen worden beschouwd als een mechanisme voor het standaardiseren van de beschrijving van datastructuren, zo zijn relatietabellen een mechanisme voor het beschrijven van interacties tussen twee . En waar velden een concrete invulling zijn van een lege datastructuur, daar geven gewichten een invulling aan het interactiepatroon. Interactiepatroon en gewichten samen kunnen worden beschouwd als een generalisatie van ijle matrices. In het verlengde hiervan kan de reshape-operatie worden gezien als een generalisatie van het matrix-vectorproduct.

5.7

Koppelingscategori¨ en

De acties die nodig zijn in de update-operatie verschillen nu afhankelijk van het soort koppeling van twee subdomeinen. Bij een DDVERT koppeling zullen er andere interpolaties moeten gebeuren (en op een andere plek in de update-operatie) dan bij een DDHOR koppeling. Verder is het voor “sigma-vast” koppeling in de vertikaal nodig meerdere keren per tijdstap bepaalde coëfficiënten worden gecommuniceerd en interpolatiematrices worden herberekend. Bij een DDHOR koppeling is juist een tijdelijke opslagstructuur nodig die kan worden omzeild bij een DDVERT koppeling. Het is niet gewenst om alleen het meest krachtige mechanisme te implementeren en dit in alle gevallen toe te passen. In geval van WAQUA/TRIWAQ met horizontale en vertikale verfijning vereist dit altijd gebruik van tijdelijke opslag en horizontale interpolaties, terwijl dit relatief veel overhead introduceert voor parallelle runs. Ook is het niet acceptabel als


5-9

een grote parallelle som fors langzamer wordt zodra er een ander DDHOR-domein aan het oorspronkelijke rekenrooster gekoppeld wordt. Het is dus nodig binnen een enkele gekoppelde run tegelijkertijd verschillende mechanismes in de update-operatie te kunnen gebruiken. De manier waarop dit in COCLIB is mogelijk gemaakt is door middel van “koppelingscategoriën”, die min of meer de relatie tussen twee subdomeinen beschrijven. Een rekenproces kan bijvoorbeeld gekoppeld zijn aan drie buurprocessen, waarbij de relatie met de eerste van het soort (categorie) “parallel” is, de relatie met het tweede buurproces kan “ddv-sigvast” zijn, en de relatie met het derde weer “parallel”. De namen en betekenissen van de verschillende koppelingscategoriën worden ingevuld door de gebruiker. COCLIB bepaalt dan aan de hand van gebruikersinformatie en eventueel met een gebruikersroutine wat de relatie per buurproces is. Tenslotte beschrijft de gebruiker wat de update-operatie voor iedere categorie moet doen (de “betekenis” van de categorie), en doet COCLIB per buurproces precies wat er moet gebeuren, zonder dat het gebruikerprogramma precies weet welk buurproces (nummer, proces-ID) hoe wordt behandeld.

5.8

Stramien van de update-operatie

In de vorige paragrafen hebben we gezien dat de uitwerking van de conceptueel eenvoudige update operatie voor alle relevante situaties heel wat voeten in aarde heeft. In deze paragraaf geven we een schematisch overzicht van hoe alle mogelijkheden in elkaar zijn gepast. Het belangrijkste aspect bij de beschrijving van de update-operatie is dat er verschillende “paden” worden onderscheiden. Ten eerste is er een pad voor “directe communicatie”, waarbij de gegevens die van een buurproces worden ontvangen direct kunnen worden ge¨ınterpoleerd en/of in de eigen arrays kunnen worden geplakt. Daarnaast bestaat er een pad (in principe ook meerdere paden) voor “indirecte communicatie”. Indirecte communicatie werkt niet op de datastructuren van de gebruiker zelf, maar gebruikt door COCLIB gereserveerde tijdelijke opslagruimte. De gebruiker bepaalt de structuur (index set) van deze tijdelijke arrays. De update-operatie kan nu worden onderverdeeld in vijf fasen. De eerste stap bestaat uit het alloceren van een tijdelijk array met gewenste afmetingen voor indirecte communicatie, en het overzetten van de gebruikersdata hiernaartoe. Dan worden de gebruikelijke acties toegepast op het tijdelijke array: versturen en ontvangen van data (resp. fase 2 en 3). Op de ontvangen data worden direct de interpolaties toegepast die per buur kunnen worden uitgevoerd. In fase 4 worden de resterende interpolaties gedaan waarbij informatie van meerdere rekenprocessen nodig is. Tenslotte worden de ontvangen en ge¨ınterpoleerde gegevens van tijdelijke arrays overgezet naar de gebruikersarrays. Een aspect dat nog niet is genoemd is dat er vier arrays tegelijkertijd kunnen worden gecommuniceerd in een enkele update-operatie. Dit is nodig voor de efficiëntie op parallelle computers, omdat het significant meer tijd kost om vier berichten te versturen dan om een enkel bericht te versturen dat vier keer zo groot is. Het is dus voordelig om de updates van verschillende arrays samen te voegen. Het aantal van vier arrays tegelijkertijd is enigszins arbitrair gekozen; een groter aantal levert nauwelijks winst in het aantal updates dat moet worden uitgevoerd, maar leidt wel tot het overal moeten toevoegen van extra subroutine-


5-10

argumenten. Het verloop van de update-operatie wordt nu in pseudo-code gepresenteerd in Figuur 5.1. Het verwerken van informatie in fases 3 en 4 van de update omvat in het geval van DDVERT en DDHOR een vorm van interpolatie. Het omzetten van informatie van en naar het tijdelijk opslagformaat in fases 1 en 5 betreft een reshape-operatie. De gepresenteerde indeling wijkt iets af van de indeling die in de eerste complete versie van DDHOR is gebruikt, waarbij fases 4 en 5 waren samengevoegd.

5.9

Configuratie van samengestelde conversiemethoden

De gebruiker moet per koppelingscategorie aangeven welke stappen er in de update-operatie nodig zijn en welke data (index sets, coëfficiënten, interpolatiemethodes) daarbij van toepassing zijn. De specificatie van alle stappen voor alle koppelingscategoriën samen noemen we een “samengestelde conversiemethode”, of ook wel een “samengestelde interpolatiemethode”. De specificatie van een samengestelde conversiemethode is sterk geënt op het hierboven gepresenteerde stramien van de update-operatie. Er worden drie aparte soorten van bouwstenen onderscheiden. • Type I: de reshape-operatie: kopiëert waarden van een index set naar een tijdelijk opslagformaat of terug. In de update-operatie kan een Type I operatie in fase 1 worden uitgevoerd, voorafgaand aan het verzenden van de eerste boodschap, of na afloop van het ontvangen en verwerken van de laatste boodschap (fase 5). • Type II: directe interpolaties: interpoleert waarden op een index set van het ene rekenproces naar waarden in een opslagstructuur van het andere rekenproces. In de update-operatie wordt een Type II interpolatie uitgevoerd zodra er een boodschap van een van de buurprocessen arriveert (fase 3), zodat het ontvangende proces geen gegevens hoeft op te slaan in de structuur van het buurproces. • Type III: uitgestelde interpolaties: interpoleert waarden vanuit de discretisatie punten in een index set naar de interpolatiepunten in die index set. In de update-operatie wordt een Type III interpolatie uitgevoerd zodra de informatie van alle buurprocessen op de index set ontvangen is (fase 4). De bouwstenen zijn zogenaamde “enkelvoudige interpolatie/conversiemethodes”. Deze bestaan uit een basisoperatie en de daarbij benodigde data: index set, coëfficiënten, eventuele maskers, e.d. De samengestelde methode kan voor verschillende koppelingstypes anders zijn ingevuld (andere enkelvoudige methodes selecteren), en moet in principe voor ieder voorkomend koppelingstype zijn gedefiniëerd. Merk op dat het type bouwsteen niet vast ligt voor een basisoperatie maar mede wordt bepaald door de toepassing ervan. Zo kan lineaire interpolatie in de vertikaal een type III interpolatie worden als de verschillende lagen over meerdere subdomeinen worden verdeeld, en in dat geval kan bilineaire interpolatie in de horizontale richtingen misschien juist als type


5-11

Fase 1: Voorbereiding indirecte communicatie. * Voor alle velden: ◦ voor alle indirecte communicatiepaden die worden gebruikt (afhankelijk van interpolatiemethode, en de relatie tussen twee buurdomeinen): – alloceer werkarray met geschikte structuur; – kopiëer eigen veldwaardes naar tijdelijk opslagformaat. Fase 2: Versturen van informatie. * Voor alle buren: ◦ voor alle velden: – voor alle communicatiepaden (direct, indirect): - zoek uit welke stukken coëfficiëntensets er verstuurd moeten worden, pak deze in. - zoek uit welke veldwaardes verstuurd moeten worden, pak deze in. ◦ verstuur complete boodschap Fase 3: Ontvangen/verwerken van informatie. * Voor alle binnenkomende boodschappen/buren: ◦ voor alle velden: – voor alle communicatiepaden (direct, indirect): - pak de informatie uit - verwerk de informatie (met/zonder interpolatie) en plaats de resultaten op de gewenste plaats Fase 4: Uitvoeren uitgestelde interpolaties * Voor alle velden: ◦ voor alle communicatiepaden (direct, indirect) waarvoor horizontale interpolatie wordt gevraagd: – voer de gewenste horizontale interpolatie uit. Fase 5: Afronding indirecte communicatie. * Voor alle velden waarvoor indirecte communicatie wordt gebruikt: ◦ kopiëer ontvangen/berekende waardes van tijdelijk array naar eigen veldarray. ◦ vernietig de tijdelijke opslagstructuur. Figuur 5.1: Indeling van de update-operatie in vijf fases en uitgevoerde bewerkingen per fase.


rekenrooster domein 1

globaal fysisch rooster

5-12

rekenrooster domein 2

Figuur 5.2: Een koppeling die voor verwarring kan zorgen: volgens het linker domein ligt de bovenste interface rechts van de onderste, en volgens het rechter domein is het andersom. II interpolatie worden uitgevoerd. Verder is het voor de basisoperaties niet nodig om te eisen dat ze van een index set naar dezelfde index set werken (type III). In plaats daarvan is het gewenst om ze zo te implementeren dat er ook tussen twee verschillende sets kan worden ge¨ınterpoleerd. Het benodigde tijdelijk opslagformaat voor indirecte communicatie wordt samen met de te gebruiken reshape-operatie gespecificeerd door de relatietabel die moet worden toegepast. In principe kunnen er meerdere tijdelijke formaten worden gebruikt als er met verschillende soorten van buren wordt gecommuniceerd, dit leidt dan tot meerdere paden door de updateoperatie. Dit wordt nog niet ondersteund, omdat er nog geen toepassing voor is en omdat nog niet duidelijk is hoe je de verschillende paden zou willen configureren. Vooralsnog is er daarom slechts een enkel pad voor indirecte communicatie, worden alle DDHOR interpolatiepunten (−1 in POWNER) via dit pad geupdated en alle parallelle en DDVERT “kopiëerpunten” (p > 0 in POWNER) via directe communicatie behandeld. Het is in principe mogelijk om in geval van horizontaal 1:1 aansluitende roosters van verschillende DDHOR-domeinen het pad van directe communicatie te gebruiken (kopiëren i.p.v. horizontale interpolatie). De van een buurdomein ontvangen waardes kunnen direct vertikaal worden ge¨ınterpoleerd en in het eigen veldarray worden geplaatst. Een moeilijkheid hierbij is echter wel dat de ordening van roosterpunten per deeldomein kan verschillen, zie Figuur 5.2. Daarom kan een rekenproces in dit geval niet voor de ander bepalen wat hij gaat versturen in welke volgorde, terwijl dat voor (parallelle/DDVERT) buren uit hetzelfde rekenrooster wel wordt gedaan. Dit is oplosbaar door de initialisatie van interfaces te veranderen, door hierbij te communiceren in plaats van redundant uit te rekenen. Daarmee is aangetoond dat de gebruiker kan sturen in wat hij via welk pad door de update wil laten uitwisselen, en dus ook dat het zin heeft om meerdere paden voor indirecte communicatie toe te staan.


5.10

5-13

Invulling van communicatie-interfaces

De gebruikte communicatie-interface (“stencil”) wordt van oudsher als aparte parameter aan de update-operatie doorgegeven: call update(array, ’indexset’, ’interface’, ’conv.meth’) Dit is praktisch omdat de interface en de conversiemethode min of meer “orthogonale” aspecten zijn; voor de gebruiker is het prettig om iedere interface en methode slechts een keer te hoeven specificeren en dan in willekeurige combinaties te kunnen gebruiken. Intern in COCLIB worden er echter wel per combinatie aparte verstuur- en ontvangtabellen aangemaakt. Het gebruikte stencil bepaalt daarbij welke guardbandpunten van het eigen rooster moeten worden vervangen, de interpolatiemethode bepaalt welke waardes hiervoor moeten worden verstuurd en ontvangen. Deze drie aspecten samen definiëren een complete interface. Merk op dat het daadwerkelijk versturen en ontvangen alleen bestaat uit kopiëren van waardes, terwijl er bij het interpoleren alleen gegevens gebruikt worden uit arrays van het rekenproces zelf. Bij het kopiëren (versturen/ontvangen) is eigenaarschap een relevant concept, bij het interpoleren is juist alleen de status van roosterpunten van belang. De gebruikte interface kan worden gezien als de configuratie van fase 2 van de updateoperatie. Deze configuratie moet in principe voor ieder pad door de update apart worden gedaan, de update moet weten welk gedeelte van het tijdelijk opslagformaat moet worden ververst, en welk gedeelte hiervoor moet worden verstuurd en ontvangen. Deze informatie wordt nu op de volgende manier geconfigureerd: 1. de gebruiker specificeert het vervanggebied op de veld-indexset aan de hand van een stencil. Dit gebied valt uiteen in twee stukken: de ontvanggebieden per buurproces p > 0 en de interpolatiepunten (−1) van het vervanggebied. Met het stencil worden ook de verstuurgebieden van de veld-indexset per buurproces p > 0 bepaald; 2. het interpolatiegedeelte van het vervanggebied wordt bij eerste gebruik van een bepaalde interface overgezet (gereshaped) naar het vervanggebied op het tijdelijk opslagformaat; 3. aan de hand van de interactiestructuur van de gebruikte (enkelvoudige) type III interpolatiemethode bepaalt ieder rekenproces welke waardes van buurprocessen hij nodig gaat hebben: het ontvanggebied op het tijdelijk opslagformaat; 4. de ontvanggebieden worden gecommuniceerd, een proces stuurt aan zijn buren voor welke indices waardes moeten worden gecommuniceerd. Hierbij wordt het eigenaarschap van punten van het tijdelijk opslagformaat gebruikt. Dit levert voor ieder buurproces het verstuurgebied op het tijdelijk opslagformaat. In de stappen 2, 3 en 4 wordt een communicatie-interface ingevuld voor het tijdelijke opslagformaat. De belangrijkste reden om bij het construeren van interfaces op het tijdelijke opslagformaat communicatie te gebruiken is dat het ene proces niet kan bepalen welke waardes de ander wil


5-14

gaan gebruiken voor een interpolatiepunt. De interactiestructuur wordt namelijk voor diverse interpolatiemethodes (bijv. bilineair) bepaald via een zoekproces. Het resultaat hiervan hangt af van welke punten er precies in de tijdelijke opslagstructuur zijn opgenomen, en dit verschilt per rekenproces. Dit is gekoppeld aan het gebruik van Type III (uitgestelde) interpolaties, die in dezelfde richting werken als waarin de roosteropdeling is gespecificeerd. Wat interessant is om op te merken is dat er in geval van Type II (directe) interpolaties niet de “echte” interface in COCLIB wordt opgeslagen. Bijvoorbeeld bij verikale verfijning “weet” de interface van het ene rekenproces niet hoeveel lagen er in het andere proces worden gebruikt, maar wordt dit pas in een later stadium ingevuld. Een andere manier om dit te beschrijven is dat de echte interface een deelverzameling is van een index set die niet in COCLIB is geregistreerd. In het verlengde hiervan kan directe communicatie worden beschouwd als “ik weet niets van de ander zijn array-dimensie, en wil er eigenlijk ook niets van zien”. De gebruiker specificeert alleen dat er wordt ge¨ınterpoleerd op een bepaalde array-dimensie en welke methode en coefficiëntenset daarbij worden gebruikt, de rest gebeurt onder water. Dit is voor de gebruiker zeer gemakkelijk, maar kan alleen als de interpolatie-richting orthogonaal staat op de richting waarin wordt gecommuniceerd. De ontvangen data kunnen namelijk niet worden gebufferd in een tijdelijk opslagformaat en dus moet er voor de hele ge¨ınterpoleerde arraydimensie worden gecommuniceerd met hetzelfde proces.

5.11

Glossary

In de voorgaande paragrafen zijn een groot aantal concepten ge¨ıntroduceerd die binnen COCLIB of de domein-decompositieversie van WAQUA/TRIWAQ een specifieke betekenis hebben. Hieronder wordt getracht dit zo goed mogelijk weer te geven. index set ... interface ...

5.12

Verdere uitbreidingen

• meerdere logische rekenprocessen per fysiek Unix proces/thread • uitgangspunten voor de technische realisatie: – aansturing van gebruikersroutines met strings als enorm prettig mechanisme - gebruiksgemak; – het gebruik van object oriëntatie in de implementatie - beheersbaarheid, uitbreidbaarheid.


5-15

• op welke index set moeten coëfficiëntensets leven, hoe worden ze opgeslagen, m.n. bij gebruik van directe en indirecte communicatie. Punten uit overlap en uit fullbox, motherchild coefsets, of twee aparte coefsets? → uitdaging voor DDH+V project. • hoe weet COCLIB wat er van een coëfficiëntenset moet worden gecommuniceerd - kun je z’n maximale interface automatisch laten construeren? → gemaakte keuzes beschrijven/motiveren bij technische uitwerking van coëfficiëntensets. • welke maskers spelen er allemaal een rol bij het definiëren van index sets, interfaces en interpolatiemethodes, en worden er nog andere maskers binnen COCLIB gebruikt? → uitdaging voor de technische documentatie van COCLIB. • hoe kan gebruiker aangeven welke van de drie stappen (ijlheid, gewichten, matrix-vector) er moeten worden uitgevoerd? niet-verversbare coefsets, nieuwe maskers maar interactiepatroon handhaven, ... → uitdaging voor verdere ontwikkeling van COCLIB. • wat is een generieke manier van bootstrappen van index sets, interfaces e.d. zonder gebruik van informatie van de context, en welke bouwstenen volgen hieruit? → uitdaging voor de verbetering van de interne structuur van COCLIB. → meer inzicht == flexibeler, gemakkelijker aan te passen voor nieuwe situaties. • hoe zou je een programmeerbare update kunnen maken, waarin bijvoorbeeld eerst uit coëfficiënten sep, hlay, e.d. de coëfficiënten zks worden berekend, die dan daarna in interpolatiegewichten worden verwerkt? Hoe ga je om met het maken en opruimen van werkruimte?


6-1

Hoofdstuk 6 Detail ontwerp aanpassingen WAQPRO 6.1

Inleiding

In Hoofdstuk 4 is een overzicht gegeven van de manier waarop domein decompositie is geimplementeerd in WAQUA/TRIWAQ. Die manier kan kort worden samengevat als • het gekoppeld simuleren van verschillende roosters of domeinen, eventueel verdeeld in meerdere deeldomeinen, • het toevoegen van een guardband van kopiëer- en interpolatiepunten rondom ieder (deel)-domein, het invullen van waardes in de guardband middels communicatie en interpolatie, en • het discretiseren van de PDV’en in discretisatiepunten nabij domein decompositie interfaces met de gewone discretisatiestencils met gebruik van waardes uit de guardband. De snelheidspunten op de interface zijn steeds eigendom van het fijnst verroosterde van de twee naburige domeinen, en massabehoud wordt gegarandeerd door eenduidige definitie van fluxen op de interface. De iteratieve procedures zijn meestal direct gerelateerd aan de methodes die in sequentiëel WAQUA/TRIWAQ worden gebruikt. Speciale technieken zijn ontwikkeld voor de continu¨ıteitsvergelijking (methode van uitgaande informatie), voor het oplossen van tri-/pentadiagonale stelsels voor rijen van het grid (BJ-TWGE), en voor het garanderen van massabehoud (fluxcorrectieschema). In dit hoofdstuk wordt deze strategie in meer detail uitgewerkt. De complete discretisatiestencils worden gespecificeerd voor alle solvers in WAQUA/TRIWAQ, en alle gebruikte interpolatiemethoden worden in detail toegelicht. De iteratieve procedures worden uitgewerkt waar nodig, inclusief lastige details zoals het kleuren van rijen of het bepalen van de globale rijnummers. Vervolgens worden de gebruikte index sets en communicatie-interfaces toegelicht. Ook is er aandacht voor de administratie van verzamelingen van roosterpunten. Deze administratie is in het project DDHOR+VERT ingrijpend gewijzigd, omdat voortgaan met de tot dan gebruikte methode zou leiden tot zeer gecompliceerde code.

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) k =

+

6-2 = k +

=

k

: : :

kfu/up kfv/vp sep

Figuur 6.1: Discretisatiestencil voor de continu¨ıteitsvergelijking in WAQUA en TRIWAQ (subroutine trssuw). |

| =

=

k + k

=

k + k

=

= |

= k + |

: : : :

khu/up khv/vp sep khv

|

Figuur 6.2: Discretisatiestencil voor de u-impulsvergelijking in de eerste halve tijdstap in WAQUA (subroutine trssuw).

6.2

Details van de discretisaties

De discretisaties nabij en op de interfaces tussen verschillende domeinen worden verkregen door de gewone veld-discretisaties toe te passen, waarbij voor een aantal omringende roosterpunten informatie wordt gebruikt uit de guardband, die wordt verkregen vanuit een ander (deel-)domein. De verzameling van roosterpunten die gebruikt worden bij de discretisatie van een differentiaalvergelijking in een bepaald punt wordt het discretisatiestencil genoemd. De discretisatiestencils per berekening bevatten essentiële informatie ten aanzien van de vereiste communicaties. In de Figuren 6.1 tot en met 6.7 worden de stencils uitgewerkt voor de discretisaties van de continu¨ıteits-, impuls- en transportvergelijkingen in WAQUA en TRIWAQ. Als hulpmiddel bij de interpretatie van deze figuren wordt in Figuur 4.1 een klein stukje van een gestructureerd rooster getoond met daarbij de gehanteerde conventie voor afbeelding van het versprongen rooster naar array indices. Het middelste punt in de stencils is het punt waar de vergelijking wordt benaderd. Dit punt is steeds gemarkeerd door er een wat groter teken in te zetten. In de figuren 6.1 tot en met 6.7 is te zien dat de grootste stencils worden gebruikt in het transportgedeelte van TRIWAQ. Deze stencils zorgen dat de guardband tenminste drie rijen en kolommen van roostercellen rond het eigen deeldomein moet bevatten (merk op dat het stencil alleen wordt getoond voor de eerste helft van de tijdstap, in de tweede halve tijdstap is het stencil zeven hoog in de y-richting). Dit komt door de gebruikte hogere orde differentieformules voor de transportfluxen. Deze stencils zijn bepalend voor de benodigde extra ruimte in arrays, de breedte van de guardband.


6-3

= |

| =

=

k + k

=

k + k

= k + |

=

= |

: : : :

khu/up khv/vp sep khv

| =

Figuur 6.3: Discretisatiestencil voor de u-impulsvergelijking in de tweede halve tijdstap in WAQUA (subroutine trscue). = =

k + k

=

k + k

= k +

=

: : :

kfu/up kfv/vp sep

=

Figuur 6.4: Stencil voor discretisatie van de u-impulsvergelijking in de eerste halve tijdstap in TRIWAQ (subroutine trssuw). = |

| =

=

=

k + k

=

k + k

=

=

= |

= k + |

: : : :

kfu/up kfv/vp sep kfv

| =

Figuur 6.5: Discretisatiestencil voor de u-impulsvergelijking in de tweede halve tijdstap in TRIWAQ (subroutine trscue). + k +

-

+

=

+ k +

=

+

-

+

= k + -

: : : :

khu/qx khv/qy rp khu

Figuur 6.6: Discretisatiestencil voor de transportvergelijking in de eerste halve tijdstap in WAQUA (subroutine trsdif).

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) + k +

-

+

-

+

=

+

=

+

-

+

-

+

k +

6-4

= k + -

: : : :

khu/qxk khv/qyk rp khu

Figuur 6.7: Discretisatiestencil voor de transportvergelijking in de eerste halve tijdstap in TRIWAQ (subroutine trsdif).

6.3

Details van de horizontale interpolatiemethodes

Voor het realiseren van interpolaties van 3D velden in geval van horizontale èn vertikale verfijning bij een interface kiezen we ervoor om steeds eerst vertikaal te interpoleren en daarna horizontaal te interpoleren. Dat is praktisch omdat een subdomein bij vertikale interpolatie steeds slechts te maken heeft met een enkel buurdomein, terwijl er bij horizontale interpolaties informatie van meerdere buren nodig kan zijn. In het eerste geval kan dus direct na het ontvangen van een boodschap worden ge¨ınterpoleerd, in het tweede geval moet worden gewacht totdat alle boodschappen binnen zijn. Zie het onderscheid tussen “type II interpolatie” en “type III interpolatie” in paragraaf 5.9. Verder levert het scheiden van horizontale en vertikale interpolaties op zich geen verlies van nauwkeurigheid op. In deze paragraaf werken we de verschillende interpolatiemethodes uit die in COCLIB zijn ge¨ımplementeerd en in WAQUA/TRIWAQ worden gebruikt.

6.3.1

Bilineaire interpolatie

Een bekende interpolatiemethode voor 2D velden is bilineaire interpolatie. In deze methode worden de gegeven discretisatiewaardes beschouwd als samples in de overeenkomstige discretisatiepunten. Hiermee is de methode geschikt voor allerlei grootheden zoals waterstanden, stroomsnelheden, transportconcentraties e.d. Voor vier waardes f1 , .., f4 opgegeven in de hoekpunten (0,0), (0,1), (1,0) en (1,1) van een eenheidsvierkant wordt de volgende interpolatieformule gebruikt: f (x, y) = (1 − x)(1 − y)f1 + x(1 − y)f2 + (1 − x)yf3 + xyf4

(6.1)

Bij de toepassing van deze methode in WAQUA/TRIWAQ moeten diverse keuzes worden gemaakt: • van welke coördinaten wordt uitgegaan? • welke discretisatiepunten worden gebruikt voor een interpolatiepunt? • hoe wordt omgegaan met niet-rechthoekige bronroostercellen? • hoe wordt omgegaan met interpolatiepunten buiten het bronrooster? • welke randvoorwaarden moeten worden meegenomen?


6-5

De eerste vraag hangt samen met het gebruik van kromlijnige rekenroosters. De coördinaten die bij het interpoleren kunnen worden gebruikt zijn de fysische (x, y)-coördinaten van het kromlijnige rooster en de logische (ξ, η)-coördinaten van roosterpunten. Er wordt voor gekozen om de laatsten als uitgangspunt te nemen. Hierbij kan het namelijk eenvoudiger zijn om eventueel optredende numerieke problemen op te sporen en te verhelpen, omdat de berekeningen gemakkelijker met de hand kunnen worden nagerekend. Verder is het gebruik van logische coördinaten vooral voordelig voor de andere interpolatiemethodes. Een aantal effecten van de kromming van de echte rekenroosters wordt hiermee verwaarloosd ten behoeve van een vereenvoudiging van de programmatuur. De achtergrond van de andere vragen wordt ge¨ıllustreerd in Figuur 4.5. In de situatie van de linker figuur ligt het niet voor de hand om van het fijne domein de waterstanden van de tweede en vijfde getekende rij te gebruiken voor het getekende interpolatiepunt. Het lijkt ook niet gewenst om van het fijne domein alleen de waarde van de vierde rij van onderen te gebruiken. Dat zou betekenen dat er speciale betekenis wordt toegekend aan de ξ- en η-coordinaatassen, waarmee de interpolatiemethode minder geschikt wordt voor rekenroosters die niet precies langs de assen van het coördinatenstelsel zijn gericht. Het wordt dan bijvoorbeeld moeilijker om over te schakelen op het gebruiken van fysische (x, y)-coördinaten in plaats van de logische coördinaten. Daarom wordt gekozen voor de strategie om “de vier dichtstbijzijnde omliggende discretisatiepunten” te gebruiken. De omgeving van een interpolatiepunt wordt hiervoor in vier kwadranten verdeeld: xdiscr < xintpol versus xdiscr ≥ xintpol ,

ydiscr < yintpol versus ydiscr ≥ yintpol

(6.2)

Per kwadrant wordt het dichtstbijzijnde discretisatiepunt geselecteerd, als dit tenminste niet verder weg ligt dan een in te stellen maximale afstand. In de situatie van het linker gedeelte van Figuur 4.5 geeft dit de derde en vierde rij van het fijne domein. In de figuur is nu direct te zien dat de beschreven strategie voor het selecteren van vier discretisatiepunten geen rechthoek hoeft op te leveren, zodat formule (6.1) niet direct toepasbaar is. In plaats daarvan worden de interpolatiegewichten bepaald door het oplossen van een kwadratische vergelijking die min of meer correspondeert met de afbeelding van de vierhoek op een vierkant. Het rechter gedeelte van Figuur 4.5 illustreert de vierde vraag over implementatie van de bilineaire methode. Voor het met rood getekende interpolatiepunt worden er slechts twee discretisatiepunten gevonden: het punt in de onderste rij van het fijne domein ligt in kwadrant “links-boven”, het discretisatiepunt van het grove domein in kwadrant “rechts-boven”. In dit geval wordt het interpolatiepunt geprojecteerd op de verbindingslijn tussen de twee punten en wordt er lineair ge¨ınterpoleerd op de verbindingslijn. In geval van drie discretisatiepunten wordt lineaire interpolatie toegepast op de overeenkomstige driehoek, en in geval van een enkel discretisatiepunt wordt de waarde daarvan gekopiëerd. Deze regels zorgen ervoor dat de interpolatiewaarde nooit groter en kleiner dan de grootste resp. kleinste betrokken discretisatiewaardes kan worden, dat er nooit extrapolatie wordt toegepast. Tenslotte wordt opgemerkt dat er bij de randen van het simulatiedomein zoals in het rechter gedeelte van Figuur 4.5 nog extra roosterpunten zijn die in WAQUA/TRIWAQ worden


6-6

gebruikt voor de randafhandeling. Op de plaats van de schuine streepjes is er nog een rij van extra waterstandspunten waarvan evident is dat de waardes niet in interpolaties moeten worden gebruikt. Hetzelfde geldt eigenlijk voor drooggevallen cellen: bij diverse testen met de eerste complete versie van DDHOR is gebleken dat het meenemen van waterstanden en concentraties in deze punten leidt tot ongewenste effecten, bijvoorbeeld instabiliteiten. De verzamelingen van roosterpunten die mogen worden meegenomen in interpolaties moeten dus tijdsafhankelijk worden gemaakt. Voor de stroomsnelheden is het veel minder duidelijk of/welke randpunten moeten worden meegenomen: de v-snelheid is nul op de rand en het lijkt voordelig om dit mee te nemen in de interpolaties. De randpunten voor de u-snelheid (onder de eerste getekende rij van roostercellen) moeten daarentegen weer niet worden gebruikt in de interpolaties, dit zou een kunstmatige grenslaag opleveren. Een complicatie is nu dat een enkel randpunt bij een diagonale rand nu zowel een buurpunt kan zijn van een interpolatiepunt in de stroomrichting als van een interpolatiepunt in de dwarsrichting. Daarvoor wordt als regel gebruikt om snelheidspunten n`ıet mee te nemen als ze tussen twee rand-waterstandspunten liggen en anders wèl mee te nemen in interpolaties.

6.3.2

Implementatie van bilineaire interpolatie in COCLIB

In de vorige paragraaf is aangegeven welke wiskundige complicaties er optreden bij het uitwerken van de op zichzelf eenvoudige bilineaire interpolatiemethode, en hoe daarmee wordt omgegaan. Een heel ander soort problemen komt op bij het op een generieke manier implementeren van de methode. Vragen die hierbij voorkomen zijn: • hoe zijn de verzamelingen van discretisatie- en interpolatiepunten in de computer gerepresenteerd ? • hoe zijn de benodigde coördinaten opgeslagen ? • welke maskers kan de gebruiker opgeven en hoe gaat dat ? Deze vragen betreffen in algemene zin de gebruikersvriendelijkheid en configureerbaarheid van de interpolatiemethode. In Hoofdstuk 5 is beschreven dat arrays in COCLIB worden beschreven met index sets en dat interpolatiemethodes worden gevormd door basisoperaties te combineren met coëfficientensets. Een algemeen stramien voor basisoperaties is dat er een bronarray is met discretisatiewaardes, een doelarray voor de ge¨ınterpoleerde waardes, en verdere arrays met maskers en coëfficiënten. Bij het gebruik van de update-operatie is relevant dat er bij horizontale verfijning gebruik wordt gemaakt van een tijdelijk opslagformaat waar de gebruiker weinig bemoeienis mee wil hebben. In dat geval wil de gebruiker de maskers en coëfficiënten graag aanleveren in andersoortige arrays dan dat in de interpolatie wordt gebruikt. Dat kan als er een relatietabel bestaat waarmee gegevens uit het ene soort array kunnen worden overgezet naar een andere soort. Daarentegen is het tijdelijk opslagformaat zodanig groot gekozen dat er steeds slechts


6-7

een enkel array nodig is voor de bron- en doelwaardes van de interpolatie. Dit geldt voor alle type-III implementaties die voor DDHOR zijn ontwikkeld. Al met al omvat de configuratie van een bilineaire interpolatiemethode in COCLIB de volgende aspecten: • de naam mthnam waarmee de methode later kan worden opgevraagd; • de naam setnam van de index set waarop de methode wordt gedefiniëerd. Deze index set bevat zowel de interpolatiepunten waarin waardes moeten worden berekend als de discretisatiepunten waarin waardes beschikbaar zijn. Dit is voldoende zolang de methode alleen binnen de update-operatie wordt gebruikt, maar staat bijvoorbeeld wel het gebruik voor interpolatie van het wind- naar het WAQUA-rooster in de weg. In de toekomst zouden er daarom aparte index sets voor discretisatie- en interpolatiepunten kunnen worden onderscheiden; • het tijdsonafhankelijke masker mskdis dat aangeeft welke punten van de index set discretisatiepunten zijn die mogen worden gebruikt in interpolaties. Je zou hier ook de naam van een integer coëfficiëntenset kunnen opgeven en hiermee tijdsafhankelijke maskers kunnen gaan ondersteunen; • het masker mskint dat aanduidt welke punten van de index set interpolatiepunten zijn waarin waardes moeten kunnen worden berekend; • de naam setmsk van de index set die de maskerarrays beschrijft. Deze hoeft niet gelijk te zijn aan de index set waarop de methode wordt gedefiniëerd, als de maskers maar kunnen worden geconverteerd naar die laatste index set; • de naam st2msk van de relatietabel die wordt gebruikt voor het converteren van maskerarrays (relatie van setnam naar setmsk). Het “reshapen” van de maskers wordt nu door de interpolatieroutine cocbil gedaan, maar zou ook met geschikte gebruikersroutines door de gebruiker kunnen worden uitgevoerd; • de naam itfnam van een communicatie-interface op setnam waarmee rekenprocessen de benodigde discretisatiepunten aan elkaar kunnen doorgeven. Deze interface hoort niet echt bij de interpolatiemethode maar is meer een onderdeel van de configuratie van de update-operatie. Op termijn zou ze daarom ergens anders kunnen worden ondergebracht; • de naam cfclsz van een coëfficiëntenset die de grootte van roostercellen aanduidt, die wordt gebruikt in het criterium dat aangeeft of discretisatiepunten te ver weg liggen; • de namen cfmcor, cfncor, cfxcor en cfycor van de m-, n-, x- en y-coördinaten van alle punten in setnam. De (m, n)-coördinaten worden gebruikt in het bepalen van de omliggende vier punten (interactiepatroon) en de (x, y)-coördinaten bij het berekenen van interpolatiegewichten. In WAQUA/TRIWAQ worden voor zowel m als x de logische m-coördinaten opgegeven, analoog n en y. Het is onduidelijk waarom m en x in de


6-8

basisoperatie worden onderscheiden. In plaats daarvan zouden alleen x en y moeten worden gebruikt (de implementatie is geschikt voor het gebruik van fysische coördinaten) en zou WAQUA/TRIWAQ hiervoor m en n kunnen invullen. De bilineaire operatie wordt ge¨ımplementeerd door de routines cocbil (registreren van de methode), cocamg (bepalen interactiepatroon) en cocibl (bepalen gewichten).

6.3.3

Celgemiddelde interpolatie

De waterstanden en transportconcentraties in WAQUA/TRIWAQ kunnen worden beschouwd als de gemiddelde waarde over een roostercel. Uit deze interpretatie kan op een eenvoudige manier een interpolatiemethode worden geconstrueerd. Namelijk door net te doen alsof de waterstand of de concentratie overal in een cel de gemiddelde waarde heeft. Dit levert een stuksgewijs constante functie op, waarvan de gemiddelde waarde in een interpolatie-roostercel kan worden bepaald via integratie. Een complicatie die op kan treden bij de uitwerking van dit principe is dat interpolatiecellen niet geheel hoeven te worden overdekt door discretisatiecellen. Verschillende manieren om hiermee om te gaan zijn om iets te verzinnen voor de bronfunctie (bijvoorbeeld 0) of dit gedeelte te negeren bij het berekenen van het gemiddelde. In COCLIB wordt het laatste gedaan, en als er totaal geen discretisatiecellen overlappen met een interpolatiecel dan wordt de arraywaarde voor het interpolatiepunt niet overschreven. Een tweede probleem ontstaat als er verschillende discretisatiecellen kunnen zijn die met elkaar overlappen. Dit wordt momenteel niet afgevangen. Het wordt als het goed is uitgesloten door de manier waarop coördinaten van cellen worden opgegeven: door vier waardes [xlow , xhigh ] × [ylow , yhigh ]. Voor deze (x, y)-coördinaten worden steeds de logische (m, n)-coordinaten van cellen gebruikt ten opzichte van het eigen domein. Een derde moeilijkheid zit in de bepaling van oppervlaktes als de cellen niet rechthoekig zijn. Dit wordt in COCLIB opgevangen door een coefficientenset met gewichten aan te bieden aan de COCLIB-gebruiker bij het aanmaken van een celgemiddelde interpolatiemethode. Hiervoor wordt in WAQUA de coefficientenset gsqs gedefiniëerd. Deze coëfficiënten worden als weegfactoren in de interpolatie gebruikt. Deze gewichten kunnen in principe ook worden gebruikt voor het meenemen van verschillen in de waterdieptes (volumes) per roostercel bij het interpoleren van transportconcentraties. Deze volumes zijn echter tijdsafhankelijk en leiden daarmee tot het steeds moeten communiceren van coëfficiënten en herberekenen van interpolatiegewichten. De formule die in de celgemiddelde interpolatie wordt gebruikt is als volgt: fiintpol =

X j∈J(i)

wj fjdiscr /

X

wj

(6.3)

j∈J(i)

Hierin staat f discr voor de input-array met discretisatiewaardes en f intpol voor de berekende waardes in interpolatiepunten. De verzameling J(i) staat voor alle discretisatiecellen die geheel of gedeeltelijk overlappen met interpolatiecel i. De variabele wj staat tenslotte voor het door de gebruiker toegekende gewicht aan discretisatiecel j. Merk op dat deze formule zelf


6-9

Figuur 6.8: de berekende snelheid kan worden gezien als de gemiddelde stroomsnelheid over het aangegeven vlak: de cellface. niet verwijst naar cellen, en dus ook voor andere gewogen gemiddeldes kan worden gebruikt. Dat de basisoperatie wel beperkt is tot cellen hangt samen met de manier waarop de coordinaten moeten worden opgegeven en met de manier waarop de verzamelingen J(i) worden bepaald. De celgemiddelde operatie is ge¨ımplementeerd in de routines coccel (registreren van de methode), cocscl (bepalen overlappende cellen) en cocwgs (berekenen formule (6.3)). De implementatie van de celgemiddelde operatie is op dezelfde manier gericht op de update-operatie als de bilineaire operatie. Er wordt dus uitgegaan van een enkele index set waarin zowel de discretisatie- als interpolatiepunten staan, en van coëfficiëntensets die direct op deze index set zijn gedefiniëerd. De variabelen die moeten worden opgegeven voor het configureren van deze methode zijn: • methodenaam mthnam, index-setnaam setnam, maskers mskdis en mskitp, index-setnaam setmsk en relatietabel st2msk, interfacenaam itfnam: zie beschrijving bij bilineaire operatie; • de namen cfmlft, cfmrgt, cfnbot en cfntop van de coëfficiëntensets met (m, n)-coordinaten van de linker-, rechter-, onderen bovenzijdes van roostercellen. Hier zou beter van x en y kunnen worden gesproken; • de naam cfwght van de coëfficiëntenset met de gewichten per (discretisatie)roostercel.

6.3.4

Cellfacegemiddelde interpolatie

Berekende snelheden kunnen worden beschouwd als samples, maar ook als cellface-gemiddelde waarden. Dat wil zeggen dat de snelheid de gemiddelde snelheid is over een zijwand van een controlevolume, zie Figuur 6.8. In dat geval is het logisch om een interpolatiemethode te gebruiken waarin de snelheid wordt behandeld alsof hij constant is per cellface. Voor de interpolatie naar een cellface die tussen twee discretisatie-cellfaces in ligt, ligt lineaire interpolatie voor de hand (zie Figuur 4.6). Merk op dat deze methode in principe is gebaseerd


6-10

op rechtlijnige roosters. Ze wordt in WAQUA/TRIWAQ ook voor kromlijnige roosters gebruikt door de logische (m, n)-coördinaten als uitgangspunt te nemen in plaats van de echte (x, y)-coördinaten. De formule die wordt gebruikt bij de cellface-gemiddelde interpolatie is als volgt: fiintpol = α ·

X

wj fjdiscr /

X

wj + β ·

X

wj fjdiscr /

X

wj j∈Jright (i)

(6.4a)

α = (xright − xi )/(xright − xlef t ), β = (xi − xlef t )/(xright − xlef t )

(6.4b)

j∈Jlef t (i)

j∈Jlef t (i)

j∈Jright (i)

Wat er gebeurt is dat er wordt gezocht naar de discretisatie-cellfaces Jlef t (i) en Jright (i) die links en rechts van de interpolatiecellface i het dichtste bij liggen en die in y-richting overlappen met cellface i. Er worden twee gewogen gemiddeldes uitgerekend voor de cellfaces links en de cellfaces rechts, met door de gebruiker opgegeven gewichten wj . Tenslotte wordt lineair ge¨ınterpoleerd tussen deze twee waardes met coëfficiënten α en β = 1 − α. Vanwege deze procedure wordt de interpolatiemethode ook wel linear-on-weighted-average en lin(weigh) genoemd. Verschillende gevallen die speciaal worden behandeld zijn als volgt: • als xi praktisch samenvalt met de x-coördinaat van een of meer cellfaces met een overlap in y-richting (minder dan 1 · 10−5 verschil), dan wordt/worden deze cellface(s) ingedeeld in verzameling Jlef t (i) en wordt α = 1, β = 0 gesteld. • als er geen cellfaces links of rechts van een interpolatiecellface i worden gevonden dan is Jlef t of Jright leeg, en wordt ofwel α = 1, β = 0, ofwel α = 0, β = 1 gesteld. • als er totaal geen discretisatiecellfaces bij een interpolatiepunt worden gevonden dan wordt de waarde in het interpolatiepunt niet veranderd. Deze interpolatiemethode is ge¨ımplementeerd in de subroutines coccfl (registreren van de methode), cocfcs (bepalen interactiepatroon) en cocwgl (gewichten voor “lin(weigh)” operatie). De argumenten van coccfl zijn: • methodenaam mthnam, index-setnaam setnam, maskers mskdis en mskitp, index-setnaam setmsk en relatietabel st2msk, interfacenaam itfnam: zie beschrijving bij bilineaire operatie; • de namen cfmrgt, cfnbot en cfntop van de coëfficiëntensets met de m-coördinaat en n-coördinaten onder/boven van cellfaces. Hier zou beter van x en y kunnen worden gesproken; • de naam cfmlft van de coëfficiëntenset met de m-coördinaat van de direct links van iedere cellface gelegen cellface. Deze coördinaat wordt gebruikt om een maximale afstand te bepalen voor cellfaces die mogen worden meegenomen in interpolaties. • de naam cfwght van de coëfficiëntenset met de gewichten per (discretisatie)cellface.


6.3.5

6-11

Maximum-interpolatie en som-interpolatie

Bij alle interpolatiemethodes die worden gedefiniëerd met de routines cocbil, coccel en coccfl kunnen afgeleide methodes worden gemaakt. De eerste afgeleide methode is de “maximum-interpolatie” waarbij de ge¨ınterpoleerde waarde gelijk is aan het maximum van alle gebruikte discretisatiewaardes. In geval van de celgemiddelde interpolatiemethode is dit fiintpol = max fjdiscr

(6.5)

j∈J(i)

In geval van celfacegemiddelde interpolatie levert de max-methode de volgende formule: fiintpol =

max

j∈Jlef t (i)∪Jright (i)

fjdiscr

(6.6)

De maximum-operatie neemt dus het interactiepatroon van een bestaande methode en kijkt verder totaal niet naar de gewichten die daarop zijn gedefiniëerd. Deze methode is vooral van belang voor de interpolatie van schotjes, waarbij er in het grove domein alleen dan een schotje mag worden geplaatst als alle overeenkomstige cellfaces in het fijne domein zijn afgesloten. Daarnaast wordt de maximum-operatie gebruikt om te bepalen welke rijen van het rekenrooster met elkaar samenhangen in de solver voor de continu¨ıteitsvergelijking. De som-operatie is analoog gedefiniëerd, en geeft de som van alle discretisatiewaardes die voorkomen in een eerder gedefiniëerd interactiepatroon. Deze methode wordt gebruikt om debieten en transportfluxen op de interfaces tussen domeinen te kunnen communiceren van het fijne naar het grove domein. Daarvoor wordt eerst een “lin(weigh)”-methode gedefiniëerd, deze heeft op de interface precies het gewenste interactiepatroon, en dan worden de gewichten uitgeschakeld.

6.4 6.4.1

Details van de vertikale interpolatiemethodes Nieuwe basismethodes voor vertikale interpolatie in DDH+V

Een flinke aanpassing in de vertikale interpolatiemethoden is nodig geweest omdat het vertikaal interpoleren gebruik maakt van coëfficiëntensets die werden aangeleverd op horizontaal verschillende roosters. Dit wordt ge¨ıllustreerd in Figuur 6.9 waarin een interface wordt getoond met horizontaal 1 : 2 verfijning en vertikaal een sigma-vast koppeling. Het probleem bij de communicatie in dit geval is dat de vertikale interpolatie momenteel is gebaseerd op de actuele, ruimtelijk variabele z-coördinaten op beide roosters, terwijl de punten waarvoor moet worden ge¨ınterpoleerd niet in beide roosters voorkomen. Als bijvoorbeeld het fijne domein voor een van de vier punten zijn zout-concentraties verstuurt in alle drie de lagen, dan weet het grove domein niet welke weging hierbij moet worden toegepast. Hetzelfde speelt bij communicatie van fluxen (totalen) van het grove domein naar het fijne: er zijn geen coëfficiënten bekend op het fijne domein voor het betreffende punt van het grove domein, dus valt het totaal niet te verdelen over de verschillende lagen. Merk op dat een vergelijkbaar probleem op kan treden bij horizontale 1 : 3 verfijning: in dat geval zijn de actuele laagposities mogelijk wel bekend, maar die hoeven niet te passen


6-12

sigma laag

sigma laag vaste laag

Figuur 6.9: Schema voor gelijktijdige horizontale en vertikale verfijning bij de verder gebruikte interpolatie methodes. Bijvoorbeeld kunnen de laagposities in de middelste van 3 × 3 cellen van het fijne domein worden vergeleken met de laagposities die zijn berekend uit de gemiddelde waterstand en bodem van de 3 × 3 cellen. Er worden drie verschillende soorten vertikale interpolaties uitgevoerd: • constante interpolatie van laag-gemiddelde informatie (u, v, c); • constante interpolatie van totalen per laag (F ); • lineaire interpolatie van samples in laag-interfaces (ω, k, ). Een vierde soort die van belang kan worden betreft: • lineaire interpolatie van samples in laag-middens (niet gebruikt). De derde methode vereist bij communicatie van het grove naar het fijne domein de actuele laagposities op het fijne domein. De methode om hiermee om te gaan is om het berekenen van de laagposities in een basismethode te verstoppen. De getallen kmax, indlay, hlay, hlaysh en trsdep worden dan in (tijdsonafhankelijke) coëfficiëntensets gestopt, en verder worden de nieuwe (tijdsonafhankelijke) coëfficiëntensets deps full, depu full, depv full, deps ovl, depu ovl en depv ovl gebruikt voor de bodemligging, en de nieuwe (tijdsafhankelijke) coëfficiëntensets seps full, sepu full, sepv full, seps ovl, sepu ovl en sepv ovl voor de waterstanden. Daarmee kunnen de actuele lokale laagposities worden berekend, zowel die van het versturende gebied als de laagposities die het ontvangende gebied zou gebruiken. Met deze methode wordt een erg lelijk punt uit DDVERT verholpen: het berekenen van laagposities in de hele guardband in trslav.

6.4.2

Interpolatie van laaggemiddelde waardes

De basismethode “cns lay avg” implementeert stuksgewijs constante interpolatie voor laaggemiddelde waardes. Bij 1 : n verfijning, waarbij iedere laag van het fijne domein te maken heeft met een enkele laag van het grove domein bestaat deze methode uit het n-keer kopiëren


6-13

van de waarde van het grove domein. Bij 1 : n vergroving wordt het gewogen gemiddelde van de n waardes van het fijne domein berekend met als weging de relatieve laagdiktes hk . fkintpol = 0

X

hk fkdiscr /

k∈K(k0 )

X

hk

(6.7)

k∈K(k0 )

Merk op dat deze formule precies overeenkomt met formule 6.3. Een verschil is echter hoe de coëfficiënten worden opgegeven ....

6.4.3

Interpolatie van laag-ge¨ıntegreerde waardes

De basismethode “cns lay intg” implementeert stuksgewijs constante interpolatie voor laagge¨ıntegreerde waardes. Bij 1 : n vergroving bestaat deze methode uit het optellen van de n waardes van het fijne domein, bij 1 : n verfijning wordt aan iedere laag van het fijne domein de fractie hf ijn,k /hgrof van de waarde van het grove domein toegekend. fijn → grof: fkintpol = 0

fkdiscr

(6.8a)

grof → fijn: fkintpol = hk0 fkdiscr /Hk 0

(6.8b)

X k∈K(k0 )

6.4.4

Lineaire interpolatie van samplefuncties op laaginterfaces

De basismethode “lin sampl kmax0” implementeert lineaire interpolatie voor willekeurige samplefuncties op laaginterfaces. Bij 1 : n aansluitende roosters komt iedere laaginterface van het grove domein in het fijne domein voor. Bij vergroving bestaat deze methode dan uit het selecteren van de geschikte waarde van het fijne domein. Bij verfijning wordt voor sommige laaginterfaces de waarde gekopiëerd van het grove domein, voor andere laaginterfaces “echt” lineair ge¨ınterpoleerd met behulp van de absolute vertikale posities. De basismethode “lin sampl kmaxi” implementeert lineaire interpolatie voor samplefuncties op laaginterfaces die nul zijn aan het oppervlak en op de bodem. Deze methode is gelijk aan de vorige, behalve dat de waardes op het oppervlak en de bodem niet hoeven te worden opgegeven. Deze laatste methode wordt niet meer gebruikt in de huidige DDVERT programmatuur. In plaats daarvan is er enige behoefte aan een methode voor interpolatie van samples in de laagmiddens, met name voor array WPHYS. De waardes in dit array worden momenteel als laaggemiddelden behandeld.

6.4.5

Sigma-vast koppeling en hogere orde interpolatiemethoden

Bij bespreking van de basismethoden in de vorige paragrafen is te zien dat deze afhangen van de laagdiktes of de vertikale posities van laaginterfaces. Dit zijn in TRIWAQ zowel plaatsals tijdsafhankelijke gegevens, wat impliceert dat interpolatiegewichten iedere keer moeten worden herberekend. Nu zijn er twee situaties waarin deze complicatie kan worden omzeild:


6-14

1. de posities/laagdiktes zijn bij methode cns lay avg alleen nodig in geval van vergroving (gewogen gemiddeldes berekenen) en bij de andere methodes alleen nodig voor verfijning (lineaire interpolaties, naar laagdikte gewogen verdeling bepalen). 2. in het geval van 1 : n aansluiting (iedere fijne laag heeft te maken met een enkele grove laag) waarbij vaste lagen steeds zijn gekoppeld aan vaste lagen kunnen de absolute posities en laagdiktes worden herleid tot relatieve posities/laagdiktes. In dat geval zijn de interpolatiegewichten onafhankelijk van de actuele waterstand en kan er worden gerekend met een voor alle roosterpunten gelijke, willekeurig te kiezen totale waterdiepte. Bij gebruik van hogere orde interpolaties is de actuele waterstand in het algemeen steeds nodig. Vanwege de eenvoud en efficiëntie van de laatste situatie was de DDVERT programmatuur hier in eerste instantie toe beperkt. Complicatie bleek echter te zijn dat hiermee het gebruik van deeldomeinen met 1 laag werd uitgesloten in combinatie met het gebruik van vaste lagen elders in het domein. Later is ook de mogelijkheid van koppeling van sigmalagen aan vaste lagen toegevoegd, zij het alleen voor deeldomeinen met 1 laag aan meerdere lagen. Eén gevolg van de sigma-vast uitbreiding is dat er in de collector COPPOS bij het verfijnen van de simulatieresultaten voor een deeldomein met 1 laag ook actuele waterstanden nodig kunnen zijn (als er in de fijnste laagverdeling vaste lagen voorkomen). Wanneer er geen sigma-vast koppeling voorkomt (als alle vaste lagen aan vaste lagen zijn gekoppeld) dan kan steeds met een willekeurige totale waterdiepte worden gerekend. Een complicatie is nu dat de volledige arrays van waterstanden en laagposities minder frequent worden weggeschreven dan andere laagafhankelijke informatie zoals de transportconcentraties in transportcontrolestations. Vanwege deze complicatie is de restrictie ingevoerd dat in geval van sigma-vast koppeling alle snelheids- en concentratiestations ook waterstandsstations zijn. Tijdens de initialisatiefase van COPPOS worden dan speciale tabellen aangelegd voor interpolatie van gegevens op MNMAXK, NOCUR en NOPOL data-structuren (index sets). Voor interpolatie van gegevens op andere gedistribueerde (horizontale) index sets dan MNMAXK, NOCUR en NOPOL wordt geen ondersteuning geleverd. Dit vereist namelijk dat gegevens op zulke index sets steeds worden weggeschreven op tijdstippen dat de array SEP beschikbaar is en vereist het uitzoeken van de relatie tussen de betreffende horizontale index set en de MNMAXK-structuur van SEP. Dit schema zou momenteel alleen worden gebruikt voor arrays DFL en NFLI op de verzameling van openingspunten NTOPT. Maar doordat in COPPOS alleen wordt verfijnd en doordat DFL en NFLI als laaggemiddelde waardes kunnen worden opgevat kan het gebruik van actuele waterstanden overbodig worden gemaakt (zie punt 1. hierboven).

6.5

Oplossing van de gediscretiseerde vergelijkingen

In Sectie 4.2 is besproken hoe de discretisaties van WAQUA en TRIWAQ nabij koppelingsranden worden bepaald. De discretisaties leiden in de meeste gevallen tot stelsels algebra¨ısche vergelijkingen waarvoor iteratieve oplosprocedures worden toegepast. In deze sectie wordt


6-15

beschreven op welke manier deze iteratieve methoden worden aangepast voor gekoppelde berekeningen. In de aanpassingen van de solvers wordt onderscheid gemaakt naar het soort koppeling dat wordt gebruikt: parallel, DDVERT of DDHOR. Dit onderscheid is nuttig omdat er bij eenvoudigere koppelingen efficiëntere algoritmes mogelijk zijn. De aanpassingen worden in aparte secties beschreven voor de verschillende fases van de berekening: 1. impulsvergelijking (trscue, waslgs voor WAQUA, en trscue, trsjam voor TRIWAQ); 2. gekoppelde impuls- en continu¨ıteitsvergelijkingen (trssuw, trsumo en trscnt voor WAQUA/TRIWAQ); 3. transport van meegevoerde stoffen (trsdif, waspnd voor WAQUA, en trsdif, trsjac voor TRIWAQ); 4. vergelijkingen van het verticale k, -turbulentiemodel (trstur, trsdgs voor TRIWAQ, niet beschikbaar voor WAQUA).

6.5.1

Impulsvergelijking in TRIWAQ (trscue, trsjam)

Voor de berekeningen die uitgevoerd moeten worden voor het oplossen van de impulsvergelijkingen zijn relatief weinig aanpassingen nodig om deeldomeinen aan elkaar te koppelen. De reeds bestaande code voor vertikale verfijningen bevat nagenoeg alle onderdelen van de berekening. Deze sectie beschrijft de wijze waarop deeldomeinen gekoppeld worden en in hoeverre dat verschilt van de manier waarop dat gebeurt in de reeds bestaand codes. In subroutine trscue wordt een lineair stelsel opgesteld, dat wordt opgelost in trsjam. Voordat het stelsel wordt opgesteld, worden de variabelen w (vertikale snelheden), vicow (vertikale eddy-viscositeiten) en kfbu (masker-array voor barrier-punten, schotjes per laag) gecommuniceerd. De interpolatie van kfbu is problematisch. Er mogen echter geen barrierpunten voorkomen in de guard-band van DDHOR- of DDVERT-koppelingen, dus is deze interpolatie ook nooit nodig. De gebruikte oplosmethode wordt red-black Jacobi genoemd. Deze methode kan ongewijzigd worden gebruikt, wanneer de gebruikte communicatie zorgvuldig wordt geconfigureerd. Een iteratie bestaat uit twee halve iteraties; één waarin nieuwe snelheden worden berekend in de zogenaamde “rode” punten (de punten waarin m + n even is), en één waarin nieuwe snelheden worden berekend in de “zwarte” punten (m + n oneven). Na elke halve iteratie vindt een communicatie plaats, waarbij alleen voor die roosterpunten hoeft te worden gecommuniceerd waar de snelheidswaarden door de berekening zijn veranderd. Bij parallelle en DDVERT-koppelingen zijn dat na de eerste halve iteratie de rode roosterpunten, en in de tweede de zwarte. Aangezien de deelroosters in dat geval alle onderdeel zijn van één globaal gestructureerd rooster, kan elk deeldomein van zijn eigen guardbandpunten de juiste kleur bepalen. Op DDHOR-koppelingen is de situatie anders. Hier moeten na de eerste halve iteratie de snelheden worden vervangen in alle roosterpunten waarin voor de interpolatie gebruik


6-16

gemaakt wordt van rode punten (tweede halve iteratie: zwarte). In veel guardbandpunten zullen dus na elke halve iteratie nieuwe waarden moeten worden ingevuld, en voor dit vervangen moeten steeds alle benodigde interne waardes worden verstuurd. Welke punten na beide halve iteraties moeten worden vervangen, kan alleen worden bepaald met behulp van een communicatie in de initialisatie van WAQPRO. Tijdens de iteratieve oplossing van de impulsvergelijking wordt de routine waschk gebruikt om te bepalen of het stelsel nauwkeurig genoeg is opgelost, hoe groot het grootste residu in de vergelijking is, en op welke plaats in het rooster het grootste residu in de vergelijking gevonden is. In een DDHOR simulatie, waarin meerdere roosters worden gebruikt, kan de lokatie van het grootste residu niet meer uniek worden weergegeven met de logische coördinaten, omdat dezelfde coördinaten in meerdere roosters voor kunnen komen. Als extra informatie wordt gekozen voor het run-id van het rooster waarin het grootste residu voorkomt, omdat dit voor de gebruiker het meest aansprekend is. Alternatieven zijn om het roosternummer toe te voegen of om de residuen voor alle roosters afzonderlijk af te drukken. Subroutine wasck2 drukt de locatie van het grootste residu niet af en hoeft hiervoor dus niet te worden uitgebreid.

6.5.2

Impulsvergelijking in WAQUA (trscue, waslgs)

In WAQUA wordt een blok Gauss-Seidel iteratie gebruikt voor het oplossen van de gediscretiseerde impulsvergelijkingen. Steeds worden de snelheden binnen een hele rij van een deelrooster ineens vervangen door het oplossen van een tridiagonaal stelsel. De volgorde waarin de rijen bezocht worden hangt in eerste instantie af van de dominante stroomrichting, en wordt verder steeds afgewisseld. Bij de parallellisatie van WAQUA is ervoor gekozen om een keer per iteratie te communiceren en wordt binnen ieder deelrooster de Gauss-Seidel strategie gehandhaafd. Op subdomeinranden wordt aldus een blok Jacobi koppeling gebruikt. Deze strategie is even goed bruikbaar bij horizontale verfijning. Alleen wordt de directe communicatie daarbij uitgebreid met interpolatie. De communicatie van hubar in trscue betreft de waterdiepte links en rechts van barriers. Deze is niet van toepassing voor DDHOR omdat barriers niet in de buurt van DDHOR interfaces mogen liggen.

6.5.3

Impuls- en continu¨ıteitsvergelijking in WAQUA en TRIWAQ (trssuw)

Het oplossen van de gekoppelde impuls- en continu¨ıtetsvergelijkingen levert de grootste moeilijkheden op met betrekking tot het koppelen van deeldomeinen. Dit komt voort uit het moeten garanderen van massabehoud en het moeten oplossen van tridiagonale stelsels voor rijen van het rooster. In subroutine trsumo wordt eerst de impulsvergelijking gediscretiseerd. Samen met de continu¨ıteitsvergelijking levert dit een niet-lineair stelsel op. Dit stelsel wordt iteratief opgelost, waarbij er steeds door linearisatie een tridiagonaal stelsel wordt verkregen voor de


6-17

waterstanden. Bij parallel rekenen en 1:1-koppeling in het horizontale vlak lopen de tridiagonale stelsels per rij door verschillende subdomeinen heen. Bij horizontale verfijning is er een koppeling tussen verschillende rijen per domein. In geval van horizontale verfijning wordt de methode van uitgaande informatie gebruikt voor het definiëren van de koppeling. In geval van parallel rekenen en 1:1-koppeling worden de gewone discretisaties gebruikt. In dat geval wordt de methode van uitgaande informatie als oplosmethode gebruikt. Deze methode is in dat geval sterk aan de BJ-TWGE methode gerelateerd die voorheen werd gebruikt. De methode van uitgaande informatie wordt gedetailleerd uitgelegd in paragraaf 6.6. In parallelle berekening kan de impulsvergelijking door beide betrokken deeldomeinen worden gediscretiseerd in de snelheidspunten op de interface (zgn. redundante berekening). Dit leidt tot een efficiënte koppeling omdat een aantal communicatieslagen wordt vermeden. geen Redundante discretisatie van de impulsvergelijking op de interface is echter niet mogelijk in redundante geval van DDHOR-koppeling, ook niet als dezelfde roosterfijnheid wordt gebruikt (1:1). Er berekening kan namelijk niet worden gegarandeerd dat beide deeldomeinen exact dezelfde waardes voor aa, cc en dd berekenen. Omwille van de eenvoud wordt de redundante berekening van de impulsvergelijking nu ook niet meer voor subdomeinranden m.b.t. parallel rekenen gebruikt. De coëfficiënten van de vertikaal ge¨ıntegreerde impulsvergelijking aa, cc en dd zijn in beide subdomeinen aan weerszijden van een interface nodig voor het opstellen van de continuiteitsvergelijking, en moeten dus worden gecommuniceerd. Tot voor de uniformering van WAQUA en TRIWAQ [8] was de definitie van aa, cc en dd in TRIWAQ anders dan in WAQUA. Inmiddels representeren ze zowel in WAQUA als in TRIWAQ de vertikaal geintegreerde impulsvergelijking: 1

[q]

[q] guum,n

[q] [q] [q] [q] qxm,n + aam,n ζm,n + cc[q] m,n ζm,n+1 = ddm,n .

(6.9)

waarin guu de cellface-lengte is van het controlevolume (m,n), en qxk het debiet door de cellface. Nasst de diepte-ge¨ıntegreerde impulsvergelijking (6.9) wordt ook de volgende continu¨ıteitsvergelijking opgesteld: 1 [q] [q] old old old gsqsm,n ζm,n − ζm,n + ∆t qx[q] m,n − qxm−1,n + qym,n − qym,n−1 = 0, 2

(6.10)

waarbij gsqs de oppervlakte is van het controlevolume (m,n). Wanneer de diepte-ge¨ıntegreerde impulsvergelijking (6.9) wordt ingevuld in de continu¨ıteitsvergelijking (6.10), wordt een tridiagonaal stelsel voor de waterstand gevonden van de vorm [q]

[q]

[q] [q] [q] [q] a[q] m,n ζm−1,n + bm,n ζm,n + cm,n ζm+1,n = ddm,n .

(6.11)

In rooster-rijen die gekoppeld zijn aan een buurdomein wordt de diepte-ge¨ıntegreerde impulsvergelijking (6.9) van het grofste rooster verkregen uit de vergelijkingen van het fijnere buurdomein. Bovendien komen waterstanden die in het buurdomein liggen voor in de tridiagonale stelsels (6.11).


6.5.4

flux correctie schema

6-18

Transportvergelijking in TRIWAQ (trsdif, trsjac)

Hoewel er verschillende grootheden getransporteerd kunnen worden, zullen we er in het vervolg van dit hoofdstuk -ten behoeve van eenvoud van presentatie- van uitgaan dat de getransporteerde grootheid zout is. Bij de berekening van zoutconcentraties, net zoals bij die van waterhoogten, is massabehoud van belang. In TRIWAQ wordt dit afgedwongen door conservatieve discretisatieformules te gebruiken en door de daaruit voortkomende lineaire stelsels tot op machine-nauwkeurigheid op te lossen. Hiervoor wordt een red-black Jacobi-methode gebruikt die sterk lijkt op de methode voor de impulsvergelijking in TRIWAQ, zie paragraaf 6.5.1. Zoals al in Sectie 4.2 is besproken, wordt behoud alleen dan gegarandeerd op de koppelingsranden wanneer de transport-flux op de koppelingsrand eenduidig bepaald is. In het project DDVERT [1] is gebleken dat hierbij het beste de transport-flux van het fijnst verroosterde deeldomein genomen kan worden. In het project DDVERT is een methode voor het iteratief oplossen van de transportvergelijkingen ontwikkeld, waarbij gebruik gemaakt wordt van fluxcorrecties [11]. De berekening van de transport-fluxen op basis van de eigen concentraties, waarvan de discretisatiestencils worden weergegeven in Figuur 4.8, betreft een lineaire operatie, die kan worden weergegeven als X

fluxx(n, m, k, l) =

a(n, m, k, n1, m1, k1, l) ∗ rp(n1, m1, k1, l).

(6.12)

n1,m1,k1

De transportflux wordt dus berekend als een lineaire combinatie van concentraties op het eigen rooster. Op de interfaces moet deze flux echter niet met de eigen concentraties worden berekend, maar uit de fluxen van het buurdomein. De grofrooster-flux is de som van een aantal fijnrooster-fluxen. Dit kan worden weergegeven met: fluxx(n, ml, k, l) =

X

fluxx(n1, mf, k1, l),

(6.13)

n1,mf,k1

Hierbij is onderstreping gebruikt om aan te geven welke variabelen op een ander rooster leven. Door de vergelijkingen (6.12) en (6.13) op een heel eenvoudige manier te combineren, kan worden afgeleid fluxx(n, ml, k, l) =

X

a(n, m, k, nm1, k1, l) ∗ rp(n1, m1, k1, l) + dfluxx(n, ml, k, l),

n1,m1,k1

met dfluxx(n, ml, k, l) =

X

fluxx(n1, mf, k1, l)

n1,mf,k1

−

X

a(n, m, k, nm1, k1, l) ∗ rp(n1, m1, k1, l).

n1,m1,k1

De fluxcorrectie dfluxx wordt steeds op het laatst beschikbare iteratieniveau berekend. In het geval van parallelle berekening is de fluxcorrectie altijd gelijk aan nul.


6-19

Het algoritme wordt in de DDVERT-programmatuur met succes toegepast. De grootste aanpassing voor DDHOR betreft data-structuur waarin de fluxen kunnen worden opgeslagen, waarmee kan worden gecommuniceerd voor de cellfaces aan het begin en einde van de rekenrijen. In Sectie 6.7.2 wordt hierop dieper ingegaan. Net als bij het ontwerp van de koppelings-iteratie in trssuw is uitgegaan van een aantal leidende principes: • De koppeling vereist geen nieuwe communicatie-momenten in de binnenste loop; • Wanneer het algoritme zou worden toegepast in het geval van een parallelle run, reduceert het algoritme tot gewone Red-Black Blok-Jacobi iteratie (de fluxcorrecties zijn gelijk aan nul in iedere iteratie).

6.5.5

Transportvergelijking in WAQUA (trsdif en waspnd)

In het transportgedeelte van WAQUA wordt een ADI benadering gecombineerd met tweede orde upwind methode voor de advectieve termen. Op deze manier wordt per rij van het rekenrooster een lineair penta-diagonaal stelsel verkregen. In parallelle berekeningen worden de stelsels per rij opgelost met de BJ-TWGE methode (subroutine waspnd). Hiervoor is een iteratie-proces ge¨ıntroduceerd voor het geval dat er rijen zijn die in meer dan twee stukken worden opgedeeld, waarvoor de BJ-TWGE methode per iteratie niet de exacte oplossing bepaalt. Op DDHOR-randen wordt gebruik gemaakt van een blok Jacobi-koppeling: van de zoutconcentraties buiten het eigen domein worden de waarden uit de vorige iteratie gebruikt. Verder zijn in het transportgedeelte van WAQUA ook aanpassingen nodig om massabehoud te garanderen in DDHOR berekeningen. Hiervoor wordt hetzelfde fluxcorrectie schema gebruikt als in TRIWAQ. De benodigde coëfficiëntenarrays worden net als voor TRIWAQ in subroutine trsdif ingevuld. Het flux-correctiealgoritme zelf is in subroutine waspnd nageprogrammeerd van dat van trsjac.

6.5.6

Het verticale turbulentiemodel in TRIWAQ (trstur, trsdgs)

De berekeningen van het verticale k − turbulentiemodel in subroutine trstur bestaan uit twee verschillende stappen. In de eerste stap wordt de horizontale advectie van turbulente grootheden k en verdisconteerd. Hierbij wordt eerste orde upwind discretisatie gebruikt. De discrete vergelijkingen worden opgelost met behulp van een stroomrichting-afhankelijke Gauss-Seidel iteratie in subroutine trsdgs. De gebruikte Gauss-Seidel iteratie kan ongewijzigd per deeldomein worden uitgevoerd, zoals dat al wordt gedaan in de DDVERT- en parallelle codes. In de tweede stap van de berekening worden alle vertikale termen in de tijd ge¨ıntegreerd: de interacties aan de bodem en het wateroppervlak en tussen de turbulente grootheden onderling. In dit deel van de berekening zijn alleen variabelen uit het eigen roosterpunt van belang. Daarom is de horizontale opdeling van het globale domein hierbij van geen belang.


6.5.7

6-20

Het horizontale turbulentiemodel (trshke, trstrd)

Het horizontale k − turbulentiemodel levert lineaire tridiagonale stelsels van vergelijkingen voor rijen van dieptepunten op. Deze worden in parallelle runs opgelost met de BJ-TWGE methode. Hiervoor is subroutine trstrd die oorspronkelijk voor de waterstanden werd gebruikt uitgebreid zodat ze ook voor dieptepunten kan worden gebruikt. Ook is subroutine wasrwc uitgebreid voor het kleuren van sub-rijen voor dieptepunten. Voor meer informatie zie [10]. Het horizontale turbulentiemodel kan nog niet in combinatie met domein decompositie worden gebruikt.

6.6

Iteratie op basis van uitgaande informatie (trssuw)

voor het berekenen van de waterstanden gebruikten we in de domein decompositie versie van WAQUA/TRIWAQ oorspronkelijk een variant van de additive Schwarz-methode. In de loop der tijd is deze methode verfijnd, en vervolgens vervangen door een koppeling op basis van “uitgaande informatie”. Bij deze koppeling op basis van uitgaande informatie worden in geval van horizontale verfijning andere vergelijkingen opgelost dan in de eerdere versies het geval was. In het geval zonder horizontale verfijning (maar mogelijk met vertikale verfijning) levert de methode dezelfde oplossingen als voorheen; in gevallen zonder verfijning is dat tevens dezelfde oplossing als sequentieel gevonden wordt.

6.6.1

Berekenen van uitgaande informatie

De uitgaande informatie waarop de methode is gebaseerd is een lineaire combinatie van waterstand en debiet die zonder informatie van het buurdomein kan worden berekend. In roosterrijen die slechts aan het einde zijn gekoppeld aan een ander domein kan door te vegen een vergelijking worden opgesteld van de vorm [q]

[q] ∗[q] ∗[q] b∗[q] m,n ζm,n + cm,n ζm+1,n = dm,n .

(6.14)

Deze vergelijking wordt gecombineerd met de diepte-ge¨ıntegreerde impulsvergelijking (6.9) en met de interpolatieformule voor waterstanden op u-punten [q]

[q]

[q] ζm+1/2,n = θm,n ζm,n + (1 − θm,n )ζm+1,n .

(6.15)

De drie bovenstaande vergelijkingen kunnen worden gecombineerd tot een vergelijking voor het interfacedebiet qxm,n en de interface-waterstand ζm+1/2,n . Deze vergelijking heeft de volgende vorm: qxm,n + q2sepm,n ζm+1/2,n = outgom,n . waarin q2sepm,n outgom,n

coëfficiënt in de berekening van outgo uitgaande informatie in het snelheidspunt op de interface (m + 1/2, n).

(6.16)


6-21

De vraag is nu voor welke waarde van q2sepm,n vergelijking (6.16) inderdaad uitgaande informatie betreft, wat wil zeggen dat de waarde van outgom,n niet van grootheden van het buurdomein afhankelijk is. Als we deze waarde van q2sep hebben, dan kunnen we de uitgaande informatie outgo berekenen en toesturen aan het buurdomein. De crux van deze berekening aanpak zit in de observatie dat we al informatie hebben over het einde van een domein. Namelijk de geveegde vergelijking (6.14). We kennen niet de waarde van ζm+1,n , maar wel een vergelijking waarmee deze in ζm,n wordt uitgedrukt. Alle coëfficiënten hierin ((6.14): b∗ , c∗ , d∗ ) zijn bekend, en zijn bepaald zonder gebruik te maken van informatie van het buurdomein. Als we nu (6.16) van dezelfde vorm maken als (6.14) dan hebben we daarmee de goede verhouding van qxm,n en ζm+1/2,n ten behoeve van uitgaande informatie bepaald. We gaan uit van de gewenste vorm voor de koppelingsvergelijking (6.16). In het linker lid schrijven we qx uit met behulp van de diepte-ge¨ıntegreerde impulsvergelijking (6.9), en su met zijn definitie (6.15): guum,n (ddm,n − aam,n ζm,n − ccm,n ζm+1,n ) + q2sepm,n (θm,n ζm,n + (1 − θm,n )ζm+1,n ) = outgom,n

(6.17)

We groeperen de termen met waterstanden ζm,n en ζm+1,n , en eisen dat de coëfficiënten hiervan dezelfde verhouding hebben als b∗ en c∗ in (6.14): q2sepm,n θm,n − guum,n aam,n b∗ = ∗ (6.18) q2sepm,n (1 − θm,n ) − guum,n ccm,n c Deze waarde is q2sepm,n =

c∗m,n aam,n − b∗m,n ccm,n guum,n c∗m,n θm,n − b∗m,n (1 − θm,n )

(6.19)

Met deze waarde is vergelijking (6.16) equivalent gemaakt met (6.14). Het verschil met die geveegde vergelijkingen is echter dat (6.16) wél betekenisvol kan worden gecommuniceerd van het fijne naar het grove buurdomein. Wanneer de koppeling met een ander domein niet aan het einde van een rooster-rij ligt, maar aan het begin daarvan, dan wordt het tridiagonale stelsel (6.11) van achter naar voren geveegd, wat een vergelijking oplevert van de vorm [q]

∗∗[q] [q] ∗∗[q] a∗∗[q] m,n ζm−1,n + bm,n ζm,n = dm,n .

(6.20)

Ook met deze vergelijking kan een vergelijking van de vorm (6.16) worden opgesteld, maar dan voor de interface aan het begin van de rooster-rij. In het geval van een rooster-rij die is gekoppeld aan beide zijden, wordt de uitgaande informatie aan een van beide kanten verkregen door een blok-Jacobi randvoorwaarde toe te passen aan het andere uiteinde van de rooster-rij. Het effect van deze blok-Jacobi randvoorwaarde op de uitgaande informatie is doorgaans zeer gering. Nadat de uitgaande informatie van het buurdomein is verwerkt, kan het tridiagonale stelsel worden opgelost. Aan het uiteinde van de rij waarop de block-Jacobi randvoorwaarde is toegepast, wordt de uitgaande informatie vastgesteld en uitgewisseld met het buurdomein, waarna deze informatie wordt gebruikt om de oplossing te corrigeren.


6.6.2

6-22

Koppelingscondities

De koppelingscondities zijn de eisen waaraan de oplossing moet voldoen, wanneer de vergelijkingen in de verschillende domeinen allemaal opgelost zijn. Niet alle koppelingscondities kunnen met de verschillende vormen van uitgaande informatie worden gecombineerd. Dit is de reden dat de vroegere koppelingscondities in geval van horizontale verfijning is aangepast. De koppelingscondities die in WAQUA/TRIWAQ worden gebruikt zijn de volgende: 1. Gelijkheid van het debiet op de interface, ten behoeve van massabehoud: qxml,n =

X

qx ˜ mf,~ ~ n

(6.21)

n ~

Hierin verwijzen de tildes naar grootheden van het fijne domein. 2. De waterstand in interfacepunten van het fijne domein is gelijk aan de waterstand in het overeenkomstige punt van het grove domein plus een variatie dsu langs de interface: ˜~ ζ˜mf+1/2,~ ~ n = ζml+1/2,n + δ ζmf+1/2,~ n.

(6.22)

Een moeilijkheid hierbij is om het profiel δ ζ˜ langs de interface te kiezen. Op deze moeilijkheid wordt dieper ingegaan in paragraaf 6.6.4. In het geval van 1:1 koppeling wordt in beide domeinen dezelfde waterstand gevonden met de keuze δ ζ˜ = 0. Wanneer beide domeinen dezelfde impulsvergelijking en tetau-interpolatie hanteren, dan voldoet alleen de volgende oplossing hieraan: ˜~ n = ζml,n , ζ˜mf+1,~ qxml,n = qx ˜ mf,~ ~ ~ n , ζmf,~ n = ζml+1,n

(6.23)

In dat geval is de koppeling equivalent met die van de vroegere programmatuur voor parallel rekenen en DDHOR-1:1 koppeling. In het geval van horizontale verfijning leveren deze koppelingen niet exact dezelfde oplossingen als de vroegere programmatuur, maar wel oplossingen die even nauwkeurig zouden moeten zijn.

6.6.3

Oplossen van de koppelingsvergelijkingen

Vanuit de koppelingscondities (6.21) en (6.22) en de koppelingsinformatie (6.16) met q2sep berekend volgens (6.19) is een praktisch algoritme geconstrueerd voor gevallen met verfijning. • Alle domeinen berekenen hun eigen coëfficiënten voor de optimale koppeling q2sep en de bijbehorende uitgaande informatie outgo. • Het grove domein krijgt de uitgaande informatie outgo en de coëfficiënt q2sep toegestuurd van het buurdomein. De bijdragen van de verschillende buurrijen van de grof-roosterrij worden bij elkaar opgeteld: outnghml,n =

X n ~

˜ mf,~ outgo ~ n , q2snghml,n =

X n ~

˜ mf,~ q2sep ~ n

(6.24)


6-23

• Het grove domein heeft nu de beschikking over de volgende vergelijkingen: eigen vgl:

outgoml,n = qxml,n + q2sepml,n ζml+1/2,n , X ˜ ~ ζ˜mf+1/2,~ qx ˜ ~ + q2sep outngh = ~ n

ontvangen vgl:

mf,~ n

ml,n

mf,~ n

(6.25)

n ~

• In deze vergelijkingen mogen de koppelingscondities (6.21) en (6.22) worden ingevuld. De vergelijkingen worden hiermee: eigen vgl: ontvangen vgl:

outgoml,n = qxml,n + q2sepml,n ζml+1/2,n , outnghml,n = qxml,n + q2snghml,n ζml+1/2,n + dcrossml,n , (6.26)

waarbij de term dcross gegeven wordt door dcrossml,n =

X

˜~ ˜ mf,~ q2sep ~ n δ ζmf+1/2,~ n.

(6.27)

n ~

Voor het opstellen van de vergelijking (6.25) moet naast de termen q2sngh en outngh ook de term dcross verkregen worden door middel van communicatie. Vervolgens kunnen de twee onbekenden qxml,n en ζml,n op het grove rooster eenvoudig worden bepaald. De waterstand wordt weer naar het fijne domein gecommuniceerd, en daar kan vervolgens de totale oplossing worden bepaald. • De twee vergelijkingen (6.26) kunnen eenvoudig worden opgelost en leveren voor het grove domein de waterstand ζml+1/2,n en het debiet qxml,n op de interface op. • De waterstand op de interface wordt naar het fijne domein gecommuniceerd. Hierbij wordt conform de koppelingsconditie (6.22) constante interpolatie gebruikt, waarna het fijne domein de correctie δ ζ˜ toepast. • Het fijne domein gebruikt de geveegde vergelijking (6.14) en de definitie (6.15) van de waterstand in het interfacepunt voor het oplossen van zijn waterstanden, en de oplossing is bekend. In het geval van 1:1 koppeling wordt de uitgaande informatie naar beide domeinen gecommuniceerd, waarna beide domeinen het stelsel (6.26) oplossen, en verdere communicatie niet nodig is.

6.6.4

Waterstandsprofiel langs de interface in het fijne domein

In paragraaf 6.6.2 is de term δ ζ˜ ge¨ıntroduceerd, waarmee het profiel langs de interface voor het fijne domein wordt verwerkt. In deze paragraaf presenteren en bespreken we enkele verschillende keuzen voor deze term:


6-24

• In het prototype [9] is geëxperimenteerd met de eenvoudigste keuze δ ζ˜ = 0. Deze keuze bleek niet te voldoen, omdat deze keuze leidt tot een vlakke waterspiegel in de meeste roosterpunten, en een zeer groot verhang in de rest van de roosterpunten. • Een beter profiel wordt verkregen door middel van (lineaire) interpolatie van de waterstanden op de interface: ˜ ~ ζ˜mf+1/2,~ ) =⇒ δ ζ˜mf+1/2,~ ) − ζ˜mf+1/2,~ ~ ~ ~ ~ n = B(ζml+1/2,: n = Bg→f (ζml+1/2,: n.

(6.28)

waarbij Bg→f de interpolatie weergeeft van de grofroosterwaterstanden. Het probleem van deze keuze is echter dat de ge¨ınterpoleerde waarde afhangt van de oplossing uit verschillende rijen en daarom niet vooraf bekend is. Een eenvoudig iteratief proces kan worden gebruikt om het stelsel op te lossen. Het is echter duidelijk dat de introductie van (nóg) een extra iteratief proces het algoritme en de programmatuur (verder) compliceert. • Een keuze voor δ ζ˜ die vooraf kan worden berekend, voorkomt de introductie van een extra iteratief proces. Een eenvoudige manier om een expliciete formulering te verkrijgen, is om de keuze (6.28) eenmalig te berekenen, op basis van de waarden vlak voor de interface, op het oude tijdsnivo: õld õld δ ζ˜mf+1/2,~ ~ ~ )) − ζmf,~ ~ n. n = Bg→f (Bf →g (ζmf,:

(6.29)

Deze laatste keuze is in de programmatuur ge¨ımplementeerd.

6.6.5

Stopcriterium per rij

In trscnt wordt het stop-criterium per rij geëvalueerd in plaats van dat voor alle rijen evenveel iteraties worden uitgevoerd. Tridiagonale stelsels worden uit de berekening genomen wanneer deze opgelost zijn voordat alle andere tridiagonale stelsels zijn opgelost. Dit mechanisme moet correct functioneren, ook bij horizontale verfijning, die kan leiden tot interactie tussen verschillende rijen van een enkel deeldomein, zie Figuur 4.9. Het stop-criterium per rij is belangrijk omdat er in WAQUA voor sommige rijen veel meer iteraties nodig zijn dan gemiddeld over het hele rooster. Dit is een van de grootste knelpunten in parallel WAQUA en kan worden aangepakt met andere linearisatie-technieken. Een efficiënte uitbreiding voor horizontale verfijning is nu om de een rij uit de berekening te halen wanneer het lokale stelsel is opgelost in het eigen domein en in de gekoppelde stelsels van beide aangrenzende domeinen. Het is hierbij mogelijk dat een stelsel uit de berekening wordt genomen omdat het is opgelost, maar later weer in de berekening wordt opgenomen, omdat de oplossing in het aangrenzende domein in een latere iteratie toch te veel is aangepast.


6.7

6-25

Configuratie van de communicaties door WAQPRO

Bij de beschrijving van de iteratieve methoden in Sectie 6.5 is aangegeven op welke momenten gegevens uitgewisseld moeten worden tussen verschillende deeldomeinen en welke informatie dat moet zijn. In Sectie 4.2 is aandacht besteed aan de daarbij gebruikte interpolatiemethoden. In deze sectie wordt aandacht besteed aan de manier waarop WAQPRO aan COCLIB kenbaar maakt hoe de communicatie uitgevoerd moet worden. De configuratie van de communicatie bestaat uit vier delen, te weten de definitie van koppelings-categoriën, index sets, stencils en interpolatie methoden. Het tweede en vierde deel betreft eigenschappen van de te communiceren velden, het derde stuk heeft vooral betrekking op de berekeningen die ermee worden uitgevoerd, en het eerste deel stuurt de communicaties in verschillende gevallen. De koppelings-categoriën worden gebruikt om te voorkomen dat de communicatie in parallelle berekeningen onnodig wordt belast. De uitwerking hiervan wordt in Sectie 6.7.1 beschreven. In Sectie 6.7.2 wordt aandacht besteed aan het tweede deel. Het gaat hier over de datastructuur van de velden, welke in de vorm van index sets door COCLIB wordt opgeslagen. Stencils worden gebruikt omdat het niet steeds nodig is dat informatie wordt uitgewisseld voor de hele guardband. Welke stukken gecommuniceerd moeten worden bij gebruik van een bepaald stencil wordt door COCLIB opgeslagen in de vorm van interface-tabellen. De configuratie van de interface-tabellen wordt besproken in Sectie 6.7.3. In Sectie 6.7.4 wordt aandacht besteed aan het vierde deel, dat betrekking heeft op de te gebruiken interpolatiemethoden.

6.7.1

Koppelings-categori¨ en

De communicatie omvat verschillende conversie-bouwstenen, zoals is uiteengezet in Sectie 5.9. Van deze bouwstenen hangt de directe interpolatie (Type II conversie) af van welk buurproces de data afkomstig zijn. Om TRIWAQ in de gelegenheid te stellen aan te geven welke directe interpolatie gebruikt moet worden, zijn de koppelingscategieën ingevoerd. In het project DDHOR+VERT zijn er nog maar 3 koppelingscategorieën, die genoeg informatie geven om te bepalen welke vertikale interpolatie gebruikt moet worden. Deze koppelingscategorieën zijn 1. noddv: gelijke laagverdeling; De veld-waarden van de buurdomeinen kunnen direct in de eigen guardband geplaatst worden. 2. ddv-fixfix: koppeling met vertikale verfijning, waarbij sigma-lagen aan sigma-lagen, en vaste aan vaste lagen gekoppeld zijn. De interpolatie-gewichten zijn identiek voor alle roosterpunten in de guardband en zijn constant in de tijd. 3. ddv-sigfix: koppeling met vertikale verfijning, waarbij sigma-lagen en vaste lagen samen aan een enkele (sigma-)laag zijn gekoppeld.


6-26

De interpolatie-gewichten variëren in de guardband en zijn tijdsafhankelijk (berekend uit de posities van laaginterfaces).

6.7.2

Configuratie van index sets

In de programmatuur worden velden, zoals bijvoorbeeld het waterstandsveld sep, weergegeven met behulp van arrays. In de code is een array niet veel meer dan een rij getallen, genummerd 1, 2, · · ·. Bij uitwisseling van gegevens is het echter heel belangrijk om te weten voor welke roosterpunten de indices staan. In het geval van waterstanden, staat de index voor een waterstands-roosterpunt. Zo staat sep(20) voor de waterstand in het twintigste waterstandsroosterpunt. De communicatie-bibliotheek COCLIB moet bepaalde informatie hebben over deze roosterpunten, bijvoorbeeld in welk deeldomein het ligt, en welke de buur-punten zijn. Zulke informatie wordt aan COCLIB verstrekt in de vorm van een index-set beschrijving. In de DDHOR-code worden aparte index sets gebruikt voor de variabelen die leven op waterstands-, diepte, of u- en v-snelheidspunten. De status (discretisatie- versus interpolatiepunt), c.q. het eigenaarschap van dezelfde array-index (m, n) moet namelijk verschillend kunnen zijn voor de verschillende soorten punten. In Tabel 6.1 is te zien welke index sets gebruikt worden in de DDHOR-code.

6.7.3

Configuratie van interfaces

Met behulp van interfaces kan heel precies bepaald worden welke informatie moet worden gecommuniceerd, en welke niet. Om twee redenen is het erg belangrijk dat van deze mogelijkheid gebruik wordt gemaakt. De eerste is efficiëntie: de berekening verloopt veel sneller wanneer informatie niet nodeloos wordt gecommuniceerd en/of ge¨ınterpoleerd. Dit effect kan nog groter zijn wanneer synchronisaties kunnen worden vermeden. De tweede reden is dat sommige informatie niet correct gecommuniceerd kan worden bij bepaalde koppelingen. Een voorbeeld hiervan is gsqs. Deze kan in DDHOR niet worden gecommuniceerd (omdat ze niet ge¨ınterpoleerd kan worden), maar moet wel worden gecommuniceerd in een parallelle berekening. Met een juiste specificatie van een interface kan ervoor worden gezorgd dat daarin de punten bij de DDHOR koppeling niet voorkomen en de punten bij een parallelle koppeling wel. In Tabel 6.2 is een overzicht te zien van de verschillende interfaces die nodig zullen zijn in de verschillende communicaties in de DDHOR-code. De interfaces op produkt-index sets (zoals full s*kmax) worden afgeleid uit hun horizontale deel-index set (zoals fullbox s), en worden niet apart genoemd. Veel interfaces kunnen worden verkregen door middel van “gewone” stencil-operaties, die al in vele versies van de programmatuur worden toegepast. Bij een aantal interfaces wordt echter aangegeven “alleen voor ...”. Bij deze interfaces mogen punten alleen worden opgenomen als ze in een domein liggen met bepaalde eigenschappen. Zulke interfaces kunnen worden geconstrueerd met behulp van de gebruikelijke stencil-operaties, omdat deze operaties op een krachtige manier gestuurd kunnen worden met behulp van twee masker-invoer arrays.

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) index set mnmaxk s fullbox s full s*kmax full s*kmax0 mnmaxk u fullbox u full u*kmax fullbox u*kmax0 mnmaxk v fullbox v full v*kmax full v*kmax0 mnmaxk d fullbox d flux u*kmax flux u flux v*kmax flux v nbaru*kmax nbarv*kmax nbaruv nbaru nbarv nbaru*2 nbarv*2

variabele sep sepf rpf zksp up umea upf zkup vp vmea vpf zkvp xdep, ydep xdepf, ydepf fluxx fluxx fluxy fluxy barfrc barfrc sinb, cosb cbuv cbuv hubar hvbar

6-27

beschrijving WAQUA-waterstand TRIWAQ-waterstand TRIWAQ-concentraties TRIWAQ: laaginterfaces in wl-punten WAQUA-snelheid TRIWAQ: diepte-gemiddelde snelheid TRIWAQ-snelheid TRIWAQ: laaginterfaces in u-punten WAQUA-snelheid TRIWAQ: diepte-gemiddelde snelheid TRIWAQ-snelheid TRIWAQ: laaginterfaces in v-punten WAQUA-roostercoördinaten TRIWAQ-roostercoördinaten TRIWAQ-transport-flux WAQUA-transport-flux TRIWAQ-transport-flux WAQUA-transport-flux barrier-verliescoëfficient barrier-verliescoëfficient hoek tussen barrier en rooster extra wrijvingsverlies t.g.v. u-barriers extra wrijvingsverlies t.g.v. v-barriers waterdiepte links en rechts van u-barrier waterdiepte links en rechts van v-barrier

Tabel 6.1: De index sets die gebruikt worden in interpolaties, met bij elk een voorbeeld van een variabele. De interfaces stc3xb en stx3xr, waarin alleen punten voorkomen waarvan de waarde is veranderd in een halve iteratie van het red-black Jacobi proces, kunnen ook worden verkregen met behulp van stencil-operaties en de juiste maskers. De maskers kunnen echter alleen worden verkregen met behulp van interpolaties. Het zelfde geldt voor de stencils red11 en blk11. Bij een aantal communicaties is het de bedoeling dat bepaalde soorten koppelingen niet in de gebruikte interfaces voorkomen. Zo is het niet toegestaan dat er barriers in de guardband van DDHOR- of DDVERT-randen voorkomen, omdat bijbehorende arrays niet te interpoleren zijn en omdat barriers nabij domein decompositie randen problemen kunnen veroorzaken met betrekking tot stabiliteit. Indien onverhoopt toch dergelijke punten in de guardband staan, zal COCLIB opmerken dat er voor zulke punten geen interpolatie is gedefiniëerd, waarna deze


6-28

fullbox s stcsv, stcsu, stcmax, stc1x, stc1y, ge odd 1x, ge even 1x, red3x, stc3, stc1, red3y, blk3x, blk3y. mnmaxk s stcmax, stc1x, stc1, stc2x fullbox u ubar max, stcuv*m1y, stcmax, stc1, stc1*1, red1*1, blck1*1 stcus(ddh-refine) alleen op koppelingen met horizontale roosterverfijning mnmaxk u stcus, stcmax, stc1x2, stcuv, bnd u max, bar us stcus(dd) alleen op koppelingen met deeldomeinen uit ander globaal domein stcmax(owndom) alleen voor subdomeinen uit eigen globaal domein nbaru stcmax nbaruv stcmax fullbox d stcmax mnmaxk d stcmax flux u stcus alleen voor ddv-*, ddh-* (fluxx) stcus(dd) alleen op koppelingen met deeldomeinen uit ander globaal domein of met andere laagverdeling Tabel 6.2: Voor elk van de index sets een lijstje van benodigde interfaces. De interfaces voor index sets van v-punten zijn niet opgenomen om ruimte te besparen. Zij komen overeen met die voor index sets van u-punten. na een duidelijke foutmelding het programma beëindigt.

6.7.4

Configuratie van de interpolaties

Zoals al in Sectie 4.2.7 is opgemerkt, worden er voor veel variabelen twee verschillende interpolatiemethoden aangeboden. Voordat de interpolatiemethoden kunnen worden geconfigureerd, moet eerst een keuze worden gemaakt. De twee mogelijke keuzes zijn: • eerste orde interpolatie: De waterstanden worden ge¨ınterpoleerd met de lokaal constante methode. De snelheden met de methode lineair in de stroomrichting en constant in de richting haaks erop (zie Figuur 4.6). De concentraties worden ge¨ınterpoleerd met de lokaal constante methode. meth_s = ’samecell’,

meth_uv = ’lin*weigh’

• tweede orde interpolatie: De waterstanden, snelheden en concentraties worden alle met bilineaire interpolatie ge¨ınterpoleerd. meth_s = ’bilin’,

meth_uv = ’bilin’

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) interpolatiemethode meth s meth r max meth s meth w meth uv max meth uv q-distr q-distr bilin max bilin

6-29

voor index sets fullbox s, mnmaxk s full s*kmax fullbox s en mnmaxk s full s*kmax0 fullbox u, mnmaxk u, fullbox u*kmax, full u*kmax0 mnmaxk u, fullbox u, full u*kmax mnmaxk u full u*kmax, 2*norows u*kmax fullbox d, mnmaxk d mnmaxk d, fullbox d

Tabel 6.3: Gebruikte interpolatiemethoden, en de index sets van de variabelen die met die methoden ge¨ınterpoleerd moeten worden. De tweede stap in de configuratie van de communicatie betreft de interpolatiemethoden. In vergelijking met eerdere versies is deze stap sterk uitgebreid, omdat er per koppelingscategorie apart moet worden opgegeven welke acties er moeten worden uitgevoerd. Hoewel er een groot aantal mogelijkheden is voor de stappen die tijdens een communicatie moeten worden uitgevoerd, kunnen ze alle worden beschreven binnen het volgende patroon: • Voor alle velden: – indien gewenst door een van de buurdomeinen: ∗ vul een tijdelijk opslagformaat met veld-waarden • Voor alle buren: – voor alle velden: ∗ zoek uit wat er verstuurd moet worden, pak dat in en verstuur. • Voor alle binnenkomende boodschappen: – pak de boodschap uit – verwerk de boodschap en plaats de resultaten op de gewenste plaats. • indien er nog onverwerkte informatie op tijdelijk opslagformaat staat: – Verwerk de informatie die op een tijdelijk opslagformaat staat. Ter illustratie van de configuratie van een interpolatiemethode beschrijven we de interpolatiemethode meth r (voor transportgrootheden) in detail.


6-30

1. Initialisatie: Als er interpolatiepunten zijn, waarvan de waarden via DDHOR-interpolatie moeten worden verkregen, maak dan een tijdelijk opslag-array op index set ovl s*kmax aan, en vul die met waarden uit het veld-array (dat leeft op index set full s*kmax) 2. Verzenden van boodschappen: Doe voor alle buurdomeinen: (a) Verzamelen: Bepaal of gebruikte coëfficiënten-sets zijn ververst en moeten worden verstuurd: • voor buren van koppelingstype ddv-sigfix: coëfficiënten-set seps full • voor communicatie op het tijdelijke (ovl s*kmax-)array: de masker-coeficienten khs. Verzamel veld-waarden voor verzending naar het buurdomein. Indien er een tijdelijk opslag-array gebruikt wordt, kunnen er waarden verzameld worden zowel uit het tijdelijke (ovl s*kmax-)array als uit het eigenlijke (full s*kmax-)array. (b) Verzend de verzamelde veld-waarden 3. Ontvangen van boodschappen: Verwerk de boodschap, afhankelijk van het koppelingstype van de verzender: • noddv: plaats de veldwaarden in het full s*kmax-array en/of het (ovl s*kmax-)array • ddv-fixfix: (a) interpoleer de veldwaarden voor het full s*kmax-array en/of het (ovl s*kmax-)array met basismethode cns lay avg en coëfficiëntenset zkg; (b) plaats de resultaten in het full s*kmax-array en/of het (ovl s*kmax-)array. • ddv-sigfix: (a) interpoleer de veldwaarden voor het full s*kmax-array met basismethode cns lay avg en coëfficiëntensets seps full en deps full; (b) plaats de resultaten in het full s*kmax-array. (c) interpoleer de veldwaarden voor het ovl s*kmax-array met basismethode cns lay avg en coëfficiëntensets seps ovl en deps ovl; (d) plaats de resultaten in het ovl s*kmax-array. 4. Verwerken van tijdelijke opslag: In sommige gevallen zijn de uitgewisselde gegevens nu opgeslagen in het tijdelijke opslagformaat (het ovl s*kmax-array) Deze moeten op de juiste wijze worden verwerkt tot veld-waarden (op het full s*kmax-array): (a) interpoleer binnen het ovl s*kmax-array.


6-31

(b) plaats de veldwaarden van het ovl s*kmax-array in het full s*kmax-array. In Tabel 6.3 is te zien welke interpolatiemethoden er allemaal gebruikt worden in de DDHOR-code. Deze kunnen alle worden geconfigureerd voor alle koppelingscategorieën zoals hierboven is ge¨ıllustreerd.

6.8

Administratie van roosterpunt-verzamelingen

Er komen allerlei verschillende berekeningen voor in WAQUA/TRIWAQ, zoals voor “de usnelheidspunten van een subdomein”, eventueel in- of juist exclusief de fysieke randpunten, in/exclusief bepaalde soorten subdomeinranden, en idem dito voor waterstandspunten en vsnelheidspunten. Voor de implementatie van de loops voor deze berekeningen werd in eerdere versies gebruik gemaakt van de irogeo-tabel en van de randcodes uit de irobou-tabel. Met de randcodes werden verschillende soorten randvoorwaarden worden aangeduid: gesloten, waterstand, snelheid, parallel, DDVERT, DDH-to-finer, etc. Deze manier van werken wordt door verschillende programmeurs aan de rekenroutines als moeilijk ervaren, en wordt ook steeds omslachtiger naarmate er meer verschillende soorten randcodes worden ge¨ıntroduceerd. Dit laatste is aan de orde in het DDH+V project door het gelijktijdig kunnen gebruiken van DDHOR en DDVERT.

6.8.1

Oorspronkelijk code voor de selectie van roosterpunten

Voor de implementatie van de loops voor deze berekeningen werd oorspronkelijk gebruik gemaakt van de irogeo-tabel. Deze tabel representeert het actieve (natte) gedeelte van het rooster als een lijst van “rijen” van actieve punten. De rijen worden aangeduid met triplets (n,mfu,ml), en het aantal rijen norows bepaalt de lengte van de tabel. Naast irogeo is er ook een tabel icolge voor de kolommen van het rooster, met lengte nocols. Deze arrays zijn oorspronkelijk bedoeld om één bepaalde deelverzameling van de roosterpunten te vinden: de interne waterstandspunten van een deeldomein. De loops die een berekening uitvoeren in al deze punten, hebben de volgende vorm:

100 110

do 110 irk = 1,norows n = irogeo(1,irk) mfu = irogeo(2,irk) ml = irogeo(3,irk) nmfu = iadres(n,mfu) nml = iadres(n,ml) do 100 nm = nmfu, nml, minc << Loop contents >> continue continue


6-32

Wanneer een berekening moet worden uitgevoerd in een andere deelverzameling van de roosterpunten, dan worden alternatieve grenzen bepaald voor de inner loop 100. Een loop over alle u-snelheidspunten van een deelrooster ziet er bijvoorbeeld als volgt uit:

200 210

do 210 irk = 1,norows n = irogeo(1,irk) mf = irogeo(2,irk)-1 ml = irogeo(3,irk) nmf = iadres(n,mf) nml = iadres(n,ml) do 200 nm = nmf, nml, minc << Loop contents >> continue continue

De loops worden gecompliceerd, en daardoor minder helder, wanneer de eigenschappen van de domeindecompositie een rol gaan spelen in de selectie van de roosterpunten. Een loop over de eigen u-snelheidspunten ziet er als volgt uit:

300 310

do 310 irk = 1,norows n = irogeo(1,irk) mf = irogeo(2,irk)-1 ml = irogeo(3,irk) msta = mf if (ibf.ge.ibitfc .and. ibf.ne.ibddhc) msta=mf+1 mend = ml if (ibl.eq.ibddhf) mend=ml-1 nmsta = iadres(n,msta) nmend = iadres(n,mend) do 300 nm = nmsta, nmend, minc << Loop contents >> continue continue

De complexiteit zit erin dat er voor verschillende soorten loops verschillende logische expressies worden gebruikt, en dat het de nodige training vereist om uit de logische expressies de bedoeling te reconstrueren.

6.8.2

Systematische naamgeving van loop-structuren

In de loop der tijd is er een systematische naamgeving ontwikkeld voor het beschrijven van loops in de rekengedeeltes van WAQUA en TRIWAQ. We gebruiken hierbij de term loop-index set om verzamelingen van roosterpunten aan te duiden die door een bepaalde loop-structuur worden afgelopen.


6-33

De systematische naamgeving van loop-index sets bestaat uit maximaal 6 woordjes achter elkaar: < subdomain > − < global status > − < drywet status > − < point type > − < boundary type > − < boundary direction > Elk van de woordjes geeft een reden aan waarom een roosterpunt wel of niet tot de loop-index set moet horen. De verschillende woordjes worden uitgelegd in Appendix K van de Technische Documentatie van TRIWAQ. De verschillende onderdelen hebben de volgende mogelijkheden: subdomain global status drywet status point type boundary type boundary direction

all, own all, int, bnd, active all, dry, wet, floodable wlp, up, vlp, dp all, open, closed, wl, veloc all, xdir, ydir

Bij alle woorden behalve het subdomain-gedeelte is de keuze all de default, en wordt daarom weggelaten. Het subdomain-gedeelte heeft geen default: de keuze wordt altijd aangegeven. Voorbeelden van loop-index sets die veelvuldig worden gebruikt in de data-analyse van WAQUA/TRIWAQ zijn own-up, own-wet-up, all-int-up, all-wlp-xdir etc. Er kan een scheiding worden gemaakt tussen bewerkingen die alleen op randen interfacepunten moeten worden uitgevoerd, en bewerkingen die (ook) voor interne punten moeten worden uitgevoerd. Voor de eerste soort bewerkingen (op de rand en interface) is namelijk een enkele loop voldoende, terwijl voor de tweede soort (interne punten) een geneste loop nodig is. Het blijkt dat de twee soorten bewerkingen een andere behandeling vergen. Loops voor randpunten kunnen goed worden uitgevoerd met de huidige irogeo-tabel met geschikte codering van de randen (zie alternatief 1. hieronder), terwijl dit voor loops over (ook) interne punten niet voldoende vereenvoudiging oplevert. De systematische naamgeving wordt gebruikt in de documentatie van de berekeningen ten behoeve van de data-analyse, en blijkt daarbij heel goed te helpen bij het doorgronden van de code. Het is daarom gewenst dat dit wordt doorgetrokken naar de code zelf. Daarbij hoeven voor de loop-structuren alleen de attributen subdomain, global status, point type en boundary direction te worden gebruikt. De belangrijke loop-index sets voor WAQUA/TRIWAQ zijn all-wlp, all-wlp-xdir, all-wlp-ydir, all-int-wlp, all-up, all-int-up, all-vp, all-int-vp, own-wlp-xdir, own-wlp-ydir, own-up en own-vp. Een manier die we hiervoor hebben gevonden is om integer codes te gebruiken met korte namen die bij elkaar worden opgeteld: c global status criterion integer jALL, jINT, jBND, jACT parameter (jALL=0, jINT=1, jBND=2, jACT=3) c subdomain criterion integer jOWN


6-34

parameter (jALL=0, jOWN=-4) c point type criterion integer jWLP, jUP, jVP, jDP parameter (jWLP=0, jUP=-8, jVP=-16, jDP=-24) c boundary direction criterion integer jXDIR, jYDIR parameter (jALL=0, jXDIR=-32, jYDIR=-64) In de FORTRAN-code ziet de systematische naamgeving er aldus uit: iset

= jALL-jWLP-jXDIR

Dit levert het nummer 32 op voor loop-index set all-wlp-xdir.

6.8.3

Alternatief 1: apart array van rand-codes ISBBOU

Een eerste mogelijkheid om de code te vereenvoudigen is door de informatie over randcodes in twee stukken te verdelen: informatie over fysische randen (open, gesloten), en informatie over subdomeinranden. Het eerste stuk blijft opgeslagen in array irobou, en gebruikt de volgende codes: code 0 niet-fysische, interne rand, voor domein decompositie of parallel rekenen code 1 gesloten rand code 2 open rand met waterstandsrandvoorwaarde code 3 open rand met snelheidsrandvoorwaarde code 5 open rand met debietrandvoorwaarde code 6 open rand met Riemann randvoorwaarde Het tweede stuk van de randcodes maakt onderscheid mogelijk tussen verschillende soorten subdomeinranden, en wordt opgeslagen in array isbbou. Dit array bevat 7 (nsbbou) kolommen, die als volgt zijn gedefiniëerd: kolom 1 - icple 1 0

= “is gekoppeld”, subdomeinrand, = geen koppeling (fysische rand)

kolom 2 −1 0 1

ifinr = buurdomein is fijner verroosterd dan eigen subdomein, = horizontaal en vertikaal 1:1 aansluitende roosters, = eigen subdomein is fijner verroosterd dan buurdomein.

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) kolom 3 −1 0 1

ihfin = buurdomein is horizontaal fijner dan eigen subdomein, = horizontaal 1:1 aansluitende roosters, = eigen subdomein is horizontaal fijner dan buurdomein.

kolom 4 −1 0 1

ivfin = buurdomein is vertikaal fijner dan eigen subdomein, = vertikaal 1:1 aansluitende roosters, = eigen subdomein is vertikaal fijner dan buurdomein.

6-35

kolom 5 - isamd 1 = buurpunt hoort bij hetzelfde globale domein (zelfde siminpfile: parallel rekenen of DDVERT), 0 = buurpunt hoort bij een ander globaal domein. kolom 6 - iuphys 0

= u-punt is geen fysiek randpunt (interne rand voor parallel rekenen of domein decompositie), 1 = u-punt is een fysiek randpunt met gesloten randvoorwaarde, 2 = u-punt is een fysiek randpunt met waterstandsrandvoorwaarde, 3 = u-punt is een fysiek randpunt met snelheidsrandvoorwaarde, 5 = u-punt is een fysiek randpunt met debietrandvoorwaarde, 6 = u-punt is een fysiek randpunt met Riemann randvoorwaarde. kolom 7 - iumyds 0 1

= u-punt aan begin/eind van de rij/kolom is geen discretisatiepunt van het eigen deeldomein (is een interpolatiepunt of hoort bij een ander deeldomein), = u-punt aan begin/eind van de rij/kolom is een discretisatiepunt van het eigen deeldomein.

kolom 8 - itrcpl 1 0

= “is gekoppeld”, subdomeinrand, voor het transportprobleem = geen koppeling (fysische rand) voor het transportprobleem.

kolom 9 - itrphs 0 1 2

= wl-punt is geen fysiek randpunt voor het transportprobleem (interne rand voor parallel rekenen of domein decompositie), = wl-punt is een fysiek randpunt voor het transportprobleem met gesloten randvoorwaarde, = wl-punt is een fysiek randpunt voor het transportprobleem met Dirichlet/outflow randvoorwaarde met Tatcher-Harlemann methode.

Merk op dat kolom 6 identiek is aan wat in irobou wordt opgeslagen, het array irobou kan hiermee worden geelimineerd.


6-36

In de programmatuur worden statement-functies gebruikt om de goede kolom van isbbou te selecteren. Bijvoorbeeld lcoupl(jbgdum,irkdum) = isbbou(jbgdum,1,irkdum).eq.1 luphys(jbgdum,irkdum) = isbbou(jbgdum,6,irkdum).ge.1 lumyds(jbgdum,irkdum) = isbbou(jbgdum,7,irkdum).eq.1 Hiermee betekent de conditie (luphys(1,ic)) “aan het begin van rij ic geldt een fysieke randvoorwaarde”. Met deze herordening van randcodes worden de logische expressies in de rekenroutines korter en overzichtelijker, maar blijven ze wel bestaan.

6.8.4

Alternatief 2: extra tabellen van rijen, op basis van array indices (nm)

De verschillende logische expressies kunnen worden omzeild door aparte arrays te maken voor de verschillende soorten loops die moeten worden uitgevoerd, in plaats van al die loops uit te voeren met een enkel array irogeo. In de uitwerking van deze oplosrichting zijn twee formaten bedacht: arrays met triplets (n,m0,m1) zoals in irogeo worden gebruikt, of arrays met paren (nm0,nm1) die ranges aanduiden in de platgeslagen array-adressering (jstart:mnmaxj). Bij de realisatie van DDH+V is ervoor gekozen om alleen de tweede hiervan verder uit te werken. Een loop-indexset kan worden gerepresenteerd met een masker van nullen en enen met afmetingen (jstart:mnmaxj). In dit masker wordt gekeken welke opeenvolgende elementen samen een “rijtje” vormen. Deze intervallen van actieve punten worden als paren (nm0,nm1) (start, eind) opgeslagen in een tabel. De aparte tabellen voor verschillende loop-structuren hebben verschillende lengtes. Bovendien worden de loop-structuren door het generieke schema uit paragraaf 6.8.2 genummerd van 0 tot en met 127 (nixset), maar worden er hiervan slechts een tiental daadwerkelijk gebruikt. Daarom is het niet praktisch om een drie-dimensionaal array te gebruiken voor alle loopstructuren. De tabellen voor verschillende loop-indexsets worden onder elkaar geplakt in een array nmloop(2,tot num rows). Een apart index-array nmixst(2,0:nixset) geeft per loopstructuur aan wat de eerste en laaste bijbehorende rijen in nmloop zijn. Met deze opslagstructuren kan de loop 300 voor de deelverzameling own-up van paragraaf 6.8.1 als volgt worden geprogrammeerd:

500 510

do 510 irk = nmixst(1,jOWN-jUP), nmixst(2,jOWN-jUP) do 500 nm = nmloop(1,irk), nmloop(2,irk) << Loop contents >> continue continue


6.8.5

6-37

Overwegingen met betrekking tot de alternatieven

Voordelen van de “platte” indicering (alternatief 2, loop 500) zijn als volgt: 1. De loops worden compacter en leesbaarder dan met de alternatieven. 2. De loops kunnen 20-30% sneller uitgevoerd worden, omdat het geheugen efficienter wordt benaderd. 3. Een enkele tabel is geschikt voor berekeningen in x èn y richting, in tegenstelling tot de irogeo-tabel, waar altijd een icolge-tabel tegenover staat. Nadelen zijn: 1. De platgeslagen structuren zijn niet toepasbaar voor alle loops over de roosterpunten. Berekeningen die afhangen van de rij-ordening (zoals het lijn-Gauss-Seidel proces in waslgs) kunnen niet worden uitgevoerd met behulp van de platte loop-structuur. Ook het stop-criterium per rij in subroutines trssuw en trsdif, en het vegen van tri- en penta-diagonale stelsels in trstrd en waspnd kan slechts met grote moeite (d.w.z. minder leesbaar) met dit alternatief worden ge¨ımplementeerd. 2. Als de oorspronkelijke irogeo-loops gebruikt blijven worden naast het nieuwe formaat (en dat is welhaast onontkoombaar) dan komen er twee verschillende loop-formaten in de programmatuur voor. 3. De platte loop-structuur komt nog niet voor in de code, en de programmeurs zullen daar aan moeten wennen. Alternatieven 1 en 2 zijn beiden ge¨ımplementeerd in de nieuwe versie DDH+V.

6.8.6

Implementatie in WAQUA/TRIWAQ

De implementatie van het hierboven gepresenteerde ontwerp (alternatieven 1 en 2) bestaat uit de volgende onderdelen: 1. aanmaken en vullen van de tabellen nmixst en nmloop. de nieuwe routine wascge maakt de arrays aan en doet een call naar de routine wasgeo, die ze vult. De routine wascge wordt op twee plaatsen aangeroepen door waspig. De volgende intgda-entries worden gebruikt om de arrays te vinden: intgda(429,1) = nsbbou aantal kolommen in het array isbbou (nsbbou = 7). intgda(430,1) = nixset aantal loop-index sets dat kan worden opgeslagen in nmixst en nmloop (nixset = 127). intgda(431,1) = nmsize aantal kolommen in het array nmloop (nmsize is vooraf onbekend).


6-38

intgda(446,1) = isbbou INFOR index van isbbou. intgda(447,1) = inmixs INFOR index van nmixst. intgda(448,1) = inmlop INFOR index van nmloop. Het array nmloop kan de loop-index set in sommige gevallen aangeven met intervallen die over verschillende rooster-kolommen verspreid liggen, omdat de punten (m,nmax) en (m+1,1) aansluitende nm-indices hebben. Er is echter voor gekozen zulke intervallen op te breken. De reden is, behalve controleerbaarheid en helderheid, dat er problemen kunnen ontstaan in de bepaling van rode en zwarte punten in de Gaus-Seidel processen. 2. doorsluizen van de nieuwe arrays naar alle relevante rekenroutines. De arrays nmixst en nmloop worden doorgegeven aan en dertigtal routines. 3. aanpassen van loops met behulp van de nieuwe arrays. De loops in de genoemde arrays zijn aangepast. 4. aanmaken en vullen van het array isbbou. Het array isbbou wordt aangemaakt door de routine wascge, en in drie stappen gevuld. wascge vult icple, en kopieert de fysieke randcodes uit irobou, wagbou vult de koppelingsinformatie in die betrekking heeft op het eigen globale domein (parallel rekenen en DDVERT), en wagov1 bepaalt de informatie voor DDHOR-randen. 5. doorsluizen van het nieuwe array naar alle relevante rekenroutines. Het array isbbou wordt doorgegeven aan een kleine veertig routines. 6. aanpassen van de beschrijving van variabelen. Dit betreft irobou in het commentaar van de rekenroutines, en het invullen van een voldoende beschrijving van de nieuwe arrays. 7. testen van de aanpassingen.

6.9

Overige aspecten in WAQPRO

In de vorige secties is een groot aantal aspecten besproken die bij de koppeling van deeldomeinen voor WAQPRO van belang zijn. Een klein aantal zaken is daarbij nog niet aan bod gekomen, en die worden in deze sectie besproken.

6.9.1

Voortzetting van de fysische co¨ ordinaten in de guardband

Bij DDHOR-simulaties zijn de roostercoördinaten van een deeldomein niet beschikbaar in de guardbands, omdat die buiten het eigen domein kunnen liggen. In de guardband worden de fysische coördinaten daarom overschreven door de interpolatie-waarden van de beschikbare coördinaten van de buur-domeinen. Als gevolg hiervan moet ook een aantal van de rooster-transformatiecoëfficiënten worden herberekend. Hierbij worden zoveel mogelijk


6-39

rooster-transformatiecoëfficiënten van betekenisvolle waarden voorzien, eventueel door middel van extrapolatie. Speciale aandacht is nodig wanneer gebruik gemaakt wordt van bolcoördinaten. In dat geval worden de coördinaten namelijk gegeven in radialen, en de rooster-transformatiecoëfficiënten in (vierkante) meters.

6.9.2

Globale rijen

Globale rijnummers worden gebruikt door wasck2 om te bepalen of het stelsel voor een bepaald rij voldoende nauwkeurig is opgelost, zodat deze uit de berekening kan worden genomen. Het is soms onjuist om in het geval van een “echte” DDHOR-koppeling (d.w.z. niet 1:1) een rij uit de berekening te nemen. Zo’n rij kan immers via verfijningen en vergrovingen gekoppeld zijn met een groot aantal andere rijen (zie Figuur 4.9). In een simulatie met horizontale verfijning moet een globale rij daarom worden gezien als de verzameling van alle in het stelsel aan elkaar gekoppelde roosterpunten. Er moet een algoritme worden geconstrueerd voor het nummeren van deze verzamelingen. Net zoals het algoritme voor globale rij-nummering dat in wasrnm wordt gebruikt, wordt begonnen elke rij waarvan het begin (fysische rand) in het eigen deeldomein ligt, per deeldomein te nummeren. Door aan elk deeldomein een offset toe te kennen, krijgen al deze rijen een uniek nummer. Deze rij-nummers worden op een array (index set mnmaxk s voor WAQUA, fullbox s voor TRIWAQ) verwerkt. Middels een communicatie met methode max meth s worden deze rij-nummers uitgewisseld. Vervolgens wordt voor alle rijen het rij-nummer in het guardbandpunt (n,mf) vergeleken met dat van het binnen-punt (n,mfu). De volgende situaties kunnen zich voordoen: 1. Zowel het guardbandpunt als het eigen punt hebben nog geen rij-nummer. Er wordt geen actie ondernomen. 2. Het guardbandpunt heeft nog geen rij-nummer, het eigen punt al wel. Er wordt geen actie ondernomen. 3. Het guardbandpunt en het eigen punt hebben het zelfde rij-nummer. Er wordt geen actie ondernomen. 4. Het guardbandpunt heeft een rij-nummer, het eigen punt nog niet. Alle punten (n,mfu) tot en met (n,ml) krijgen het rij-nummer van het guardbandpunt. 5. Het guardbandpunt en het eigen punt hebben een verschillend rij-nummer. Alle punten in het eigen domein waarvan het rij-nummer gelijk is aan het laagste van de twee rij-nummers, krijgen het hoogste van de rij-nummers. Vervolgens wordt het rij-nummer van het guardbandpunt (n,mlu) op dezelfde manier vergeleken met dat van het binnen-punt (n,ml). Op deze manier worden ook rijen ter lengte 0, die in parallelle koppelingen voor kunnen komen, correct verwerkt.


6-40

Communicatie wordt zolang herhaald totdat er geen rij-nummers meer kunnen worden ingevuld of veranderd. Alle inwendige punten moeten nu een rij-nummer hebben. Tot slot wordt een aaneengesloten nummering verkregen door middels globale reductie te achterhalen welke rij-nummers ontbreken, en vervolgens een her-nummering door te voeren.

6.9.3

Rij-kleuring voor BJ-TWGE en voor uitgaande informatie

Bij het BJ-TWGE algoritme worden vergelijkingen uitgewisseld tussen domeinen. Hierbij is het van belang dat de ontvangen vergelijking geen onbekenden bevat die buiten het domein liggen, en dat de ontvangen vergelijking ook daadwerkelijk gebruikt wordt in de volgende berekening. Hiervoor is het van belang dat gekoppelde rijen “naar elkaar toe” vegen: als een domein de vergelijkingen voor een rooster-rij van links naar rechts veegt, dan moet het buur-domein voor de gekoppelde rij van rechts naar rechts vegen. Als dit niet correct gebeurt, werkt het algoritme niet. Aangezien in het BJ-TWGE algoritme een blok-Jacobi koppeling wordt gebruikt in geval van horizontale verfijning, is de veeg-richting voor dergelijke randen niet van belang. WAQUA zorgt er voor dat het BJ-TWGE algoritme niet in de war raakt door aan elke rij een kleur toe te kennen: rood of zwart. Zwarte rijen worden van het achter naar voren geveegd, rode van voor naar achter. Wanneer een rij niet aan een andere rij is gekoppeld, maakt de kleur niet uit en wordt de rij rood gekleurd. Wanneer twee rijen alleen aan elkaar zijn gekoppeld, en zich aan de andere kant dus een echte rand bevindt, wordt altijd van de echte randen naar de koppeling geveegd. Wanneer een groter aantal rijen aan elkaar is gekoppeld, wordt de veeg-richting per iteratie omgewisseld. Daardoor wordt op sommige koppelingen in de even iteraties een blok-Jacobi randvoorwaarde gebruikt, en op de andere in oneven iteraties. Bij de koppeling op basis van uitgaande informatie speelt een soortgelijke kwestie als bij BJ-TWGE. Deze koppeling is echter iets minder gevoelig voor de juiste kleuring: wanneer de kleuring van rijen in de war zou komen, wordt geen onjuiste uitgaande informatie doorgegeven, maar wordt slechts iets verouderde uitgaande informatie doorgegeven. Dit zou resulteren in een suboptimale, maar nog steeds efficiënte koppeling. Voor deze koppeling is de rij-kleuring echter ook van belang voor randen met horizontale verfijning, omdat ook op verfijnde randen uitgaande informatie wordt uitgewisseld. Bij de introductie van de koppeling op basis van uitgaande informatie is daarom de rij-kleuring zodanig aangepast dat ook op verfijnde randen een zo gunstig mogelijk veeg-patroon ontstaat. Dit veeg-patroon wordt ge¨ıllustreerd in Figuur 6.10. Het bestaat uit de volgende vijf stappen: trsswp Eerst wordt elk tridiagonaal deel-stelsel geveegd van links naar rechts of van rechts naar links, afhankelijk van de gekozen rijkleur. Op dubbel-gekoppelde rijen moet aan een kant een blok-Jacobi voorwaarde worden gebruikt. Op dergelijke rijen wordt daarom ook een extra (homogeen) stelsel geveegd, zodat later een betere koppeling kan worden gebruikt.


6-41

trsout Op alle interfaces wordt vervolgens de uitgaande informatie uitgewisseld en geanalyseerd. Op de uiteinden van dubbel gekoppelde rijen waar een blok-Jacobi conditie is gebruikt, wordt de uitgaande informatie uit de vorige iteratie uitgewisseld. Deze wordt echter niet gebruikt als de rijkleuring optimaal is. De informatie wordt alleen uitgewisseld op plaatsen waar deze in de eerstvolgende berekening nodig is. Welke informatie dat is, wordt opgeslagen in een array icalcp en in speciale communicatie-interfaces. trssub In de volgende stap wordt voor niet-gekoppelde rijen en voor dubbel gekoppelde rijen het stelsel opgelost door middel van achterwaartse substitutie van het geveegde stelsel. Op dubbel gekoppelde rijen is vooralsnog een blok-Jacobi voorwaarde gebruikt aan een van beide uiteinden. Om een betere koppeling te krijgen aan dat uiteinde, wordt nu de uitgaande informatie opgesteld. Ook wordt het homogene stelsel opgelost, zodat een correctie voor de blok-Jacobi koppeling kan worden doorgevoerd. trsout Weer wordt op, de interfaces waar dat nodig is, uitgaande informatie uitgewisseld en geanalyseerd. trssub Tot slot worden de stelsels opgelost in alle enkel-gekoppelde rijen door middel van achterwaartse substitutie. In dubbel gekoppelde rijen wordt een correctie doorgevoerd voor de gebruikte blokJacobi voorwaarde.

6.9.4

Procesgroepen voor communicatie voor barriers en debietrandvoorwaarden

In een aantal routines waarin berekeningen worden uitgevoerd voor barriers en debietrandvoorwaarden, komen communicatie-operaties voor die problematisch kunnen zijn in het geval van een gecombineerde DDHOR/parallelle run. Het gaat hier om globale communicaties waarin een aantal termen moet worden opgeteld, en waarbij deze termen verspreid kunnen zijn over een aantal processen. In de DDVERTversie worden deze communicaties uitgevoerd door de routine cocrgl. Deze routine berekende in eerdere versies de maxima, totalen of minima van een array over alle deelnemende processen. In de DDHOR-code zal deze routine extra functionaliteit krijgen, en zullen de maxima, totalen of minima van een array over alle deelnemende processen uit een groep van processen berekend kunnen worden. Dit maakt het bijvoorbeeld mogelijk om de informatie over alle QAD-openingen uit een domein te verkrijgen. In de code zullen hiervoor de volgende proces-groepen worden gedefiniëerd: • all: alle processen, • mydomain: de groep van processen die bij het zelfde domein horen, • havebarr owndomain: de groep van processen waarin barriers voorkomen en die bij het zelfde domein horen,


Subdomain 2 3

1 trsswp trsout trssub trsout trssub

6-42

X

4 X

X axpy

axpy

Subdomain 1 trsswp trsout trssub trsout trssub

2

3

X X axpy

sweep/substitute system/solution sweep/substitute homogeneous system/solution Block−Jacobi condition X exchange and analyse outgoing information axpy correction for Block−Jacobi condition Figuur 6.10: Illustratie van het veeg-algoritme voor globale rijen die zijn verdeeld over een even (boven) of oneven (onder) aantal subdomeinen. • haveqad owndomain: de groep van processen waarin QAD-openingen voorkomen en die bij het zelfde domein horen, • haveqh owndomain: de groep van processen waarin QH-openingen voorkomen en die bij het zelfde domein horen.

6.9.5

Controle op correcte modelinvoer voor barriers

Door WAQPRO moeten controles worden uitgevoerd op het vóórkomen van barriers in DDHOR- of DDVERT- guardbands. Ook moet WAQPRO controleren of de partitionering de correcte afhandeling van dynamische barrier-sturing niet verstoort. Deze controles kunnen worden uitgevoerd met behulp van een aantal eenvoudige communicaties. Bij de controle op het vóórkomen van barriers in de DDHOR- en DDVERT- guardbands wordt een vlaggen-array ibarfl aangemaakt op index set fullbox u (TRIWAQ) of mnmaxk u (WAQUA). Hierin worden alle barrier punten gemerkt met een 1, terwijl alle overige punten


6-43

met een 0 worden gemerkt. Door communicatie met interpolatiemethode max meth uv worden ook de barrier punten in de guardband gevonden. Al deze guardband barrier punten mnbar moeten in parallel gekoppelde deeldomeinen liggen: de koppelingscategorie van deeldomein POWNER(mnbar) dient par te zijn. Bij dynamische barriersturing kan het voorkomen dat de waterstand in een checkpoint gebruikt moet worden, terwijl dat checkpoint in een deeldomein ligt dat van de berekening is uitgesloten. Het zelfde kan gebeuren met een cross-section, waarvan het debiet gebruikt moet worden. Dergelijke fouten in de invoer kunnen worden gedetecteerd door vlaggen-array te maken van alle checkpoints die nodig zijn, en van alle checkpoints die beschikbaar zijn. Na globale reductie over alle processen van de groep have barr mydom kan worden gecontroleerd of alle benodigde checkpoints ook beschikbaar zijn.


7-1

Hoofdstuk 7 Het matchen van (deel-)roosters voor DDHOR 7.1

Inleiding

Een vernieuwing in de eerste versie DDHOR ten opzichte van het prototype is dat de koppelingsranden tussen subdomeinen (multi-curves) niet meer worden opgegeven door de gebruiker, maar moeten worden afgeleid uit de rooster-coördinaten per subdomein. Dit afleiden noemen we het “matchen van (deel-)roosters”. Daarbij moeten ook de verfijningsfactoren automatisch worden bepaald. Het matchen is zowel nodig in COEXEC als in WAQPRO. In COEXEC is dit voor het uitvoeren van controles op de gebruikersinvoer. Daarbij wordt ook aandacht besteed aan de laagverdelingen van deeldomeinen van verschillende globale domeinen die aan elkaar zijn gekoppeld. In WAQPRO is het match-gedeelte vooral nodig voor het vullen van datastructuren ten behoeve van communicaties in DDHOR berekeningen. Dit stelt meer eisen aan de matchprocedure dan de controles in COEXEC, namelijk dat alle benodigde data worden bepaald voor het aanmaken van overlap-sets. Het matchen blijkt met name een complex probleem te zijn wanneer de eigenschappen van de te koppelen deelroosters en de overlap-sets niet goed zijn gespecificeerd of afgebakend. Daarom worden in dit hoofdstuk eerst keuzes gemaakt ten aanzien van de te koppelen deelroosters en guardbands (paragrafen 7.2 en 7.3) en wordt het wezen van overlap-sets beschreven (paragraaf 7.4). Vervolgens worden moeilijkheden bij de invulling van de guardband beschreven en het daaruit volgende matching probleem (paragraaf 7.5). Tenslotte wordt in paragraaf 7.6 een gedetailleerd ontwerp gegeven voor een module voor het matchen van deelroosters, en wordt beschreven hoe deze module in COEXEC en WAQPRO wordt gebruikt.

7.2

Specificatie van het globaal discretisatie rooster

In het prototype DDHOR en het oorspronkelijk detail ontwerp voor de eerste complete versie met horizontale verfijning (v1.0) is het totale rooster waarop wordt gerekend beschreven


7-2

vanuit afzonderlijke gestructureerde roosters per deeldomein. Na diepgaande bestudering van het matchingsprobleem en de controles die daarin worden uitgevoerd stellen we nu dat de volgende presentatie beter is, waarin wordt uitgegaan van een enkel globaal te modelleren gebied. De manier waarop horizontale verfijning wordt mogelijk gemaakt met de huidige versie van DDHOR is als volgt. Er wordt een gebied geselecteerd (geometrie gedefiniëerd) dat moet worden gemodelleerd. Voor dit gebied wordt verondersteld dat er een globale coördinatentransformatie ˜ η˜) = (ξ(x, ˜ y), η˜(x, y)) (ξ,

(7.1)

is of bestaat. Equivalent hiermee is dat er voor het totale te modelleren gebied een enkel gestructureerd orthogonaal kromlijnig superfijn rooster is te definiëren. Nu wordt het totale gebied opgedeeld in niet-overlappende stukken, gedecomponeerd in ˜ η˜)-coördidomeinen. Per domein wordt een rooster gedefiniëerd dat aansluit bij de globale (ξ, naten: alle roosterlijnen van alle domeinen vallen samen met roosterlijnen uit het superfijne rooster, dus voldoen aan ξ˜ = constant of η˜ = constant. Hierbij worden roosterlijnen alleen in beschouwing genomen voor zover ze niet over land lopen. De doorsnedes van twee riviertakken door een lijn “m = constant” in het superfijne rooster worden als twee aparte roosterlijnen opgevat. De verzameling van roosters voor de verschillende domeinen definiëert het zogenaamde globaal discretisatie rooster waarop in DDHOR berekeningen de ondiep-water vergelijkingen worden gesimuleerd. (Alleen de cell-faces van grove domeinen op de interface horen niet bij het discretisatierooster, zie verder.) Het definiëren van een rooster per domein is equivalent met het selecteren van roosterpunten en -lijnen uit het superfijne rooster. Hierbij kunnen echter uit de ene riviertak meer lijnen (doorsnedes) worden weggegooid dan uit de andere, het globaal discretisatierooster is dus niet langer eenvoudig gestructureerd. Ten behoeve van het opstellen van discretisaties worden de roosters per domein uitgebreid met een guardband. Hiervoor wordt het WAQUA-rooster van dieptepunten beschouwd. De roosterlijnen door de dieptepunten definiëren een opdeling van het te simuleren domein in rekencellen. De keuze die wordt gemaakt voor de omvang van de guardband is hiermee uit te drukken als drie cellen diep, en een cel breed (aan het begin en einde van iedere interface, lijn van samenvallende roosterpunten). Deze keuze wordt in paragraaf 7.3 gemotiveerd. De domeinen waarin het totale gebied wordt opgedeeld worden opgegeven aan het simulatie-systeem via afzonderlijke siminp-files. Daarbij kunnen stukken uit bestaande siminpfiles worden gemarkeerd als inactief , het domein wordt dan ge¨ıdentificeerd met de actieve gedeeltes. Verder kan ieder domein worden opgedeeld in meerdere stukken, subdomeinen, bijvoorbeeld voor parallelle berekening. De specificatie van het globaal discretisatie rooster kan nu ook worden beschreven via de roosters per domein. Belangrijke voorwaarden die daarbij moeten worden gesteld zijn nu: • de oriëntatie van naburige roosters moet hetzelfde zijn op de interface: ξ-lijnen mogen alleen aan ξ-lijnen gekoppeld worden en η-lijnen aan η-lijnen, en η/n of ξ/m-coördinaten langs de interface moeten in beide roosters in dezelfde richting oplopen;


7-3

• in de overlappende gedeeltes van verschillende roosters (de guardbands) moeten de logische coördinaten (ξ, η) per rooster consistent met elkaar zijn, door middel van translatie en schaling in elkaar over te voeren; • roosterlijnen mogen niet rondlopen zonder globaal begin en einde. In de huidige versie van DDHOR worden daarnaast de volgende eisen gesteld aan de roosters per domein: • van naburige roosters moet eenduidig zijn aan te geven welke grover en welke fijner is of ze moeten steeds 1:1 gekoppeld zijn: er moet een grof-fijn relatie bestaan; • de dieptepunten op de interface en in de guardband van het grove rooster moeten samenvallen met dieptepunten van het fijne rooster. Alleen aan de beide uiteinden van een interface mag de interface op het fijne rooster iets breder of smaller zijn dan op het grove rooster. Als de interface breder is, worden schotjes geplaatst op de extra breedte. Hierbij wordt een waarschuwing gegeven. • de roosterlijnen loodrecht op de interface mogen niet te sterk gekromd zijn; • verschillende interfaces van hetzelfde rooster mogen niet aan elkaar gekoppeld worden. Het bestaan van een grof-fijn relatie is nodig om te kunnen praten over “het grove (fijne) rooster”, maar heeft ook voordelen voor de afhandeling van communicaties binnen COCLIB. De keuze voor het laten samenvallen van dieptepunten op de interface zorgt voor het eenvoudiger kunnen forceren van massabehoud, door het kunnen matchen van cellfaces van de domeinen aan weerszijden van de interface. Voor de roosterpunten in de guardband wordt deze keuze gemaakt met het doel om fysische coördinaten te kunnen vervangen door logische coördinaten ten opzichte van het eigen rooster (subdomein). Dit vereenvoudigt de interpolaties, omdat de cellfaces van het ene domein in logische coördinaten gezien niet enigszins gedraaid kunnen zijn ten opzichte van die in het andere domein, terwijl ze dat in fysische coördinaten wel kunnen zijn. Wel mogen vanwege deze keuze de roosterlijnen op de interface niet te sterk gekromd zijn, omdat sterke kromming leidt tot minder nauwkeurige resultaten. De eisen ten aanzien van de oriëntatie, het rondlopen van roosterlijnen en het aan zichzelf koppelen zijn voornamelijk ge¨ıntroduceerd voor het omzeilen van programmeer-technische complicaties. Als ξ- aan η-lijnen gekoppeld zouden worden dan ontstaan moeilijkheden met de nummering van halve tijdstappen in verschillende rekenprocessen alsook potentiële problemen met lussen, zichzelf snijdende roosterlijnen. Als een vertikale interface in de twee naburige domeinen tegengesteld genummerd zou worden, dan worden twee rij-eindes aan elkaar gekoppeld en wordt de u-snelheid voor de een −u voor de ander. Het rondlopen van roosterlijnen zorgt ervoor dat een rij of kolom geen globaal begin en einde meer heeft, waardoor tri-diagonale stelsels overgaan in cyclisch. Het is a priori niet duidelijk of dit moeilijkheden oplevert. In ieder geval zouden er wel speciale uitbreidingen nodig zijn in het algoritme voor het kleuren van sub-rijen. Het aan zichzelf koppelen van subdomeinen tenslotte kan allereerst niet worden gebruikt voor verfijning (grof-fijn relatie!), en vereist daarnaast ook speciale afhandeling in de


7-4

communicatie-bibliotheek bij het versturen en ontvangen van boodschappen. Deze eis wordt net als het bestaan van een grof-fijn relatie in de programmatuur feitelijk niet per rooster of siminp-file maar per rekenproces (deelrooster) opgelegd.

7.3

Specificatie van de guardband; samengesteld gestructureerde roosters

In de DDHOR programmatuur worden de deelroosters uitgebreid met een guardband, voor het opslaan van (ge¨ınterpoleerde) waardes van naburige subdomeinen. De verzameling van deelroosters en guardbands definiëert een samenstelling van gestructureerde roosters, en wordt een samengesteld gestructureerd rooster genoemd. In de vorige paragraaf is al een primaire keuze ten aanzien van de guardband gemaakt, namelijk dat we eisen dat de roosterlijnen van de guardband de roosterlijnen van het naburige domein volgen: • alle dieptepunten van het grove subdomein vallen samen met dieptepunten van fijnere domeinen; • de guardband roosterlijnen van het fijne domein hebben een constante (mogelijk gebroken) waarde van ξ of van η in het coördinatensysteem van het grovere domein. Deze keuzes zorgen ervoor dat het samengestelde rooster in logische coördinaten eenvoudiger is dan in fysische coördinaten. Op het niveau van de logische coördinaten bestaat ieder deelrooster uit een verzameling rechte roosterlijnen met ξ constant of η constant. De waterstandspunten van het eigen domein en de eigen guardband hebben integer coördinaten ξ = m en η = n, de dieptepunten van het eigen domein gebroken coördinaten ξ = m ± 0.5, η = n±0.5 die één op één zijn te identificeren met integer waardes m, n (array index, WAQUA staggered grid conventie). De ξ- en η-coördinaten van naburige subdomeinen zijn constant per roosterlijn en kunnen in principe willekeurige waardes hebben. Deze structuur kan worden benut bij het implementeren van zoek-procedures en interpolatiemechanismen voor de communicatie-bibliotheek COCLIB. Ten behoeve van de transportsolver in TRIWAQ is een guardband vereist van drie rijen en kolommen van cellen ten opzichte van het eigen subdomein. Dit maakt het mogelijk om de discretisaties voor het inwendige van een subdomein ook toe te passen nabij subdomeininterfaces, zodat in geval van 1:1 aansluitende roosters geen nauwkeurigheidsverlies op zal treden. In geval van WAQUA-berekeningen of TRIWAQ berekeningen zonder stoftransport is een guardband breedte van twee vereist. Ten behoeve van de eenvoud van de programmatuur wordt dit niet benut bij de definitie van de guardband (wel bij invullen van de communicatietabellen voor stencil stencmax ). Ten aanzien van de dwars- of diagonale-richting is het niet zinvol om een guardbandbreedte van drie aan te houden. Het gebruik van diagonale punten in parallel WAQUA/TRIWAQ (δm = ±1, δn = ±1) hangt meestal samen met effecten van staggering, en verdwijnt als de “eigen” gedeeltes van de index sets van waterstands- en snelheidspunten van elkaar kunnen


7-5 v, k (v) u, k (u) k (u)

Figuur 7.1: Boven: discretisatiestencil voor de advectieve term in dwarsrichting u∂v/∂ξ. Onder: vier mogelijke keuzes voor de grootte van de guardband in “diagonale” richting: volledig, 1 cel breed, volledige diepte, 1 cel, helemaal niet. De tweede mogelijkheid zal worden gekozen. verschillen (deze zijn in parallel WAQUA/TRIWAQ gelijk aan elkaar door gebruik van een enkel POWNER-array). De stencils stencmax en stenc1⊗1 zijn in parallel WAQUA/TRIWAQ nooit volledig nodig, maar zijn ge¨ıntroduceerd om de code te vergemakkelijken. Een argument daarbij was dat de extra communicatie die werd uitgevoerd verwaarloosbaar klein was. De enige plek in de code waar diagonale punten echt worden gebruikt is in de discretisatie van dwars-advectie (v∂u/∂η, u∂v/∂ξ), zie Figuur 7.1. In geval van een v-snelheidspunt zijn daarbij van 3 × 2 cellen alle acht de schotjes in u-snelheidspunten vereist. Drie keuzes die nu kunnen worden gemaakt ten opzichte van de volledige guardband van drie in diagonale richting zijn om slechts één extra cel toe te voegen in de breedte en drie in de diepte, om precies één extra cel toe te voegen, of om geen enkele cel toe te voegen. Wanneer geen enkele extra cel wordt toegevoegd, moet de uiteinden van interfaces echter een iets minder nauwkeurige discretisatie toegepast worden. De onnauwkeurigheid treedt alleen op als er een derde domein aanwezig is rechts van het beschouwde domein. De benodigde v-snelheden op het verlengde van de getekende interface zijn dan beschikbaar via de guardband voor de interface met dit derde domein. De onnauwkeurigheid is dat door het ontbreken van de ucellface in het getekende diagonale stuk van de guardband een eerste orde upwind-discretisatie wordt gebruikt in plaats van de gebruikelijke tweede orde upwind-methode. De eenvoudigste manier om de volledige nauwkeurigheid te handhaven lijkt te zijn om een cel in de breedte toe te voegen aan de guardband, met de volledige diepte van drie cellen, zoals in Figuur 7.1 te zien is in het tweede plaatje van links. De verdere specificatie van de guardband is aldus: • de guardband bestaat uit drie rijen en kolommen van cellen, en één rij/kolom in “diagonale richting” (de interface wordt uitgebreid gedacht met één celbreedte aan weerszijden); • de cell-faces op de subdomein-interface worden tot het fijne subdomein gerekend. Cellfaces en dieptepunten van het grove subdomein op de interface horen bij de guardband.


7-6

Bij 1:1 verfijning (zowel horizontaal als vertikaal) worden de conventies van parallel WAQUA/TRIWAQ gevolgd: de cellface hoort bij het linker/onderste domein, ofwel ieder subdomein bevat per waterstandspunt (m, n) ook de snelheidspunten (m+1/2, n) en (m, n+1/2) en het dieptepunt (m+1/2, n+1/2); • de guardband van het grove subdomein omvat aldus vier rijen/kolommen van dieptepunten. De array-offsets van de meest veraf gelegen dieptepunten voor het fijne subdomein ten opzichte van de m, n-coördinaten (array-indices) van cellen zijn -4 en +3. Voor deze dieptepunten worden alleen eenmalig de fysische coördinaten gecommuniceerd; • de cell-faces aan de buitenkant van de guardband (offsets -4 en +3) worden genegeerd, hiervoor worden geen snelheden en/of schotjes gecommuniceerd.

7.4

Specificatie van de overlap sets

Overlap sets zijn index sets die speciaal worden ge¨ıntroduceerd voor domein decompositie met horizontale verfijning, en die roosterpunten bevatten uit verschillende roosters (siminpfiles). Ze worden gebruikt als datastructuur voor het opslaan van ontvangen waardes van verschillende roosters, voorafgaand aan de interpolatie naar de eigen interpolatiepunten (zie paragraaf 5.8). Verder worden stencils in geval van DDHOR-interfaces gedefiniëerd op de overlap-sets in plaats van op fullbox of mnmaxk. Consequentie hiervan is dat alle interne punten die effect kunnen hebben op wat er bereikt wordt met een stencil in de overlap set moeten zitten. Er worden vier (horizontale) overlap sets ge¨ıntroduceerd: voor cellen (waterstandspunten), voor horizontale en voor verticale cellfaces (u/v-punten) en voor dieptepunten. De overlap sets bestaan ieder uit alle roosterpunten van het eigen subdomein en van de buurdomeinen die van belang kunnen zijn bij communicaties met het maximaal toegestane stencil stencmax . Ze zijn sterk aan elkaar gerelateerd, maar kunnen bijvoorbeeld verschillende kenmerken toekennen aan dezelfde m, n-index (waterstands-discretisatiepunt, snelheids-interpolatiepunt). Concreet bevat de overlap set in het geval van cellen/waterstandspunten - alle cellen van de guardband van het eigen subdomein (zeg drie rijen/kolommen), - alle cellen van de guardbands van naburige subdomeinen die overlappen met het eigen subdomein (drie rijen/kolommen van naburige subdomeinen), - alle eigen interne cellen die overlappen met de guardband cellen van naburige subdomeinen (voor een fijn subdomein: meer dan drie rijen/kolommen), en - alle interne cellen van buurdomeinen die overlappen met de eigen guardband cellen (voor een fijn subdomein: minder dan drie rijen/kolommen van de buurdomeinen); - alle eigen interne cellen die effect kunnen hebben op welk gedeelte van de eigen guardband er bereikt wordt met een stencil operatie (drie rijen/kolommen van het inwendige van het eigen subdomein);


7-7

- alle interne cellen van buurdomeinen die effect kunnen hebben op welk gedeelte van het eigen subdomein bereikt wordt met een stencil operatie (drie rijen/kolommen van het inwendige van naburige subdomeinen). De overlap set van dieptepunten bevat alle dieptepunten van het eigen subdomein en van de buurdomeinen die hoekpunt zijn van een of meer cellen in de overlap set van waterstandspunten. De dieptepunten worden voornamelijk gebruikt voor het communiceren van coördinaat-gegevens, voor het berekenen van de oppervlakte van cellen en lengtes van cellfaces in de guardband. Als de guardband van een subdomein het hele buurdomein precies overdekt, dan wordt een eventueel derde subdomein genegeerd, ook als dat fijner is dan het middelste subdomein en daardoor formeel eigenaar is van de betreffende interface/roosterlijn. De overlap sets van u- en v-punten bestaan uit alle cell-faces die voorkomen in de cellen van de overlap set van waterstandspunten, behalve de buitenranden van de guardbands per subdomein. Die buitenranden zijn nooit nodig in communicaties. De grootste stencils die worden gebruikt voor cell-faces zijn stenc2 voor discretisatie van de impulsvergelijking (toegepast in “eigen” u-punten, reikt naar u-punten) en stenc−1ξ ⊗ 2ξ (array-offsets -3 t/m +2, toegepast in waterstandspunten en reikt naar u-punten) voor communicatie van schotjes voor de transportberekening in TRIWAQ. De overlap sets zijn onregelmatige 3D index sets. De indices bestaan uit tuples (m, n, p), met p het rekenprocesnummer en (m, n) de -globale- logische coördinaten (array-index) van het (s/u/v/d-) roosterpunt binnen het bijbehorende rooster r. De zogenaamde “echte” roosterpunten, discretisatiepunten, worden steeds slechts voor één bepaalde p in de overlap-set opgenomen. Interpolatiepunten (m, n) van een rooster r kunnen wel meerdere keren voorkomen met verschillende procesnummers p, namelijk als ze van belang zijn voor verschillende subdomeinen van rooster r. Hiermee kan een proces zowel voor zichzelf als voor zijn buren de “vervanggebieden” bepalen (externe interfaces). Welke roosterwaardes van buurdomeinen hiervoor moeten worden gecommuniceerd en ge¨ınterpoleerd (de “verstuurgebieden” ofwel interne interfaces) hangt af van de gebruikte interpolatiemethode en wordt opgeslagen via zogenaamde relatietabellen op de overlap set. Bijvoorbeeld wordt er voor de overlap set van cellen een relatietabel “samecell” gemaakt die aangeeft welke cellen van het eigen subdomein en de buurdomeinen met elkaar overlappen. De relatietabellen worden bepaald bij het definiëren van interpolatie methodes. De vereiste invoer bestaat uit coördinaat-gegevens van de entiteiten waarmee wordt gewerkt: de functie samecell werkt op cellen en verwacht daarom vier (x, y) paren per index. In de huidige versie van DDHOR worden hiervoor de logische coördinaten ten opzichte van het eigen rooster opgegeven. Omdat we daardoor alleen te maken hebben met roosterlijnen x constant en y constant, bestaat in de huidige implementatie (coccel) de invoer voor de functie samecell uit vier getallen per cel: xlow , xhigh , ylow en yhigh .

7.5

Invulling van de guardband; het matching probleem

Ten aanzien van de invulling van de guardband, de bepaling van de fysische coördinaten en logische coördinaten ten opzichte van de buurdomeinen van de guardband roosterpunten,


7-8

wordt gesteld dat dit te belastend is voor de gebruiker. De coördinaten van de guardband roosterpunten zijn dus vooralsnog onbekend en moeten worden bepaald door voortzetting van de verschillende deelroosters. Dit leidt tot het probleem van het matchen van deelroosters. Het matching probleem kan in algemene zin worden gedefiniëerd als “het bepalen van welke roosterpunten (dieptepunten) van de buurdomeinen voor een bepaald subdomein van belang zijn (voor interpolaties voor de eigen guardband) en wat de logische coördinaten van die roosterpunten zijn ten opzichte van het eigen deelrooster, onder de restrictie dat de interne structuur van de buurdomeinen geen geweld wordt aangedaan: roosterlijnen van het globaal discretisatierooster hebben een constante ξ of η-coördinaat ten opzichte van het eigen deelrooster voor zover ze zichtbaar zijn vanuit (binnen de guardband liggen van) het eigen subdomein.” Bij dit matching probleem willen we graag variabele verfijningsfactoren toestaan, zodat 1:2 aansluiting op een stuk van de interface kan worden gecombineerd met 1:5 aansluiting op een ander stuk. Dit is praktisch voor gebruikers en levert geen moeilijkheden op voor de gebruikte interpolatiemethoden. Om dezelfde reden willen we toestaan dat de verfijningsfactoren langs en haaks op de interface van elkaar verschillen. Tenslotte is uitbreiding van de mogelijkheden gewenst ten behoeve van de combinatie met parallel rekenen. Het is gewenst dat domeinen kunnen worden gepartitioneerd in subdomeinen zonder (veel) rekening te moeten houden met de interfaces tussen verschillende roosters. Dit vereist onder andere dat subdomeinen dicht bij elkaar kunnen liggen zonder dat ze interfaces met elkaar delen. Het blijkt complex om het matching probleem volledig generiek op te lossen, doordat er complicaties optreden in uitzonderlijke configuraties. Een aantal belangrijke complicaties wordt ge¨ıllustreerd in Figuren 7.2-7.4: • de guardband ten opzichte van een interface kan in de knel komen met het inwendige van het eigen subdomein of met de guardbands van andere interfaces (Figuur 7.2, links bij grotere guardband-breedte); • in geval van elkaar overlappende guardbands kunnen er conflicten ontstaan tussen de gewenste verfijningsfactoren (Figuur 7.2, rechts); • de verfijningsfactor hoeft niet eenduidig te volgen uit de verhouding van roosterbreedtes. Er kunnen, zeker bij sterk gekromde roosterlijnen, meerdere keuzes mogelijk zijn (Figuur 7.3, guardband van subdomein 3: verhouding van roosterbreedtes is 4/3, mogelijke keuzes zijn 1:1 en 1:2); • bij het bepalen van de logische coördinaten haaks op een interface moet soms rekening worden gehouden met een of meer andere interfaces. – bij “teruggevouwen hoeken” worden de logische coördinaten haaks op de ene interface voorgeschreven door de logische coördinaten langs de andere interface (Figuur 7.3, subdomeinen 1 en 2),


1

7-9

1

2

2

Figuur 7.2: Wat is zichtbaar vanuit een subdomein met guardband ? In het rooster links is subdomein 1 goed gestructureerd (toegestaan), in het rooster rechts niet, omdat voor de eerste vertikale roosterlijn van subdomein 2 twee verschillende ξ/m-coördinaten worden voorgeschreven (verboden).

1

2

3

Figuur 7.3: Het bepalen van verfijningsfactoren: voor de guardband van subdomein 3 zijn zowel 1:1 als 1:2 mogelijk. Voor de guardbands van subdomein 1 ten opzichte van de horizontale interfaces zijn de verfijningsfactoren gekoppeld aan elkaar en aan de vertikale interface. De 1:1.3 verhouding tussen subdomeinen 1 en 3 is niet toegestaan.

2

1

3

2

3

1

Figuur 7.4: Buurdomeinen zonder gezamenlijke interfaces: een extra complicatie in het rooster rechts ten opzichte van links is dat de guardband van subdomein 3 niet reikt tot in subdomein 1, subdomein 3 weet niet dat 1 hem nodig heeft.


7-10

– bij interfaces in elkaars verlengde moet een consequente keuze worden gemaakt (Figuur 7.3, horizontale interfaces van subdomeinen 2 en 3 met subdomein 1); • subdomeinen moeten soms met elkaar communiceren terwijl ze geen gemeenschappelijke interfaces hebben (Figuur 7.4). Andere complicaties zouden zich kunnen voordoen als er binnen de guardbands rond interfaces open randen voorkomen. Het matchingsprobleem wordt hanteerbaar gemaakt door het specificeren van aanvullende restricties of veronderstellingen aan de deelroosters per subdomein: • de roosterbreedtes per deelrooster moeten zodanig zijn dat de meest voor de hand liggende verfijningsfactoren per interface tot de juiste keuzes leiden (round(∆grof /∆f ijn )); • de verfijningsfactoren zijn constant in de richting haaks op de interface en in het verlengde van de interface (niet van toepassing bij guardband-breedte van 1); • binnen iedere grofroostercel worden constante, geheeltallige verfijningsfactoren gebruikt; • guardbandcellen van een grof subdomein moeten overeenkomen met interne cellen van een enkel fijner domein, eventueel met meerdere subdomeinen van dit fijnere domein; • interfaces zijn alleen dan in de buurt van elkaar toegestaan (met overlappen van de guardbands) als hun eindpunten samenvallen, of als ze parallel aan elkaar lopen op een afstand van precies drie roosterbreedtes van het meest grove betrokken subdomein. De eerste twee veronderstellingen zorgen ervoor dat de guardband per interface afzonderlijk bepaald kan worden, in plaats van dat er bij het matchen direct moet worden gekeken naar interfaces in de buurt van elkaar. Het gebruiken van constante, geheeltallige verfijningsfactoren per grofrooster-cel wil zeggen dat bij interpolaties op basis van logische coördinaten geen rekening wordt gehouden met verschillen tussen de groottes van de betrokken fijnroostercellen. Dit speelt bijvoorbeeld een rol bij bilineaire interpolatie van waterstanden: bij 1:3 verfijning wordt in het grove subdomein steeds de middelste waarde van de 3 × 3 cellen van het fijne subdomein gebruikt, ook als de locatie daarvan niet overeenkomt met die van het grofrooster-waterstandspunt. De keuze heeft echter geen effect voor de “same-cell” methode, omdat daar de oppervlakte van cellen als gewicht wordt meegegeven. De achtergrond van de laatstgenoemde eis is dat daardoor de subdomeinen waarmee moet worden gecommuniceerd gemakkelijker zijn te lokaliseren, en dat het gebied van de buurdomeinen dat is betrokken bij communicaties eenvoudiger is te karakteriseren. Een consequentie is namelijk dat interfaces tussen verschillende roosters recht moeten zijn voor zover ze binnen de guardband (drie grofrooster-celbreedtes) van andere interfaces liggen (trappetjes worden uitgesloten). De andere roosters waarmee moet worden gecommuniceerd hebben tenminste één dieptepunt gemeenschappelijk met de koppelbare randen van het eigen rooster, en de overlappende gebieden zijn steeds rechthoekig. Merk op dat hiermee de a-symmetrische situatie rechts in Figuur 7.4 wordt vermeden, waarbij het eerste subdomein het derde nodig


7-11

heeft voor zijn guardband maar niet andersom. Ook is voor de gebruiker duidelijker wat wel en niet mag. De situatie rechts in Figuur 7.4 is namelijk niet toegestaan als subdomeinen 2 en 3 tot verschillende roosters (siminp-files) behoren, omdat deze twee subdomeinen beiden betrokken zijn bij een enkele guardband-cel van subdomein 1. De geschetste situatie mag wel als 2 en 3 tot hetzelfde rooster behoren; vrijwel willekeurige partities worden toegestaan.

7.6

Procedure voor het matchen van deelroosters

Met de beschreven eigenschappen van de deelroosters en de overlap sets is een structuur aangebracht in het probleem van het matchen van de deelroosters. Met name doordat vanuit een rekenrooster geredeneerd alle andere rekenroosters worden beschouwd als verzamelingen lijnen ξ constant en lijnen η constant. Het matchen kan worden opgevat als het bepalen van de interne gedeeltes van buurdomeinen die van belang zijn voor de eigen guardband en het toekennen van (ξ, η) -logische coördinaten ten opzichte van het eigen rekenrooster- aan de bijbehorende dieptepunten van de naburige rekenroosters, onder de restrictie dat ξ en η constant zijn per roosterlijn. Een procedure voor het matchen van interfaces (koppelbare randen) en invullen van de logische coördinaten in de guardband is nu als volgt (met direct daarbij de overeenkomstige subroutines): 1. bepaal alle benodigde informatie van “koppelbare u- en v-curves” (open randen en DDHOR interfaces) en bijbehorende dieptepunten van alle subdomeinen per globaal domein (wagmt2, coemt3, wasmt3); 2. bepaal welke koppelbare u- en v-curves van verschillende subdomeinen van een enkel domein/rooster in elkaars verlengde liggen (wagmt4); 3. bepaal alle benodigde informatie van koppelbare u- en v-curves en dieptepunten van alle globale domeinen, door samenvoegen van curves per subdomein (wagmt5, coemt6, wasmt6); 4. bepaal welke u-curves aan elkaar gekoppeld zijn en analoog voor v-curves. Bepaal alle benodigde informatie over de koppelingen, zoals de verfijningsfactoren haaks op en in het verlengde van de interface en eventueel gedeeltelijk samenvallende cellfaces aan de uiteinden van de interfaces (wagmt7); 5. bepaal welke begin- en eindpunten van u-curves gekoppeld zijn aan begin- en eindpunten van v-curves: koppelingen van een enkel dieptepunt van domeinen die diagonaal liggen ten opzichte van twee interfaces. Bepaal alle benodigde informatie over de koppelingen, zoals de verfijningsfactoren (wagmtd); 6. bepaal de grof-fijn relaties tussen alle globale domeinen (wagmt8);


7-12

7. in geval van TRIWAQ: controleer of de laagverdelingen van aan elkaar gekoppelde deeldomeinen passen, en of de hierbij behorende grof-fijn relatie samengaat met die voor de horizontale roosters (wagngh, coeckn, wasckn, wagvfn); 8. zet extra schotjes op plaatsen waar de fijnrooster-interface iets breder is dan de grofroosterinterface (gedeeltelijk gekoppelde cellfaces), en pas de randcodes (irobou, isbbou) en ownership-arrays hiervoor aan (wagovp); 9. vul de koppelingsinformatie voor DDHOR-interfaces in in arrays irobou en isbbou. Maak aanpassingen aan POWNER voor losse virtuele randpunten (wagov1); 10. bepaal de beschrijving en afmeting van de index set “maxovl”, de samenvoeging van rechthoeken per globaal domein per interface: de maximale overlap set. In WAQPRO bevat maxovl per rekenproces alleen die rechthoeken voor koppelingen waarbij het eigen globale domein bij is betrokken (wagov2); 11. voer controles uit op het overlappen van “rechthoeken per interface” van globale domeinen: interfaces die te dicht bij elkaar liggen (wagmta); 12. alleen in COEXEC: controleer of er barriers voorkomen binnen de rechthoeken rond DDHOR koppelingen (coemtb); 13. initialiseer de beschrijving van items in de maximale overlap set: index (imatch, m, n, r), maskers voor s/u/v/d-punten, owner (wagov3); 14. per globaal domein: bepaal de logische coördinaten van alle punten in de maximale overlap set ten opzichte van dat globale domein, en controleer of deze coördinaten consistent zijn tussen overlappende rechthoeken voor verschillende koppelingen (wagmt9); 15. alleen in WAQPRO: vul per subdomein de informatie over discretisatiepunten en ownership in in de beschrijving per item van de maximale overlap set (wagov4); 16. alleen in WAQPRO: communiceer de statusinformatie voor items van de maximale overlap set (discretisatie/interpolatie, ownership), eerst binnen het eigen globale domein, dan tussen alle domeinen (wasov5); 17. alleen in WAQPRO: bepaal de echte overlap sets voor cellen/waterstandspunten, cellfaces (u- en v-punten) en dieptepunten: overlap s, overlap u, overlap v en overlap d (wasov6). Deze procedure kan beknopt worden samengevat als bepalen van koppelbare randen per globaal domein, op het niveau van globale domeinen bepalen van de koppelingen, per koppeling uitbreiden en matchen van de betrokken roosters, en detecteren van conflicten tussen de uitbreidingen voor verschillende koppelingen. Een mogelijke beperking van deze strategie is dat situaties kunnen worden afgekeurd die wel zouden kunnen worden ondersteund. Een andere karakterisatie is dat er overvloedig wordt gecommuniceerd en opgeslagen. Voor beide aspecten geldt dat ze waarschijnlijk geen problemen opleveren ten aanzien van de te koppelen roosters, rekentijd en geheugenbeslag voor de beoogde grootschalige toepassingen van DDHOR.


7.6.1

7-13

Uitwerking stap 1, bepalen van koppelbare curves

In de eerste stap wordt per subdomein bepaald op welke curves kan worden gekoppeld en wordt deze informatie uitgewisseld met de andere subdomeinen van hetzelfde globale domein. Er wordt gewerkt met curves in plaats van dieptepunten, omdat aan een lijst van dieptepunten van een buurdomein zelf niet is te zien wat de samenhang daarvan is, welke koppelingen mogelijk zijn. Interfaces tussen subdomeinen van hetzelfde rekenrooster (parallelle randen) worden niet als koppelbare curves geregistreerd. De partitie-informatie van een rooster wordt later via de POWNER-array gecommuniceerd naar alle ge¨ınteresseerde andere roosters (stap 16). Samenvallende subdomeinen echte randen leiden tot complicaties. Als een subdomein alleen het rand-waterstandspunt mf van het globale domein bevat en het eerste interne punt is inactief (interpolatiepunt) dan is zijn rij niet koppelbaar. In geval van een open rand leidt dit tot de foutmelding voor het naburige globale domein dat een gedeelte van een opening niet gekoppeld is. In geval van een gesloten rand wordt een ad hoc aanpassing aan POWNER gemaakt door het andere domein. Als een opening van een subdomein gedeeltelijk een open rand betreft en verder overgaat in een DDHOR opening dan wordt een foutmelding gegeven. Voor het overeenkomstige globale domein valt een van de open randpunten dan namelijk samen met een punt (cel) op de gesloten rand haaks daarop. Een geschikte opslagstructuur voor de informatie van alle subdomeinen bestaat uit: ncurvu,ncurvv,ndeppt - totaal aantal u-curves, v-curves en dieptepunten in alle subdomeinen samen; icurvs(6,ncurvu+ncurvv+1) - informatie over de u- en v-curves van alle subdomeinen: rekendomein- en procesnummer, oriëntatie, type (opening of DDHOR interface), aantal betrokken cellfaces, en pointer naar eerste betrokken dieptepunt in coordp. In de laatste kolom wordt alleen de pointer ingevuld naar de eerste lokatie voorbij het gebruikte stuk in coordp; coordp(5,ndeppt) - voor alle curves van alle subdomeinen de fysische x, y coördinaten en logische globale m, n coördinaten voor alle betrokken dieptepunten. Ook wordt de eerste inwendige roosterbreedte ∆ haaks op de curve opgeslagen ten behoeve van het bepalen van verfijningsfactoren in latere stappen. Dieptepunten die op meerdere curves liggen komen meerdere keren voor; er worden aldus icurvs(5,ic)+1 dieptepunten gegeven voor curve ic en het totaal aantal dieptepunten ndeppt is gelijk aan ( Sum icurvs(5,ic), ic=1:ncurvu+ncurvv ) + ncurvu + ncurvv Voor het lokaliseren van de u- of v-curves en de dieptepunten per subdomein worden pointerarrays gedefiniëerd:


7-14

ixcurv(2*numprc+1) - index van de eerste u- en v-curve per subdomein in icurvs. De uen v-curves per subdomein staan direct na elkaar in icurvs, uit de twee kolommen valt het aantal u-curves en het aantal v-curves per subdomein te berekenen; icoord(numprc+1) - index van het eerste dieptepunt per subdomein in array coordp. De arrays icurvs en coordp kunnen per subdomein worden ingevuld met behulp van de beschrijving van de eigen mesh: irogeo, irobou, powner, xdep, ydep, guu en gvv. Het blijkt hierbij gemakkelijker te zijn om de oriëntatie op te slaan dan om de dieptepunten zodanig te nummeren dat het inwendige van het eigen subdomein links van de curves ligt (zoals in het oorspronkelijk detail ontwerp v1.0 was voorgesteld). In WAQPRO worden de curves per subdomein worden uitgewisseld met de zogenaamde newspaper communicatie-operatie, zie paragraaf 8.4.4.5, en worden daarbij de pointer-arrays ixcurv en icoor2 ingevuld (subroutine wasmt3). Ten behoeve van COEXEC is de subroutine wagmt2 uitgebreid zodat een loop over alle subdomeinen kan worden uitgevoerd. Hier wordt subroutine coemt3 gebruikt om de totale aantallen curves en dieptepunten te bepalen. Om in COEXEC gemakkelijk heen en weer te kunnen springen tussen de WAQUA-arrays (bijv. irogeo) van verschillende subdomeinen zijn twee extra routines coemt0 en coemt1 gemaakt respectievelijk voor het lezen van alle benodigde informatie van deel-SDS-files naar de ibuffr-array en voor het invullen van dimensies en pointers binnen de ibuffr-array voor een enkel subdomein. Bovengrenzen voor het totaal aantal curves en betrokken dieptepunten van alle subdomeinen samen zijn 100*numprc en 4*noroco*numprc, waarbij in het laatste geval zowel de som als het maximum van noroco over alle subdomeinen kan worden gebruikt. De bepaling van curves en dieptepunten per subdomein hoeft hiermee slechts eenmaal te worden uitgevoerd, en de aangemaakte SIMONA arrays kunnen na afloop tot de daadwerkelijk vereiste lengte worden ingekort (routine simm11). De m, n coördinaten die worden opgeslagen worden gegeven ten opzichte van het globale rekenrooster waartoe de punten behoren (de siminp-file). Hierdoor kunnen buurdomeinen uit hetzelfde rekenrooster elkaars coördinaten interpreteren zonder dat ze daarbij de verschuivingen nodig hebben (m,ncordt).

7.6.2

Uitwerking stap 2, in verlengde van elkaar liggende curves

De tweede stap bestaat uit het bepalen van welke curves in elkaars verlengde liggen. Dit gebeurt om uit de curves per subdomein de totale curves per globaal domein te kunnen bepalen. Curves die in elkaars verlengde liggen worden gekarakteriseerd doordat ze van verschillende subdomeinen zijn, doordat het beiden u-curves zijn of v-curves zijn, doordat de hoek tussen twee aansluitende cellfaces klein is, en doordat ze dezelfde oriëntatie hebben (het binnengebied ligt voor beide subdomeinen aan dezelfde kant). De hoek tussen twee cellfaces ~a en ~b wordt berekend via cos(α) = (~a/k~ak, ~b/k~bk), een min of meer willekeurig gekozen invulling voor “klein” is dat de absolute waarde van α kleiner is dan 30◦ .


7-15

Per curve worden de nummers van curves opgeslagen die aan het begin en einde in het verlengde liggen: ngbcrv(2,ncurvu+ncurvv) - voor alle curves van alle subdomeinen de verwijzingen naar eventuele absolute nummers van curves in het verlengde aan het begin en einde van de curve. Waar er geen curve in het verlengde ligt wordt de waarde 0 opgeslagen. Er is gekozen voor een generieke bepaling van curves in elkaars verlengde, omdat deze informatie ook voor andere toepassingen kan worden gebruikt. Als het puur ten behoeve van partitionering zou zijn, dan zou ook kunnen worden gezocht naar curves van subdomeinen van hetzelfde rooster en kunnen de controles op oriëntatie en hoek worden weggelaten. Ieder subdomein heeft alle “continuations” nodig tussen de curves van alle andere subdomeinen. Daarom wordt de bepaling per proces ineens gedaan voor alle curves van alle subdomeinen tezamen in een enkele subroutine wagmt4 welke zowel door WAQPRO als COEXEC wordt aangeroepen.

7.6.3

Uitwerking stap 3, curves per globaal domein

In de volgende stap worden de curves per subdomein in elkaars verlengde samengevoegd tot curves per globaal domein. Dit is een betrekkelijk eenvoudige operatie, waarbij vooral veel data van een beschrijving per subdomein naar een beschrijving per globaal domein wordt gekopiëerd. Op de overgang tussen twee subdomeinen verdwijnt hier en daar een dubbel voorkomend dieptepunt. De beschrijving per globaal domein is op dezelfde manier gestructureerd als die per subdomein in stap 1. Hiervoor worden er aparte namen gehanteerd (ncrvug, ncrvvg, icurvg, ndeppg, coordg). Net als in stap 2 is er communicatie nodig in WAQPRO voor het verzamelen van de informatie voor alle globale domeinen (wasmt6), en moeten in COEXEC de totale aantallen curves en dieptepunten worden bepaald (coemt6). Een belangrijke functie van deze twee routines is te rapporteren aan de gebruiker over de gevonden koppelbare curves per globaal domein.

7.6.4

Uitwerking stap 4, matchen van koppelbare curves

In de volgende stap wordt bepaald welke dieptepunten van verschillende globale domeinen met elkaar samenvallen en welke (delen van) curves aldus aan elkaar zijn gekoppeld. Hierbij worden nog niet de koppelingen bepaald die bestaan uit een enkel gemeenschappelijk dieptepunt (zie stap 5). Er wordt een brute-kracht algoritme ge¨ımplementeerd, waarbij domweg alle dieptepunten van curves met elkaar worden vergeleken. Een slimmere oplossing is denkbaar bijvoorbeeld door een rechthoek rond iedere curve te bepalen en dieptepunten niet met elkaar te vergelijken als de rechthoeken niet overlappen. Omdat het slechts gaat om de openingen per globaal domein is dit waarschijnlijk niet nodig.


7-16

Bij iedere gevonden koppeling worden gegevens opgeslagen voor de twee overeenkomstige rechthoeken van de betrokken globale domeinen (array imtchs(21,nrctng)): imatch - volgnummer van de koppeling waar een rechthoek bij hoort; idom - nummer van het domein/rooster waarop de rechthoek betrekking heeft; icurv - het betreffende curve-nummer binnen dit domein (absolute index in icurvs); ixdp1a - offset van het eerste dieptepunt van de koppeling ten opzichte van het eerste dieptepunt van de curve (als de hele curve gekoppeld is: 0); ixdp1b - offset van het laatste dieptepunt van de koppeling ten opzichte van het eerste dieptepunt van de curve (als de hele curve gekoppeld is: icurvs(4,icurv)); ifiner - vlag met waardes 1, 0 en -1 waarmee wordt aangegeven dat het domein idom fijner, even fijn of grover is dan het overeenkomstige domein, voor zover naar deze koppeling wordt gekeken; irfprp,irfmin,irfmax,irfsta,irfend - verfijningsfactoren: haaks op de interface (perpendicular), minimum/maximum langs de interface, en in het verlengde aan het begin/einde van de interface; m0,n0,m1,n1 - logische coördinaten ten opzichte van domein idom van de hoekpunten linksonder en rechtsboven van de rechthoek; jrctng - pointer naar de overeenkomstige rechthoek van het gekoppelde domein (absolute index binnen imtchs); iofovl - pointer naar de eerste positie binnen de maxovl-data structuur voor de huidige rechthoek; itype - type koppeling: 0 is normaal, 1 en 2 staan voor speciale koppelingen die bestaan uit een enkel dieptepunt. De waarde 1 staat dan voor een rechthoek in de guardband van domein idom, 2 staat voor het inwendige van domein idom. iprtst, iprtnd - in het geval dat de interface op het fijne rooster iets breder of smaller is dan de interface op het grove rooster, staan hier het aantal cellfaces voor/na het eerste/laatste gezamenlijke dieptepunt (“partially matched, start/end”). ivfin - vlag die aangeeft of de huidige rechthoek (domein) in de vertikale richting fijner (1), even fijn (0) of grover (-1) is dan de gekoppelde rechthoek (buurdomein). In deze stap (subroutine wagmt7) worden alleen de “normale” koppelingen met itype=0 bepaald. De waardes van m0, n0, m1, n1 en iofovl worden later, bij het bepalen van de structuur van maxovl in stap 10 ingevuld.


7-17

Algorithm 1 - matchen van alle koppelbare curves alle globale domeinen for icurv1=1 to ncurvu+ncurvv do ixdp1a=icurvs(5,icurv1) (absolute index in coordp) while ( ixdp1a < laatste d-punt van icurv1 (icurvs(5,icurv1+1)-1) ) do zoek een match icurv2,ixdp2a voor dieptepunt ixdp1a (Algoritme 2) if ( geen match gevonden ) then zet ixdp1a=ixdp1a+1 else bepaal geheel gekoppelde cellfaces ixdp1a..ixdp1b versus ixdp2a.. ixdp2b (Algoritme 3) if ( match bevat geen cellfaces ) then zet ixdp1a=ixdp1a+1 else registreer twee rechthoeken in array imtchs(18,ixmtch), incl. verfijningsfactoren zet ixdp1a=ixdp1b end if end if end while end for Algorithm 2 - zoeken van een match voor een enkel dieptepunt “ixdp1a” imatch=0, icurv2=icurv1+1 (alleen hogere curve-nummers interessant) while ( icurv2 ≤ ncurvu+ncurvv ∧ imatch=0 ) do if ( icurv2 heeft geschikte oriëntatie ∧ is van een ander subdomein ) then ixdp2a=icurvs(5,icurv2) while ( ixdp2a < eind2 ∧ imatch=0 ) do if ( x, y-coördinaten komen overeen ) then imatch=1 else ixdp2a=ixdp2a+1 end if end while end if if ( imatch=0 ) then icurv2=icurv2+1 end while Het globale algoritme dat wordt gebruikt voor het matchen wordt in Algoritme 1 getoond. Invulling van twee complexe onderdelen wordt verder uitgewerkt in Algoritmes 2 en 3. Iedere koppeling wordt een keer opgeslagen, namelijk alleen de instantie waarbij icurv1<


7-18

Algorithm 3 - matchen van hele cellfaces van twee koppelbare curves met gemeenschappelijk dieptepunt ixdp1a=ixdp2a. ixdp1b=ixdp1a, ixdp2b=ixdp2a, iready=0 initialiseer verfijningsfactoren irfprp, irfmin, irfmax initialiseer ifiner (1=ik ben het fijnere subdomein, 0=grof-fijn relatie nog onbekend, -1=ander is fijner) while ( not iready ) do imatch=0 if ( ifiner ≥ 0 ) then zoek dieptepunt ixdp2b+1 in eigen curve icurv1 vanaf positie ixdp1b+1 if ( match gevonden, imatch=1 ) then pas aan: ifiner, verfijn.factoren, ixdp1b, ixdp2b, vlag iready end if end if if ( imatch=0 ∧ ifiner ≤ 0 ) then zoek dieptepunt ixdp1b+1 in andere curve icurv2 vanaf positie ixdp2b+1 if ( match gevonden, imatch=1 ) then pas aan: ifiner, verfijn.factoren, ixdp1b, ixdp2b, vlag iready end if end if if ( imatch=0 ) then iready=1 end if end while icurv2. Dit wordt bereikt door in Algoritme 2 te beginnen bij icurv2=icurv1+1. Door de buitenste loop in Algoritme 1 worden de koppelingen in imtchs gesorteerd op de curvenummers icurv1. Voor het bepalen van de overlap sets in WAQPRO zijn alleen de matches van de curves van het eigen globale domein nodig. Hiervoor is de subroutine wagmt7 waarin het matchen is ge¨ımplementeerd uitgebreid met een extra argument isbonl waarmee wordt aangegeven of een specifiek (isbonl=1) of voor alle domeinen moet worden gewerkt (isbonl=0). Een vrij strakke bovengrens voor het totaal aantal matches van de curves van alle subdomeinen is ncurvu+ncurvv. Richtlijn bij het kiezen van de verfijningsfactoren is dat de roosterpunten in de guardband van een subdomein zo dicht mogelijk in de buurt liggen van roosterpunten in het inwendige van het buurdomein. Ter vereenvoudiging van het matchen is daarbij gekozen voor een constante verfijningsfactor voor de richting haaks op de interface. Variabele verfijningsfactoren zijn in principe mogelijk, maar vereisen speciale algoritmiek om ongewenste resultaten te voorkomen in het geval dat de roosterbreedtes aan weerszijden van de interface niet goed deelbaar zijn. Bijvoorbeeld in geval van roosterafstanden 200m en 120m levert de meest voor de hand


1

3

2

1

7-19

1

2

Figuur 7.5: Benodigde diagonale koppelingen van een enkel dieptepunt. Links: situatie met 3 domeinen. Midden: guardbands van domein 1, in het gearceerde stuk weet domein 1 niet automatisch dat hij waardes moet ontvangen van domein 2 in plaats van domein 3. Rechts: extra toegevoegde diagonale koppelingen tussen domein 1 en 2 om dit probleem te ondervangen. liggende berekening koppeling op op de tweede, derde en vijfde roosterlijn van het fijne domein (240m, 360m en 600m). Ten behoeve van de huidige stap zijn in stap 1 de roosterbreedtes ∆ haaks op de curves gecommuniceerd. De roosterbreedtes worden op elkaar gedeeld per dieptepunt van het grove subdomein op de interface (∆grof /∆f ijn ). De afgeronde waardes moeten identiek zijn voor alle dieptepunten. Het getal irfprp dat hieruit volgt wordt opgeslagen bij de informatie per koppeling. Samen met de vlag ifiner valt hiermee af te leiden welke roosterlijnen van het buurdomein samenvallen met de eigen guardband-lijnen en vice versa.

7.6.5

Uitwerking stap 5, lokaliseren van diagonale koppelingen

Vervolgens wordt gezocht naar diagonale koppelingen van domeinen, dus naar koppelingen die bestaan uit een enkel dieptepunt. Hierbij blijken niet alleen samenvallende begin- en eindpunten van u- en v-curves van belang te zijn. Door een complicatie in het initialiseren van de communicaties moet ook worden gezocht naar begin/eindpunten van curves die matchen aan interne punten van andere curves, zie Figuur 7.5. In de geschetste situatie weet domein 1 van het gearceerde gebied in eerste instantie niet dat domein 2 de eigenaar is. Hij zal daarom gegevens van domein 3 verwachten, terwijl 3 ze niet verstuurt omdat hij niet de eigenaar is. Domein 2 weet daarentegen weer niet dat hij gegevens moet versturen aan 1. Hetzelfde probleem treedt op bij domeinen 2 en 3. Om deze problemen te ondervangen worden diagonale koppelingen tussen de startpunten van de vertikale curves van domeinen 1 en 3 met de horizontale curve van domein 2 toegevoegd. In de linker figuur is te zien dat het beginpunt van zogenaamde “West” (domein 3) en “East”-curves (domein 1) kan worden gekoppeld aan willekeurige punten van “North”-curves (domein 2). In geval van een East-curve is daarbij echter de koppeling aan het eindpunt van een North-curve niet van belang (bijvoorbeeld als het getekende punt in de rechter figuur het eindpunt is van de curve van 2). In dat geval bevatten de extra rechthoeken namelijk geen interne cellen die nog niet bij normale koppelingen zijn gevonden. Analoog is de diagonale koppeling van een West-curve aan een North-curve niet interessant als dat het beginpunt van de North-curve betreft.


7-20

Iedere diagonale koppeling bestaat in de array imtchs uit vier rechthoeken: voor het interne stuk en het guardband stuk voor beide betrokken domeinen. Dit is te zien in Figuur 7.5 (rechts); er zijn twee stukken van 3 × 3 cellen aangegeven, die ieder voor twee domeinen als rechthoek worden toegevoegd aan de administratie. De verfijningsfactoren in deze stukken worden berekend door de roosterafstanden haaks op de ene curve en langs de andere curve op de gebruikelijke manier te vergelijken, en zijn constant in beide richtingen.

7.6.6

Uitwerking stap 6, controleren van koppelingen

Door de hierboven beschreven procedure voor het matchen van curves voldoen alle gevonden koppelingen aan de eisen dat: • alleen ξ- aan ξ-roosterlijnen en η- aan η-lijnen gekoppeld mogen worden, • het binnengebied van beide domeinen niet aan dezelfde kant van de interface ligt, • de nummering van dieptepunten in beide domeinen in dezelfde richting oplopend is. Fouten in de gebruikersinvoer ten aanzien van deze eisen leiden ertoe dat waar de gebruiker koppelingen verwacht (samenvallende dieptepunten) deze niet door de programmatuur worden gevonden. Op basis van de huidige informatie kan/moet nu worden gecontroleerd dat: • alle cellfaces van ieder domein op DDHOR interfaces gekoppeld zijn, • alle cellfaces of geen van alle cellfaces per openingen gekoppeld zijn, • of de grof-fijn relatie voor alle koppelingen tussen dezelfde domeinen hetzelfde is. De controle ten aanzien van het gekoppeld zijn van DDHOR interfacepunten gebruikt het type van curves, DDHOR interface of open rand, dat in stap 1 speciaal hiervoor is geintroduceerd.

7.6.7

Uitwerking stap 7, vertikale verfijningsinformatie

In geval van TRIWAQ dan is het toegestaan dat er verschillende laagverdelingen worden gebruikt in aan elkaar gekoppelde deeldomeinen. Deze laagverdelingen moeten wel voldoen aan de eisen die er zijn gesteld voor DDVERT: er moet een unieke grof-fijn relatie bestaan, en de laaginterfaces van het grove deeldomein moeten precies aansluiten op laaginterfaces van het fijne deeldomein. Merk op dat er ook DDVERT gebruikt kan worden binnen ieder globaal domein. Daarom moeten de laagverdelingen per paar van aan elkaar gekoppelde deeldomeinen worden gecontroleerd in plaats van op het niveau van globale domeinen. Dit is tot op zekere hoogte lastig omdat de matches op het niveau van globale domeinen zijn bepaald. Hierdoor is niet gemakkelijk te achterhalen welke deeldomeinen precies aan elkaar grenzen. Dit is opgelost door te


7-21

eisen dat per match alle deeldomeinen die zijn betrokken bij de twee koppelbare curves ook opelkaar aansluiten. Subroutine wagngh is ge¨ıntroduceerd om alle hieruit volgende paren van deeldomeinen (idom1, ipart1; idom2, ipart2) te bepalen. Vervolgens worden de laagverdelingen gecontroleerd in coeckn en wasckn. Tenslotte bepaalt routine wagvfn voor iedere match de verfijningsrelatie (vlag ivfin), en controleert hij of deze overeenstemt met de verfijningsrelatie in horizontale richting.

7.6.8

Uitwerking stap 8, aanpassingen geometrie voor gedeeltelijk gekoppelde cellfaces

Op plaatsen plaatsen waar de fijnrooster-interface iets breder is dan de grofrooster-interface (gedeeltelijk gekoppelde cellfaces) moet de geometrie iets worden aangepast. De laatste cellfaces van het fijne domein zijn namelijk niet meer gekoppeld maar worden vervangen door een gesloten rand van het eigen domein. Hiervoor worden schotjes gezet, wordt de randcode in irobou op 1 gezet (gesloten rand), wordt de koppelingsinformatie in isbbou aangepast, en worden de u/v- en s-randpunten bij het eigen domein getrokken (aanpassing ipowns, ipownu en ipownv). Een andere aanpassing die wordt gemaakt betreft rijen en kolommen waar een virtuele randpunt als inactief is gemarkeerd (eigenaar −1). Dit is nodig bij het maken van een DDHOR-koppeling bij diagonale gesloten randen. Als het virtuele punt niet inactief is, dan krijgt het DDHOR-domein van de partitioner COPPRE een rekenrij of kolom die alleen uit dit randpunt bestaat, wat tot problemen leidt in de berekeningen. Zodra COPPRE de rijen/kolommen van het DDHOR-domein heeft bepaald moet het eigenaarschap van het randpunt weer worden teruggezet. Anders ontstaat er in de andere rekenrichting een kolom of rij waarvoor er een DDHOR-koppeling wordt verwacht, omdat het eindpunt als inactief is gemarkeerd. De losse virtuele randpunten worden herkend aan het samenvallen van subdomeinranden en echte randen. Min of meer dezelfde aanpassingen worden gemaakt als waar extra schotjes worden ingevuld.

7.6.9

Uitwerking stap 9, aanpassing rand-codes en POWNER

Met behulp van de grof-fijn relatie die in de vorige stappen is bepaald kan nu de koppelingsinformatie in array isbbou worden ingevuld. Voor alle cellfaces op DDHOR-interfaces wordt het bijbehorende start of einde van de betreffende rij of kolom opgezocht, en worden de vlaggen icple, ifinr, ihfin, ivfin, isamd, iuint en iumyn ingevuld. Daarbij wordt ook op openingen die zijn gekoppeld de echte randvoorwaarde in irobou overschreven met de waarde 0 die aangeeft dat er een koppeling is. Tenslotte wordt het eigenaarschap van de uen v-punten op de interface ingevuld in arrays ipownu en ipownv.


7.6.10

7-22

Uitwerking stap 10, beschrijving/dimensies van overlap sets per koppeling

In de volgende stappen moet er nu informatie worden opgeslagen voor de stukken van alle roosters in de buurt van subdomein-interfaces. Hiervoor wordt de “maximale overlap set” ge¨ıntroduceerd: voor alle koppelingen een rechthoekig stuk van allebei de betrokken subdomeinen. De rechthoeken worden zodanig groot gekozen dat alles wat er ooit in de verschillende echte overlap sets (voor s/u/v/d-punten) moet zitten ook in de rechthoeken past. In geval van overlap tussen de rechthoeken voor verschillende koppelingen wordt informatie dubbel opgeslagen. In de huidige stap, ge¨ımplementeerd in subroutine wagov2, worden de afmetingen per rechthoek bepaald en opgeslagen en wordt de totale omvang van index set maxovl bepaald. Deze index set wordt overigens niet officiëel gedeclareerd, omdat ze alleen tijdens de initialisaties wordt gebruikt en COCLIB niet voorziet in het weggooien van index set. De structuur van maxovl wordt vastgelegd via: iovlsz totaal aantal elementen van de overlap set maxovl; m0,n0,m1,n1 in imtchs: logische coördinaten van de linker-beneden en rechter-bovenhoek van de rechthoeken. iofovl in imtchs: offset per rechthoek naar eerste bijbehorende item binnen arrays met data-structuur maxovl ixovdm(ndom+1) pointer naar het eerste element binnen maxovl per globaal domein. De coördinaten van hoekpunten van de rechthoeken worden berekend aan de hand van de m, n-coördinaten van de eindpunten van de gekoppelde stukken van curves, de oriëntaties van curves en met de beschikbare verfijningsfactoren. Voor “speciale rechthoeken”, behorend bij koppelingen die uit slechts een enkel dieptepunt bestaan, zijn deze m, n-coördinaten al ingevuld en wordt alleen iofovl bepaald.

7.6.11

Uitwerking stap 11, controle op overlappende rechthoeken

Op pagina 7-10 zijn beperkingen opgelegd aan interfaces die bij elkaar in de buurt liggen. Deze beperkingen zijn nodig om ervoor te zorgen dat van iedere rechthoek gemakkelijk kan worden aangegeven wat “intern” en “extern” is voor het eigen domein. In subroutine wagmta worden de beperkingen gecontroleerd. Er wordt gezocht naar overlappende rechthoeken van hetzelfde domein. Speciale rechthoeken voor koppelingen van een enkel dieptepunt worden overgeslagen omdat daar geen probleem-situaties mee bekend zijn. Rechthoeken die bij dezelfde curve horen leveren ook geen problemen op. Tenslotte moet het gebruik van op elkaar aansluitende u- en v-koppelingen worden toegestaan. Alle andere situaties met overlappende rechthoeken worden (vooralsnog) verboden.


7.6.12

7-23

Uitwerking stap 12, controle op barriers in de guardband

Barriers mogen echter niet voorkomen in de guardband rond DDHOR interfaces omdat niet duidelijk is hoe bepaalde waardes moeten worden ge¨ınterpoleerd (array kfbu: schotjes per laag) en hoe betekenisvol de mogelijke interpolaties zijn. Tijdens het partitioneren is echter nog niet bekend hoe breed de guardband rond DDHOR interfaces wordt. Aan de ene kant is de interne guardband van een fijn subdomein drie keer de verfijningsfactor breed, aan de andere kant is van openingen niet bekend of ze blijvend zijn of door een DDHOR-koppeling worden vervangen. Daarom wordt de controle op het voorkomen van barriers in de guardband in COEXEC uitgevoerd. De controle is ge¨ımplementeerd in subroutine coemtb. Voor alle (lijn-)barriers worden de m, n-coördinaten van de begin en eindpunten bepaald, en wordt gecontroleerd dat het bijbehorende domein geen rechthoeken bevat waar de (lijn-)barrier (gedeeltelijk) binnen valt.

7.6.13

Uitwerking stap 13, initialisatie van maximale overlap set

Er worden maskerarrays gedefiniëerd op de verzameling van rechthoeken rond alle interfaces. Ten eerste bevatten de rechthoeken ruimte voor de grootst nodige overlap set van dieptepunten, terwijl de overlap sets van waterstands- en snelheidspunten hier en daar een rij of kolom minder bevatten. Ten tweede moeten de rekenprocessen met elkaar statusinformatie communiceren over wat ze discretisatie- en interpolatiepunten vinden en wat de roosteropdeling in subdomeinen binnen ieder domein is. Voor deze doeleinden wordt een array maxovl(iovlsz,8) ge¨ıntroduceerd. Deze representeert in zekere zin de zogenaamde maximale overlap set van alle punten in alle rechthoeken bij elkaar. In de eerste vier kolommen worden de “coördinaten” van de items in deze index set opgeslagen: (imatch, m, n, d), het match-nummer van de rechthoek, de globale m, n-coordinaten per domein, en het domein-nummer d waartoe het punt behoort. Merk op dat een enkel roosterpunt (m, n) van een domein d meerdere keren voor kan komen als verschillende rechthoeken van dit domein met elkaar overlappen. In de volgende vier kolommen worden maskers en ownership voor s/u/v/d-punten ingevuld. In de huidige stap betreft dit de eerste initialisatie op basis van enkel informatie van de rechthoeken, zonder gebruik te maken van verdere WAQUA datastructuren. De code −2 wordt ingevuld in s/u/v-punten die te ver van de interface af liggen. De code −1 wordt ingevuld in het externe gebied per rechthoek (interpolatiepunten m.b.t. de bijbehorende rechthoek). Voor snelheidspunten op de interface wordt hierbij de vlag ifiner over de grof-fijn relatie gebruikt. In het interne gebied per rechthoek wordt tenslotte de code 0 ingevuld.

7.6.14

Uitwerking stap 14, logische co¨ ordinaten t.o.v. eigen rooster

De volgende stap is het vastleggen van de relaties tussen eigen guardbandpunten en interne punten van de buurdomeinen, ofwel het kiezen van logische coördinaten voor de roosterpunten van de buurdomeinen ten opzichte van het eigen coördinatensysteem.


7-24

Het blijkt lastig te zijn om hierbij alle relaties te benutten die worden voorgeschreven door stukken guardband van verschillende koppelingen die met elkaar overlappen. Daarom wordt gekozen voor een aanpak per koppeling en het daarna detecteren van conflicten. Voor goed ontworpen roosters levert dit geen problemen op (geen sterke oprekking/kromming nabij interfaces), mede omdat de verfijningsfactoren binnen een grofrooster-cel constant worden gekozen. De logische coördinaten kunnen direct worden ingevuld voor punten van het eigen domein. Voor rechthoeken van naburige domeinen is de situatie ook redelijk eenvoudig in de richting haaks op de interface: op de interface is de eigen m of n-coördinaat bekend, en verder geldt er een vaste verfijningsfactor. In de richting langs de interface moet tot op zekere hoogte het echte matchen worden herhaald. Er wordt steeds een cellface van het grove domein bekeken, en binnen die cellface geldt een constante verfijningsfactor. Speciale koppelingen worden apart behandeld omdat er hier geen “richting van de interface” bestaat; speciale koppelingen betreffen steeds een u- en een v-curve. Hier zijn de verfijningsfactoren echter constant in beide coördinaat-richtingen. Na het invullen van de logische coördinaten op alle rechthoeken die matchen aan het eigen domein wordt de consistentie van de gegevens gecontroleerd. De informatie voor overlappende rechthoeken van hetzelfde naburige domein moet kloppen. Hiervoor wordt de hulproutine wagov7 gebruikt.

7.6.15

Uitwerking stap 15, bepalen statusinformatie voor de maximale overlap set

De maximale overlap set wordt gebruikt voor het communiceren van status informatie over de verschillende soorten roosterpunten. Ten eerste betreft dit welke punten discretisatie-, interpolatie- of loze punten zijn, ten tweede wordt de ownershipinformatie gecommuniceerd. In stap 13 is deze status-informatie ge¨ınitialiseerd. Nu wordt ze per subdomein verder ingevuld, en in stap 16 vindt de communicatie plaats. De hulproutine wagdsc vult vier “fullbox” arrays mdscrs, mdscru, mdscrv en mdscrd voor s/u/v/d-punten. Hierin staat 0 voor “geen discretisatiepunt” en 1 voor “wel een discretisatiepunt van het eigen deeldomein”. Er wordt geen onderscheid gemaakt tussen interne discretisatiepunten en punten voor randafhandeling. Bijvoorbeeld worden de snelheidspunten haaks op open randen (v-punten bij een vertikale opening m constant) ook als discretisatiepunt gemarkeerd. De huidige maskers worden namelijk gebruikt om te bepalen welke punten “bestaan” in het globale discretisatierooster, en deze randpunten bestaan; er wordt een zeer eenvoudige randvoorwaarde gediscretiseerd, en je kunt aan de oplossing vragen wat de waarde er is op ieder tijdstip. In het geval van dieptepunten worden de hoekpunten van interne cellen als discretisatiepunt gemarkeerd. De vier fullbox-arrays worden nu als volgt naar de maximale overlap set gekopiëerd. Een fullbox-array iwork wordt ge¨ınitialiseerd op 999. Dan wordt voor alle punten in de fullbox die een of meer keer voorkomen in de maximale overlap set (code −1 of 0 in maxovl) het minimum van de daarin gegeven maskerwaardes naar iwork gekopiëerd. Dus als tenminste


7-25

een van de instanties van punt (m, n) in de maximale overlap set een interpolatiepunt is dan wordt iwork(n,m) op −1 gezet. Voor alle andere (m, n) in de maximale overlap set wordt iwork 0. Vervolgens wordt voor alle discretisatiepunten (s/u/v/d) van het eigen subdomein de waarde myprc in iwork geschreven. Tenslotte worden de waardes uit iwork naar alle overeenkomstige punten in maxovl gekopiëerd. De moeilijkheid die met bovenstaand algoritme wordt opgelost is wat te doen met overlappende stukken van verschillende rechthoeken. Deze komen voor als verschillende interfaces dicht bij elkaar komen te liggen, momenteel alleen als horizontale en vertikale interfaces op elkaar aansluiten. Cruciaal daarbij is het onderscheid tussen “gewone” en “teruggevouwen” hoeken. Bij een gewone hoek in een interface moet in de overlappende stukken bij verschil van mening de code −1 voorgaan boven code 0, bij een teruggevouwen hoek juist andersom. Het algoritme definiëert eerst alles wat potentiëel een interpolatiepunt kan zijn, en met behulp van wagdsc wordt dan heel precies ingevuld wat zeker geen interpolatiepunt is. In de overlappende stukken kunnen enkele punten nog onterecht als interpolatiepunt worden gemarkeerd (als er land in de buurt van de hoekpunten ligt), maar deze kunnen geen kwaad in de rest van de berekening. Een alternatief zou zijn om bij de rechthoeken onderscheid te maken tussen “recht naast de interface” en “het diagonale stuk” en hiermee het verschil van mening in de overlappende stukken te beslechten. Een andere mogelijkheid is om onderscheid te maken tussen “gewone” en “teruggevouwen” hoeken. Deze problematiek is een van de belangrijkste struikelblokken voor het toestaan van meer grillig gevormde interfaces tussen DDHOR-domeinen.

7.6.16

Uitwerking stap 16, communiceren van statusinformatie

De statusinformatie die in de vorige stap per subdomein is bepaald wordt nu gecommuniceerd tussen de subdomeinen van een enkel globaal domein, en tussen de verschillende globale domeinen. De communicatie tussen de subdomeinen van hetzelfde globale domein is eenvoudig omdat alle betrokken rekenprocessen dezelfde datastructuren hebben gedefiniëerd (die zijn immers gebonden aan het globale domein). Hierdoor kan een globale communicatie-operatie worden uitgevoerd op stukken van de kolommen van maxovl. Het maximum over de verschillende subdomeinen wordt berekend, en bevat dan: p > 0 voor punten die in een van de subdomeinen discretisatiepunt zijn, −1 voor punten die interpolatiepunt kunnen zijn en nergens discretisatiepunt zijn, en 0 voor ongebruikte punten. Daarbij heeft code −1 wel voorrang op code 0, omdat er punten uit overlappende rechthoeken in maxovl kunnen zijn ontsnapt aan het als “potentiëel interpolatiepunt” markeren in de vorige stap, namelijk als een rechthoek buiten het bereik van de fullbox van een subdomein valt. De nullen worden daarom tijdelijk vervangen door −3 gedurende het communiceren. Na deze globale communicatiestap per globaal domein bevat maxovl de definitieve keuze voor het eigenaarschap van roosterpunten nabij DDHOR-interfaces. Deze informatie wordt nu geëxpandeerd naar arrays ipowns, ipownu, ipownv en ipownd voor gebruik in subroutine wasixs, voor het definiëren van index sets mnmaxk s, fullbox s etc. De communicatie tussen processen van verschillende globale domeinen is een stuk lastiger.


7-26

De maximale overlap sets per globaal domein bevatten alleen de koppelingen van het eigen domein en verschillen dus tussen de globale domeinen. Daarom wordt naast de maskerwaardes uit maxovl zelf ook de beschrijving van de maximale overlap set uit imtchs gecommuniceerd (imatch, m0-n1, iofovl). Beide communicaties worden met de newspaper-operatie gedaan, waarbij alleen subdomein 1 van ieder globaal domein gegevens hoeft te versturen. Op deze manier worden de kolommen 5 t/m 8 van maxovl in hun geheel ingevuld.

7.6.17

Uitwerking stap 17, definitie echte overlap sets

Tenslotte worden de echte overlap sets overlap s/u/v/d gedefiniëerd. Dit gebeurt in een aantal stappen met behulp van verschillende tussen index sets. De eerste hulp-index set bestaat uit de roosterpunten uit maxovl die meedoen voor het betreffende soort punt (masker6= −2) en die van belang zijn voor het eigen globale domein. De tweede hulp-index set ontstaat door sortering en hernummering van deze index set. In de derde hulp-index set zijn alle dubbel voorkomende (m, n, d) indices geëlimineerd. Tenslotte wordt de echte overlapset gedefiniëerd door het overgaan op procesnummers. Er worden tabellen bijgehouden die de relatie tussen verschillende index sets aangeven. Bijvoorbeeld bevat de tabel irel1m de relatie van hulp-index set 1 naar maxovl: de lengte van de tabel is gelijk aan het aantal elementen van hulp-set 1, en voor ieder element van deze set wordt het nummer van het overeenkomstige element in maxovl gegeven. De tabel van hulpset 3 naar maxovl is meerwaardig. In dit geval wordt een pointerarray iptr3m gebruikt met als lengte het aantal elementen van hulpset 3 plus 1, en bevat irel3m zelf per element van hulpset 3 een of meer verwijzingen naar elementen van maxovl. De conversie van hulpset 3 naar de uiteindelijke overlap set gaat als volgt. Een punt (m, n, d) dat een discretisatiepunt is binnen globaal domein d mag slechts een keer voorkomen in de overlapset, namelijk als (m, n, p) met p het procesnummer van de eigenaar. Interpolatiepunten worden meerdere keren gekopiëerd voor alle subdomeinen van domein d waarvoor (m, n) binnen de fullbox valt. Dit repliceren is nuttig voor COCLIB, voor het communiceren van vervangen verstuurgebieden. Op de overlapsets worden direct coëfficientensets gedefiniëerd ten behoeve van de interpolaties. Ook worden de maximale interfaces gedefiniëerd. Dit zijn min of meer de doorsnedes van de overlapsets per proces: het verstuurgebied van proces p1 naar proces p2 bestaat uit alle eigen punten van p1 die in de overlapset van proces p2 voorkomen. Tenslotte wordt met de nieuwe index sets en interfaces een communicatie uitgevoerd van bekende getallen m + 0.001n om te controleren dat de update-operatie correct werkt.


8-1

Hoofdstuk 8 Detail ontwerp communicatiebibliotheek COCLIB 8.1

Introductie

In hoofdstuk 5 is een overzicht gegeven van het ontwerp van de communicatiebibliotheek COCLIB. Daarbij is behandeld welke principes er worden gehanteerd en hoe deze hebben geleid tot het ontstaan van de basisentiteiten zoals index sets, coëfficiëntensets, enkelvoudige interpolaties e.d. Verder is er uitgebreid aandacht besteed aan het stramien van de updateoperatie, waarin alle basisentiteiten samen worden gebruikt. In dit hoofdstuk wordt dit conceptuele verhaal concreet uitgewerkt. Ten eerste wordt beschreven welke basisoperaties (interpolatiemethoden) er zijn en welke coëfficiënten hierin worden onderkend. Daarna wordt een gedetailleerde beschrijving gegeven van de uitwerking van de basisentiteiten in de COCLIB-programmatuur. Tenslotte wordt een overzicht gegeven van alle COCLIB gebruikersroutines.

8.2 8.2.1

Interne werking: entiteiten en datastructuren Inleiding

Deze en de volgende secties behandelen de interne opzet en werking van COCLIB. Daarbij wordt eerst een globaal beeld geschetst door de entiteiten op logisch niveau verder te beschrijven. In de daaropvolgende twee secties worden de beschikbare operaties in meer detail gepresenteerd. Dit sluit aan bij de nieuwe opzet van de communicatiebibliotheek (vanaf de DDHOR versie van COCLIB), waarin de datastructuren zo min mogelijk direct worden gebruikt. In plaats daarvan is bij elke groep van datastructuren een aantal facilitaire routines gemaakt, waarmee bepaalde informatie uit de datastructuren kan worden opgehaald. De reden hiervan is dat oudere versies van COCLIB soms lastig leesbaar waren vanwege zeer complexe adresseringen in de datastructuren. Deze adresseringen zijn nu uitsluitend terug te vinden in de beperkte set van facilitaire routines. Bovendien is het hierdoor veel eenvoudiger


8-2

geworden om datastructuren te wijzigen (bijvoorbeeld een extra kolom toevoegen aan een array) omdat dit slechts voor een zeer beperkt aantal routines gevolgen kan hebben. Merk op dat de groepen van datastructuren in COCLIB hiermee in feite abstracte datatypes zijn geworden. De belangrijkste entiteiten in COCLIB zijn: 1. indexsets: beschrijvingen van de structuur van arrays waaruit de COCLIB-gebruiker gegevens wil communiceren 2. relatietabellen: tabellen die elementen uit een index set koppelen aan elementen uit een andere indexset; deze tabellen worden gebruikt om gegevens die op een bepaalde indexset (lees: array) bestaan over te zetten naar een andere indexset (lees: array met een andere structuur) 3. (communicatie) interfaces: verzamelde informatie die van belang is om snel gegevens te kunnen versturen en ontvangen in een update-operatie (bijv. lijsten van indexsetelementen die van belang zijn voor verschillende buur-processen) 4. co¨ effici¨ entensets: een hoeveelheid gegevens die nodig zijn in een interpolatiemethode, bijvoorbeeld om interpolatiegewichten te bepalen 5. koppelingscategori¨ en: soorten koppelingen tussen processen, bijvoorbeeld ddh-1:1 of ddv-fixfix 6. procesgroepen: groepen van processen die van belang zijn voor globale communicaties. 7. interpolatiemethoden: conversiemethodes die worden toegepast bij het omzetten van gegevens van het sturende proces naar het rooster van het ontvangende proces. Deze entiteiten worden in de volgende secties uitgebreid toegelicht.

8.2.2

Indexsets

Indexsets zijn van oudsher het centrale concept in COCLIB, en worden voor verschillende doeleinden gebruikt. Primair karakteriseren indexsets de structuur van variabelen in het programma van de gebruiker. Hiervoor wordt aan de indexset-naam een cardinaliteit n gekoppeld. De indices [1..n] worden beschouwd als identifiers voor n verschillende entiteiten van een bepaalde soort. Uit enkelvoudige indexsets kunnen nieuwe sets gevormd worden door het maken van Cartesische producten. Dit is zinvol voor meerdimensionale arrays waarbij de verschillende dimensies een zelfstandige betekenis hebben. Op indexsets kunnen velden worden gedefiniëerd; de indexset dient hierbij als domein van een functie en het veld bestaat uit het resultaat van de functie: de waarde die wordt toegevoegd aan iedere index van de indexset. Merk op dat het bereik van de functie vrij te bepalen is. Dit kan dus net zo goed een enkele reële waarde zijn (∈ IR) als een tuple van drie waardes (bereik = IR3 ) of bijvoorbeeld een string of een code (rood/geel/groen, procesnummer, ...).


8-3

Twee belangrijke velden op indexsets zijn de (gebruikers, logische) coördinaten en de ownership-informatie. De eerste wordt bijvoorbeeld gebruikt voor het definiëren van interfaces met behulp van stencils, en voor het aan elkaar linken van verschillende indexsets (bijv. van verschillende processen, of aan een “globale indexset”). De tweede speelt een belangrijke rol in het bepalen van verzenden ontvang-gebieden in bepaalde soorten communicaties. Van oudsher worden deze twee velden tot de indexset zelf gerekend, maar feitelijk gezien is dat niet nodig. In de huidige versie van COCLIB zijn ze daarom optioneel in de interne datastructuur, en in de toekomst zou het kunnen dat er meerdere varianten van ownership worden gedefinieerd op een enkele indexset. De logische coördinaten van een indexset zijn integer en d-dimensionaal (∈ ZZd ). Er worden twee manieren onderscheiden voor het opgeven van het veld aan COCLIB en voor de interne opslag: regelmatig en onregelmatig. In het tweede geval worden de coördinaten opgegeven als een lijst van n tuples (i1 , .., id ). In het andere geval worden de tuples gegenereerd uit intervallen per dimensie: i1 ∈ ilow(1)..ihig(1), .., id ∈ ilow(d)..ihig(d), met de Fortran-conventie voor het mappen van tuples naar indexset-elementen. Het veld met ownership-informatie bestaat uit een lijst van n integers in [−1..numprc]. Hierin is numprc het aantal processen dat deelneemt in de indexset (DDHOR: aantal subdomeinen van alle domeinen samen). De code 0 wordt gebruikt voor elementen van de datastructuur die niet van belang zijn voor het programma van de gebruiker. De code −1 geeft de mogelijkheid om elementen aan te duiden die wel van belang zijn maar waarvan geen van de processen 1..numprc eigenaar is. Deze code wordt in DDHOR gebruikt voor interpolatiepunten: punten waarvoor de waardes worden bepaald via interpolatie van informatie van andere domeinen/roosters. Merk op dat ownership niet van belang is voor indexsets die geen horizontaal/ruimtelijke interpretatie hebben, zoals kmax. Tabel 8.1 geeft een overzicht van de informatie die over elk van de index sets wordt opgeslagen. COCLIB kent ook indexsets die niet opgeslagen liggen in indset: de zogeheten impliciete indexsets. Een impliciete indexset bestaat uit getallen 1 tot en met het aantal elementen van de indexset. Deze indexsets worden vooral gebruikt als indexset voor zend- en ontvangbuffers. Er komen zeer veel van dergelijke bufferarrays voor met tal van verschillende lengtes; expliciete definitie van de indexsets ervan zou leiden tot een zeer groot aantal indexsets, terwijl van deze indexsets uitsluitend de cardinaliteit van belang is. Impliciete indexsets worden gerepresenteerd door een negatieve indexset-handle (zie de beschrijving van coccr1 verderop), waarbij de absolute waarde van de handle gelijk is aan de cardinaliteit: de indexset met handle −12 is de impliciete indexset [1..12]. Opmerking: bij het ownership hoort ook informatie over de interpretatie van de nummers, ofwel informatie over de groep van processen waar de nummering op slaat. Opmerking: in DDVERT verwijzen de indices k uit indexset kmax van verschillende subdomeinen mogelijk naar lagen met verschillende karakteristieken, dus naar aparte abstracte entiteiten. Dit betekent dat het getal k eigenlijk niet geschikt is als logische coördinaat. Het onderscheid tussen de indexsets kmax per subdomein zou kunnen worden benadrukt door het roosternummer r als tweede coördinaat in te voeren.


8-4

- administration of indexsets (array indset) - IndexSet-ID (entry in 1:nins) - indexset name (array setnms) - datastructure description - total cardinality - type: std-alone / product - product: number of factors - product: references to factors (IndexSet-ID’s) - logical coordinates (optional) - number of dimensions d - type: regular / irregular - regular: low/high-bounds per dimension - irregular: d-dimensional integer field on indexset - ownership information (optional) - field from indexset to [−1..npart] Tabel 8.1: De gegevens die voor elk van de index sets worden opgeslagen

8.2.3

Relatietabellen

Centraal in het hele ontwerp van COCLIB voor DDHOR staan verder de relatietabellen. Deze worden gebruikt voor het representeren van relaties tussen twee indexsets (of ook tussen een indexset en zichzelf), bijvoorbeeld om aan te geven dat de ene indexset een deelverzameling is van een andere, of om aan te geven welke waardes uit een veld op de ene indexset moeten worden gecombineerd in een interpolatieformule voor het berekenen van een waarde uit een veld op de andere index set. Ook kan de ownership-informatie van indexsets worden beschouwd als een relatie tussen de indexset zelf en de indexset van processen (m.u.v. de code −1). De twee indexsets in de relatie worden van elkaar onderscheiden door ze bron- en doelindexset te noemen. De relatie zelf bestaat uit paren (i, j) met i een element van de bronindexset en j een element van de doel-indexset (min of meer het ijlheidspatroon van een matrix). Het nut van de termen bron- en doel-indexset zit in het benoemen van eigenschappen van de relatie. Bijvoorbeeld als er per element van de bron-indexset meerdere paren kunnen zijn gedefiniëerd dan heet de relatie meerwaardig. Merk op dat de omgekeerde (inverse) relatie niet meerwaardig hoeft te zijn. Als er per element van de bron-indexset ten hoogste een paar is opgegeven dan heet de relatie scalair. Een een-op-een relatie is scalair in beide richtingen. Relatietabellen worden gebruikt door de reshape operatie (cocrsh, cocsh[1-5], cocmlt en coccp[uvy]), die (delen van) velden van de ene representatie omzet naar een andere, waarbij mogelijk ook interpolatie plaatsvindt. De gegevensmanipulaties in COCLIB voor DDHOR zijn voor een zeer groot deel ge¨ımplementeerd als reshape operaties. Dit onderstreept het belang van deze operatie en van de bijbehorende relatietabellen. Relatietabellen hebben een naam, een bron-indexset en een doel-indexset, en een beschrijving van de relatie tussen deze indexsets. De beschrijving kan worden opgeslagen in een of


8-5

meer verschillende formaten. Als een tabel wordt opgevraagd in een ander formaat dan waarin hij is opgeslagen, dan zal COCLIB, indien mogelijk, de tabel converteren naar het gevraagde formaat. Een tabel kan ondermeer impliciet worden opgeslagen als het resultaat van een operatie op één of twee andere tabellen. Daarbij wordt opgeslagen welke operatie en welke andere tabellen het betreft. Een dergelijke impliciete relatietabel wordt in principe pas opgebouwd als hij wordt opgevraagd in een bepaald formaat. Voorbeelden van impliciete relatietabellen zijn de inverse van een tabel die eerder is gedefiniëerd en het Cartesisch product van twee tabellen, werkend van het Cartesisch product van de bijbehorende bron-indexsets naar het Cartesisch product van de betreffende doel-indexsets. Een overzicht van de informatie die voor elk van de relatietabellen wordt opgeslagen in te vinden in Tabel 8.2. - administration of relationtables (array ireltb) - Reltab-ID (entry in 1:nreltb) - reltab name (array relnms) - source indexset - type: defined / implicit / variable - defined: reference to defined indexset (IndexSet-ID) - implicit: cardinality of implicit indexset - target indexset - type: defined / implicit / variable - defined: reference to defined indexset (IndexSet-ID) - implicit: cardinality of implicit indexset - storage of relation - number of images (source,target-pairs) - opt: from subset storage format (field on source indexset) - opt: to subset storage format (field on target indexset) - opt: two way scalar storage format (field on num images) - opt: multi value storage format (variable-size tuples on source indexset) - opt: implicit (operator) storage format - opt: pointer to inverse relation (Reltab-ID) Tabel 8.2: De gegevens die voor elk van de relatietabellen worden opgeslagen

8.2.4

Communicatie-interfaces

Communicatie-interfaces zijn in eerste instantie ge¨ıntroduceerd voor parallel rekenen. Ze bestonden initiëel uit de interne en externe stukken van de guardband die van belang zijn in communicaties voor verschillende stencils en maskers: per buurproces een lijst van te versturen indices en een lijst van te ontvangen indices van de eigen indexset.


8-6

Vertikale verfijning Dit concept is al enigszins opgerekt bij de implementatie van vertikale verfijning. In dat geval kunnen de roosters met verschillende aantallen lagen niet goed als een enkel regelmatig gestructureerd rooster worden beschouwd, maar is er feitelijk sprake van een samengesteld gestructureerd rooster. Alleen per subdomein kan het rooster dan nog als een Cartesisch product worden geschreven; de globale index set heeft een samengestelde structuur. In de guardband tussen twee subdomeinen kunnen dan ook twee verschillende roosters worden onderscheiden, en “de interface” bestaat dan uit vier gedeeltes: de in- en externe gedeeltes van het eigen- en van het buurrooster. Alleen is dit nog niet expliciet in de opslag van interfaces verwerkt. Er worden slechts twee tabellen opgeslagen, die voor het eigen rooster. De derde tabel, het interne gedeelte van het buurrooster wordt uit de eigen tabel afgeleid samen met het aantal replicaties voor het buurdomein, dat wordt bepaald uit de lengte van een binnenkomende message. De vierde tabel is in praktijk nooit relevant omdat interpolaties consequent door het ontvangende proces worden uitgevoerd. Horizontale verfijning In het geval van horizontale verfijning kan de interpolatie niet direct toegepast worden op de ontvangen data. In dat geval wordt de data ontvangen en ge¨ınterpoleerd op een speciale datastructuur, de overlap-indexset. De interface voor de veld-indexset bevat nu een extra relatietabel die aangeeft welke punten door de communicatie/interpolatie via de overlap-indexset overschreven moeten worden. Op de overlap-indexset is nu ook een interface nodig om de communicaties te beschrijven die nodig zijn tussen DDHOR-deeldomeinen voor een update van een veld op een veldindexset. De elementen van de overlap-indexset die verstuurd moeten worden liggen niet vast maar zijn afhankelijk van de interpolatiemethode die gebruikt wordt. Daarom bestaan voor een enkele overlap-indexset meerdere interfaces met dezelfde naam als de interface op de veld-indexset. Deze interfaces worden automatisch aangemaakt door COCLIB wanneer ze voor het eerst nodig zijn. Als horizontale verfijning gecombineerd met vertikale verfijning wordt de ontvangen data voor de overlap-indexset vertikaal ge¨ınterpoleerd alvorens deze op de overlap-indexset gezet wordt. Hiermee kan voor de overlap indexset dezelfde eenvoudige productstructuur worden gebruikt als voor de veld-indexset. Een communicatie-interface wordt als volgt geconstrueerd: 1. Er wordt een indexset aangegeven waarop het veld leeft dat moet worden gecommuniceerd, de data-indexset. Op deze indexset mag een masker worden gezet: “is ongewijzigd sinds vorige update”. 2. Door middel van een tweede indexset (de loop-indexset), een masker, en een stencil wordt opgegeven welke elementen van het veld moeten worden ververst: alle gewijzigde elementen die worden bereikt met het stencil toegepast in alle eigen punten van de loopindexset. Dit definiëert het vervanggebied (overwrite-area), en in parallelle berekeningen ook het verstuurgebied van het buurproces. 3. Als indirecte interpolatie nodig is, dan wordt er een derde indexset aangegeven die moet worden gebruikt als tussenformaat: de overlap-indexset. Bij de overlap-indexset wordt


8-7

een relatie van/naar de data-indexset opgegeven, en een communicatie-interface voor directe communicatie van maskers op de overlap-indexset. De relatie wordt gebruikt om het eigen vervanggebied op de overlap-set te bepalen. De interface lijkt niet meer te worden gebruikt. Intern zal dan echter een tweede interface gemaakt worden, die leeft op de overlap-indexset 4. Tenslotte wordt de relatie tussen punten van verschillende roosters in de overlap-indexset voor een bepaalde interpolatiemethode gespecificeerd. Hiermee wordt het verstuurgebied van alle buurprocessen op de overlap-set vastgelegd en aan hen bekend gemaakt (via een communicatie-interface op de overlap-set in de interpolatiemethode). In het verstuurgebied worden ook ongewijzigde data-elementen meegenomen, omdat deze niet bewaard blijven na uitvoering van de interpolatie op het tussenformaat. De loop-indexset, het stencil en de maskers zijn niet meer nodig zodra de interface-tabellen zijn bepaald. De permanente opslag van communicatie-interfaces bestaat aldus uit een naam, de data-indexset, de tabellen per buurproces voor directe communicaties, de basisinformatie op de overlap-set voor indirecte communicaties, en de uiteindelijke tabellen per buurproces en interpolatiemethode voor indirecte communicaties (zie Tabel 8.3). - administration of interfaces (arrays itface, itfitp, itfngb) - Interface-ID (entry in 1:nitf) - name (array itfnms) - data indexset for which the interface is defined (IndexSet-ID) - type: stand-alone / replication of other interface - data of replicated interface: - corresponding interface (Interface-ID) - num replications (for myself, not stored for neighbours) - data of standalone interface: - data for direct comm: - num neighbours for direct communication - per neighbour the Process-ID and two Reltab-ID’s: own interior/exterior guard band area (subsets of data indexset) - data for indirect comm: - relation table for the points that must be filled in by indirect communication (via overlap) (Reltab-ID) Tabel 8.3: De gegevens die voor elk van de interfaces worden opgeslagen

Defini¨ eren van interfaces Bij een gedefiniëerde indexset zijn er nu twee manieren om een eenvoudige interface op te tuigen: met een stencil of volledig handmatig. Een nieuw mechanisme dat kan worden toegevoegd is om de doorsnede van een eigen indexset met indexsets


8-8

van alle buren te bepalen. Het resultaat is een “maximale interface” voor communicatie zonder interpolatie op de betreffende indexset. Dit vereist het versturen van logische coördinaten van alle eigen indices en alle niet-eigen indices naar alle buren, ontvangen van de logische coördinaten per buurproces, en bepalen van de overlap (conform de definitie van indexsets in de parallelle versie van het Kalman filter voor WAQUA/TRIWAQ). Hiermee wordt “de maximale interface” een nieuw attribuut van een indexset.

8.2.5

Co¨ effici¨ entensets

Een interpolatiemethode heeft, naast het te interpoleren veld, ook interpolatiegewichten nodig. Bij DDHOR- resp. DDVERT-interpolaties hangen deze gewichten samen met de horizontale roosterafstanden en met de verticale laagverdeling. De waardes die COCLIB van de gebruiker nodig heeft om interpolatiegewichten te kunnen bepalen staan bekend als coëfficiëntensets. De coëfficiëntsets kunnen in de tijd variabel zijn. Dit geldt met name voor de posities van laaginterfaces bij DDVERT, die meebewegen met de waterstand. Dat betekent dat een proces in principe van tijd tot tijd nieuwe coëfficiënten van de buren moet ontvangen. In de huidige versie van COCLIB kan vertikale interpolatie op twee manieren uitgevoerd worden: • direct: coëfficiëntensets die de laagverdeling bevatten. Dit is de oorspronkelijke DDVERT aanpak • indirect: coëfficiëntensets met waterstanden en opgegeven laagverdelingseigenschappen. COCLIB zal hieruit de laagverdeling berekenen. Dit is de aanpak zoals gebruikt voor de combinatie van DDHOR+DDVERT. De routine cocint definiëert een vertikale interpolatie volgens de ”oude”, directe methode en cocin1 definiëert deze volgens de ”nieuwe”, indirecte methode. Coëfficiëntensets leven op een interface: stukken van het eigen rooster en van de buurroosters die van belang zijn in bepaalde communicaties. Deze interface moet door de gebruiker zodanig groot worden gekozen dat alle volgende gebruik ermee wordt gedekt. De interface van de coëfficiëntenset kent, zoals boven beschreven, een verstuur- en ontvanggebied voor elke buurman. De opslag van coëfficiëntensets wordt gedaan op basis van deze verstuur- en ontvanggebieden. De coëfficiëntensets worden door de gebruiker middels coccoe aangeleverd als veld, op een bepaalde indexset, in plaats van op de interface. In coccoe worden daaruit vervolgens de waarden gehaald voor de verstuurgebieden per buurman, op dezelfde wijze als waarop veldwaardes worden ingepakt in de verzendbuffer tijdens een update. Alleen blijft nu de verzendbuffer permanent aanwezig in COCLIB, voor het later versturen van de coëfficiënten naar de buurman. De coëfficiënten in de guardband worden ontvangen van de buurman. Maar in veel interpolatie-methodes zijn deze coëfficiënten nodig naast de coëfficiënten van het eigen domein: er overlappen twee verschillende roosters en van beiden zijn de coördinaten nodig. In feite worden er daarom drie stukken van de coëfficiëntenset opgeslagen:


8-9

1. de waardes van interne punten van het eigen subdomein, die indien nodig naar het buurproces moeten worden gestuurd; 2. de waardes van guardband punten van het eigen subdomein, de coördinaten van het eigen rooster in het overlap-gebied met het buurdomein; 3. de waardes van interne punten van het buurdomein, coördinaten van het naburige rooster in het overlap-gebied. De laatste twee onderdelen worden gebruikt voor het bepalen van interpolatiegewichten. In sommige gevallen is het niet zinvol om een interface bij een coëfficiëntenset te definieren. Dit is met name het geval voor de coëfficiëntenset van laagposities in het geval van een DDVERT koppeling waarbij geen vaste lagen aan sigma-lagen zijn gekoppeld: in dat geval variëren de gebruikte laagposities niet over de horizontale punten en kan dus volstaan worden met het opgeven van de laagposities op de indexset kmax. In dat geval wordt de gehele coefficiëntset opgeslagen voor het eigen subdomein en voor alle buurdomeinen. Daarbij wordt vanuit verschillende plaatsen verwezen naar het array van waardes voor het eigen subdomein, dat slechts een keer wordt opgeslagen. Een ander feature van coëfficiëntensets is dat ze door de gebruiker op een andere indexset kunnen worden toegeleverd dan waarop ze feitelijk nodig zijn: bijvoorbeeld de oppervlaktes van cellen gsqs op mnmaxk s die nodig zijn voor interpolatie van concentraties op overlap s. In dat geval moet COCLIB voor het vullen van de arrays op de interface weten hoe de twee indexsets aan elkaar zijn gerelateerd. Hiervoor bevat een coëfficiëntenset een relatietabel tussen de twee indexsets (unity als de twee hetzelfde zijn). De horizontale interpolaties in een DDHOR berekening zijn gebaseerd op logische (m, n) in plaats van de fysische (x, y) coördinaten. Omdat de logische coördinatenstelsels per rooster niet vergelijkbaar zijn, mogen de coëfficiënten niet worden gecommuniceerd tussen buurprocessen. In plaats daarvan levert een rekenproces de coëfficiënten voor de externe punten van zijn eigen subdomein èn voor de overeenkomstige interne punten van het buurdomein. Merk op dat dit niet mogelijk is binnen de datastructuur fullbox, omdat die geen ruimte bevat voor roosterpunten van verschillende roosters/subdomeinen. Voor deze niet-communiceerbare coefficiëntensets moet de gebruiker de coëfficiënten dus op een voldoende grote (overlap-)indexset toeleveren. Tabel 8.4 geeft een overzicht van de gegevens die voor elke coëfficiëntenset worden opgeslagen.

8.2.6

Koppelingscategori¨ en

Een rekenproces in een DDHOR-berekening kan in principe op tal van manieren aan buurprocessen gekoppeld zijn. Voorbeelden zijn: een DDHOR-koppeling met verfijning, een DDHORkoppeling zonder verfijning, een parallelle koppeling of een DDVERT-koppeling. Omwille van efficiëntie is het gewenst om overbodige kopiëer- en interpolatie-operaties tot een minimum te beperken. Dat betekent dat een proces per buurman in principe andere handelingen moet verrichten bij de communicatie: in het ene geval moet bijvoorbeeld wel verticale interpolatie plaatsvinden, in het andere geval niet. Daarom wordt van elk van de buurprocessen


8-10

- administration of coefficient sets - Coefset-ID (entry in 1:ncofst) - name of coefficientset (array cofnms) - type: standard / no-communication&refreshing - data-type: Integer / Real - storage structure (internal data-structure for the coefficients, Interface-ID, only the direct-communication parts are used, refes to storage Indexset-ID) - user datastructure (on which coefficients are provided, Indexset-ID) - Reltab-ID (relation from Indexset of storage structure to user Indexset-ID) - own timestamp, version number - neighbour information (array icofng) - Process-ID - neighbour knows (flag, current version of own data has been sent) - pointers to data-arrays (own internal data, own guard band data, other guard band data) - ngb timestamp, version number of neighbour’s guard band data - num ngb coefs (derived from incoming message, dependent on nr. of layers) Tabel 8.4: De gegevens die voor elk van de coëfficiëntensets worden opgeslagen bepaald wat voor type koppeling er gebruikt wordt. De soorten koppelingen die toegestaan zijn, worden aangeduid als koppelingscategoriën. Tabel 8.5 geeft een overzicht van de gegevens die voor elke koppelingscategorie worden opgeslagen. - administration of coupling categories - CoupCat-ID (entry in 1:numcat) - name of coupling category (array copcat - administration of neighbour processes - Process-ID (entry in 1:ntids) - PVM task-id (array itids) - coupling category of neighbour (CoupCat-ID, array icptyp) Tabel 8.5: De gegevens die voor elk van de koppelingscategorieën worden opgeslagen

8.2.7

Procesgroepen

In DDHOR vinden globale operaties (bijvoorbeeld een sommatie van waarden over alle processen) niet langer altijd plaats over alle processen. In plaats daarvan kunnen subgroepen van processen gedefiniëerd worden die met elkaar een bepaalde globale operatie uitvoeren. Een dergelijke subgroep wordt aangeduid als procesgroep.


8-11

Iedere procesgroep heeft een naam waarmee deze kan worden geselecteerd in het gebruikersprogramma. Bij de naam hoort verder het instantiatie-nummer van het eigen proces: van een groep mydomain kunnen er meerdere versies naast elkaar bestaan, en een rekenproces neemt in ten hoogste een van die versies deel. Tenslotte bevat de administratie van groepen per rekenproces de lijst van processen in de eigen versie van iedere groep. Tabel 8.6 geeft een overzicht van de gegevens die voor elke procesgroep worden opgeslagen. - administration of process groups - Group-ID (entry in 1:ngrps) - name of process-group (array grpnms) - own instance number (array igrpin) - num members of own instance - list of members (Process-ID’s) Tabel 8.6: De gegevens die voor elk van de procesgroepen worden opgeslagen

8.2.8

Basisoperaties

Interpolatiemethoden worden opgebouwd door basisoperaties te combineren met coëfficiënten, en kunnen daarna worden toegepast voor het interpoleren van velden. Attributen van basisoperaties zijn een naam, het aantal argumenten, en het soort operatie (type I/II/III, zie paragraaf 5.9). De basisoperatie “constant for layer-averages” (directe vertikale interpolatie) is bijvoorbeeld gebaseerd op de volgende formules: gi = fj van grof naar fijn, voor geschikte j op het grove rooster X gi = fj · (zhigh,j − zlow,j )/(zhigh,i − zlow,i ) van fijn naar grof

(8.1) (8.2)

j

De totale operatie heeft naast het invoerveld g en uitvoerveld f vier argumenten, die allemaal uit een enkel veld van z-coördinaten kunnen worden verkregen met geschikte adressering. Daarbij zijn er twee argumenten op het eigen rooster (indexset waartoe i behoort) en twee op het buurrooster waartoe de punten j behoren. Tabel 8.7 geeft een overzicht van de gegevens die voor elke basisoperatie worden opgeslagen. - administration of base operations - BaseMeth-ID (entry in 1:nopers) - name of base-operation (array oprnms) - num arguments (array nargop) - type of operation (I, II of III) Tabel 8.7: De gegevens die voor elk van de basisoperaties worden opgeslagen


8-12

Feitelijk zijn de door de basisoperatie gehanteerde formules en de posities van argumenten daarbinnen ook attributen van de basisoperatie. Daarnaast kan als extra informatie worden toegevoegd de routines waarmee de basisoperaties worden gedefiniëerd (constant for layeraverages: routine cocint).

8.2.9

Samengestelde interpolatiemethoden

Een complete samengestelde interpolatiemethode bestaat uit het gedrag dat de update-routine moet vertonen in elk van de fases van de update. De derde fase (vertikale interpolatie) verschilt hierbij voor alle koppelingscategoriën. Het gedrag voor alle fases en koppelingscategorie wordt vastgelegd door een samengestelde interpolatiemethode te definiëren (routines cocml0), en vervolgens de gegevens voor elk van de fases in het stramien van de update, zie paragrafen 5.9 en 5.8. Deze fases zijn: 1. relatietabel voor Fase 1 (reshape-operatie, type I, (routine cocmt1), 3. enkelvoudige methode voor Fase 3 voor elke koppelingscategorie (vertikale interpolatie, type II, routine cocmt3), 4. enkelvoudige methode Fase 4 (horizontale interpolatie, type III, routine cocmt4).

- administration of compound methods (array imtcmp - CompoundMeth-ID (entry in 1:nmtcmp) - name of compound method (array mthnms) - field indexset (data-structure for which method is designed, Indexset-ID) - tempstorage indexset (data-structure used in case of horizontal interpolation, Indexset-ID) - method fase 1 (reshape, Reltab-ID) - method fase 3 (vertical interpolation, DDVmeth-ID, for each coupling category, array ifase3) - method fase 4 (horizontal interpolation, DDHmeth-ID) Tabel 8.8: De gegevens die voor elk van de samengestelde interpolatie methode worden opgeslagen Het tussenopslagformaat dat wordt gebruikt in indirecte interpolaties wordt momenteel nog niet opgeslagen bij de samengestelde methode, maar bij communicatie-interface en bij afzonderlijke enkelvoudige methodes, in beide gevallen via de target van een relatietabel. Dit geeft enige redundante opslag en mogelijk een beperking aan welke interfaces met welke interpolatie-methodes samen gebruikt kunnen worden. Een motivatie voor de keuze in de huidige implementatie is dat aan de samengestelde interpolatiemethode niet kan worden gezien of er buren zijn voor indirecte communicatie, dus of het tijdelijke opslagformaat moet worden gealloceerd en gevuld.


8.2.10

8-13

Enkelvoudige interpolatiemethoden

Hierboven is beschreven dat samengestelde interpolatiemethoden verwijzen naar DDVmethID’s en DDHmeth-ID’s. Dit zijn enkelvoudige interpolatiemethoden, voor een enkele fase van de update en voor een enkele koppelingscategorie. Het invullen van een enkelvoudige methode gebeurt door te kiezen voor een basisoperatie en door aan te geven welke coëfficiënten daarin moeten worden gebruikt (voor zover van toepassing). Verder moet een indexset worden gekozen waarvoor de methode gaat worden toegepast, met daarop maskers voor de interpolatiepunten (waarvoor waardes moeten worden berekend door de methode) en discretisatiepunten (waarvan waardes mogen worden gebruikt in de interpolatie). Deze maskers mogen op een andere indexset worden aangeleverd dan waarvoor de interpolatiemethode wordt gedefiniëerd (m.b.v. relatietabel) en worden onder water gecommuniceerd tussen rekenprocessen via een opgegeven interface. Zoals in paragraaf 8.2.8 is toegelicht beschrijft een basisoperatie een principe waarmee getallen kunnen worden geconverteerd, maar hangt de uitwerking daarvan af van parameters en coëfficiënten. Bijvoorbeeld kan pas uit de coëfficiënten voor (coördinaten van) discretisatie- en interpolatiepunten een interactiepatroon worden gedestilleerd (matrix-ijlheid/sparsity, relatietabel). Dit patroon hangt af van welke basisoperatie wordt gebruikt; bijvoorbeeld zoekt de bilineaire methode per interpolatiepunt vier omliggende discretisatiepunten, en zoekt de methode “cell-average” de met een interpolatie-roostercel overlappende discretisatie-cellen. Op de interacties kunnen ook gewichten worden gedefiniëerd, hiermee worden interpolatiematrices verkregen. Bij elke enkelvoudige interpolatiemethode behoren één of meerdere interpolatiematrices. In het geval van een DDHOR interpolatie is er een enkele matrix die veldwaarden op een (overlap) indexset interpoleert naar diezelfde indexset. In het geval van een DDVERT interpolatie is er voor elke buurman een interpolatiematrix, die waarden uit de ontvangstbuffer interpoleert naar de doel-indexset. De interpolatiematrices worden bepaald uit de coëfficiëntensets aan de hand van de gebruikte basisoperatie. Daarbij bepaalt de routine van de basisoperatie hoe de argumenten van de basisoperatie zijn gerelateerd aan de coëfficiëntensets. Bijvoorbeeld heeft de methode “constant for layer-averages” vier argumenten die achtereenvolgens worden gelezen uit het eigen/eigen/neighbour/neighbour-gedeelte van een enkele coëfficiëntenset van vertikale coördinaten. Een coëfficiëntenset kan in de tijd veranderen: de gebruiker kan door middel van coccoe nieuwe waardes voor coëfficiënten opgeven. Als er een nieuwe versie van een coëfficiëntenset beschikbaar komt, moeten de bijbehorende matrixgewichten opnieuw berekend worden. Dit is ge¨ımplementeerd door bij een matrix op te slaan welke versie van de coëfficiënten (of ook interpolatie-argumenten) zijn gebruikt bij het bepalen van de gewichten. Als bij het ophalen van de matrix blijkt dat coëfficiëntensets zijn gewijzigd, dan worden de waardes van de matrix-elementen (d.i. de gewichten) opnieuw bepaald. Om dat snel te kunnen doen wordt in zogeheten argument-selectietabellen ook opgeslagen welke elementen van elke coëfficientenset er precies gebruikt worden en in welke volgorde. Daarmee wordt het berekenen van de gewichten sterk vereenvoudigd. De argument-selectietabellen zijn feitelijk relatietabellen.


8-14

- administration of single methods (array intmth) - SingleMeth-ID (aliases: DDHmeth-ID, DDVmeth-ID, entry in 1:nintmt) - name of single interpolation method (array intnms) - field indexset (data-structure for which method is designed, Indexset-ID) - type stand-alone / replication of other method - data of replicated method - corresponding method (SingleMeth-ID) - num replications - data of stand alone method - base operation (BaseMeth-ID) - arguments - num arguments (equal to value stored in base operation) - per argument: CoefSet-ID and selection-type own-ext/ngb-ext/overlap - matrices - num matrices - per matrix: neighbour to which matrix applies (Process-ID or void (all)) - per matrix: table for addressing input-field (Reltab-ID) - per matrix: handle of matrix itself (Matrix-ID) - administration of interpolation matrices (array matrix) - Matrix-ID (entry in 1:nmatr) - actual matrix contents - sparsity pattern table (Reltab-ID, multi value) - num nonzeros (equal to number of images in relationstable) - weights (matrix elements) - data of arguments used - num arguments (value of corresponding single method/base operation) - per argument: version number used in construction of matrix - per argument: relations table for addressing arguments (Reltab-ID) Tabel 8.9: De gegevens die voor elk van de enkelvoudige interpolatiemethode en voor elk van de interpolatiematrices worden opgeslagen

8.3

Overzicht van de wijzigingen aan COCLIB t.b.v. DDHOR+VERT

In het project DDHOR+VERT is de interne structuur van COCLIB op een aantal punten flink veranderd. De aanpassingen die zijn gemaakt hebben de volgende achtergrond: • de samengestelde interpolatie methode kan nu tegelijkertijd fase-3 en fase-4 interpolaties bevatten. • de oorspronkelijke sigvast-interpolatie op basis van de coëfficiëntensets zks, zku en zkv


8-15

kan niet worden gebruikt wanneer roosterpunten in het horizontale vlak niet 1:1 samenvallen. Hiervoor zijn nieuwe basisoperaties toegevoegd die gebruik maken van de coëfficiëntensets depth, sep, hlay, indlay en hlaysh. • herstructurering van de COCLIB-entiteiten. De “DDHOR”-definities van COCLIBentiteiten was erop gericht per object de gehele update-operatie te beschrijven. Dit was niet meer houdbaar. De belangrijkste aanpassing betreft die van de interfaces. In geval van indirecte communicatie (via overlap) spelen er nu twee interfaces een rol: een voor de indexset waarop de gebruiker zijn data aanlevert en een voor de overlap indexset (afhankelijk van interpolatie methode). Hiervoor zijn naast de interface ook de matrices en samengestelde interpolatiemethoden aangepast. • toevoegen van tijdsafhankelijke maskers voor de DDHOR interpolatie. Met behulp van het masker kunnen droge punten buiten de interpolatie gehouden worden.


8.4

8-16

De gebruikersroutines

In deze paragraaf wordt een specificatie gegeven van alle subroutines van COCLIB voor zover deze door applicatieprogrammeurs gebruikt mogen worden. Allereerst wordt een overzicht gegeven. In de navolgende paragrafen worden de routines in detail uitgewerkt.

8.4.1

Overzicht

Indexsets, interfaces, co¨ effici¨ entensets (zie paragraaf 8.4.2) cocidr definiëer een regelmatige indexset cocidi definiëer een onregelmatige indexset cocidx definiëer een indexset zonder informatie over eigenaarschap cocprd definiëer het produkt van twee indexsets cocitf definiëer een interface met behulp van stencil cocifd definiëer een interface direct coctpr repliceer een interface voor een produkt-indexset cocico definiëer een coëfficiëntenset coccoe (her)vul een coëfficiëntenset coccoo bereken een coëfficiëntenset uit meerdere andere Conversiemethoden (zie paragraaf 8.4.3) cocmt0 definiëer een nieuwe samengestelde methode cocmt1 zet de reshape methode (naar overlap indexset) voor een samengestelde methode cocmt3 voeg een enkelvoudige fase 3 interpolatie methode toe aan een samengestelde methode cocmt4 voeg een enkelvoudige fase 4 interpolatie methode toe aan een samengestelde methode cocin1 definiëer een DDV interpolatiemethode cocint definiëer een DDV interpolatiemethode coccel definiëer een DDHOR lokaal constante interpolatie coccfl definiëer een DDHOR lin*weigh interpolatie cocbil definiëer een DDHOR bilineaire interpolatie cocsum definiëer een DDHOR sommatie interpolatie cocmax definiëer een DDHOR maximumwaarde interpolatie cocmpr repliceer een DDHOR interpolatie voor produkt-indexsets coctyp bepaal koppelingscategorieën voor buurprocessen coccat bepaal koppelingscategorie behorende bij gegeven parameters

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) Communicatie-operaties (zie paragraaf 8.4.4) cocupd ververs kopiën van veldwaarden uit buurprocessen cocigl globale reductie van integers cocrgl globale reductie van reals cocrgs vector reductie op basis van één van de vector elementen cocnws newspaper-operatie Relatietabellen (zie paragraaf 8.4.5) cocrdm creëer relatie tussen een indexset en een subset ervan cocr2r combineer twee relatietabellen tot een nieuwe cocrss creëer relatie door twee indexsets te matchen Print routines (zie paragraaf 8.4.6) cocstt print overzicht van een interface cocrpr print overzicht ven een relatie tabel cocprm print overzicht van een interpolation methode cocstk print overzicht van het geheugen gebruik door COCLIB Diversen (zie paragraaf 8.4.7) cocini initialiseert COCLIB cocend sluit COCLIB af cocdgr definiëer een procesgroep cocmem bepaal benodigde geheugenruimte voor COCLIB cocsrt sorteer een coördinatenarray cocarg haal een argument op van standaard invoer

8-17


8-18

8.4.2

Routines voor het defini¨ eren van indexsets, interfaces en coeffici¨ entensets

8.4.2.1

cicidr

Registers a regular index set with name setnam and size [idmmin(idim),idmmax(idim)], idim=1,ndim, in which ipown defines the ownership of points (owner=0: not used). The index set is recorded in array icocad subroutine cocidr(setnam,ndim,idmmin,idmmax,ipown, icocad,name) integer ndim,idmmax(ndim),idmmin(ndim), ipown(*),icocad(*) character*(*) setnam,name icocad idmmax idmmin ipown name ndim setnam 8.4.2.2

o i i i i i i

administration array for COCLIB largest coordinate in each of the dimensions smallest coordinate in each of the dimensions array defining the ownership of points in full-box name of the calling subroutine number of dimensions for index set name of the set to be created

cocidi

Registers an irregular index set, given by coordinate-pairs and owners. subroutine cocidi(setnam,length,ndims,icoor,ipown,icocad,name) integer length, ndims, icoor(ndims,length), ipown(length), icocad(*) character*(*) setnam, name icocad i o icoor i ipown i length i name i ndims i setnam i 8.4.2.3

administration array for COCLIB X- and Y-coordinates of each point in index set array defining the ownership of points number of points in the index set name of the calling subroutine Number of coordinates per index (dimension) name of new index set

cocidx

Registers an index set without coordinate and ownership information


8-19

subroutine cocidx(setnam,length,icocad,name) integer length, icocad(*) character*(*) setnam, name icocad io length i name i setnam i 8.4.2.4

administration array for COCLIB number of points in the index set name of the calling subroutine name of new index set

cocprd

Creates a new index set by taking the Cartesian product of two existing index sets and registers it in array icocad subroutine cocprd(setnam,setnma,setnmb,name) character*(*) setnam,setnma,setnmb,name name setnam setnma setnmb 8.4.2.5

i i i i

name name name name

of of of of

cocitf

Registers an interface

the calling subroutine new index set first index set in product second index set in product


8-20

subroutine cocitf(setnm1,mask1,noffs,ioffs,idmoff,setnm2,mask2, ovlnam, rshp2, itfnam, icocad, name) Integer noffs,idmoff,ioffs(idmoff,noffs),mask1(*), mask2(*), icocad(*) character*(*) name, itfnam, setnm1,setnm2,ovlnam,rshp2 icocad o idmoff io ifcall i itfnam mask1 mask2 name noffs ovlnam

i i i i i i

rshp2 setnm1 setnm2

i i i

administration array for COCLIB number of dimensions of offsets name of ’maximum’ interface to be used for direct communication (copy-update) with overlap set name of interface to be created masking array defined on index set setnm1 masking array defined on index set setnm2 name of the calling subroutine number of offset vectors in list ioffs name of the overlap index set through which to make the overwrite-areas name of relation between index sets setnm1 and ovlnam name of index set on which stencil operates name of the index set to which table is restricted

The interface consists of - internal interface [(exter(G1) n M1) @ S) n (inter(G2) n M2) ] external interface [(inter(G1) n M1) @ S) n (exter(G2) n M2) ] where inter(G1) is index set setnm1 restricted to local points (points inside the local computational domain), exter(G1) is index set setnm1 restricted to the other domains, inter(G2), exter(G2) are likewise for setnm2, S is the stencil defined by noffs,ioffs, @ is the dilatation operation and n is the intersection of sets. Mask1 and mask2 must contain 0 and 1 only. All arrays must be consistent over all subdomains (contain the same values for the same (logical/global) index). For example, let a global domain M N = {1..20} {1..50} is partitioned row-wise in two parts: N 25 and N>25. The point with local N-coordinate 1 on process 2 has global N coordinate 23 (because the guard band covers N=23,24 and 25). Suppose there is a water level checkpoint at global coordinate (10,25), then this point must be included in the index set by both processors (albeit with different local coordinates) and they must use the same value for mask for this water level checkpoint. This is so because both processes must agree on what is in the index set. See also E.A.H.Vollebregt,”Parallel Software Development Methods for Shallow Water Equation”, PhD-thesis, TUDelft. 8.4.2.6

cocifd

Define an index set directly (i.e. not implicitly through the specification of a stencil as in cocitf)


8-21

subroutine cocifd(setnam,itfnam,itbovw,itbfa4,itab,nproc,ixitf,icocad,name) Integer nproc, itbovw, ixitf, itbfa4, itab(nproc,2), icocad(*) character*(*) setnam, itfnam, name icocad io itab i

itbfa4 itbovw

i i

itfnam ixitf name nproc setnam

i o i i i

coclib administration array handles of relation tables for intenal and external interface itab(iprc,1) = handle of internal interface for process iprc itab(iprc,2) = handle of external interface for process iprc indices are IVOID when no corresponding relation table exists handle of relation table for horizontal interpolation relation table containing the overwrite area (interpolation points) interface. name of interface to be created handle of the created interface name of the the calling subroutine number of processes in coupled run name of index set on which interface is defined

This routine is used to define an index set directly (i.e. not implicitly through the specification of a stencil as in cocitf), which is needed when defining interfaces on overlap sets. For each process in the total run, an internal and an external interface relation table needs to be provided; if a particular process does not occur in the interface of the calling process, the a zero can be specified for the relation table handles for that process. 8.4.2.7

coctpr

Defines an interface on a product index set as the product of an interface on the horizontal part of the product index set with the vertical part of the product index set. subroutine coctpr(itfnam,setnam,setprd,icocad,name) Integer icocad(*) character*(*) itfnam, setnam, setprd, name icocad io itfnam i name i setnam i setprd i

COCLIB administration array name of interface that is replicated name of the calling subroutine. name of the index set where itfnam lives on name of the index set for wich the interface must be made available by replication

This routine defines an interface on a product index set as the product of an interface on the horizontal part of the product index set with the vertical part of the product index set. This ”replicated¨ınterface can be used for communications on the product index set.

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) 8.4.2.8

8-22

cocico

Defines a coefficient set. subroutine cocico(cofnam,setnm1,itfnam,setnm2,tabnam,typnam,itype, icocad,name) Integer itype, icocad(*) character*(*) name, setnm1, itfnam, setnm2, cofnam, typnam, tabnam cofnam icocad itfnam itype

i o i i

name i setnm1 i setnm2 i tabnam i typnam i

name of new coefficient set to be made administration array for COCLIB name of a sufficient interface for communication of coefficients a flag specifying constraints on the coefficientset 0 = no special constraints 1 = coefficientset may not be communicated or refreshed name of the calling subroutine name of index set on which coeffs will be delivered (through coccoe) name of index set on which coeffset is defined name of relation between setnm1 and setnm2 one of: ’real’ and ’integer’: data type of the coefficients

Defines a coefficient set with values of type typnam. The index set on which the coefficient set is defined, is setnam. To obtain coefficients from neighboring processes, communication is to be done over interface itfnam. The argument itype defines special attributes of the coefficient set. At this moment, there is just one special attribute that a coefficient set may have, begin that the set may not be communicated and not be refreshed. This is useful for coefficient sets in which horizontal coordinates of index set points are stored: horizontal interpolation methods are static and therefore the coordinates are not supposed to change. Also, each process may use its own coordinate frame to define coordinates, so that coordinates from neighboring subdomains may be incomparable and should therefore not be exchanged. If a coefficient set is marked as unrefreshable, then an error will occur if coccoe is called a second time for this coefficient set. Coefficient sets are used to construct interpolation methods using for example cocint, and supply additional information to the interpolation methods such as concerning the grids in neighbouring processes. The index set and interface that are given here will be used to exchange the data for the coefficient set between neighbouring processes. Some coefficient sets are used as a whole, so all neighbours obtain the same, full information. Such coefficient sets have no interface, which is indicated by the empty string itfnam. 8.4.2.9

coccoe

Fill or refresh a coefficient set with data for later use in cocupd()


8-23

subroutine coccoe(cofnam,ivar,vtype,setnam,icocad,name) Integer ivar(*), icocad(*) character*(*) name, setnam, cofnam,vtype cofnam i name of coefficient set to be filled with data icocad i COCLIB administration array ivar i data to be put into coefset name i name of the calling subroutine setnam i name of index set on which ivar lives vtype i data type of coefficent set ’INTEGER’ of ’REAL’ Array ivar contains the (integer or real) data of the coefficient set. The index set on which ivar is defined, indicated by its name setnam, must be the same index set as the index set of the coefficient set as registered by cocico. The subroutine coccoe copies only those parts of ivar which will be needed for the construction of interpolation matrices into ICOCAD, as specified by the stencil for the coefficient set that was registered by cocico. Fills the specified coefficient set using values from array ivar, which is structured according to index set setnam. For coefficient sets that are marked ”read-only”(see cocico) coccoe may be called only once. 8.4.2.10

coccoo

Compute a new index set by combining several others subroutine coccoo(cofnm1,cofnm2,cofnm3,cofnm4,cofnm5,opstr,icocad,name) Integer icocad(*) character*(*) cofnm1, cofnm2, cofnm3, cofnm4, cofnm5, opstr, name cofnm1 i name of first coefficient set cofnm2 i name of second coefficient set cofnm3 i name of third coefficient set cofnm4 i name of fourth coefficient set cofnm5 i name new created coefficient set after operation icocad io COCLIB administration array name i name of the calling subroutine opstr i type of operation of index sets This routine can be used to compute a new index set by combining several others. The supported ways of combining coefficient sets are: ’c5 = |(c1, c2) − (c3, c4)|’ i.e. the length of the vector from (x0 , y0 ) to (x1 , y1 ), where x1 = c1, y1 = c2, x0 = c3 en y0 = c4. ’c5 = (c1 + c2)/2’ i.e. the average of the two coefficient sets Note that the combination of coefficient sets can only be done if the coefficient sets are defined on the same interface. Note also that if one of the coefficient sets that is used changes over time, then the result of this operation is not automatically updated.


8.4.3

Routines voor het defini¨ eren van conversie-operaties

8.4.3.1

cocmt0

8-24

Create a new composite interpolation method . subroutine cocmt0(mthnam,setnm,name) character*(*) mthnam, setnm, name mthnam i name i setnm i

name of the method to be constructed name of the calling subroutine. Only used for error messages. index set for which the method is to be used

Defines a composite interpolation method mthnam, Base interpolation methods added in the composite method using cocmt3 and cocmt4. The relation table for the overlap index set can be set using the routine cocmt1. cocmt0 initialized the reshape and basic interpolation methods in new composite method to IVOID. 8.4.3.2

cocmt1

Enter a reshape method for a composite interpolation method. subroutine cocmt1(mthnam,setnm,rshp,name) character*(*) mthnam, setnm, rshp, name mthnam name rshp setnm

i i i i

name of the composite interpolation method the name of calling subroutine.Only used for error messages. reshape method, to be used in fases 1 and 4 of update index set for which the method is to be used

Set the relation table to the overlap indexset. This is necessary if ddhor interpolation methods are added to the composite method. (The fase 4 ddhor interpolations take place on the overlap index set). 8.4.3.3

cocmt3

Registering simple fase 3 interpolation.


8-25

subroutine cocmt3(mthnam,setnm,iviaov,catnms,ncat,ddvmth,name) integer ncat, iviaov character*(*) mthnam, setnm, catnms(ncat), ddvmth, name catnms ddvmth iviaov mthnam name ncat setnm

i i i i i i i

coupling category for which the method is to be filled interpolation method to be used in fase 3 of update (COCUP3) considering communication via overlap index set (1) or not (0) name of the method to be constructed name of calling subroutine. Only used for error messages. size of array catnms (number of coupling cathegories) index set for which the method is to be used

Add a simple fase 3 interpolation method to a composite interpolation method. The simple fase 3 interpolation method is created using cocin1 or cocint (=old format) 8.4.3.4

cocmt4

Register a simple interpolation method for fase 4 in a composite interpolation method subroutine cocmth(mthnam,setnm,cpcat,rshp,ddvmth,ddhmth,name) integer iviaov, icocad(*) character*(*) mthnam, setnm, ddhmth, name ddhmth i icocad io iviaov i mthnam name setnm

i i i

interpolation method to be used in fase 4 of update (COCUP4) administration array flag: considering communication via overlap index set (1) or not (0) name of the method to be constructed name of calling subroutine. Only used for error messages. index set for which the method is to be used

Add a simple fase 4 interpolation method to a composite interpolation method. The simple fase 4 interpolation method is created using coccel, coccfl, cocbil, cocsum, cocmax or cocmpr. 8.4.3.5

cocin1

Defines a DDV interpolation (an interpolation for vertical refinement)


8-26

subroutine cocin1(mthnam,setnam,copnam,numcop,basmth,cofnm1,cofnm2, cofnm3, cofnm4, cofnm5, itfnam, setifc, icocad, name) Integer numcop, icocad(*) character*(*) mthnam, setnam, basmth, cofnm1, cofnm2, cofnm3, cofnm4, cofnm5, name, setifc, itfnam, copnam(numcop) basmth cofnm1 cofnm2 cofnm3

i i i i

cofnm4 i cofnm5 i copnam i icocad i itfnam i mthnam name numcop setifc setnam

i i i i i

name of the ’base’ method name of the 1st coefficient set to be used holding depth() name of the 2nd coefficient set to be used holding sep() name of the 3th coefficient set to be used holding [fixdep,hlay()] name of the 4th coefficient set to be used holding [nofix, indlay()] name of the 5th coefficient set to be used holding [trsdep, hlaysh()] names of the coupling catagories for which method works COCLIB administration array interface which from which the possible neighbors may be read for this interpolation method name of the method name of the calling process number of coupling catagories (dimension of copnam) index set on which interface itfnam lives (see itfnam) name of the index set for which the interpolation is to be used

Defines a DDV interpolation (i.e. interpolation directly from the received message to the target index set), using the specified way of interpolating data and the specified coefficient set. The base interpolation methods ’cns lay avg’, ’cns lay intg’, ’lin sampl kmax0’ and ’lin sampl kmaxi’ are all used for interpolation of data representing a function of a single variable. They are based on the distribution of the co-ordinate range of interest into a number of consecutive interval. Methods ’cns lay avg’ and ’cns lay intg’ treat the data items as average function values and integrated function values per interval ’cns lay intg’ treat the data items as average function values and integrated function values per interval Base methods ’lin sampl kmax0’ and ’lin sampl kmaxi’ treat the data items as samples at the end points of all intervals. These four base methods can -under certain restrictionsbe applied to 1D, 2D and 3D arrays of values (index sets). Only one of these array-dimensions is interpolated. The coefficient values are allowed to vary from one non-interpolated index to another, or the same coefficients can be applied to all elements of a non-interpolated array dimension. This is determined by the size of the coefficient set used in the definition of an actual interpolation method. If the coefficient set is 1D, then the same coefficient values are used (replicated) for all non-interpolated array dimensions. Otherwise, the coefficient set should be 2D with the second dimension corresponding to the interpolated array dimension. In this case the resulting interpolation method can be applied to 2D and 3D fields only, and the first dimen-


8-27

sion of the field-index set must match the first dimension of the coefficient set for which the coefficient values are varying. The coefficient values are replicated in case there is a third array dimension. 8.4.3.6

cocint

Defines a DDV interpolation (an interpolation for vertical refinement) subroutine cocint(mthnam,setnam,copnam,basmth,cofnam,icocad, name) Integer icocad(*) character*(*) mthnam, setnam, copnam, basmth, cofnam, name basmth cofnam copnam icocad mthnam name setnam

i i i i i i i

name of the ’base’ method name of the coefficient set to be used name of the coupling for which method works COCLIB administration array name of the method name of the calling subroutine name of index set for which method is to be used

Defines a DDV interpolation (i.e. interpolation directly from the received message to the target index set), using the specified way of interpolating data and the specified coefficient set. The base interpolation methods ’cns lay avg’, ’cns lay intg’, ’lin sampl kmax0’ and ’lin sampl kmaxi’ are all used for interpolation of data representing a function of a single variable. They are based on the distribution of the co-ordinate range of interest into a number of consecutive intervals, and require a single coefficient set that describes the coordinates of the end-points of the intervals. Methods ’cns lay avg’ and ’cns lay intg’ treat the data items as average function values and integrated function values per interval and require one less data items than co-ordinate values in the coefficient set. Base methods ’lin sampl kmax0’ and ’lin sampl kmaxi’ treat the data items as samples at the end points of all intervals. The former requires as many data items as co-ordinate values, the latter supplies zero boundary conditions at the outer ends of the entire co-ordinate range and requires two less data items than co-ordinate values. These four base methods can -under certain restrictionsbe applied to 1D, 2D and 3D arrays of values (index sets). Only one of these array-dimensions is interpolated. The coefficient values are allowed to vary from one non-interpolated index to another, or the same coefficients can be applied to all elements of a non-interpolated array dimension. This is determined by the size of the coefficient set used in the definition of an actual interpolation method. If the coefficient set is 1D, then the same coefficient values are used (replicated) for all non-interpolated array dimensions. Otherwise, the coefficient set should be 2D with the second dimension corresponding to the interpolated array dimension. In this case the resulting interpolation method can be applied to 2D and 3D fields only, and the first dimension of the field-index set must match the first dimension of the coefficient set for which the coefficient values are varying. The coefficient values are replicated in case there


8-28

is a third array dimension. 8.4.3.7

coccel

Define a DDHOR interpolation (an interpolation for horizontal refinement) with local constant method. subroutine coccel(mthnam,ovlnam,mskdis,mskint,setmsk,ov2msk,itfnam, cfmlft,cfmrgt,cfnbot,cfntop,cfwght,icocad,name) Integer mskdis(*),mskint(*), icocad(*) character*(*) ovlnam,itfnam,mthnam,setmsk,cfwght,ov2msk,name,cfmlft, cfmrght,cfnbot,cfntop cfmlft i cfmrgt i cfnbot i cfntop i cfwght i icocad io itfnam i mskdis i

mskint

i

mthnam name ov2msk ovlnam

i i i i

setmsk wght xycel

i i i

name of coeffset with left m-coordinates of gridcells name of coeffset with right m-coordinates of gridcells name of coeffset with lower n-coordinates of gridcells name of coeffset with top n-coordinates of gridcells name of coeffset with weights COCLIB administration array name of interface to be used for communication of array mask mask-array on setmsk 0 grid points is not a discretization point 1 grid point is a discretization point mask-array on setmsk 0 grid points is not an interpolation point 1 grid point is an interpolation point name of the method to be constructed name of the calling subroutine name of relation table from overlap to setmsk name of the overlap index set through which to make the interpolation name of index set on which interpolated field lives name of coefficient set with interpolation weights (cell-areas) name of coefficient set with upperright and lowerleft coordinates of cells

Defines a DDH interpolation (from discretization points in an overlap set to interpolation points). The method that is defined by this operation is a local constant method. Each of the coefficient sets must be ”read-only”. (see cocico). 8.4.3.8

coccfl

Create a linear-on-weighted-average interpolation method.


8-29

subroutine coccfl(mthnam,ovlnam,mskdis,mskint,setmsk,ov2msk,itfnam,cfmlft, cfmrgt,cfnbot,cfntop,cfwght,icocad,name) Integer mskdis(*),mskint(*), icocad(*) character*(*) ovlnam,itfnam,mthnam,setmsk,cfwght, ov2msk,name,cfmlft, cfmrght,cfnbot,cfntop cfmlft i cfmrgt i cfnbot i cfntop i cfwght i icocad io itfnam i mskdis i

mskint

i

mthnam name ov2msk ovlnam

i i i i

setmsk wght xycel

i i i

name of coeffset with left m-coordinates of gridcells name of coeffset with right m-coordinates of gridcells name of coeffset with lower n-coordinates of gridcells name of coeffset with top n-coordinates of gridcells name of coeffset with weights COCLIB administration array name of interface to be used for communication of array mask mask-array on setmsk 0 grid points is not a discretization point 1 grid point is a discretization point mask-array on setmsk 0 grid points is not an interpolation point 1 grid point is an interpolation point name of the method to be constructed name of the calling subroutine name of relation table from overlap to setmsk name of the overlap index set through which to make the interpolation name of index set on which interpolated field lives name of coefficient set with interpolation weights (cell-areas) name of coefficient set with upperright and lowerleft coordinates of cells

Defines a DDH interpolation (from discretization points in an overlap set to the interpolation points). The method that is defined by this routine is a interpolation method. Each of the coefficient sets must be ”read-only”(see cocico). 8.4.3.9

cocmax

Defines a DDH interpolation (an interpolation for horizontal refinement) with maximum value method.


8-30

subroutine cocmax(mthnam,mthnm1,setnam,icocad,name) Integer icocad(*) character*(*) setnam, mthnam, mthnm1, name icocad io mthnam i mthnm1 i name i setnam i

COCLIB administration array name of the method to be constructed name of the method from which the tables should be merged name of the calling subroutine name of index set on which interpolated field lives

Defines a DDH interpolation (from discretization points in an overlap set to the interpolation points). The method that is defined by this routine is a maximum value method. Each of the coefficient sets must be ”read-only”(see =cocico). 8.4.3.10

cocmpr

Create a 3D interpolation method from a 2D method subroutine cocmpr (intnam,setnam,setprd,name) character*(*) setprd, setnam, intnam, name intnam name setnam setprd index set)

i name of interpolation method that is replicated i name of the calling subroutine. i name of the index set on which interpolation method intnam works (first factor in product index set) i name of the replicated index set (second factor in product

The methods to define horizontal interpolation methods define the methods for horizontal, 2D index sets. When the interpolation is to be applied on a 3D index set (i.e. the product of the 2D index set with a 1D index set), then the method can be ”replicated¨ using cocmpr. In the call to cocmpr. 8.4.3.11

coctyp

Determine for every neighbour what type of coupling there is between the current process and the neighbour process.


8-31

subroutine coctyp(nint,idi1,i1,idi2,i2,idi3,i3,nproc,nm1,m1,icocad,name) Integer nint, idi1, idi2, idi3, nproc, nm1, i1(idi1), i2(idi2), i3(idi3), icocad(*), m1(nm1,nproc) character*(*) name i1

i

1st array to be used for coupling type identification arrays i1... are completed using communication by coctyp i2 i 2nd array to be used for coupling type identification i3 i 3rd array to be used for coupling type identification icocad io COCLIB administration array idi1 i dimension of i1 idi2 i dimension of i2 idi3 i dimension of i3 m1 i Integer information for each process. One column is sent to coccat in each call name i name of the calling subroutine. nint i Number of integers i1..i nint(rest is assumed real) nm1 i Number of integers in m1 for each process nproc i Number of processes In a loop over all the processes, coctyp communicates the arrays i1, i2 and i3 and calls the model-specific user-routine coccat with both the own and the neighbour data. The arrays i1..i3 for both domains should be supplied in the call from the user-program in such a way that they give sufficient information to the user-routine for the determination of the coupling type. To be called by the programmer with a number of parameters describing properties of the own subdomain. This routine exchanges the parameters with neighboring processes and then passes all its data to the routine coccat, which determines the coupling category per neighbor. 8.4.3.12

coccat

Determine for a pair of processes what type of coupling there is between them, for the definition of interpolation methods. This routine must be filled in by the user.


8-32

subroutine coccat(kmax1,indly1,ninov1,inovl1,kmx1,hlay1,kmax2, indly2, ninov2, inovl2, kmx2, hlay2, nhref, ihref, categ, name ) Integer kmax1, kmx1, ninov1, kmax2, kmx2, ninov2, nhref, indly1(kmax1), inovl1(ninov1), indly2(kmax2), inovl2(ninov2), ihref(nhref) character*(*) name character*20 categ categ

hlay1 hlay2 ihref

indly1 indly2 inovl1 inovl2 kmax1 kmax2 kmx1 kmx2 name nhref ninov1 ninov2

o coupling type par = parallel coupling ddv-fixfix = vertical refinement only sigma/fixed layers of own domain are connected to sigma/fixed layers in other domain only ddv-sigfix = vertical refinement only connections between sigma and fixed layers occur ddh-1:1 = horizontal refinement only, but matching grid cells ddh-refine = horizontal refinement only par+ddh = parallel coupling combined with horizontal refinement i own layer information HLAY i neighbour’s layer information HLAY i information regarding horizontal coupling with other domain: ihref(1): ddh-refinement used yes(1)/no(0) ihref(2): subdomain is part of same domain yes(1)/no(0) ihref(3): own process number ihref(4): neighbour’s process number i own layer information INDLAY i neighbour’s layer information INDLAY i process numbers of subdomains in own overlap index sets i process numbers of subdomains in neighbor overlap index sets i length of ndlay1 i length of indlay2 i length of hlay1 (==kmax1) i length of hlay2 (==kmax2) i name of the calling subroutine i number of elements in ihref (==4) i dimension of inovl1 i dimension of inovl2

The arrays i1..i3 are identical to the same arrays in coctyp. The arrays j1..j3 are the equivalent arrays from the other process, which have been obtained by coctyp through communication. The output is a string denoting the coupling type, which the user is free to choose (within the limits of a maximum name length of 20 characters), and which can be used in the formation of interpolation methods that behave differently in different circumstances, see cocmth. Since coccat is a user routine, it is possible to make a header which is more meaningful


8-33

than the example header shown above. Such a header could be subroutine coccat(kmax1,indly1, 0,idum1 ,kmx1,hlay1, kmax2,indly2, 0,idum2 ,kmx2, hlay2, nhref, ihref, categ, name) integer real character*(*)

kmax1, indly1(kmax1), kmx1, kmax2, indly2(kmax2), kmx2, idum1(1), idum2(1), ihref hlay1(kmx1),hlay2(kmx2) categ

Such a header expresses that some variables (*dum*) are not used, and offers more meaningful names for the other variables. Determines the type of coupling using the parameters of the grids that are supplied through coctyp. This routine is in fact a backward interface: the implementation is to be provided by the programmer that uses COCLIB.


8.4.4

Communicatie-operaties

8.4.4.1

cocupd

8-34

Updates fields, i.e. exchanges information at subdomain boundaries with neighbouring domains. subroutine cocupd(numint,numrea, ifld1,setnm1,itfnm1,intpl1, ifld2,setnm2,itfnm2,intpl2, ifld3,setnm3,itfnm3,intpl3, ifld4,setnm4,itfnm4,intpl4, icocad,name) Integer numint, numrea, icocad(*) ifld1(*), ifld2(*), ifld3(*), ifld4(*) character*(*) name, intpl1, intpl2, intpl3, intpl4, itfnm1, itfnm2, itfnm3, itfnm4, setnm1, setnm2, setnm3, setnm4 icocad o ifld1 io

administration array for COCLIB Field variable for which values must be exchanged with neighbors ifld2 io second field variable, see ifld1 ifld3 io third field variable, see ifld1 ifld4 io fourth field variable, see ifld1 intpl1 i name of interpolation method for first field intpl2 i name of interpolation method for second field intpl3 i name of interpolation method for third field intpl4 i name of interpolation method for fourth field itfnm1 i name of interface for first field itfnm2 i name of interface for second field itfnm3 i name of interface for third field itfnm4 i name of interface for fourth field name i name of the calling subroutine numint i number of integer fields (ifld1...ifld[numint]) numrea i number of real fields (field[numint+1].field[numint+numrea]) setnm1 i name of index set for first field setnm2 i name of index set for second field setnm3 i name of index set for third field setnm4 i name of index set for fourth field The routine cocupd must be called at the same point in the code by all processes that may have to exchange data at that point. For each of the numint+numrea fields that have to be exchanged, the field itself, the setname (see subroutine cocidi, cocidr and cocprd) and the interface name (see subroutine cocitf) must be supplied. If interpolation may be necessary, the name of the interpolation method must also be given (see subroutine cocmth). If not, then an empty string can be specified for the name of the interpolation method. Each of the


8-35

specified interpolation methods must be a compound interpolation method. 8.4.4.2

cocigl

Perform a global integer reduction operation to collect all length items in array indata. The type of reduction is either MAX, MIN or SUM. subroutine cocigl(indata,length,type,grpnam,info,name) Integer info, length, indata(lenght) character*(*) type, grpnam, name grpnam i indata io info o length i name i type i

name of the processgroup over which operation takes place input data result of operation length of array indata and array outdata name of the calling subroutine type of reduction COCSUM determine sum over all processors COCMAX determine max over all processors COCMIN determine min over all processors

On input, indata must contain at least length items, and type must be one of the valid types. Every process must have the same length specified. Upon return, if successful, each item in indata contains the global reduction of the corresponding items on all processes and info is 0. Else, info is 1. For instance, suppose there are two worker processes. Worker process 1 calls cocigl with indata=[1,10,3] and worker process 2 calls cocigl with indata [2,5,2], length=3 and type = ’COCMAX’. Then, on output, indata = [2,10,1] in both processes. 8.4.4.3

cocrgl

Perform a global real reduction operation to collect all length items in array rdata. The type of reduction is one of MAX, MIN or SUM.


8-36

subroutine cocrgl(rdata,length,type,grpnam,info,name) Integer info, length real rdata(length) character*(*) type, grpnam, name grpnam i info o length i name i rdata io type i

name of the processgroup over which operation takes place result of operation length of array indata and array outdata name of the calling subroutine input data type of reduction COCSUM determine sum over all processors COCMAX determine max over all processors COCMIN determine min over all processors

See cocigl for a description of the function of this routine. 8.4.4.4

cocrgs

Perform a global reduction operation on real vector-valued items to collect all length items in array rdata. The type of reduction is currently restricted to MAX1. subroutine cocrgs(rdata,ndim,nentry,type,grpnam,info,name) Integer info, ndim, nentry real rdata(ndim,nentry) character*(*) type, grpnam, name grpnam i info o ndim i nentry i name i rdata io type i

name of the processgroup over which operation takes place result of operation number of data items (real values) per entry(¨ ındex", tuple) number of entries / indices / tuples in data set name of the calling subroutine input data type of reduction COCMAX1 select tuple with largest value in first element over all processes

This routine is conceptually similar to routines cocigl and cocrgl in that all processors start with their own ‘length’ data items and that they are returned a combined ‘global’ set of ‘length’ data items. The combination can in principle be done using any associative operation such as sum, max, etc, such that the order in which the values of different processors are combined does not matter. This routine differs from the other global reduction operations in that the input values that are to be combined are (small) ‘ndim’-vectors. This opens the way to a tremendous amount of possible associative operations, of which currently only the


8-37

selection on basis of the first element is implemented. This is used in WAQUA/TRIWAQ for communicating the location of the maximum residual together with the maximum residual itself. See also cocigl for a further explanation of the function of this routine. 8.4.4.5

cocnws

Implementation of newspaper-protocol for exchange of variable amounts of data among all computing processes. subroutine cocnws(indata,lendat,ipindx,lenpin,grpnam,type,info,name) Integer info, lendat, lenpin indata(lendat), ipindx(lenpin) character*(*) type, grpnam, name grpnam i indata io info o ipindx io lendat lenpin name type

i i i i

name of the processgroup over which operation takes place input data result of operation index to first element in rdata for each process; last element points to first unused location in rdata length of array rdata length of array ipindx name of the calling subroutine data type of indata (’int’ or ’real’)

This communication operation can be used to obtain information about all the other processes in a group, where the amount of information contributed by each process may differ. Each process supplies an array rdata that is sufficiently large to contain all data and an array ipindx in which a process initially marks the start and end of its own data in rdata by the first two elements in ipindx. Upon return from this operation, rdata contains all data that has been supplied by the processes in the group and ipindx contains for each process the location of its data in rdata.


8.4.5

Routines voor het defini¨ eren van relaties

8.4.5.1

cocrdm

8-38

Create a table linking a sub-index set to an index set using a marker array subroutine cocrdm(relnam,setmrk,marker,neig,ixrel,icocad,name) Integer neig, ixrel, marker(*), icocad(*) character*(*) relnam, setmrk, name icocad ixrel marker

io COCLIB administration array o index of created table i marker of points in new table if marker(i)==neig the element is included in the new table name i name of the calling process neig i value of elements in marker that must added in new table relnam i name of the new table setmrk i index set of the marker array This routine is used to define a new relation that relates an index set to a subset of the index set. The subset is specified by a mask array and the by the value that marks elements of the subset in the mask array. If the mask array contains, for example, values 3, 5 an 10, and if neig has value 5, then the subset consists of all elements of setmrk for which the mask array has value 5. 8.4.5.2

cocr2r

Construct a relation table by combining two using an operator. subroutine cocr2r(relnm1,relnm2,relnm3,opstr,icocad,name) Integer icocad(*) character*(*) relnm1, relnm2, relnm3 icocad io name i opstr i relnm1 i relnm2 i relnm3 i

administration array name of the calling process The operator to be carried out name of first relation table name of second relation table name of new relation tabel construced by combining relnm1 and relnm2

This routine defines a new relation by combining two existing relations. The currently supported ways in which relations can be combined are: r3(i) = r2(r1(i)) r3 = inverse(r1) r3(i) = r1(inv(r2(i)) r3(i) = r1(i) for i in img(r2) r3(i,j) = (r1(i),r2(j)) r3(i) = i, r3: s1 -¿ s2 r3(i) = inv(r1)(r2(i)) The combination can only be made if the relations that are to be combined have


8-39

corresponding index sets. For example, in the first of the above mentioned combinations, the target set of r1 must be the source set of r2. 8.4.5.3

cocrss

Construct a relation table by matching two index sets subroutine cocrss (setnm1,setnm2,relnam,icnscr,ncnscr, icocad, name ) Integer ncnscr icnscr(ncnscr), icocad(*) character*(*) relnam, setnm1, setnm2, name icocad io icnscr i

administration array constant coordinates to be added after the coordinates of one of the index sets, if the number of dimensions differs ncnscr i number of constant cordinates (see icnscr) name i name of the calling process relnam io name of the new table (output if table already exists) setnm1 i name of the first index set to be matched (to setnm2) setnm2 i name of the second index set to be matched (to setnm1) This routine defines a new relation that relates two index sets. The relation is determined by the coordinates of the elements in the index sets: elements that have the same coordinates belong together (are related). The dimensions of the index sets do not have to match exactly: one index set may have more dimensions than the other. In that case, coordinates from the index set with the lesser number of dimensions are extended with the specified constant coordinates.


8.4.6

Printroutines

8.4.6.1

cocstt

8-40

Prints an overview of the interface with name itfnam. subroutine cocstt(itfnam,setnam,intnam,icocad,name) Integer icocad(*) character*(*) itfnam,setnam,intnam,name icocad i administration array for interfaces itfnam i name of interface to be printed intnam i name of the interpolation method in case setnam is an overlap index set name i name of the the calling subroutine setnam i name of index set on which interface is defined The routine cocstt supplies a detailed overview of an interface, giving lists of points in the internal and external interface. This routine is typically used in case of problems with communication, e.g. cocupd does not update sufficient values or one process sends more data than the other expects. 8.4.6.2

cocrpr

Prints an overview of a relations table subroutine cocrpr(irel0,icocad,name) Integer irel0, icocad(*) character*(*) itfnam,setnam,intnam,name icocad i administration array irel0 i table handle for the table to be printed name i name of the calling subroutine The routine cocrpr prints a detailed overview of a relation table. 8.4.6.3

cocprm

Print the contents of a composite interpolation method


8-41

cocprm(mthnam, setnam, icocad, name) Integer icocad(*) character*(*) setnam, mthnam, name icocad io mthnam i name i setnam i

administration array name of the interpolation method that must be printed name of the calling subroutine name of the index set on which interpolation method works (first factor in product index set)

The routine cocrpr prints a detailed overview of a composite interpolation method. 8.4.6.4

cocstk

Prints an overview of the current use of array icocad subroutine cocstk(name) character*(*) name name i

name of the calling subroutine

This routine prints an overview of the current use of array ICOCAD, giving an overview of the permanent and temporary arrays in it. This is information is difficult to understand and therefore, this routine is mostly used by programmers familiar with the internal structure of COCLIB.


8.4.7

Diversen

8.4.7.1

cocini

8-42

Initializes the communication library and receives stdinp from master. subroutine cocini(nargc,argv,ihavpr,ispar,mypart,mydom, myprc, nproc, ndom,runids, nparts,rmatch,name) Integer ihavpr, nargc, ispar, mypart, ndom, mydom, myprc, nproc, nparts(*) real rmatch character*(*) name, argv(*), runids(*) argv ihavpr

o i

list of words on standard input flag to indicate whether the calling process has/ has not a parent in parallel runs (1/0). Esp. used to distinguish the worker processes (1) from the executive (0) ispar o flag to denote run as parallel (1) or not (0) mydom o the number of the global domain to which this process belongs mypart o part number for which this process is responsible myprc o the process sequence number of this process name i name of the calling subroutine nargc io number of words on standard input ndom io number of global domain in a simulation i.c. parallel and/or DDVERT: ndom=1 on input: max. number; on output: actual number nparts o number of parts for each global domain nproc o number of processes in coupled run rmatch o tolerance for matching physical coordinates runids o the run id’s of the global domains Determines ispar (yes/no parallel run) and myprc (the process number in the set of all processes, in range [1,nproc]), mydom, (number of the domain on which the process works, in range [1,ndom]) and mypart (the number of the parallel part of mydom, in range [1,nparts]). Also obtains list of words on stdin. On input nargc is the length of argv, on output, it is the number of items filled in argv. ispar denotes whether this is a parallel run (=1) or not (=0). 8.4.7.2

cocend

Terminates the COCLIB functionality. After this call, any use of COCLIB routines results in undefined behavior. subroutine cocend This routine does not return until all processes in the parallel run have called this routine or


8-43

have terminated otherwise. On some SMP systems, the entire parallel run will be terminated just after this call, so the programmer should call this routine as the last call in his program. 8.4.7.3

cocdrg

Makes a process belong to a particular group of processes subroutine cocdgr(grpnam,iinstn,supgrp,name) Integer iinstn character*(*) grpnam,supgrp,name grpnam i name of the group to be defined iinstn i number of the instantiation of group grpnam in which the calling process takes part name i name of the calling subroutine supgrp i name of the supergroup of which grpnam is to be a subgroup This operation is used to make a process belong to a particular group of processes. Identification of a group is done through a name ( grpnam) and an instance number (iinst). A process can only take part in one instance of a group. Therefore, global communication operations only the name of the group. The defined group is a subgroup of supgrp: only processes that take part in supgrp become part of group grpnam. The group supgrp must be defined before it can be used as such. The only predefined group is the group äll”, which includes all processes that take part in the coupled run. The group äll”has only a single instance. All processes that take part in a particular instance of supgrp must call this operation simultaneously; processes that do not want to take part in the new group grpnam must supply name none for grpnam or a value equal or less than zero for the instance number. 8.4.7.4

cocmem

Estimates the length of the communication administration array that is needed in COCLIB for WAQUA/TRIWAQ computations.


8-44

subroutine cocmem(imodel,iddtyp,iusrtr,mmax,nmax,mnmaxk,kmax,length, name) Integer iusrtr,mmax,nmax,kmax,length,imodel, iddtyp,mnmaxk character*(*) name iddtyp

i

type of domain decomposition 1 :parallel 2 :only ddv 3: only ddhor 4: ddv+ddh imodel i type of model 1=WAQUA 3=TRIWAQ iusrtr i use transport yes(1)/no(0) kmax i trailing dimension of WAQUA/TRIWAQ main index set, used when required length must be estimated length io length used/needed for COCLIB administration array. This value is estimated for WAQUA/TRIWAQ using the values of mmax, nmax and kmax when mmax>0 on input and is then an output-argument, and must be supplied by the calling routine otherwise mmax i mmax>0: first dimension of WAQUA/TRIWAQ main index set mmax<=0: used to signal that the length of the COCLIB administration array is supplied by the calling routine mnmaxk i number of computation points in grid name i name of the calling subroutine. nmax i second dimension of WAQUA/TRIWAQ main index set Important note: cocmem assumes that icocad is actually allocated with the estimated / supplied value. If the size should be increased (happens very rarely) then call cocmem with mmax¡=0 and set the appropriate value in length in input. 8.4.7.5

cocsrt

Sorts a coordinate array subroutine cocsrt(length,ndims ,icoor,iperm1,iperm2,name ) Integer length, ndims, icoor(ndims,length), iperm1(length), iperm2(length) character*(*) name icoor iperm1 iperm2 length name ndims

i o o i i i

X- and Y-coordinates of each point in index set permutation of indices sorted on coordinates work array for sorting number of points in the index set name of the the calling subroutine Number of coordinates per index (dimension)

This routine sorts a coordinate array, which can be particularly useful when constructing an


8-45

overlap index set. 8.4.7.6

cocarg

Gets the iarg-th argument from the list argv, which contains nargc arguments. subroutine cocarg(nargc,argv,iarg,type,text,value,name) Integer nargc, iarg double precision value character*(*) name, argv(*), text character*4 type argv iarg name nargc text type value

i i i i o o o

list of arguments number of argument to be returned name of the calling subroutine length of significant part of argv text of argument in case type is char or key type of argument (key,char,int or real) value of argument in case type is int or real

Type is the type of argument, text/value the value. If type is ’char’ or ’key’, then text is filled, else value is filled. If iargc larger than nargc, then type = eof. Analogous to SIRDEL in the SIMONA library. See the SIMONA programmer’s guide for details.


8.5 8.5.1

8-46

Interne werking COCLIB: indeling in subroutines Inleiding

Zoals beschreven in paragraaf 8.2.1 is er in de DDHOR +DDVERT versie van COCLIB bij elke groep van datastructuren een aantal facilitaire routines gemaakt, waarmee de implementatie van de datastructuren kan worden afgeschermd. Deze nieuwe opzet leidt tot een vierdeling in de COCLIB routines: 1. gebruikers routines, die van buiten COCLIB aangeroepen kunnen worden 2. generieke COCLIB routines, die functionaliteit implementeren die op meerdere plaatsen in COCLIB nodig is en die niet aan een bepaalde datastructuur gerelateerd zijn 3. specifieke laag-nivo routines, die functionaliteit implementeren die slechts op één bepaalde plek in COCLIB nodig is 4. facilitaire routines per datatype, die de toegang tot de datastructuren regelen De tweede en de laatste categorie kunnen samen gezien worden als een generieke basislaag waarop de gebruikersroutines gebouwd zijn. Hieronder wordt allereerst de generieke COCLIB routines besproken (Paragraaf 8.5.2). Vervolgens worden in Paragraaf 8.5.3 t/m 8.5.8 de routines (zowel gebruikers- als facilitaire routines) besproken die bij de diverse datatypes horen. Aan het eind van dit hoofdstuk wordt een overzicht gegeven van de specifieke laag-nivo routines (Paragraaf 8.5.9).

8.5.2

Generieke laag-nivo routines

8.5.2.1

Overzicht

coc112 coccr1 coccre cocdes cocid0 cocid1 cocnsp coctrc 8.5.2.2

verkrijg een real waarde uit ibuffr creëer een nieuw COCLIB object creëer een nieuw array in icocad verwijder een nieuw array uit icocad zoek een naam op in een lijst van namen haal handle van een COCLIB object op genereer melding dat functionaliteit nog niet beschikbaar is timed receive: probeer gedurende zekere tijd een boodschap te ontvangen

coccr1, cocid1 en cocid0

De gebruikersroutines verwijzen naar specifieke entiteiten door middel van een identificerende naam; intern in COCLIB wordt echter gebruik gemaakt van handles. Een handle is een getal aan de hand waarvan de betreffende entiteit in de datastructuren kan worden teruggevonden of, concreter: de index van de entiteit in zijn datastructuur. De feitelijke betekenis van een handle is alleen van belang in de faciliteitenroutines, waarmee gegevens opgehaald worden


8-47

uit of weggeschreven worden naar de datastructuren. Buiten de faciliteitenroutines is het voldoende om van een handle te weten dat het een bepaalde entiteit identificeert. De routine coccr1 alloceert een nieuwe handle met bijbehorende naam voor een bepaald datatype (bijvoorbeeld: een nieuwe indexset). De handle die bij een naam behoort kan worden gevonden met cocid1. De routine cocid0 is een oudere variant van cocid0 en is eigenlijk obsolete. Omdat hij toch nog op een paar plaatsen voorkomt, is hij nog in bovenstaand overzicht opgenomen. 8.5.2.3

coctrc

De routine coctrc wordt gebruikt door communicatie-operaties. Hij probeert gedurende enige tijd om een boodschap van een bepaald ander proces op te vangen. Lukt dat niet, dan wordt contact gezocht met het masterproces COEXEC om na te gaan of de boodschap nog verwacht mag worden. Als dat het geval is, dan wordt een tijdlang opnieuw geprobeerd om de boodschap te ontvangen. Dit proces herhaalt zich totdat COEXEC uiteindelijk besluit dat de run moet worden afgebroken. Zodra dat besluit gevallen is, dan zal coctrc bij het eerstvolgende contact met COEXEC het bericht ontvangen dat de run moet worden afgebroken. 8.5.2.4

cocnsp

De opzet van COCLIB is nogal generiek: het ontwerp staat heel veel gebruiksmogelijkheden toe. Niet alle gebruiksmogelijkheden zijn op dit moment nodig en daarom zijn sommige stukken functionaliteit nog niet ge¨ımplementeerd. Daar waar dat het geval is, wordt de routine cocnsp (COCLIB-no-support) aangeroepen, die de gebruiker de melding geeft dat de gevraagde functionaliteit nog niet bestaat. Bij voorzien normaal gebruik van COCLIB zal deze melding niet optreden (zal cocnsp niet worden aangeroepen). Pas als COCLIB wordt gebruikt voor situaties die niet voorzien zijn, kan cocnsp aangeroepen worden. Als dat gebeurt, dan moet op de plek van de aanroep een extra stuk functionaliteit geprogrammeerd worden, meestal analoog aan al bestaande functionaliteit. 8.5.2.5

coccre en cocdes

COCLIB maakt gebruik van een eigen intern stuk geheugen (het array icocad). Hierin maakt COCLIB (met coccre) dynamisch arrays aan. Deze arrays kunnen tijdelijk zijn (werk-arrays) of permanent. Een permanent array kan niet worden verwijderd, maar wel overschreven. Een werk-array kan wel worden verwijderd (met cocdes). Daarbij is het van belang dat het verwijderen van werk-arrays volgens het LIFO-principe moet gebeuren: het laatst-aangemaakte array moet als eerste weer worden verwijderd.


8.5.3

Indexsets

8.5.3.1

Overzicht

8-48

Gebruikersroutines cocidr definiëer een regelmatige indexset cocidi definiëer een onregelmatige indexset cocidx definiëer een indexset zonder informatie over eigenaarschap cocprd definiëer het produkt van twee indexsets Facilitaire routines cocils zoek een indexset op en haal eigenschappen op cocidm geeft cardinaliteit en/of dimensies van een indexset coccrd geeft cardinaliteit van een indexset cociad converteer een coördinaat naar een enkelvoudig adres coclup zoek een coördinaat op in een onregelmatige index set cocifp zoek handle van een indexset welke een produkt is van gegeven index sets 8.5.3.2

cocils, cocidm, coccrd en cocifp

Deze routines dienen voor het ophalen van informatie over een indexset. De routine cocils haalt alle informatie over een indexset op die nodig kan zijn: de afmetingen in elke dimensie, de cardinaliteit en pointers naar het descriptor-array en het eigenaarschap-array. De enige informatie die hier niet wordt teruggeleverd zijn de factoren waaruit een indexset is opgebouwd in het geval van een produkt indexset. Voor die informatie moet gebruik gemaakt worden van cocidm, die de minimale en maximale coördinaten in elke dimensie van een indexset ophaalt, alsmede de factoren waaruit de indexset is opgebouwd (één als de indexset niet een produkt is, anders twee of meer). De functie coccrd haalt de cardinaliteit (d.i. het aantal elementen) van een een indexset op. En tot slot is er cocifp die de handle van een indexset terug geeft welke het produkt is van twee gegeven index sets. 8.5.3.3

cociad en coclup

Deze twee functies dienen voor het bepalen van de plaats van een coördinatenpaar in de indexset. cociad zoekt een enkelvoudig adres bij een coördinatenpaar in een regelmatige indexset. coclup zoekt een coördinatenpaar op in het descriptor-array van een onregelmatige indexset. Een coördinatenpaar kan in principe meerdere keren voorkomen in een onregelmatige indexset, waarbij de betreffende elementen dan wel naast elkaar in het descriptor-array voorkomen. De routine coclup geeft de eerste en laatste locatie waarop het gegeven coördinatenpaar voorkomt in het descriptor-array.


8.5.4

Interfaces

8.5.4.1

Overzicht

8-49

Gebruikersroutines cocitf definiëer een interface met behulp van stencil cocifd definiëer een interface direct coctpr repliceer een interface voor een produkt-indexset Facilitaire routines coctls zoek een interface op en haal eigenschappen op coctng haal buurman-informatie op behorende bij een interface cocrca creëer interface op overlap 8.5.4.2

coctls

Deze routine haalt algemene informatie betreffende een indexset op: de indexset waar hij bij hoort, de interface waarvan het een gerepliceerde versie is (indien van toepassing) en het aantal replicaties, de relatietabel waarmee gegevens van de gewone indexset van/naar de overlap indexset kunnen worden gezet en het aantal directe buren (parallelle en DDVERT buren) en het aantal buren via de overlap set (DDHOR buren). Daarnaast geeft de routine terug voor hoeveel interpolatiemethoden de interface tabellen voor de overlap set zijn aangemaakt. 8.5.4.3

coctng

De routine coctng haalt informatie op over de interface met een bepaalde buurman, met name de tabellen die de interne en externe interface met de buurman weergeven. Door een switch in de argumentenlijst kan met deze tabellen opvragen voor communicatie over de bij de interface behorende indexset, of voor communicatie over de bijbehorende overlap indexset (waarbij dan ook de interpolatiemethode gegeven moet worden). 8.5.4.4

cocrca

Met behulp van een reeds bestaande interface met de daarbij behorende fase 4 interpolatie methode kan de routine cocrca de interface bepalen voor de overlap indexset.


8.5.5

Relatietabellen

8.5.5.1

Overzicht

8-50

Gebruikersroutines cocrdm creëer relatie tussen een indexset en een subset ervan cocr2r combineer twee relatietabellen tot een nieuwe cocrss creëer relatie door twee indexsets te matchen Facilitaire routines cocitd definieer een nieuwe relatietabel cocrir combineer twee relatietabellen tot een nieuwe cocrm2 creëer relatietabel tussen een indexset en een subset ervan cocrls zoek een relatietabel op en haal eigenschappen op cocrts verifiëer of een relatietabel een bepaalde eigenschap heeft 8.5.5.2

cocitd, cocrir en cocrm2

Routine cocitd wordt gebruikt om relatietabellen te vullen, cocrir en cocrm2 worden binnen COCLIB gebruikt om nieuwe relatietabellen te maken. Merk op dat het alloceren van een relatietabel gebeurt met de generieke routine coccr1, die de nieuwe tabel evenwel niet vult. cocitd is de enige routine die daadwerkelijk elementen in array ireltb vult en wordt ook gebruikt in de implementatie van de overige routines waarmee relatietabellen kunnen worden aangemaakt. Facilitaire routine cocrir is vrijwel identiek aan gebruikersroutine cocr2r, met als enige verschil dat cocr2r relatietabellen specificeert met behulp van namen en cocrir dat doet met handles. cocr2r is weinig meer dan een aanroep van cocrir. Op dezelfde manier is cocrm2 vrijwel identiek aan cocrdm, en bestaat de laatste uit weinig meer dan een aanroep van cocrm2. 8.5.5.3

cocrls

De routine cocrls haalt de feitelijke relatietabel op (d.i. het array waarin de tabel ligt opgeslagen) in een gespecificeerd formaat. Als het formaat intern niet beschikbaar is, zal geprobeerd worden om de tabel aan te maken in het gevraagde formaat op basis van een formaat dat wel beschikbaar is. 8.5.5.4

cocrts

Deze routine verifiëert of een relatietabel bepaalde eigenschappen heeft die ervan verwacht worden. Een veel voorkomend gebruik is bijvoorbeeld bij het verifiëren of een relatietabel wordt toegepast voor de conversie van/naar een indexset waarvoor hij ook bedoeld is. Als de test negatief uitvalt (de verwachte eigenschap geldt niet) dan wordt het aanroepende proces afgebroken, waarbij een foutboodschap wordt gegeven.


8.5.6

Interpolatiemethoden

8.5.6.1

Overzicht

8-51

Gebruikersroutines cocmt0 definiëer een nieuwe samengestelde methode cocmt1 zet de reshape methode (naar overlap indexset) voor een samengestelde methode cocmt3 voeg een enkelvoudige fase3 interpolatie methode toe aan een samengestelde methode cocmt4 voeg een enkelvoudige fase 4 interpolatie methode toe aan een samengestelde methode cocin1 definiëer een DDV interpolatiemethode cocint definiëer een type-II interpolatiemethode coccel definiëer een type-III lokaal constante interpolatie coccfl definiëer een type-III lin*weigh interpolatie cocbil definiëer een type-III bilineaire interpolatie cocsum definiëer een type-III sommatie interpolatie cocmax definiëer een type-III maximumwaarde interpolatie cocmpr repliceer een type-III interpolatie voor produkt-indexsets coctyp bepaal koppelingscategorieën voor buurprocessen coccat bepaal koppelingscategorie behorende bij gegeven parameters Facilitaire routines cocimt definieer een nieuwe basis-interpolatiemethode cocmpt sla nieuwe informatie op over een basis-interpolatiemethode cocmls haal eigenschappen van een basis-interpolatiemethode op cochmt haal ddhor-interpolatie matrix en veldwaarden-selectietabel op cocmat haal ddvert-interpolatie matrix op cocma1 haal ddvert-interpolatie matrix op cocmtr haal eigenschappen op van een matrix cocols haal informatie op over een samengestelde interpolatiemethode 8.5.6.2

cocimt en cocmpt

Ruimte voor een nieuwe basisinterpolatiemethode wordt gealloceerd met de generieke routine coccr1 (zie eerder gegeven beschrijving). Deze ruimte wordt gevuld met routine cocimt. Na het aanroepen van deze routine is de interpolatiemethode voldoende gedefinieerd om gebruikt te worden. Met de routine cocmpt kan extra of nieuwe informatie bij de interpolatiemethode worden opgeslagen. Dit wordt vooral gebruikt als er een nieuwe (versie van) een interpolatiematrix is aangemaakt, bijvoorbeeld voor een buurproces waarvoor nog geen matrix bestond, of als er een coëfficiëntenset ververst is.

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) 8.5.6.3

8-52

cocmls, cochmt, cocmat, cocma1 en cocmtr

De routine cocmls is bedoeld om gegevens rechtstreeks uit de datastructuren voor basisinterpolatiemethodes te halen, zonder dat er aanpassingen aan de datastructuren plaatsvinden. Een van de gegevens die opgehaald kunnen worden is bijvoorbeeld een lijst van alle interpolatiematrices of een specifieke interpolatiematrix. Als deze matrix er niet is, dan wordt eenvoudigweg teruggegeven dat hij er niet is. De routines cochmt, cocmat en cocma1 halen ook een interpolatiematrix op, maar verzorgen tevens het aanmaken ervan in het geval dat de matrix nog niet bestaat of niet meer valide is (bijvoorbeeld doordat één van de gebruikte coëfficiëntensets ververst is). De routine cochmt maakt een DDHOR-interpolatie aan en de routines cocmat en cocma1 een DDVERTinterpolatie matrix. cocmat maakt matrices voor de methodes die met cocint aangemaakt zijn. cocma1 doet het werk voor de methodes die met cocin1 aangemaakt zijn. Het verschil zit hem in de gebruikte coëffiëntensets voor de berekeing van de matrices. Eigenschappen van de interpolatiematrix zelf kunnen opgehaald worden met cocmtr. De eigenschappen die opgehaald worden zijn bijvoorbeeld een pointer naar de array met interpolatiegewichten en handles van te gebruiken relatietabellen. 8.5.6.4

cocols

De subroutine cocols wordt gebruikt om op te zoeken welke basisinterpolatiemethode uit te voeren is in een bepaalde fase van de update-operatie voor een bepaalde samengestelde methode. Voor fase 3 (=DDVERT-interpolatie) is het van belang wat de koppelingscategorie is en moet het nummer van het betreffende buurproces meegegeven worden (aan de hand waarvan het koppelingstype kan worden opgezocht. Voor fase 1 en fase 4 kan er slechts één interpolatiemethode voorkomen, zodat het daar niet van belang is welk buurproces het betreft.


8.5.7

Co¨ effi¨ entensets

8.5.7.1

Overzicht

8-53

Gebruikersroutines cocico definiëer een coëfficiëntenset coccoe (her)vul een coëfficiëntenset coccoo bereken een coëfficiëntenset uit meerdere andere Facilitaire routines coccls zoek een coëfficiëntset op en haal eigenschappen op cocc2f converteer interne opslag van coëffciënten naar veldrepresentatie coccpn Zet ”informed” vlag in coeffciëntenset 8.5.7.2

coccls

De routine coccls is de “look-up” routine voor coëfficiëntensets. Aan de hand van de handle van een coëfficiëntenset wordt informatie opgehaald betreffende bijvoorbeeld de indexset waarop de set leeft en de interface waarop hij gedefinieerd is. 8.5.7.3

cocc2f

Bij de bespreking van de opslagstructuren voor coëffciëntensets is besproken dat coëfficiënten in principe opgeslagen worden op basis van de interface waarvoor ze gedefinieerd zijn. Dat wil zeggen dat de coëfficiënten opgeslagen liggen in buffer-arrays die corresponderen met de interne en externe delen van de betreffende interface. In een DDHOR interpolatie zijn de coëfficiëntensets meestal nodig in de vorm van velden. De routine cocc2f voert de conversie uit van de opslag in buffer-arrays naar de opslag als een veld. 8.5.7.4

coccpn

Met behulp van coccpn kan de ”informed” vlag in een coëffciëntenset gezet worden. Hiermee wordt aangegeven of de huidige inhoud van de coëffciëntenset al met gegeven buur is uitgewisseld.


8.5.8

8-54

Reshape methoden

De representatie van de datastructuren is in COCLIB alleen ”bekent”bij een selecte groep van routines. In de vorige secties zijn deze groepen beschreven. De reshape methodes nemen hierbinnen een aparte positie in. De reshape routines zetten (een selectie van) data over van de ene indexset naar een andere al dan niet met behulp van interpolatie. Deze routines hebben (voor de performance) kennis van zowel de representatie van relatie tabellen als van de opslagstructuur van de interpolatie matrices en vormen daarom een aparte groep. (Er zijn echter ook reshape methodes welke geen interpolatie ondersteunen en dus bij de relatietabellen gerekend zouden kunnen worden) 8.5.8.1

Overzicht

Facilitaire cocrsh coccpu coccpv coccpy cocsh1 cocsh2 cocsh3 cocsh4 cocsh5 8.5.8.2

routines algemene reshape reshape zonder interpolatie reshape zonder interpolatie reshape zonder interpolatie reshape met interpolatie reshape met interpolatie uitgebreide versie van cpcrsh voor 4d velden reshape met interpolatie reshape met interpolatie

cocrsh en cocsh3

De reshape operatie cocrsh implementeerd een groot aantal verschillende reshape operaties coccpu,coccpv ,coccpy , cocsh1 en cocsh2. De routine cocsh3 is een aangepaste versie van cocrsh voor 4d velden waarbij de eerste en laatste dimensie gerepliceerd is. Deze methode implementeerd de reshape operaties cocsh4 en cocsh5. 8.5.8.3

coccpu, coccpv , coccpy , cocsh1, cocsh2, cocsh4 en cocsh5

De routines cocrsh en cocsh3 zijn erg krachtig. Als bepaalde eigenschappen van de invoer echter bekend kan er voor performance redenen gekozen worden om een van de specifieke reshapes direct aan te roepen. De exacte verschillen tussen de routines zijn te specifiek om hier te bespreken. In het ”Description” gedeelte van de routines staat uitgebreid beschreven in welk geval zij gebruikt kunnen worden.

8.5.9

Specifieke laag-nivo routines

De volgende COCLIB routines hebben geen zelfstandige waarde, maar zijn ontstaan als onderdeel van een andere routine. Voor de verdere ontwikkeling van COCLIB kunnen ze hooguit


8-55

dienen als voorbeeld voor het implementeren van bepaalde functionaliteit, maar ze zullen in ieder geval niet vanuit andere subroutines aangeroepen worden. Er wordt hier volstaan met een opsomming van deze routines, voorzien van de plek waar ze aangeroepen worden en een korte beschrijving van de betekenis. Een nadere uitwerking hier is niet zinvol. coc2ws cocrp1 cocrp2 cocrp3 cocrs2 coccol cocamg coccaw cocgi1 cocima

cocpi1 cocpma cocsp1 cocwg1 cocwgl coczco cocpcf cocucf cocup0 coctp1 coccr1

cocid2 cocst1

cocrls cocrpr cocrpr cocrpr cocrss coccoo cocbil cocwgh cocwg1 cocma1 cocbil coccel coccfl cocin1 cocint cocmax cocsum cocma1 cocima cocma1 cocma1 cochmt cocsp1 cocwg1 cocup2 cocup3 cocupd cocrca coctpr cocifp cocrca coctpr cocid2 cocstt

geef pointers en info over een ”2 way scalar” relatie tabel print een ”subset-selecting” relatie tabel print een ”2 way scalar” relatie tabel print een ”multi-values” relatie tabel maak een relatie tabel m.b.v. het vergelijken van 2 indexsets doet evaluatie van de coëfficiëntensets t.b.v. cocicoo berekend de ”agrument selection” tabel voor de discretisatie punten bepaal waardes/gewichten in de interpolatie matrix retrieve DDVERT-interpolation matrix creëer een nieuwe interpolatie matrix

(re)store DDVERT-interpolation matrix print inhoud van een interpolatie matrix bouw matrix-sparsity tabel voor DDVERT-interpolatie bepaal matrixgewichten voor DDVERT-interpolatie bepaal matrixgewichten voor de ”lin(weigh)” methode bereken de ”werk arrays” met z-coodinaten past uitvoer aan voor waterstand ”0” verzend coëfficiëntensets naar buren ontvang coëfficiëntensets van buren verzamel informatie over update en initialiseer de update maak interface beschikbaar op gegeveb indexset door middel van replicatie bepaal ”recieve areas” van ”overwrite area” en fase 4 interpolatie methode informatie controleer coördinaten van onregelmatige indexset en sla ze op print overzicht van interne en externe interface

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) cocors coctab coctbo cocmrk cocup1 cocup2 cocup3 cocup4 cocbln cocblc cocfcs cocamg cocscl cocsh1 cocsh2 cocmid cocpim cocgim coccis cocciw cocscl coccvr cocwgh coci0s coci0w cocspr cocibl coccr2 cocco1 cocrca

cocrc1 cocitf cocitf coctab coctbo cocupd cocupd cocupd cocupd cocup2 cocup3 cocupd

8-56

bepaal send/receive areas voor een interpolatie methode bepaal send/receive areas voor parallelle interface bepaal replacement areas voor DDHOR interface markeer interface punten doe fase 1 van update (d.i. reshape naar overlap) doe fase 2 van update (d.i. verstuur boodschappen) doe fase 3 van update (d.i. ontvang en DDVERT-interpolatie) doe fase 4 van update (d.i. DDHOR-interpolatie en reshape) bepaal lijst van buren waarmee gecommuniceerd moet worden bepaal lijst van coëfficiëntensets die met elk van de buren moeten worden uitgewisseld bouw interpolatie-relatietabellen in cocclf bouw interpolatie-relatietabellen in cocbil bouw interpolatie-relatietabellen in coccel doe reshape voor een integer veld doe reshape voor een real veld bepaal of er parallel gerekend wordt (re)store DDVERT-interpolation matrix retrieve DDVERT-interpolation matrix bouw matrix-sparsity tabel voor cns lay intg bepaal matrixgewichten voor cns lay intg bouw relatie tabel van interpolatiecellen naar discretisatiecellen schaal coëfficiëntenset voor overeenstemming met buur-set bepaal matrixgewichten voor DDVERT-interpolatie bouw matrix-sparsity tabel voor lin smpl kmax0 bepaal matrixgewichten voor lin smpl kmax0 bouw matrix-sparsity tabel voor DDVERT-interpolatie bepaal matrix gewichten voor bilin DDHOR-interpolatie haal handle van een COCLIB object op

cocclf cocbil coccel cocrsh cocrsh cocini cocmat cocmat cocspr cocwgh coccel cocmat cocmat cocspr cocspr cocwgh cocwgh cocmat cochmt coccr1 coccoo cocbln bepaal send/receive areas voor een interpolatie methode


9-1

Hoofdstuk 9 Detail ontwerp aanpassingen COEXEC 9.1

Inleiding

COEXEC is het zogenaamde “Executive” of “Master” proces dat de gekoppelde berekening opstart en coördineert. De coördinatie bestaat uit het versturen van een opstartboodschap aan alle rekenprocessen over de gekoppelde run, het verzamelen van de message-uitvoer van de rekenprocessen, en het verzorgen van enige foutafhandeling: signaleren dat rekenprocessen onverwachts stoppen (foutmelding, core-dump) of dat alle processen op elkaar staan te wachten ten gevolge van een fout in het communicatieschema (dead-lock). Een extra taak die aan COEXEC is toegevoegd ten behoeve van domein decompositie met horizontale verfijning het controleren van de gebruikersinvoer, met name ten aanzien van de consistentie van de verschillende simulatie-invoerfiles. Ten behoeve van deze taak kent de configuratiefile ook de optie “check-only”, waarmee COEXEC te gebruiken is om alleen de consistentie van de invoer te controleren. Dit hoofdstuk bespreekt • de structuur van COEXEC (paragraaf 9.2), • het format van de invoer en de wijze waarop die ingelezen wordt (paragraaf 9.3), • de controles die COEXEC uitvoert (paragraaf 9.4) en • de informatie die COEXEC naar WAQPRO stuurt (paragraaf 9.5).

9.2

De structuur van COEXEC

Door het toevoegen van controles voor de DDHOR functionaliteit en van de optie “check-only” wordt de basisstructuur van COEXEC enigszins aangepast:


9-2

lees de invoer en vul interne data structuren (COEINP) controleer gespecificeerde koppeling (COECKC) als run ook daadwerkelijk moet worden uitgevoerd start de processen en geef de configuratie door (COESPW) verzorg message-uitvoer en foutafhandeling totdat alle rekenprocessen geëindigd zijn (COELIS) sluit af

9.3

Het lezen van de invoer

Het programma COEXEC krijgt informatie binnen op twee verschillende manieren: de runprocedure geeft enige informatie door via de standaard-invoer, en de gebruiker levert een configuratie-file aan. Deze twee vormen van invoer worden apart besproken in de volgende twee paragrafen.

9.3.1

Format van de standaard invoer van COEXEC

De run-procedure waqpro.pl moet aan COEXEC laten weten hoe de configuratie-file heet, hoe deze moet worden ge¨ınterpreteerd (referentie-array), en of de optie check-only is opgegeven door de gebruiker. Deze opties worden doorgegeven via de standaard invoer, middels een control-file. De control-file bestaat uit vier regels waarin de volgende dingen staan: • Een vlag die aangeeft dat COEXEC Verbose moet werken, dat wil zeggen, voortgangsinformatie moet printen. • De naam van het configuratiebestand. In het geval van horizontale verfijning wordt deze naam door de gebruiker opgegeven. In het geval van vertikale verfijning of een parallelle berekening wordt het configuratiebestand door de runprocedure gegenereerd. • De naam van het referentie-array voor COEXEC. • check only = Y/N: vlag die aangeeft of de rekenprocessen moeten worden opgestart zodra de controles met goed gevolg zijn doorlopen (N), of dat de run na de controles dient te worden beëindigd (Y). Een control-file zou er als volgt uit kunnen zien: Verbose config ref check_only

= ’proc_cfg.kust’ = ’coexecref.arr’ = ’Y’


9-3

PROCESSES P 1 NAME = ’waqpro001’ EXECUTABLE = ’waqpro.exe.bf2’ WITH ’-sdsfile "sds-rym-001" -exp "rymamo" -print "waqpro-r.rym-001"’ P 2 NAME = ’waqpro002’ EXECUTABLE = ’waqpro.exe.bf10’ WITH ’-sdsfile "sds-rym-002" -exp "rymamo" -print "waqpro-r.rym-002"’ Figuur 9.1: Voorbeeld van een configuratie-file voor een DDVERT-berekening

9.3.2

Format van de configuratiefile van COEXEC

De configuratie-file van COEXEC wordt alleen in DDHOR(+VERT) berekeningen door de gebruiker toegeleverd, en wordt in parallelle en DDVERT berekeningen automatisch gegenereerd door de runprocedure waqpro.pl. Dit verschil zorgt ervoor dat we een andere layout willen gebruiken voor de configuratie-file voor DDHOR berekeningen dan dat momenteel voor parallel en DDVERT wordt gebruikt. In het geval van vertikale verfijning kan de gebruiker per deeldomein verschillende opties opgeven, wat met name wordt gebruikt voor de buffergrootte per deeldomein. Dit is gewenst omdat er grote variaties in geheugenbeslag zijn tussen de deeldomeinen. De buffergroottes worden als lijstje opgegeven aan de runprocedure en er wordt een file gegenereerd zoals weergegeven in Figuur 9.1. De buffergroottes per deeldomein zijn niet afzonderlijk zichtbaar, maar zijn verwerkt in de namen van de executables. Op deze manier hoeft COEXEC nagenoeg geen weet te hebben van het soort rekenprocessen dat er moet worden opgestart. De configuratie file voor parallel rekenen en voor domein decompositie met vertikale verfijning is als volgt opgebouwd: PROCESSES < P [ival] NAME= [string] EXECUTABLE = [exenam] WITH = [string] > P [ival]

R

definiëert een nieuw rekenproces met uniek nummer ival

NAME = [string]

M

definiëert een unieke naam voor het rekenproces

EXECutable = [exenam] M

definiëert de naam van de executable die gebruikt moet worden

WITH [string]

geeft de lijst van woorden die aan het proces zullen worden doorgegeven

M


9-4

DOMAINS D 1 NAME = ’rymamo’ RUNID = ’rym’ EXPERIMENT = ’rymamo’ EXECUTABLE = ’waqpro.exe.bf3’ SUBDOMAINS S 1 EXECUTABLE = ’waqpro.exe.bf4’ D 2 NAME = ’kust’ RUNID = ’kust’ EXPERIMENT = ’kust’ EXECUTABLE = ’waqpro.exe.bf6’ Figuur 9.2: Voorbeeld van een configuratie-file voor een DDHOR-berekening Bij horizontale verfijning zal het vaak voorkomen dat een domein in zeer veel stukken wordt opgedeeld ten behoeve van parallelle of DDVERT verwerking. In het geval van parallel rekenen wil men niet alle deeldomeinen apart moeten specificeren en hoeft ook de buffergrootte niet per deeldomein te kunnen variëren. Bij het gebruik van DDVERT wil men die mogelijkheid wel hebben. Daarom worden de opties hier in eerste instantie per domein opgegeven in plaats van per deeldomein, maar kan men desgewenst voor bepaalde deeldomeinen extra opties geven. Het gebruik van het keyword “WITH” met een string die niet door COEXEC wordt geinterpreteerd leidt hierbij tot een complicatie, namelijk dat de deeldomeinen zelf moeten weten dat ze een nummer moeten toevoegen aan de filenamen. Daarom wordt er voor gekozen het keyword WITH te vervangen door de keywords RUNID en EXPERIMENT. Het formaat voor de configuratiefile in geval van horizontale verfijning wordt dan: DOMAINS < D [ival] NAME= [string] RUNID= [string] EXPERIMENT = [string] EXECUTABLE = [string1] SUBDOMAINS < S [ival] EXECUTABLE = [string2] > > OPTIONS MATCH ACCURACY = [val] VERBOSITY LEVEL = [ival]


9-5

D [ival]

R

definiëert een nieuw domein/rooster met uniek nummer ival

NAMe = [string]

M

definiëert een unieke naam voor het domein

EXEcutable = [string1]

O

definiëert de naam van de executable die voor alle tot het domein behorende rekenprocessen gebruikt moet worden

RUNid = [string]

M

de zogenaamde “run-id” van het domein

EXPeriment = [string]

M

de naam van het experiment op de SDS-file

SUBDOMAINS

O

geeft aan dat er specifieke informatie deeldomein volgt

S [ival]

R

geeft aan dat er specifieke informatie over deeldomein ival volgt

EXEcutable = [string2]

O

definiëert de naam van de executable die voor het deeldomein gebruikt moet worden (heeft prioriteit boven de executable die bij het domein opgegeven is).

MATCH accuracy = [val] D

de tolerantie die moet worden gehanteerd bij het vergelijken van fysische coördinaten, bij het beoordelen of twee roosterpunten samenvallen. Default: 0.01m.

VERBOSity level = [ival] D

de mate waarin COEXEC voortgangsinformatie print. Een lage waarde geeft weinig uitvoer, een hoge waarde geeft veel uitvoer. Default: 8.

Een voorbeeld van een configuratie-file voor horizontale verfijning is te zien in Figuur 9.2. Bij het schrijven van de configuratie-file moet de gebruiker er op letten dat zowel het keyword RUNID als het keyword EXPERIMENT op dezelfde regel staan als hun argument. Alleen dan kan de run-procedure de argumenten automatisch uit de file destilleren.

9.3.3

Verwerking van de configuratie-file

Bij het lezen van de configuratie-file in het format voor een DDHOR-berekening vult COEXEC ook de bestaande datastructuren in voor parallelle en DDVERT berekeningen (d.w.z. per deeldomein). Hiervoor leest COEXEC uit de “000-files” per domein welke subdomeinnummers actief zijn. De “with”-string wordt dan gevormd met behulp van de opgegeven run-id en experimentnaam conform het in Figuur 9.1 gebruikte stramien.

9.4

Uitvoeren van controles

In Hoofdstuk 2 is beschreven dat we ervoor kiezen om de preprocessing fase voor alle roosters (siminp-files) afzonderlijk van elkaar uit te voeren. Dit is handig voor de implementatie, en lijkt ons ook prettig voor de gebruiker. Een consequentie is wel dat controles ten aanzien van de consistentie van de verschillende domeinen pas in de processing fase kan worden onderzocht. Daarbij worden de controles zo veel mogelijk door COEXEC uitgevoerd, opdat de gebruiker


9-6

zo snel mogelijk terugkoppeling krijgt op eventuele fouten in de invoer. Alleen sommige controles kunnen gemakkelijker door WAQPRO worden uitgevoerd, met name wanneer er veel bewerkingen op de invoer nodig zijn die grotendeels al bij de initialisaties in WAQPRO worden uitgevoerd. In Hoofdstuk 7 is aangegeven aan welke voorwaarden de verschillende roosters in een gekoppelde simulatie moeten voldoen, en hoe gecontroleerd wordt of aan die eisen wordt voldaan. Hierbij wordt ondermeer gecontroleerd of de subdomeinen minstens zo breed zijn als de guardbands van directe buurdomeinen, om te voorkomen dat communicatie nodig is met andere deeldomeinen waar geen directe koppeling mee bestaat. De controle op het rondlopen van roosterlijnen wordt uitgevoerd door WAQPRO, bij het kleuren van deelrijen ten behoeve van het BJ-TWGE schema of bij het bepalen van globale rij-nummers (subroutines wasrwc en wasrnm). Als de domeinen correct aan elkaar passen, kan het nog voorkomen dat de invoer voor de domeinen zodanig is dat een simulatie niet correct kan worden uitgevoerd. Vooral als de verschillende domeinen op basis van hun invoer verschillende communicaties willen gaan uitvoeren. Om dit soort problemen te voorkomen moet de invoer aan de volgende eisen voldoen: • zelfde proces-modellen Alle domeinen moeten ofwel met WAQUA worden doorgerekend, ofwel allemaal met TRIWAQ. Combinaties van beide in een enkele simulatie zijn verboden (imodel). In alle domeinen moet transport worden doorgerekend, ofwel in geen van alle domeinen (itrans). Het zelfde geldt voor het k − turbulentie model (iturfl) (in een TRIWAQsimulatie). In DDHOR berekeningen mogen Lagrangiaanse tijdsintegratie en de gebruikersroutine niet gebruikt worden (intflg, iusrfl, iusrtr en iusrpa). De genoemde variabelen zijn gedefin¨ıeerd in de arrays CONTROL PROCES en CONTROL FLOW ICONTB voor alle domeinen. • passende laagverdelingen Er zijn een aantal restricties de gekozen verfijningen in de verticale richting. Binnen elk globaal domein heeft COPPRE dit al gecontroleerd. Op de plekken waar de globale domeinen aan elkaar gekoppeld zijn moet COEXEC dit echter nog controleren. • ´ e´ en domein het fijnste Bij een communicatie moet één van de twee deelnemende (sub) domeinen als fijnste aangemerkt kunnen worden. Dit houdt in dat het niet is toegestaan dat een van de twee domeinen vertikaal fijner maar horizontaal grover is. Dit wordt ook in COEXEC gecontroleerd. Het is natuurlijk wel toegestaan dat de domeinen beide de zelfde verfijning hebben (waarbij geen van de twee het fijnste is). • speciale functionaliteit Roosters in bol-coördinaten mogen niet worden gekoppeld aan krom- en rechtlijnige roosters (variabele kurflg uit MESH IDIMEN). Het aantal constituents lmax uit


9-7

CONTROL TRANS ICONTB in de transportberekening moet gelijk zijn in alle domeinen. De droogvaloptie idry uit CONTROL FLOW ICONTB moet ofwel in alle domeinen wel een extra controle in waterstandspunten vereisen (waardes 0, 1 en 2, “max/mean/min”), ofwel in alle domeinen geen extra controle vereisen (waarde 3, “no”). De naam van de wind-SDS-file moet verschillend zijn in alle domeinen (array COEFF GENERAL IREFSW, bestaat alleen als ISVWP=1). • tijdstapparameters de volgende tijdstap-gerelateerde parameters moeten binnen alle domeinen gelijk zijn: tstart, tstop en dtmin uit zowel CONTROL FLOW RCONTA als CONTROL TRANS RCONTA en ticval uit CONTROL FLOW RCONTA (Chezy) tfniku, tiniku, tlniku uit CONTROL FLOW RCONTB (k-Nikuradse berekening) en tfstap, tistap, tlstap uit zowel CONTROL FLOW RCONTB als CONTROL TRANS RCONTB (printen process status information). Er wordt ook gecontroleerd of de referentie datum voor alle domeinen gelijk is (itdate uit PROBLEM FLOW NAMPRB). • iteratie-constanten alle parameters met betrekking tot de stop-criteriums voor de iteratieve procedures moeten identiek zijn in alle domeinen: uit CONTROL FLOW ICONTB de variabelen iter1, iter2, en uit CONTROL FLOW RCONTA de getallen epsvel en epswl. Het al dan niet gebruiken van horizontale verfijning wordt afgeleid uit het format dat wordt gebruikt voor de configuratie-file. Merk op dat er niet wordt gecontroleerd of bijvoorbeeld in alle domeinen wel of geen SVWP wordt gebruikt. Ook wordt het gelijk zijn van bijvoorbeeld de zwaartekracht niet geverifiëerd. We verwachten dat verschillen hierin per domein niet belastend zijn voor het kunnen uitvoeren van de simulatie. Men kan zich echter afvragen hoe gewenst het is om hierin te kunnen variëren (en fouten te maken), dus of er misschien aan de invoerzijde voorzieningen moeten worden gemaakt voor het toeleveren van gemeenschappelijke gegevens.

9.5

Informatie naar WAQPRO sturen

Bij het opstarten van een simulatie worden de processen een voor een door COEXEC opgestart. Ieder proces krijgt informatie mee van COEXEC die nodig is om de simulatie uit te kunnen voeren. Deze informatie bestaat uit • invoer voor standaard functionaliteit van WAQPRO: – de “with”-string, met de te gebruiken sds-file, experimentnaam en naam van de bulk-printfile, • de domeinen: – het aantal domeinen, de run-id’s van alle domeinen


9-8

• de processen: – het totaal aantal rekenprocessen (deeldomeinen), het eigen procesnummer, de PVM task-id’s van alle processen, en het domein/roosternummer van alle processen • configuratie-informatie met betrekking tot de koppeling: – de waarde voor de MATCH ACCURACY (zie Sectie 9.3.2).


10-1

Hoofdstuk 10 Detail ontwerp aanpassingen COPPRE 10.1

Inleiding

De partitioner COPPRE verzorgt het inlezen van een partitie- of areas-file, het automatisch opsplitsen van het rekenrooster (in parallelle berekeningen) of van een enkel subdomein (domein decompositie i.c.m. parallel rekenen), en het distribuëren van de gegevens uit een globale SDS-file naar afzonderlijke SDS-files per deeldomein conform de gehanteerde roosteropdeling. COPPRE wordt bij domein decompositie gebruikt om met bestaande simulatie-invoerfiles te kunnen werken (door het wegknippen van de delen die met andere roosters worden ingevuld), om een verdere opdeling van het domein te maken voor parallel rekenen of het gebruik van vertikale verfijning, en om extra ruimte te kunnen toevoegen aan de arrays per deeldomein voor de opslag van waardes van buurdomeinen, de zogenaamde guard band. Bij de introductie van domein decompositie met vertikale verfijning is een flink aantal wijzigingen in COPPRE doorgevoerd (met name de introductie van het AREAS-formaat voor partitioneringsfiles en het gebruik van parameters en indirecte indexsets in de beschrijving van de LDS). Deze aanpassingen worden uitgebreid behandeld in het detailontwerp DDVERT [11] en zullen hier niet verder worden behandeld. Ten behoeve van domein decompositie met horizontale verfijning zijn de volgende aanpassingen gemaakt aan COPPRE: • Functionaliteit voor het toevoegen van een guard band. • Instelbaar maken van de breedte van de guardband en het aanpassen van de controle op de minimale breedte van subdomeinen. • Toestaan van “SUBDOMAIN=−1” in de areas-file voor het niet-actieve gedeelte van een rooster/domein. • Herkenbaar markeren van de roosterpunten in de niet-actieve gedeeltes per domein (eigenaarschap −1), ten behoeve van WAQPRO en COPPOS.


10-2

• Mogelijk maken van automatische partitie van een subdomein uit een eerder opgegeven decompositie van het domein. • Automatische partitie van de niet-interne punten van het domein. • Aanpassen van de definitie van enclosures op de in WAQPRE gebruikte definitie. • Uitbreiden van het maken van distributietabellen in COPPRE met verschillende ownerships voor s/u/v/d-punten. • Speciale afhandeling voor compound arrays die gedeeltelijk tijdsafhankelijk zijn. Deze punten zullen in de volgende paragrafen achtereenvolgens worden uitgewerkt.

10.2

Toevoegen van guard bands

Voor domein decompositie is aan COPPRE functionaliteit toegevoegd om een guardband toe te voegen aan domeinen, zodat gegevens die van naburige domeinen worden ontvangen kunnen worden opgeslagen in de eigen arrays. Dit is gedaan door het toevoegen van de optie ADD GUARDB aan de configuratiefile voor COPPRE. Daarbij krijgen de guardbandpunten ook een nummer in de lgrid tabel, zodat feitelijk de indexset mnmaxk wordt uitgebreid. Het betreft de volgende wijzigingen: • cog1sc: beveiliging tegen nullen in conversie tabellen, die voorkomen als er bij een lokale index geen globale index bestaat. Als iglbix nul is dan moet de waarde uit het deeldomein niet worden gekopiëerd naar het globale domein. • copext: nieuwe subroutine voor het uitbreiden van de nummering van mnmaxk. • copc03: toevoegen van een aanroep van subroutine copext, voor de nummering van mnmaxk in de guardband. • copcv0: toevoegen van het argument iaddgb, dat aangeeft of er een extra guardband moet worden toegevoegd. • copdnm: toevoegen van extra argumenten nmax en mmax, om te bepalen of er bij een lokale index een globale index bestaat, of een entry van een conversie tabel al dan niet op nul gezet moet worden. • copcvw,copcvs: toevoegen van het argument iaddgb in de aanroep van coppow die de bounding box bepaalt; toevoegen van nmax, mmax in de aanroep van copdnm. • copd03: toevoegen van het argument iaddgb; toevoegen van een aanroep van subroutine copext voor het aanmaken van de extended lgrid tabel. • coppow: toevoegen van het argument iaddgb; rekening houden met de extra guardband bij het bepalen van de bounding box. • coprdd: ophalen van de waarde van iaddgb uit de invoerfile.


10.3

10-3

Instelbaar maken van de guardbandbreedte

In de toekomst kan het nodig zijn dat een guard band van vier wordt aangehouden in plaats van de huidige breedte van drie. Daarom is de breedte door het hele programma instelbaar gemaakt. Deze faciliteit zou later ook kunnen worden gebruikt om in speciale gevallen een kleinere guard band te hanteren (WAQUA berekeningen, TRIWAQ zonder stoftransport), waarmee het geheugengebruik van WAQUA/TRIWAQ kan worden verminderd. Daarom is er een nieuwe optie GUARDB WIDTH ge¨ıntroduceerd voor de breedte. De ingestelde guardband breedte is ingevoerd in het gehele programma waar voorheen de parameters mgdbwd en ngdbwd werden gebruikt (subroutines copchr, lin, opt, pow en wpw). De mogelijkheid om verschillende waardes te gebruiken voor de twee coördinaat-richtingen zal worden verwijderd. De nieuwe waarde igbwid wordt via parameterlijsten doorgegeven in plaats van er een common block voor te gebruiken (oude manier: parameters in include file acopcn.i). Verder komt de guardband breedte in de huidige programmatuur alleen voor in subroutine copck4, waar wordt gecontroleerd of een subdomein niet smaller is dan de guardband van een van zijn buren. Dit gebeurt na afloop van het aanmaken van een SDS-file voor het deeldomein en gaat er momenteel van uit dat de guardband altijd breedte 3 heeft. Een probleem met deze controle in COPPRE is dat de DDHOR-buurdomeinen nog niet bekend zijn. De verfijningsfactoren die daarbij van toepassing zijn zijn nodig voor de uit te voeren controle. De laagverdelingen van deeldomeinen van hetzelfde globale domein worden wel nog steeds binnen COPPRE gecontroleerd. Hierdoor krijgt de gebruiker zo snel mogelijk terugkoppeling over eventuele fouten in de invoer.

10.4

Toestaan van “SUBDOMAIN=−1” in de areas-file

Gebruikte deeldomeinen worden in de areas-file aansluitend genummerd vanaf nummer één. Ongebruikte delen van het domein worden aangegeven met (deel)domeinnummer −1. Het belangrijkste voordeel van deze manier van specificeren is dat er geen keyword ONLYDOMS in de areas-file hoeft te worden opgenomen om aan te geven welke deeldomeinen er gebruikt worden (wat voor de implementatie op veel problemen stuit). Ook vereenvoudigt het allerlei implementatiekwesties in de overige randprogrammatuur (COCLIB, COPPOS) omdat er geen vertaalslag hoeft te worden gemaakt van deeldomeinnummer naar de plaats van een deeldomein in lijsten van gebruikte deeldomeinen. Intern in COPPRE kan er op verschillende manieren met het deeldomein-nummer −1 worden omgegaan: • alle punten die tot deeldomein −1 behoren toekennen aan een (virtueel) deeldomein met een nummer groter dan het grootste gebruikte deeldomein. Op deze manier worden eventuele problemen voorkomen die het gevolg kunnen zijn van negatieve waarden in de eigenaarschap-array ihown.


10-4

• de waarde −1 ook invullen in het eigenaarschap-array ihown en alle daaruit voortvloeiende problemen oplossen. Er is gekozen voor de laatste mogelijkheid, vooral omdat dan de informatie dat punten zeker niet in de simulatie gebruikt worden ook intern beschikbaar blijft. Bij de eerste optie is er geen verschil te zien tussen een deeldomein waarvoor op een ander tijdstip alsnog een SDSfile wordt aangemaakt (zoals bijvoorbeeld bij DDVERT) en een deeldomein dat daadwerkelijk niet in de simulatie gebruikt zal worden. De gevolgen van deze keuze zijn beperkt. De volgende aanpassingen zijn gemaakt: • coppck checkt op het overdekkend zijn van een opdeling. Daarbij moet rekening gehouden worden met het feit dat −1 ook een valide subdomeinnummer is. Dit betekent dat in copprt, waar de partitionering wordt ingelezen, het eigenaarschap-array op −2 moet worden ge¨ınitialiseerd, zodat coppck alsnog een niet-overdekkende partitionering kan detecteren. Bovendien moet voor DDVERT de mogelijkheid van ongebruikte deeldomeinen nog steeds geblokkeerd blijven via de controle in coppck. • copprs bepaalt de partitionering van het windrooster op basis van die van het stromingsrooster. Allereerst wordt de partitionering van het stromingsrooster overgezet naar het windrooster en vervolgens wordt de dan ontstane partitionering van het windrooster uitgebreid naar een partitionering voor het hele windrooster (dus ook buiten het stromingsrooster). Daarbij moet deeldomeinnummer −1 ook als een deeldomein worden opgevat. Dit kan het gemakkelijkst worden ge¨ımplementeerd door tijdelijk alle punten die tot deeldomein −1 behoren toe te kennen aan deeldomein npart+1 en daarmee de routine copfil (uitvullen van de partitionering) aan te roepen. • copct0 telt het aantal punten in een indexset (bijvoorbeeld checkpoints) dat binnen elk van de deeldomeinen ligt, om daarmee de afmeting van de benodigde conversietabel vast te stellen. Als er een punt in een ongebruikt deeldomein ligt zou dat in de huidige implementatie leiden tot een waarschuwingsboodschap. Dit moet worden voorkomen. • copck2 controleert of een deeldomein een valide DDVERT deeldomein is. Deze controles worden niet uitgevoerd voor DDHOR en er hoeven hier dus geen aanpassingen gedaan te worden. • copd1d bepaalt door het aanroepen van coplin het deeldomeinnummer waar een lijnstuk toe behoort, ook als dat lijnstuk buiten het stromingsrooster valt (en er dus eigenlijk geen eigenaar gedefiniëerd is). Als een lijnstuk ver buiten alle deeldomeinen valt, wordt er een waarschuwing gegeven. Dit moet voor DDHOR worden voorkomen in het geval dat een lijn in een ongebruikt deeldomein ligt. Dit kan worden gerealiseerd door het argument isown waarmee copfil aangeeft of er een eigenaar gevonden is door de waarde −1 te laten aangeven dat er wel een eigenaar gevonden is (namelijk deeldomein −1) maar dat dit deeldomein niet gebruikt wordt. Als isown de waarde −1 heeft hoeft er in copd1d geen waarschuwing te worden gegeven. Een aanvullende controle op de ligging


10-5

van lijnen vindt later plaats in de controles die specifiek zijn voor domein decompositie (zie volgende paragraaf) Daarnaast moet worden opgemerkt dat de waarde −1 ook voorkomt in het eigenaarschap-array dat aan WAQPRO en COCLIB wordt doorgegeven (het POWNER array), en dat WAQPRO en COCLIB daar rekening mee moeten houden.

10.5

Het eigenaarschap van ongebruikte punten

COPPRE voegt aan iedere deel-SDS-file een array POWNER toe dat in WAQPRO wordt gebruikt als beschrijving van de ligging van de buurdomeinen. In DDHOR berekeningen moet WAQPRO ook weten waar er geen parallel of DDVERT buurdomein is, waar een DDHORkoppeling van toepassing is. Dit gebeurt vanzelf als gevolg van de keuze die in de vorige paragraaf is gemaakt. Het POWNER array bevat waarden −1 voor punten die tot ongebruikte deeldomeinen behoren. Dit is consistent met de POWNER array die door de collector aan de globale SDS-file wordt toegevoegd, waaraan post-processing programmatuur kan zien welke gedeeltes niet zijn gebruikt in een DDHOR berekening. Een nieuw aspect met betrekking tot eigenaarschap bij DDHOR is dat er complicaties kunnen ontstaan door het zomaar wegsnijden van stukken van een globale SDS-file. Bijvoorbeeld leidt het tot problemen als van een QH-opening de helft wordt weggesneden: ten eerste zijn speciale voorzieningen vereist bij de berekening van het totale debiet langs een opening in WAQPRO, waarbij niet moet worden gecommuniceerd met het niet-actieve deeldomein, ten tweede wordt een lager debiet berekend dan bij het aanmaken van de QH-tabellen werd verondersteld. Vergelijkbare problemen kunnen ontstaan met cross-sections, QAD-randen en dynamische barrier-sturing. Openingen en cross-sections worden opgeslagen op basis van zogenaamde lijn-indexsets. Het leidt blijkbaar tot problemen als elementen in deze sets gedeeltelijk binnen en deels buiten het actieve gedeelte van het rooster vallen, hierop moet dus worden gecontroleerd. Voor sommige lijn-indexsets volstaat een waarschuwing: halve Fourier- en series-openingen en rijen en kolommen van het rooster kunnen namelijk goed worden afgehandeld. Voor andere lijn-indexsets moet echter een foutmelding gegeven worden. Dit is opgelost met een vlag voor subroutine copd1d waarmee dit gedrag per lijn-indexset apart kan worden ingesteld. Voor QAD-openingen is de controle apart ge¨ımplementeerd in subroutine copcho. Dit is nodig omdat er geen aparte indexset bestaat voor de QAD-openingen. In plaats daarvan kunnen sommige series-openingen of Fourier-openingen als QAD-rand worden gemarkeerd. De controle op het wegsnijden van punten of cross-sections die in dynamische barriersturing worden gebruikt wordt in WAQPRO uitgevoerd, omdat deze specifieke kennis van de gebruikte data-structuren vereist. Een andere complicatie met betrekking tot eigenaarschap is dat snelheidspunten op de interface in DDHOR berekeningen tot het fijnste van de betrokken buurdomeinen worden gerekend. Dit impliceert dat een deeldomein eigenaar kan zijn van een snelheidspunt (m, n),


10-6

waarvoor in de POWNER array een −1 wordt ingevuld. In COPPRE wordt dit punt momenteel net als in parallelle en DDVERT berekeningen tot de guard band gerekend. Vanwege deze complicatie worden de guard bands van actieve deeldomeinen gevuld alsof alle buurdomeinen actief zijn. Hiermee heeft een deeldomein alle benodigde informatie over al zijn eigen snelheidspunten en is er verder niets aan de hand.

10.6

Automatische partitie van een subdomein van een decompositie

In eerste instantie kon COPPRE automatische partitionering alleen toepassen op het complete domein. Als de gebruiker domein decompositie wilde combineren met parallel rekenen dan moest hij een handmatige partitionering of areas-file gebruiken en daarin meer subdomeinen aanmaken dan voor de domein decompositie was gewenst. Dit is in 2008 uitgebreid via de mogelijkheid van automatische partitie van een enkel subdomein. Er is voor gekozen om automatische partitie slechts toe te staan voor een enkel subdomein. Dat was te realiseren met de minste hoeveelheid werk, maar bleek wel een extra aanpassing te vereisen voor DDVERT. Een alternatief was geweest om de partitie configuratiefile uit te breiden met de specificatie van een partitiemethode en aantal parts per subdomein. De gemaakte aanpassingen voor partitie van een subdomein zijn als volgt: • In de partitie configuratiefile is keyword DECOMPOSITION verwijderd, en wordt de opdeling voortaan altijd via PARTITIONING gespecificeerd. • Het keyword PARTMETHOD wordt tegelijkertijd toegestaan met ofwel PART VALUES ofwel AREAS. • Bij PARTMETHOD kan via SPLITDOM worden opgegeven welk subdomein er moet worden gepartitioneerd. • De keywords ONLYDOMS en ONLYPARTS worden allebei toegestaan. Daarbij verwijst ONLYDOMS naar de nummering van de decompositie (voor automatische partitie) en ONLYPARTS naar de uiteindelijke nummering (na automatische partitie). • In de implementatie is imeth (strip, orb, part values of areas) vervangen door twee aparte variabelen: idmeth (decompositie-methode: geen, part values of areas) en ipmeth (automatische partitie: geen, strip of orb). • De uiteindelijke partitie wordt bepaald door eerst een eventuele decompositie in te lezen en daarna automatische partitionering te doen. • Het gebruik van machine-snelheden is nog niet ge¨ımplementeerd voor automatische partitionering van een subdomein.


niet-actief

actief subdomein-interface

10-7 0

0

1

1

1

0

-1

1

1

1

-1

-1

1

1

1

-1

-1

1

1

1

-1

-1

1

1

1

-1

-1

1

1

1

-1

-1

-1

1

0

-1

-1

-1

eindpunt rij rekenrooster !

Figuur 10.1: Partitie van niet-interne roosterpunten. Links: situatie zoals gezien vanuit de gebruiker: (interne) rekencellen, actief/niet-actief. Rechts: valide partitionering, wordt ook opgegeven voor virtuele roosterpunten t.b.v. randafhandeling. Aan runprocedure waqpre.pl zijn opties -npart en -partit toegevoegd. Voor DDHOR mag hier een waarde worden opgegeven, voor DDVERT een waarde per subdomein uit de decompositie-file. Dit wordt verder ge¨ımplementeerd via template-configuratiefiles copcfg.ddh.gen en copcfg.ddv.gen. Een complicatie die hierbij is opgetreden zit in het array POWNER dat door COPPRE aan de SDS-file per subdomein wordt toegevoegd. Dit array wordt gebruikt voor het uitzoeken van de buur-subdomeinen per WAQPRO rekenproces. Daarvoor moet dit array in alle subdomeinen/parts op de uiteindelijke partitie zijn gebaseerd. Om dit voor elkaar te krijgen wordt eerst WAQPRE voor de eerste laagverdeling gedraaid, dan wordt COPPRE ndom keer uitgevoerd met optie PARTONLY, vervolgens wordt COPPRE met geschikte invulling van ONLYPARTS gedraaid voor het aanmaken van deel-SDS-files voor het eerste DDVERT subdomein en tenslotte worden WAQPRE en COPPRE aangeroepen voor de subdomeinen (laagverdelingen) 2..ndom. In de eerste loop van ndom keer aanroepen van COPPRE wordt de resulterende partitie (report-file coppre-r.) van de ene run gebruikt als decompositie voor de volgende run.

10.7

Automatische partitie van randpunten

Een complicatie van het gedeeltelijk wegsnijden van stukken van een rooster/domein is als volgt: de interface tussen het actieve en niet-actieve gedeelte van het rooster kan gedeeltelijk samenvallen met open en gesloten randen van het rooster. In bepaalde gevallen leidt dit ertoe dat een actief deeldomein alleen het randpunt van een rij of kolom van het globale rekenrooster krijgt toegewezen. Deze situatie is erg lastig te behandelen door WAQPRO en is daarom niet toegestaan. Dit stelt extra eisen aan de partitionering, die voor een gebruiker lastig na te komen zijn. Een voorbeeld hiervan wordt gegeven in Figuur 10.1, waar voor het gemarkeerde


10-8

eindpunt van een rekenrij in de rechter tekening per sé deeldomein-nummer −1 moet worden opgegeven om een rij van een enkel randpunt in het actieve deeldomein te voorkomen. Vanwege deze complicatie is ervoor gekozen om COPPRE uit te breiden zodanig dat de gebruiker alleen met de interne punten te maken heeft en dat COPPRE zorg draagt voor het partitioneren van de overige punten (randpunten en overige punten in de mnmaxk-verzameling). Dit is als volgt uitgewerkt: • Nadat subroutine copart de MESH en PROBLEM-arrays heeft ingelezen wordt de nieuwe subroutine copkcs aangeroepen voor het vullen van het array KCS overeenkomstig het array KCS in WAQUA/TRIWAQ. Interne roosterpunten (cellen) worden met 1 gemarkeerd (punten mfu:ml uit de IROGEO-tabel), open rand-punten met 2 (punten mf, mlu, nf, nlu bij bepaalde rand-codes in IROBOU), en voor alle overige punten wordt 0 opgeslagen. • De functie van subroutine copprt wordt aangepast tot het bepalen van HOWNER voor interne roosterpunten (KCS=1), in plaats van voor alle niet-landpunten (LGRID>1). • Bij gebruik van een automatische partitie-methode wordt gelijk de rekenlast van overige punten (KCS=0) op 0 gesteld. Open randpunten worden wel volledig meegeteld, omdat daar een vrijwel volledige impulsvergelijking voor wordt opgesteld. • De vorige twee punten worden bereikt door HOWNER initiëel op 0 te stellen voor overige punten (KCS=0), en aan het einde van copprt op −2 te zetten (“onbekend”) voor alle niet-interne punten (KCS6=1). • Na de eventuele optimalisatie-slag in copopt wordt nu in subroutine copbnd een geschikte partitie voor de overige punten bepaald. • Vervolgens wordt in coprep de partitie weggeschreven naar de report-file coppre-r. exclusief de deeldomein-nummers voor randpunten. De gebruiker heeft dus wederom alleen te maken met interne punten, ook het aantal punten en de interfacelengte per deeldomein wordt aangepast. • Tenslotte worden in de controles in coppck ge¨ısoleerde roosterpunten (van een deeldomein tussen twee punten van andere deeldomeinen in) toegestaan voor niet-interne punten. Ge¨ısoleerde roosterpunten kunnen leiden tot een rekenrij van 1 intern punt, met complicaties voor het communiceren van getallen voor begin- en eind-punten van rijen en kolommen. Dit speelt niet voor niet-interne punten, terwijl subroutine copbnd wel ge¨ısoleerde niet-interne punten kan opleveren. Noot: de optimalisatie van partities in copopt is uitgeschakeld in de nieuwe versie. Ten eerste vanwege een complicatie: optimalisatie van array-groottes is pas mogelijk na partitie van de randpunten, maar aanpassing van de partitie kan dan de eisen m.b.t. randpunten in de war schoppen. Ten tweede omdat de oude methode niet goed voldeed en daarom niet werd gebruikt. Deze methode was traag en optimaliseerde de onbelangrijke array-grootte nmax*mmax in plaats van mnmaxk (WAQUA) of of nmax*(mmax+6) (TRIWAQ, fullbox).


10-9

De methode die in subroutine copbnd wordt gebruikt voor het partitioneren van de nietinterne punten streeft de volgende doelen na: 1. vermijden van de complicatie van een enkel rand-punt van een rij die verder in het niet-actieve gedeelte van het domein ligt; 2. vermijden van het samenvallen van subdomein-randen met (horizontale of vertikale) openingen; 3. aansluiten bij de partitie van de interne punten: interfaces zo veel mogelijk recht voortzetten, zo min mogelijk uitbreiden van de fullbox per deeldomein. Deze doelen worden bereikt door middel van een aantal heuristieken. Daarbij wordt onderscheid gemaakt tussen de begin- en eindpunten van rekenrijen en kolommen (mf, mlu, nf en nlu) en de overige niet-interne punten. De eerste twee doelen worden bereikt met simpele regels voor de eerste categorie van punten (er zijn maximaal twee naastgelegen interne punten, en precies één wanneer de twee doelen van belang zijn). Ook het derde doel is relatief eenvoudig te bereiken voor deze categorie (kijken naar het diagonaal gelegen punt). Voor de overige punten is het allemaal wat onduidelijker (welke situaties kunnen voorkomen), en ook onbelangrijker (de punten hebben nagenoeg geen functie). Er is gekozen voor een aantal regels die direct zijn te evalueren en zo goed mogelijk de samenhang van de deeldomeinen lijken te waarborgen. Een alternatief is om vooral te kijken naar de grootte van de full-box. Er kan worden overwogen om geen eigenaar te definiëren voor de overige punten. Dit zorgt ervoor dat er voor deze punten niet wordt gecommuniceerd in WAQPRO. Dat is geen probleem zolang de afhandeling van bewerkingen voor deze punten in WAQPRO hierop is afgestemd. Merk op dat er voor het land-punt iadlnd in mnmaxk ook geen eigenaar is gedefinieerd, en dat alle WAQPRO-processen hierop inspelen door alle overeenkomstige bewerkingen zelf (redundant) uit te voeren. Ook voor randpunten bij gesloten randpunten kan eigenaar=0 worden gedefiniëerd: hiermee wordt het samenvallen van subdomeininterfaces met gesloten randen omzeild (randcode ibf/l=ibitfc+1).

10.8

De afhandeling van enclosures in de areas-file

In de eerste versie DDHOR is de afhandeling van enclosures in areas-files opnieuw ge¨ımplementeerd om een aantal voor de gebruiker prettige mogelijkheden goed te ondersteunen: • enclosure-punten die buiten de full-box liggen, zoals (-10,-10) en (100.000,100.000); • enclosures die over land-punten lopen in plaats van het actieve gedeelte van het rooster te volgen. Daarnaast heeft het automatisch partitioneren van randpunten een volgende verbetering mogelijk gemaakt:


10-10

• herdefinitie van de enclosures, zodanig dat de punten op de enclosure zelf niet tot het bijbehorende area worden gerekend. De nieuwe definitie komt goed overeen met het gebruik van enclosures in WAQPRE: punten op de enclosure horen daar niet bij het interne gedeelte van het rooster/domein. Merk op dat de randpunten voorheen aan deeldomeinen moesten worden toegewezen, en dat het gebruik van enclosures over de randpunten daarvoor vereiste dat de enclosure-punten zelf bij het omsloten area werden gerekend. Area-files met oude-stijl enclosures zijn lange tijd ondersteund naast nieuwe-stijl enclosures door aparte keywords “DOMAIN” en “SUBDOMAIN” te ondersteunen binnen een AREA. Begin 2008 is de ondersteuning voor de oude-stijl enclosures verwijderd uit de programmatuur. AREAS < AREA [ival] SUBDOMAIN [ival] | < MNMNBOX ([ival], [ival]) ([ival], [ival]) > < | ENCLOSURE < ([ival], [ival]) > >

Twee moeilijke punten in de afhandeling van enclosures zijn als volgt: • het is moeilijk om van een intekening van een enclosure op een werk-array te bepalen welke stukken intern danwel extern ten opzichte van de enclosure liggen; • het is moeilijk om lijn-segmenten te hanteren die (ver) buiten de fullbox liggen. Oorspronkelijk werd het eerste punt afgehandeld met een gecompliceerd inkleur-algoritme: als van een punt de status bekend is dan kunnen alle direct naastgelegen punten worden ingekleurd, en als aan een kant van een enclosure de ene status geldt dan geldt de andere status aan de andere kant. Dit laatste leidde tot problemen bij speciale hoeken tussen opeenvolgende lijn-segmenten. Het tweede punt werd afgehandeld door projectie van punten van lijn-segmenten buiten de fullbox op de rand van de fullbox, maar met diverse complicaties als gevolg. Merk op dat dit projecteren voornamelijk nodig is voor het inkleur-algoritme, verder is er geen noodzaak om te weten waar de enclosure precies loopt. In de huidige implementatie worden de twee moeilijkheden als volgt omzeild: 1. Voor het inkleuren van het binnengebied van de enclosure gebruiken we masker-arrays voor u- en v-punten. Zodra deze masker-arrays zijn ingevuld kan eenvoudig in een keer per rij of per kolom worden bepaald wat intern en extern is, in plaats van dat meerdere (complexe) sweeps moeten worden uitgevoerd. 2. Voor het bepalen welke kant van de enclosure intern danwel extern is gebruiken we de som van alle hoeken tussen opeenvolgende lijn-segmenten. Deze is ofwel +360◦ voor

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) angle to next segment iangsg=135 iangsg=90 j=2

iangsg=45

iangsg=0

j=3 j=2

j=1

10-11 iangsg=−45

j=1 i=n

iangsg=−135

j=4

j=2 j=1 i=n

iangsg=−90

j=2 i=n

j=3 j=2 i=n−1

i=n−1

j=4 j=5

i=n−2

iangax=90 angle to x−axis

iangsg=135 j=2

iangsg=90

i=n i=n−1

iangsg=0

iangsg=−45

iangsg=−90

iangsg=−135

j=2

j=2

j=1

i=n−2

iangsg=45

j=1 i=n

j=1 i=n

j=2 j=3 i=n i=n−1 i=n−2

j=1 j=2 i=n−1

i=n−2 j=3 i=n−3

n−3 i=n−4

j=3

iangax=45

Figuur 10.2: Afhandeling van hoeken tussen opeenvolgende lijn-segmenten van een enclosure: welke u- en v-punten moeten worden gemarkeerd. een enclosure die tegen de klok in is opgegeven ofwel −360◦ (met de klok mee). In het laatste geval wordt de volgorde van enclosure-punten omgedraaid, zodat altijd het buitengebied rechts ligt van de enclosure-punten. 3. Bij het intekenen van s-punten op de enclosure en de u- en v-punten aan de buitenkant van de enclosure wordt gecontroleerd of de lijn-segmenten binnen de fullbox elkaar niet raken of snijden. Mede hierdoor moeten we goed opletten welke u- en v-punten er worden ingetekend bij overgangen tussen opeenvolgende lijn-segmenten. Daarvoor zijn er 56 situaties (8 richtingen lijn-segment, 7 hoeken naar volgende segment) waarvan 14 wezenlijk verschillend, zie Figuur 10.2. 4. Lijn-segmenten buiten de fullbox kunnen vrijwel volledig worden genegeerd. Alleen wordt gecontroleerd dat ze elkaar niet snijden of gedeeltelijk samenvallen, omdat dan “het binnengebied” niet goed gedefinieerd hoeft te zijn. Snijden en overlappen kan worden gedetecteerd aan de hand van parametrisaties van de twee lijnen. 5. Zodra de stukken van lijn-segmenten die binnen de fullbox liggen zijn ingetekend op de werk-arrays, worden waar nodig extra punten op de rand van de fullbox ingetekend om een gesloten enclosure te verkrijgen. Dit aanvullen wordt ge¨ıllustreerd in Figuur 10.3.


111111111111111 000000000000000 000000000000000 111111111111111 000000000000000 111111111111111 000000000000000 111111111111111 000000000000000 111111111111111 000000000000000 111111111111111 000000000000000 111111111111111 000000000000000 111111111111111 000000000000000 111111111111111 000000000000000 111111111111111 000000000000000 111111111111111 000000000000000 111111111111111 000000000000000 111111111111111 000000000000000 111111111111111 000000000000000 111111111111111 000000000000000 111111111111111 000000000000000 111111111111111 000000000000000 111111111111111 000000000000000 111111111111111

10-12

11111 00000 00000 11111 00000 11111 00000 11111

Figuur 10.3: Afhandeling van enclosures: toevoegen van lijn-segmenten op de rand van de fullbox in geval van enclosure-gedeeltes buiten de fullbox. We maken twee rondes over de rand van de fullbox (n = 1, m = mmax, n = nmax, m = 1), veronderstellen eerst dat punt (1, 1) extern is, en zodra we een snelheidspunt gevolgd door een waterstandspunt op de enclosure passeren weten we de status (in- of extern). 6. Aan de hand van de gesloten enclosure vallen de interne punten eenvoudig te markeren. Alleen wanneer geen enkel lijn-segment (gedeeltelijk) binnen de fullbox ligt is nog onbekend of de hele fullbox binnen- of buitengebied is. In dat geval wordt de status van punt (1, 1) bepaald door het aantal lijn-segmenten te tellen dat wordt gepasseerd richting (−∞, 1), per definitie extern. 7. Tenslotte wordt voor enclosures “nieuwe stijl” de markering van s-punten op de enclosure zelf ongedaan gemaakt, via een loop over alle lijn-segmenten, en wordt het deeldomeinnummer voor alle geselecteerde punten in HOWNER aangepast.

10.9

Verschillende ownerships van s/u/v/d-punten

Bij gebruik van horizontale verfijning kan het begrip ownership niet meer strikt worden gekoppeld aan de (m, n)-coördinaten van roosterpunten. Bij een enkele (m, n)-coördinaat kan een subdomein eigenaar zijn van het waterstandspunt en niet van het u-snelheidspunt, maar ook andersom. Zie ook paragraaf 4.2.3. COPPRE en COPPOS moeten rekening houden met deze verschillen tussen de ownerships van de verschillende soorten punten. Met name als een domein een DDHOR-interface heeft


10-13

aan de linkerzijde (u-punten) of onderzijde (v-punten) van het domein, en als het domein fijner is verroosterd dan zijn buurdomein, dan moet informatie over ruwheden, overlaten, cross-sections e.d. op de DDHOR-interface door COPPRE worden gekopiëerd van de globale naar de lokale SDS-file om te worden meegenomen in de gekoppelde berekening. Omgekeerd moet COPPOS de berekende snelheden en debieten op zulke interfaces collecteren naar de globale SDS-file, onder anderen voor het restarten van DDHOR-berekeningen. De verfijningsinformatie is echter in COPPRE nog niet beschikbaar. Daarom wordt voor de strategie gekozen om altijd alle data op alle DDHOR-interfaces te distribueren, ongeacht of dit nodig is of niet. Ook in COPPOS is de verfijningsinformatie niet beschikbaar voordat er is begonnen met het collecteren. Daarom wordt ook hier gecollecteerd op alle DDHORinterfaces, ongeacht of deze bestaan uit discretisatie- of interpolatiepunten. Merk op dat DDHOR-interfaces bestaan uit u-punten of v-punten die liggen tussen een “echt” waterstandspunt (owner p > 0) en een interpolatie waterstandspunt (owner p = −1). Voor het distribueren en collecteren inclusief alle DDHOR-interfaces moet er onderscheid worden gemaakt tussen informatie in waterstands-, u/v-snelheids- en dieptepunten. Een complicatie bij het uitwerken van de strategie is dat in COPPOS de ruimtelijke samenhang van index sets niet meer beschikbaar is. Het is niet mogelijk om bij een index i met bepaalde coördinaten (m, n) en owner p = −1 te vragen of deze naast een intern waterstandspunt ligt ((m + 1, n) met p > 0). Neem bijvoorbeeld index i = 1 uit de index set “NBARU” (barrierpunten). In COPPOS heb je niet meer beschikbaar wat hier de (m, n)-coördinaten van zijn. Daarom moet COPPRE alle ownershipstabellen opslaan die COPPOS nodig gaat hebben. Een moeilijkheid daarbij is dat de ownerships nu alleen worden opgeslagen voor MNMAXK; alle andere index sets (MAPS) worden ofwel zonder guard band gedistribueerd, ofwel met een “second administration” waarbij de guard band eenvoudig is te negeren. Uiteindelijk is daarom de restrictie ingebouwd dat er alleen voor MNMAXK meerdere ownerships naast elkaar gebruikt mogen worden.

10.10

Voorzieningen voor gedeeltelijk tijdsafhankelijke arrays

Er bestaan binnen SIMONA compound arrays die gedeeltelijk tijdsafhankelijk zijn (met name COEFF OBS). De SIMONA standaard staat dit ook toe, maar de oudere versies van COPPRE konden er niet mee overweg: een compound werd geacht om ofwel geheel tijdsafhankelijk te zijn ofwel geheel tijdsonafhankelijk. De SIMONA tools bieden helaas niet de mogelijkheid om voor een compound op te vragen of deze al dan niet tijdsafhankelijk is weggeschreven. Hierdoor is COPPRE niet in staat het verschil te herkennen tussen een compound die in zijn geheel tijdsafhankelijk is of een compound die slecths alleen tijdsafhankelijke arrays bevat. Dit heeft als gevolg dat het niet mogelijk is om het aangeven van tijdsafhankelijkheid los te laten in de LDS-beschrijvingsfile (coplds.waqua). Er is gekozen voor de volgende aanpak: • compounds waarvoor in de LDS-beschrijvingsfile is aangegeven dat deze tijdsafhankelijk


10-14

zijn worden zoals voorheen in het geheel behandeld voor elke tijdseenheid, • compounds waarvoor in de LDS-beschrijvingsfile is aangegeven dat deze tijdsonafhankelijk zijn worden door COPPRE verder geanalyseerd. De compound zelf wordt als tijdsonafhankelijk weggeschreven en alle eventueel aanwezige tijdsafhankelijke arrays worden daarna stuk voor stuk behandeld. Dit punt heeft niet zozeer te maken met domeindecompositie. Het is een meer algemeen gebrek in de oudere versies van COPPRE, dat bij het realiseren van domeindecompositie is verholpen.


11-1

Hoofdstuk 11 Detail ontwerp aanpassingen COPPOS 11.1

Inleiding

De collector COPPOS is tot op zekere hoogte de inverse van partitioner COPPRE. Zijn belangrijkste functie is om simulatieresultaten van subdomein SDS-files te kopiëren naar de globale SDS-file. In geval van DDVERT wordt hierbij vertikale interpolatie toegepast. Alle simulatieresultaten worden daarbij vertaald naar de fijnste gebruikte vertikale resolutie. In DDHOR-berekeningen is COPPOS tenslotte nodig om de door COPPRE toegevoegde extra guardbandruimte te verwijderen, en om de ongebruikte delen van het globale rooster te vullen met herkenbare waardes. De uitbreidingen van COPPOS ten behoeve van domein decompositie zijn als volgt: • Bij vertikale verfijning interpoleert COPPOS alle resultaten naar een rooster waarin het aantal lagen gelijk is aan het maximaal in de run gebruikte aantal. Dit is uitvoerig beschreven in het detailontwerp voor vertikale verfijning [11] en zal hier niet verder beschreven worden. • COPPOS zal op een beperkt aantal deeldomeinen werken. Afgezien van de initiële toestand zullen resultaat-arrays op nul worden gezet voor ongebruikte punten. • In de conversietabellen waarmee gecollecteerd wordt kunnen ook nullen voorkomen als gevolg van het toevoegen van de guardband door COPPRE. COPPOS moet hier goed mee omgaan. • COPPOS maakt onderscheid tussen de verschillende soorten indexsets (s/u/v/d). • COPPOS moet aan de uiteindelijke resultaat file een aantal arrays toevoegen waaraan de gebruiker kan zien tot welk deeldomein punten behoord hebben (en waarin ongebruikte punten met −1 worden gemarkeerd) en waar de subdomein randen precies gelegen hebben.


11-2

• In ongebruikte gebieden worden schotjes geplaatst: de arrays khu en khv worden gekopiëerd uit de initiële toestand en in ongebruikte punten wordt de waarde +kmax vervangen door -kmax. Deze aspecten zullen in de volgende paragrafen achtereenvolgens aan de orde komen.

11.2

Beperkt aantal deeldomeinen

In de standaardversie van COPPOS wordt de eerste tijdsinstantie van een array niet gecollecteerd, omdat dit de initiële toestand is en al door WAQPRE is aangemaakt. Arrays die wel gecollecteerd worden, worden op nul ge¨ınitialiseerd, en blijven dus op nul staan in punten die niet tot de gebruikte deeldomeinen behoren.

11.3

Nullen in de conversie tabellen

COPPOS maakt gebruik van dezelfde routines (cog1sb en cog1sc) als COPPRE voor het daadwerkelijk overzetten van waardes uit de deeldomeinen naar het globale domein en vice versa. Voor COPPRE is cog1sc al beveiligd tegen het voorkomen van nullen in de conversie tabellen (die de relatie leggen tussen deeldomein punten en globale punten). Deze aanpassing is ook nodig voor COPPOS.

11.4

Verschillende ownerships voor s/u/v/d-punten

In oudere versies van WAQUA/TRIWAQ met domein decompositie werd in COPPOS het eigendom van de array-elementen van de verschillende data-structuren opgehangen aan een enkele opdeling (eigendom) van overkoepelende abstracte (m, n)-coördinaten. Bij horizontale verfijning komt het echter voor dat een u-snelheidspunt (m, n) tot een ander subdomein behoort dan het waterstandspunt met dezelfde array-index. Dit is mogelijk doordat de interface tussen domeinen aan het fijnste domein wordt toegekend. In het project DDH+V is dat ook in DDVERT ingevoerd. COPPOS is hierop aangepast om te voorkomen dat problemen ontstaan met het restarten van DDHOR-berekeningen en met het gebruik van speciale constructies (cross-sections) op interfaces tussen DDHOR-domeinen. In de LDS-beschrijving kan worden aangegeven over wat voor soort punten (s/u/v/d) een index-set gaat. Met deze uitbreiding zijn verschillende index-sets MNMAXK S, MNMAXK U e.d. gedefiniëerd met ieder een eigen ownership.


11.5

Toevoegen extra informatie

11.5.1

Toevoegen POWNER array

11-3

Na afloop van een simulatie wil men kunnen zien welke punten van het domein niet meegedaan hebben tijdens de simulatie (omdat ze tot ongebruikte deeldomeinen behoorden). Daarom voegt COPPOS aan de gecollecteerde SDS-file een array POWNER toe met dezelfde betekenis als de array POWNER die door COPPRE aan de deeldomein SDS-files wordt toegevoegd: landpunten hebben waarde 0, ongebruikte punten hebben waarde −1 en de overige punten hebben als waarde het nummer van het deeldomein waar ze toe behoren.

11.5.2

Toevoegen verfijningsinformatie

Om goed te kunnen zien welke soorten koppeling in de diverse randpunten gebruikt zijn tijdens de berekening, is het nuttig als men na afloop kan zien welke subdomein randcodes er zijn gebruikt (array ISBBOU) en wat de effectieve IROGEO is die gebruikt is. Deze informatie wordt toegevoegd aan de SDS-file.

11.6

Aanpassen arrays khu en khv

Het aanpassen van arrays khu en khv gebeurt om ongebruikte punten als tijdelijk droog te markeren. Hierdoor zal visualisatie programmatuur deze punten niet in beeld brengen. Het is niet mogelijk om de punten permanent droog te maken, want dan zou het onmogelijk worden om een restart uit te voeren omdat de geometrie van het domein gewijzigd is.


11-4

Referenties [1] B. van ’t Hof. Testrapport domein decompositie met vertikale verfijning. Technical Report TR99-11, VORtech, Postbus 260, 2600 AG Delft, Juli 1999. In opdracht van RIKZ. [2] B. van ’t Hof. Detailontwerp prototype domein-decompositie met horizontale verfijning voor WAQUA en TRIWAQ. Technical Report TR00-02, VORtech, Postbus 260, 2600 AG Delft, januari 2000. In opdracht van RIKZ. [3] B. van ’t Hof. Test report for the domain decomposition prototype with horizontal grid refinement for WAQUA and TRIWAQ. Technical Report TR00-04, VORtech, P.O. box 260, 2600 AG Delft, The Netherlands, juli 2000. By order of RIKZ. [4] L.M. Riemens, H.H. ten Cate, B. van ’t Hof, and M.R.T. Roest. Domain decomposition with vertical refinement in TRIWAQ. In Proceedings of the 4th International Hydroinformatics Conference, 2000. cd-rom. [5] Rijkswaterstaat/RIKZ. Quick Reference Guide WAQUA, 2002. SIMONA report number 92-10. [6] M.R.T. Roest, E.A.H. Vollebregt, and B. van ’t Hof. Cursusboek module 1, introductie domein decompositie en parallel rekenen in SIMONA. In Cursus “Domein decompositie en parallel rekenen in SIMONA”. VORtech, Oktober 2002. [7] M.R.T. Roest, E.A.H. Vollebregt, and B. van ’t Hof. Cursusboek module 3, programmeren aan parallel WAQUA en TRIWAQ. In Cursus “Domein decompositie en parallel rekenen in SIMONA”. VORtech, Oktober 2002. [8] B. van ’t Hof and E.A.H. Vollebregt. Detailontwerp uniformering WAQUA/TRIWAQ. Technical Report TR06-05, VORtech, Postbus 260, 2600 AG Delft, juli 2006. [9] B. van ’t Hof, E.A.H. Vollebregt, and M.J.A. Borsboom. Vooronderzoek domein decompositie met tijdstapkoppeling in WAQUA/TRIWAQ. Technical Report TR05-05, VORtech, Postbus 260, 2600 AG Delft, August 2005. [10] E.A.H. Vollebregt. Parallellisatie van het horizontaal k − turbulentie model. Technical Report TR01-10, VORtech, Postbus 260, 2600 AG Delft, April 2001. In opdracht van RIKZ.


11-5

[11] E.A.H. Vollebregt, B. van ’t Hof, and M.R.T. Roest. Ontwerp van de DDVERT functionaliteit in de standaardversie van WAQUA/TRIWAQ. Technical Report TR01-02, VORtech, Postbus 260, 2600 AG Delft, Januari 2001. In opdracht van RIKZ. [12] E.A.H. Vollebregt, M.R.T. Roest, and B. van ’t Hof. User’s Guide for Parallel WAQUA/TRIWAQ and for Domain Decomposition. VORtech, November 2001. SIMONA report number 2000-01.


A-1

Bijlage A Data-analyse van TRIWAQ A.1

Data requirements complete time-step

FIRST HALF OF TIME-STEP : WASSFF Set flow forcings, first half step. in :

kfup, up, hu, zkup, czu for own-up, sep, zksp, rp for own-wlp, kfvp, vp, hv, zkvp, czv for own-vp, sep for stencsu ⊗ own-u-barriers, sep for stencsv ⊗ own-v-barriers

out :

cirbou for own-open-bnd-wlp, pres, windu, windv for mnmaxk, dischc for own-sources, barcuv for own-barriers

WASSTF Set transport forcings, first half step. out :

rbndc for own-open-bnd-wlp, dischc, sintc for own-sources, zwnd

WASTHF If non-hydrostatic computations are used: copy positions of layer-interfaces to additional array for use in washdy. in : out :

zksp for own-int-wlp zkso for own-int-wlp

WAGDEN Calculation of densities rho for FLOW-computations. in : out :

rpsal , rptemp for own-wlp ∪ guardbox1 rho for own-wlp ∪ guardbox1

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) WASCSC Compute correction on Chezy values due to local salinity gradients in :

out :

kfup, up for stencuv ⊗ own-vp, hu, czu for own-up, kfvp, vp for stencvu ⊗ own-up, hv, czv for own-vp, rho for own-wlp ∪ guardbox1 cczu for own-up, cczv for own-vp

WASUXC Solve momentum equation for vh. in :

out :

kfvp, vp for own-vp ∪ guard2ξ∪1η , hv, cczv for own-vp, windv for own-int-vp, up for stencuv ⊗ own-vp, kfup for stenc2uv ⊗ own-vp, sep for all-wlp-ydir, pres, rho for all-int-wlp-ydir, lgvbar for all-v-barriers, cbuv, sill, gate for own-v-barriers, kfup, lgubar for all-u-barriers, bavela, bavelb, kcond for all-barriers vh for own-vp ∪ guardmax , vp, bavela, bavelb, barq for all-v-barriers

WASSUC Solve coupled continuity and momentum equations for seh and uh. in :

out :

up, kfup for own-up ∪ guard1ξ∪2η , cczu, windu for own-up, vh for stencvu ⊗ own-up, kfvp for stenc2vu ⊗ own-up, qy for all-vp, sep for all-wlp, pres, rho for all-int-wlp-xdir, dischf for own-sources, cirbou for own-open-bnd-wlp-xdir, lgubar for all-u-barriers, barcuv for own-u-barriers, kcond, bavela, bavelb for all-barriers seh for own-wlp ∪ guard1 or guardbox1 , hu for all-up, kfuh, uh for own-up ∪ guardmax , qx for own-up ∪ guarduv , kfvh, vh for own-vp ∪ guardmax , qy for own-vp ∪ guardvu , lgubar, kcond, cbuv, bavela, bavelb, barq for all-u-barriers, basepa, basepb for own-barriers

TRSVIZ Calculate vertical eddy-viscosity coefficients. in : out :

kfup, up, cmanu, windu for all-up, zksp, rho, rturp for all-wlp, kfvp, vp, cmanv, windv for all-vp vicow for own-wlp, z0wl, cfrowl, rich for own-int-wlp

TRSVIC Adapt vertical eddy-viscosity coefficients. in : out :

vicow, vicowg for own-wlp vicow for own-wlp

A-2


A-3

TRSV2D If horizontal turbulence model is used: compute horizontal eddy viscosity coefficients in : out :

tur2d for own-dp vnu2d for own-dp

TRSCWI If wphysi is needed and non-hydrostatic computation is not used or not started yet: Compute the physical vertical velocity component wphysi at layer-interfaces. in : out :

zkup, up for all-up, zkvp, vp for all-vp, w for own-int-wlp, dischf for own-sources wphysi for own-int-wlp

TRSCUE Calculation of vh for own-vp and communication for stenc1 ⊗ 1 . in :

out :

vp for own-vp ∪ guard1 , kfvp for own-vp ∪ guard2 , zkvp, czv, dqdy for own-vp, windv for own-int-vp, up for stencuv ⊗ own-vp, kfup for stenc2uv ⊗ own-vp, sep, zksp for all-wlp-ydir, vicow for own-wlp, rho, pres for all-int-wlp-ydir, w for own-int-wlp, if (lcnsrv): qyk for own-vp ∪ guard1η , qxk for stencuv ⊗ own-vp, if (lbot3d or lfulry): wphysi for own-wlp, if (lbot3d): zksp for stenc1ξ ⊗ stencsv ⊗ own-vp, if (lhortu): vnu2d for own-dp vh for own-vp ∪ guard1 ⊗ 1 , kfbv for own-vp ∪ guardmax , w for own-int-wlp ∪ guard1 , vicow for all-wlp, if (lbot3d or lfulry or lhortu): vicow for own-wlp ∪ guardbox1 , if (lbot3d or lfulry): wphysi for own-wlp ∪ guard2 , if (lhortu): vnu2d for own-dp ∪ guard1ds

TRSSUW Calculate waterlevels, layer interfaces, and flow-velocities and discharges in x(uh, qxk) and z-directions (w, qzk) in :

sep for all-wlp, zksp, vicow for all-wlp-xdir, kfup, zkup for all-up, up for own-up ∪ guard1 , czu for own-up, windu for own-int-up, zkvp, qyk for all-vp, kfvp, vh for stencvu ⊗ own-up, w, rho, pres for all-int-wlp-xdir, cirbou for own-bnd-wlp-xdir, if (lhortu): vnu2d for own-dp ∪ guard1ds , vicow for own-wlp ∪ guardbox1 , if (lbot3d): zksp for own-wlp ∪ guardbox1 , if (lcnsrv): qxk for own-up ∪ guard1ξ , qyk for stencvu ⊗ own-up

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) out :

seh for all-wlp, zksh for own-wlp ∪ guardbox1 , w, qzk for all-int-wlp, uh for own-up ∪ guardbox1 , zkuh for all-up, kfuh for own-up ∪ guardmax , vh for own-vp ∪ guardbox1 , zkvh for all-vp, kfvh for own-vp ∪ guardmax , kfbu for own-up ∪ guard1 ⊗ 1 , if (lcnsrv): qxk for own-up ∪ guardbox1 , qyk for own-vp ∪ guardbox1 , else: qxk for stencuv ⊗ own-vp, qyk for stencvu ⊗ own-up

WASKNU Compute “k-Nikuradse-at-U” values for own u-areas. in : out :

hu (WAQUA) or zkuh (TRIWAQ) for own-up cmanu for own-up

WASCVU Compute Chezy-at-U values. in :

WAQUA: kfuh, hu, cmanu for own-up, seh for all-wlp-xdir, TRIWAQ: kfuh, uh, zkuh, cmanu for own-up, vh for stencvu ⊗ own-up

in :

uh for own-u-weirs ⊗ stenc1ξ , qx, hu or zkuh, czu for own-u-weirs, vh, qy for stencvu ⊗ own-u-weirs, seh for stenc+1ξ ⊗ 1η ⊗ own-u-weirs

out :

czu for own-up, K=1 & transport: czu for all-up, ustbu for own-up (in TRIWAQ in case of Z0 -based computation)

WASCHF Compute histories flow. in : out :

uh for all-up, hu for own-up, seh for own-wlp vh for all-vp, hv for own-vp TIMEHISTORIES FLOW

WASDFC Solve transport equation for rp. in :

out :

rp for own-wlp ∪ guard2ξ∪1η , sep, seh for all-wlp-xdir, kfuh for all-up ∪ guard1ξ , uh, hu, czu for all-wet-up, kfvh, hv, qy, czv for all-wet-vp, zwnd, dischc, sintc for own-sources, gsour, gsink for own-int-wlp, nfli, dfl, rbndc for own-bnd-wlp-xdir rp for own-wlp ∪ guardmax , nfli, dfl for own-bnd-wlp-xdir

TRSMFD Calculate mass-flux at discharge sources in : out :

sintc, dischc for own-sources fluxc for own-sources

A-4

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) TRSDIZ Calculate vertical diffusivity coefficients. in : out :

rich, vicow for own-int-fldbl-wlp difcw for own-int-fldbl-wlp

TRSD2D Calculate the effective horizontal diffusivity coefficients. in : out :

difco for all-wlp, difcw for own-int-wlp, vnu2d for all-dp ∪ guard1 difeff for all-wlp

TRSDIF Compute 3D mass transport: new concentration values c0l . in :

out :

rp for own-wlp-xdir ∪ guard3ξ∪1η , zksh for all-wlp-xdir, zksp for all-wlp, qzk, difcw for own-int-fldbl-wlp, kfuh, kfbu for own-up ∪ guardus ⊗ 2ξ , zkuh, qxk for all-wet-up, kfvh, kfbv for own-vp ∪ guardvs ⊗ 1η , zkvp, qyk for all-wet-vp, K=1: czu for all-wet-up, czv for all-wet-vp, gsour, gsink for own-wlp-xdir, dischc, fluxc for own-sources, rbndc, dfl, nfli for own-bnd-wlp-xdir, zks full for own-wlp-xdir ∪ guard3 rp for own-wlp-xdir ∪ guard3 , zksp, zksh for all-bnd-wlp-xdir

WAGDEN Calculation of densities rho for k − model. in : out :

rpsal , rptemp for own-wlp rho for own-wlp

TRSTUR Compute turbulent energy and dissipation k 0 , 0 in : out :

rturp, zks full for all-wlp, kfuh, uh for all-up, kfvh, vh for all-vp, zksh, w, rho, vicow, windu, windv, cfrowl, z0wl for own-int-wet-wlp rturh for all-wlp

TRSHKE Compute horizontal turbulent energy and dissipation tur2d0 in :

out :

kfuh for own-up ∪ guardbox1 , umean for own-up, kfvh for own-vp ∪ guardbox1 , vmean for own-vp, seh for own-wlp ∪ guardbox1 , tur2d for own-dp, vnu2d for own-dp ∪ guard1 , umean for own-up ∪ guardbox1 , vmean for own-vp ∪ guardbox1 , tur2d for own-dp,

A-5


A-6

WASCHT Compute histories transport. in : in : out :

WAQUA: uh, hu for own-up, vh, hv for own-vp TRIWAQ: up, zkup for own-up, rturh for all-wlp, vp, zkvp for own-vp kfuh, czu for own-up, rp for all-wlp, kfvh, czv for own-vp TIMEHISTORIES TRANS

FOUT: Eigenlijk zouden voor TRIWAQ uh, vh, zkuh en zkvh gebruikt moeten worden, maar dat wordt niet gedaan. SECOND HALF OF TIME-STEP : WASSFF Set flow forcings, second half step. in :

kfuh, uh, hu, zkuh, czu for own-up, seh, zksh, rp for own-wlp, kfvh, vh, hv, zkvh, czv for own-vp, seh for stencsu ⊗ own-u-barriers, seh for stencsv ⊗ own-v-barriers

out :


WASSTF Set transport forcings, second half step. out :

rbndc for own-open-bnd-wlp, dischc, sintc for own-sources, zwnd

WAGDEN Calculation of densities rho for FLOW-computation. in : out :

rpsal , rptemp for own-wlp ∪ guardbox1 rho for own-wlp ∪ guardbox1

WASCSC Compute correction on Chezy values due to local salinity gradients in :

out :

kfuh, uh for stencuv ⊗ own-vp, hu, czu for own-up, kfvh, vh for stencvu ⊗ own-up, hv, czv for own-vp, rho for own-wlp ∪ guardbox1 cczu for own-up, cczv for own-vp


A-7

WASUXC Solve momentum equation for up. in :

out :

kfuh, uh for own-up ∪ guard1ξ∪2η , hu, cczu for own-up, windu for own-int-up, vh for stencvu ⊗ own-up, kfvh for stenc2vu ⊗ own-up, seh for all-wlp-xdir, pres, rho for all-int-wlp-xdir, lgubar for all-u-barriers, cbuv, sill, gate for own-u-barriers, kfvh, lgvbar for all-v-barriers, bavela, bavelb, kcond for all-barriers up for own-up ∪ guardmax , uh, bavela, bavelb, barq for all-u-barriers

WASSUC Solve coupled continuity and momentum equations for sep and vp. in :

out :

vh, kfvh for own-vp ∪ guard2ξ∪1η , cczv, windv for own-vp, up for stencuv ⊗ own-vp, kfuh for stenc2uv ⊗ own-vp, qx for all-up, seh for all-wlp, pres, rho for all-int-wlp-ydir, dischf for own-sources, cirbou for own-open-bnd-wlp-ydir, lgvbar for all-v-barriers, barcuv for own-v-barriers, kcond, bavela, bavelb for all-barriers sep for own-wlp ∪ guard1 or guardbox1 , hv for all-vp, kfvp, vp for own-vp ∪ guardmax , qy for own-vp ∪ guardvu , kfup, up for own-up ∪ guardmax , qx for own-up ∪ guarduv , lgvbar, kcond, cbuv, bavela, bavelb, barq for all-v-barriers, basepa, basepb for own-barriers

TRSVIZ Calculate vertical eddy-viscosity coefficients. in : out :

kfuh, uh, cmanu, windu for all-up, zksh, rho, rturh for all-wlp, kfvh, vh, cmanv, windv for all-vp vicow for own-wlp, z0wl, cfrowl, rich for own-int-wlp

TRSVIC Adapt vertical eddy-viscosity coefficients. in : out :

vicow, vicowg for own-wlp vicow for own-wlp

TRSV2D If horizontal turbulence model is used: compute horizontal eddy viscosity coefficients in : out :

tur2d for own-dp vnu2d for own-dp


A-8

TRSCWI If wphysi is needed and non-hydrostatic computation is not used or not started yet: Compute the physical vertical velocity component wphysi at layer-interfaces. in : out :

zkuh, uh for all-up, zkvh, vh for all-vp, w for own-int-wlp, dischf for own-sources wphysi for own-int-wlp

TRSCUE Calculation of up for own-up and communication for stenc1 ⊗ 1 . in :

out :

uh for own-up ∪ guard1 , kfuh for own-up ∪ guard2 , zkuh, czu, dqdx for own-up, windu for own-int-up, vh for stencvu ⊗ own-up, kfvh for stenc2vu ⊗ own-up, seh, zksh for all-wlp-xdir, vicow for own-wlp, rho, pres for all-int-wlp-xdir, w for own-int-wlp, if (lcnsrv): qxk for own-up ∪ guard1ξ , qyk for stencvu ⊗ own-up, if (lbot3d or lfulry): wphysi for own-wlp, if (lbot3d): zksh for stenc1η ⊗ stencsu ⊗ own-up, if (lhortu): vnu2d for own-dp up for own-up ∪ guard1 ⊗ 1 , kfbu for own-up ∪ guardmax , w for own-int-wlp ∪ guard1 , vicow for all-wlp, if (lbot3d or lfulry or lhortu): vicow for own-wlp ∪ guardbox1 , if (lbot3d or lfulry): wphysi for own-wlp ∪ guard2 , if (lhortu): vnu2d for own-dp ∪ guard1ds

TRSSUW Calculate waterlevels, layer interfaces, and flow-velocities and discharges in y(vp, qyk) and z-directions (w, qzk) in :

seh for all-wlp, zksh, vicow for all-wlp-ydir, kfvh, zkvh for all-vp, vh for own-vp ∪ guard1 , czv for own-vp, windv for own-int-vp, zkuh, qxk for all-up, kfuh, up for stencuv ⊗ own-vp, w, rho, pres for all-int-wlp-ydir, cirbou for own-bnd-wlp-ydir, if (lhortu): vnu2d for own-dp ∪ guard1ds , vicow for own-wlp ∪ guardbox1 , if (lbot3d): zksh for own-wlp ∪ guardbox1 , if (lcnsrv): qyk for own-vp ∪ guard1η , qxk for stencuv ⊗ own-vp

out :

sep for all-wlp, zksp for own-wlp ∪ guardbox1 , w, qzk for all-int-wlp, vp for own-vp ∪ guardbox1 , zkvp for all-vp, kfvp for own-vp ∪ guardmax , up for own-up ∪ guardbox1 , zkup for all-up, kfup for own-up ∪ guardmax , kfbv for own-vp ∪ guard1 ⊗ 1 , if (lcnsrv): qyk for own-vp ∪ guardbox1 , qxk for own-up ∪ guardbox1 , else: qyk for stencvu ⊗ own-up, qxk for stencuv ⊗ own-vp


A-9

WASHDY Perform timestep with respect to non-hydrostatic flow. in :

w, dqdz, zkso for own-int-wlp, wphysi for own-wlp ∪ guard2 , zksp, vicow, q, dq for all-wlp, zkup, up, qxk for all-up, zkvp, vp, qyk for all-vp

out :

wphysi, q, dq for all-wlp, w, qzk, dqdz for own-int-wlp, up for all-up, dqdx for own-up, qxk for own-up ∪ guardbox1 , vp for all-vp, dqdy for own-vp, qyk for own-vp ∪ guardbox1

WASKNV Compute “k-Nikuradse-at-V” values for own areas. in : out :

hv (WAQUA) or zkvp (TRIWAQ) for own-vp cmanv for own-vp

WASCVV Compute Chezy-at-V values. in :

WAQUA: kfvp, hv, cmanv for own-vp, sep for all-wlp-ydir, TRIWAQ: kfvp, vp, zkvp, cmanv for own-vp, up for stencuv ⊗ own-vp

in :

vp for own-v-weirs ⊗ stenc1η , qy, hv or zkvp, czv for own-v-weirs, up, qx for stencuv ⊗ own-v-weirs, sep for stenc1ξ ⊗ +1η ⊗ own-v-weirs

out :

czv, ustbv for own-vp (latter in TRIWAQ in case of Z0 -based computation)

WASCHF Compute histories flow. in : out :

up for all-up, hu for own-up, sep for own-wlp vp for all-vp, hv for own-vp TIMEHISTORIES FLOW

WASDFC Solve transport equation for rp. in :

out :

rp for own-wlp ∪ guard1ξ∪2η , seh, sep for all-wlp-ydir, kfvp for all-vp ∪ guard1η , vp, hv, czv for all-wet-vp, kfup, hu, qx, czu for all-wet-up, zwnd, dischc, sintc for own-sources, gsour, gsink for own-int-wlp, nfli, dfl, rbndc for own-bnd-wlp-ydir rp for own-wlp ∪ guardmax , nfli, dfl for own-bnd-wlp-ydir

TRSMFD Calculate mass-flux at discharge sources in : out :

sintc, dischc for own-sources fluxc for own-sources


A-10

TRSDIZ Calculate vertical diffusivity coefficients. in : out :

rich, vicow for own-int-fldbl-wlp difcw for own-int-fldbl-wlp

TRSD2D Calculate the effective horizontal diffusivity coefficients. in : out :

difco for all-wlp, difcw for own-int-wlp, vnu2d for all-dp ∪ guard1 difeff for all-wlp

TRSDIF Compute 3D mass transport: new concentration values c00l . in :

out :

rp for own-wlp-ydir ∪ guard1ξ∪3η , zksp for all-wlp-ydir, zksh for all-wlp, qzk, difcw for own-int-fldbl-wlp, kfvp, kfbv for own-vp ∪ guardvs ⊗ 2η , zkvp, qyk for all-wet-vp, kfup, kfbu for own-up ∪ guardus ⊗ 1ξ , zkuh, qxk for all-wet-up, K=1: czu for all-wet-up, czv for all-wet-vp, gsour, gsink for own-wlp-ydir, dischc, fluxc for own-sources, rbndc, dfl, nfli for own-bnd-wlp-ydir, zks full for own-wlp-ydir ∪ guard3 rp for own-wlp-ydir ∪ guard3 , zksh, zksp for all-bnd-wlp-ydir

WAGDEN Calculation of densities rho for k − model. in : out :

rpsal , rptemp for own-wlp rho for own-wlp

TRSTUR Compute turbulent energy and dissipation k 00 , 00 in : out :

rturh, zks full for all-wlp, kfup, up for all-up, kfvp, vp for all-vp, zksp, w, rho, vicow, windu, windv, cfrowl, z0wl for own-int-wet-wlp rturp for all-wlp

TRSHKE Compute horizontal turbulent energy and dissipation tur2d00 in :

out :

kfup for own-up ∪ guardbox1 , umean for own-up, kfvp for own-vp ∪ guardbox1 , vmean for own-vp, sep for own-wlp ∪ guardbox1 , tur2d for own-dp, vnu2d for own-dp ∪ guard1 , umean for own-up ∪ guardbox1 , vmean for own-vp ∪ guardbox1 , tur2d for own-dp,

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) WASCHT Compute histories transport. in : in : out :

WAQUA: hu for own-up, hv for own-vp TRIWAQ: zkup for own-up, rturp for all-wlp, zkvp for own-vp kfup, up, czu for own-up, rp for all-wlp, kfvp, vp, czv for own-vp TIMEHISTORIES TRANS

WASBTI Build right-hand side of system for harmonic analysis of tides in : out :

... ...

OUTPUT OF COMPUTED RESULTS : WASMAF Write flow map data to SDS-file. in :

SOLUTION FLOW, SOLUTION DRYWET

WASHIF Write flow history data to SDS-file. in :

TIMEHISTORIES FLOW

WASRSF Write flow restart data to SDS-file. in :

RESTART FLOW

WASMAT Write transport map data to SDS-file. in :

SOLUTION TRANS, SOLUTION STRESS, SOLUTION USER TRANS

WASHIT Write transport history data to SDS-file. in :

TIMEHISTORIES TRANS, TIMEHISTORIES STRESS, TIMEHISTORIES USER TRANS

WASRST Write transport restart data to SDS-file. in :

RESTART TRANS, RESTART STRESS

WASPBF output to bulk print file. in :

TIMEHISTORIES-arrays, SOLUTION-arrays, basepa, basepb, bavela, bavelb, barq for own-barriers, up for stencuv ⊗ own-vp, vp for stencvu ⊗ own-up

A-11


A.2 A.2.1

A-12

WASSIM-FLOW: Subroutine WASSFF Subroutine WASSFF

Goal: Compute forcings for calculation of FLOW in the first or second half timestep. The description below is for the start of first half timesteps. in :

khup, up, hu, zkup, czu for own-up, sep, zksp, rp for own-wlp, khvp, vp, hv, zkvp, czv for own-vp, sep for stencsu ⊗ own-u-barriers, sep for stencsv ⊗ own-v-barriers

out :


Note: opening points are partitioned in such a way that velocity points next to QH- and QAD-openings belong to the same subdomain as the opening points themselves. Algorithm: First the new values at openings are calculated: WASSOV (series openings), WASFOV (Fourier openings), WASFQH (QH-openings. WASSOV and WASFOV manipulate only local values (time-series and Fourier data for opening points in their own subdomain), resulting in opcv in the corresponding opening points. Subroutine WASFQH computes the discharge along a complete opening and uses this to determine the new waterlevel at the opening. To obtain the complete discharge requires communication between different processors that own parts of the opening. This is implemented using global communication routine COCRGL with process group haveqh owndomain. This group consists of all processes per global domain that hold at least one (part of a) QH-opening. in : out :

up, hu for stencus ⊗ own-qh-points, vp, hv for stencvs ⊗ own-qh-points opcv for own-qh-points

Then discharges may be automatically distributed along the points of an opening by WASFQA. Subroutine WASFQA computes the total weight along each complete QAD-opening and uses this to redistribute the prescribed discharge over the separate opening points. The implementation of this is similar to that of WASFQH. The process group that is used is haveqad owndomain. in : out :

khup, hu, czu for stencus ⊗ own-qad-points, opcv for own-qad-points khvp, hv, czv for stencvs ⊗ own-qad-points opcv for own-qad-points

Subroutines WASFQH and WASFQA are available in WAQUA only. Opening values may be smoothed w.r.t. an initial value by subroutine WASSMO, using array opsmva for opening points. Then the opening values in opcv are put at their final


A-13

destination in array cirbou by subroutine WASFDO. in : out :

opcv for own-opening-points cirbou for own-open-bnd-wlp

Then WASSFF uses subroutines WASSGW and WASGWS to compute global wind values and wind stresses. in : out :

cdv1, cdv2 for mnmaxk windu, windv, cd for mnmaxk

Note that WASGWS does not distinguish between waterlevel and velocity locations (i.e. no staggering and de-staggering are performed). WASSDR computes the new values for discharge rates at source points. out :

dischc for own-sources

Subroutine WASVWP performs all actions needed for space-varying wind and pressure. out :

windu, windv, pres for mnmaxk

WASWLC may adjust the waterlevels at opening points in cirbou for effects of atmospheric pressure variations (the inverse barometer correction). in : out :

pres, cirbou for own-wl-bnd-wlp cirbou

Finally WAGDEN is used to compute actual water densities and then WASCBA derives the new values for barriers (using the dynamic barrier steering mechanism). in :

out :

A.2.2

up, hu (WAQUA), zkup (TRIWAQ) for own-u-crosssec, vp, hv (WAQUA), zkvp (TRIWAQ) for own-v-crosssec, sep, deppnt (WAQUA), zksp (TRIWAQ), rp, rho for own-checkp, sep for stencsu ⊗ own-u-barriers, sep for stencsv ⊗ own-v-barriers barcuv for own-barriers

Subroutine WASCBA

Goal: Calculate new dimensions of barriers, possibly dependent on actual flow situation (dynamic barrier steering mechanism). in :

out :

up, hu (WAQUA), zkup (TRIWAQ) for own-u-crosssec, vp, hv (WAQUA), zkvp (TRIWAQ) for own-v-crosssec, sep, deppnt (WAQUA), zksp (TRIWAQ), rp, rho for own-checkp, sep for stencsu ⊗ own-u-barriers, sep for stencsv ⊗ own-v-barriers barcuv for own-barriers


A-14

Algorithm: First all values needed for condition evaluation are determined. For this the array rlftvl is used for all rows of the condition-table (ncnrow). The evaluation of a single condition is done by WASEVA. The following values may be needed here for TRIWAQ: in :

up, hu (WAQUA), zkup (TRIWAQ) for own-u-crosssec, vp, hv (WAQUA), zkvp (TRIWAQ) for own-v-crosssec, sep, deppnt (WAQUA), zksp (TRIWAQ), rp, rho for own-checkp

Note: WAQUA and TRIWAQ use quite different formulas for evaluating the pressure difference between two points. Remarkable is that in the one case (WAQUA), the minimum depth of both points is used, whereas in TRIWAQ the pressures in both points require the local depth only. The values for all conditions are exchanged among all subdomains that are involved in dynamic barrier steering using global communication with process group havebar owndomain. Then all conditions are evaluated, and the required “actions” are performed: activation of time series or tables. Then all parameters that are required for addressing tables are computed using WASEVA and stored in array rparvl, and the average waterlevel along line barriers is determined using WASLVL and array rwork. In both cases global communication for havebar owndomain is used to exchange values among different subdomains of a global domain in which dynamic barrier steering is used. WASLVL uses the following data: in :

sep for stencsu ⊗ own-u-barriers, sep for stencsv ⊗ own-v-barriers

Finally the barrier-values are determined by either interpolating in time series or by tablelookup using a parameter. These calculations are performed by each subdomain for all barriers that partly lie in this subdomain. The preferred sill level, gate level and barrier width are restricted to take into account maximum velocities (WASCDB), and then put into array barcuv for use in the computational routines.


A.3

A-15

WASSPU-FLOW: Subroutine WASCSC

Goal: Calculate bottom friction parameters cczu and cczv which are corrected for local density gradients. in :

out :

khup, up for stencuv ⊗ own-vp, hu, czu for own-up, khvp, vp for stencvu ⊗ own-up, hv, czv for own-vp, rho for own-wlp ∪ guard1ξ ⊗ 1η cczu for own-up, cczv for own-vp

Note: the range for which khup must be communicated for this computation may be rewritten as follows. Index set own-vp can be as large as all-vp in case of the finer domain in a domain decomposition run. The latter set is equivalent to stencvs ⊗ own-int-wlp (i.e. v-points adjacent to wl-points). Therefore khup may be needed for stencuv ⊗ stencvs ⊗ own-int-wlp, that is, for guarduv ⊗ vs ≡ guard−1ξ ⊗ 1η w.r.t. wl-points of the own subdomain. A second way of rewriting is by noting that own-vp is contained in stencvu ⊗ own-up: all v-points of a subdomain are adjacent to at least one u-point of the same subdomain. This gives guarduv ⊗ vu ≡ guard1ξ ⊗ 1η w.r.t. u-points of the subdomain. Algorithm: Compute density gradient in ξ-direction drdxu in all u-points where it is needed for the correction of czv. loop own-vp modf. drdxu for stencuv using khup for stencuv , rho for stencsu ⊗ uv Note: the points where drdxu is needed are found by actually performing a loop over v-points and computing drdxu in the four surrounding points, reached by stencil stencuv . The composite stencil stencsu ⊗ uv can be read as all wl-points adjacent to u-points that are “adjacent” to v-points. Now v-points are again adjacent to an interior wl-point of the subdomain, such that rho must be communicated for guardsu ⊗ uv ⊗ vs ≡ guard1ξ ⊗ 1η . Compute density gradient in η-direction drdyv in all v-points where it is needed for the correction of czu. loop own-up modf. drdyv for stencvu using khvp for stencvu , rho for stencsv ⊗ vu Compute adjusted cczu in wet u-points which are not weir-points and in which the magnitude of the flow-velocity is larger than 1[mm/sec]. Set cczu = czu in other u-points. loop own-up modf. cczu using khup, up, hu, czu, drdxu for stenc0 , khvp, vp, drdyv for stencvu


A-16

Compute adjusted cczv in wet v-points which are not weir-points and in which the magnitude of the flow-velocity is larger than 1[mm/sec]. Set cczv = czv in other v-points. loop own-vp modf. cczv using khvp, vp, hv, czv, drdyv for stenc0 , khup, up, drdxu for stencuv


A.4

A-17

WASSPU-FLOW: Subroutine WASUXC

Goal: Discretize and solve momentum equations for vh (half timesteps) and up (full timesteps). kfuh, uh for own-up ∪ guard1ξ∪2η , hu, cczu for own-up, windu for own-int-up, vh for stencvu ⊗ own-up, kfvh for stenc2vu ⊗ own-up, seh for all-wlp-xdir, pres, rho for all-int-wlp-xdir, lgubar for all-u-barriers, cbuv, sill, gate for own-u-barriers, kfvh, lgvbar for all-v-barriers, bavela, bavelb, kcond for all-barriers

in :

up for own-up ∪ guardmax , uh, bavela, bavelb, barq for all-u-barriers

out :

Algorithm: Overwrite field-value of u at super-critical barriers. loop all-u-barriers modf. uh using lgubar, kcond, bavela, bavelb Set initial estimate for u-velocities at new time-level loop

own-up ∪ guard1ξ∪2η

modf. using

up[q=0] uh

Initialize v-velocities array vvelb (velocities just below the barrier) loop stencvu ⊗ own-up modf. vvelb using vh Adjust v-velocities and v-screens at super-critical barriers. loop all-v-barriers modf. kfvh, vh, vvelb using lgvbar, bavela, bavelb Note: the use of loops over all barriers might be avoided by updating uh, up, kfvh, vh for barrierpoints only, just as kfbu, kfbv are communicated for barrier points in TRIWAQ.


A-18

Compute water-depth at u-barriers (different values on both sides of super-critical barriers) loop own-u-barriers modf. hubar using lgubar, hu for stenc0 , seh for stencsu Update values modified at barriers out :

(COCUPD)

hubar for all-u-barriers

Start iterative procedure: q = 1, 2, . . . If (q > 1) : update up[q−1] out :

(COCUPD)

up[q−1] for own-up ∪ guard1ξ∪2η

Start loop over all rows: set up and solve a tri-diagonal system of equations. Set up boundary conditions for physical boundary points and for interface points loop all-bnd-up modf. aa, bb, cc, dd using for waterlevel boundaries: see data required for interior points Set up equations for interior points of the row, except for barriers, and using trivial equations for dry points. loop own-int-up modf. aa, bb, cc, dd using

kfuh for stenc1ξ∪2η , up[q] , up[q−1] for stenc±2η , uh, hu, cczu, windu, lgubar for stenc0 , seh for stencsu , kfvh for stenc2vu , vh, vvelb for stencvu

Add terms for spatially varying wind and pressure and for density gradients. loop own-int-up modf. dd using kfuh, hu, dd for stenc0 , pres, rho for stencsu

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) Set up equations for barrier points

A-19 (WASUBC)

loop own-u-barriers modf. aa, bb, cc, dd using lgubar, kcond, cbuv, sill, gate, data for interior points Adjust equations for points neighbouring to supercritical barriers loop own-int-up modf. cc, aa using lgubar, kcond, hubar for stenc1ξ Eliminate the block Jacobi equations for points mfd and mlu from the system of equations for the current row, in order to get a system for all-up (from mf to ml). loop guard1ξ w.r.t. u-points modf. dd using

up[q−1] for stenc0 , cc, dd for stenc±1ξ

Solve tri-diagonal system for current row loop

all-up

modf. using

up[q] aa, bb, cc, dd

End loop over all rows Check convergence

(WASCHK)

End iteration Update final approximation for up = up[q] out :

up for own-up ∪ guardmax

Compute new values for u-barriers, reset adjusted values for v-barriers loop all-u-barriers modf. up, bavela, bavelb, barq using up, kfuh, lgubar, kcond, hubar loop all-v-barriers modf. vh, kfvh using kfvh, lgvbar, kcond, bavela, bavelb Note that the modifications to uh at the start of this routine are not undone.

(COCUPD)


A.5

A-20

TRIWAQ-FLOW: Subroutine TRSVIZ

A.5.1

Subroutine TRSVIZ

Goal: Calculate new vertical viscosities vicow for the computation of flow using the algebraic turbulence model or using k, from the k − -turbulence model. The description below is given for the calculation at the start of half time-steps. in : out :

kfuh, up, cmanu, windu for all-up, zksp, rho, rturp for all-wlp, kfvh, vp, cmanv, windv for all-vp vicow for own-wlp, z0wl, cfrowl, rich for own-int-wlp

The vertical viscosities calculated at the start of the first half of a timestep are used in TRSCUE for stencsv , in TRSSUW for stencsu and further for points in the subdomain only (TRSDIZ, TRSTUR). They are defined for interior waterlevel points only, but are copied from the interior of the domain to the boundary waterlevel points in order to simplify averaging to u- and v-points in TRSSUW, TRSCUE. Algorithm: If (not breaking-wave model): calculate roughness parameter z0wl and bottom friction velocity cfrowl loop own-int-wlp modf. z0wl, cfrowl using kfuh, up, cmanu for stencus , zksp for stenc0 , kfvh, vp, cmanv for stencvs If breaking wave turbulence model is used: Calculate vertical eddy viscosity loop own-int-wlp × all-lay-ifc modf. vicow using zksp for stenc0 Else If algebraic turbulence model is used: Calculate depth-averaged friction velocity ustbge loop own-int-fldbl-wlp × all-layers modf. ustbge using up for stencus , vp for stencvs , zksp for stenc0


A-21

Computation of vertical eddy viscosity from algebraic model: loop own-int-fldbl-wlp × int-lay-ifc modf. rich using up for stencus , vp for stencvs , zksp, rho for stenc0 loop own-int-fldbl-wlp × int-lay-ifc modf. vicow using windu for stencus , windv for stencvs , zksp, rich, ustbge for stenc0 Else: k − turbulence model: Computation of vertical eddy viscosity from k − model: loop own-int-fldbl-wlp × int-lay-ifc modf. vicow using zksp, rturp loop own-int-fldbl-wlp layers 0, K modf. vicow using zksp, rturp, z0wl, windu, windv for stenc0 up for stencus , vp for stencvs Note: here no de-staggering is done for wind-stresses. Note: the values of vicow at the free surface and bottom seem not to be used. Endif (algebraic / k − turbulence models) Restrict eddy viscosity to kinematic viscosity and an upper bound loop own-int-wlp × all-lay-ifc modf. vicow = max(xnu, min(10, vicow)) using − Copy values from interior of domain to open boundary points loop own-open-bnd-wlp × all-lay-ifc modf. vicow using vicow for adjacent own interior points Note that this calculation is problematic at diagonal open boundaries that coincide with subdomain boundaries. This is solved by computing vicow at own boundary points only (other values are updated in TRSCUE), and by using values from interior points of our own subdomain only.


A.6 A.6.1

TRIWAQ-FLOW: Subroutine TRSCWI Subroutine TRSCWI

Goal: Compute the physical vertical velocity component wphysi at layer-interfaces. in : out :

zkup, up for all-up, zkvp, vp for all-vp, w for own-int-wlp, dischf for own-sources wphysi for own-int-wlp

Algorithm: Initialise dzksdt loop all-wlp × all-lay-ifc modf. dzksdt using − Calculate the time-derivative of the z-coordinate of the position of layer-interfaces loop own-int-wlp × all-lay-ifc modf. dzksdt using zkup, up for stencus , zkvp, vp for stencvs , w for stenc0 loop all-sources × all-layers modf. dzksdt using dischf Calculate the vertical velocity loop own-int-wlp × all-lay-ifc modf. wphysi using zkup, up for stencus , zkvp, vp for stencvs , dzksdt for stenc0

A-22


A.7 A.7.1

A-23

TRIWAQ-FLOW: Subroutine TRSCUE Subroutine TRSCUE

Goal: Calculate flow-velocities vh at half timesteps and up at full timesteps from the discretised momentum equation. in :

out :

uh for own-up ∪ guard1 , kfuh for own-up ∪ guard2 , zkuh, czu, dqdx for own-up, windu for own-int-up, vh for stencvu ⊗ own-up, kfvh for stenc2vu ⊗ own-up, seh, zksh for all-wlp-xdir, vicow for own-wlp, rho, pres for all-int-wlp-xdir, w for own-int-wlp, if (lcnsrv): qxk for own-up ∪ guard1ξ , qyk for stencvu ⊗ own-up, if (lbot3d or lfulry): wphysi for own-wlp, if (lbot3d): zksh for stenc1η ⊗ stencsu ⊗ own-up, if (lhortu): vnu2d for own-dp up for own-up ∪ guard1 ⊗ 1 , kfbu for own-up ∪ guardmax , w for own-int-wlp ∪ guard1 , vicow for all-wlp, if (lbot3d or lfulry or lhortu): vicow for own-wlp ∪ guardbox1 , if (lbot3d or lfulry): wphysi for own-wlp ∪ guard2 , if (lhortu): vnu2d for own-dp ∪ guard1ds

The description below is given for the calculation of up (full timesteps). Algorithm: Initialize coefficients loop own-up × all-layers modf. bbk, ddk using uh Calculate layer thicknesses hkuh loop own-up × all-layers modf. hkuh using zkuh Compute coefficients for barriers loop own-u-barriers × all-layers modf. kfbu ((fullbox,kmax)-array), barfrc ((nbaruv,kmax)-array) using kfuh, uh, zkuh for stenc0 , seh for stencsu loop own-u-barriers × all-layers modf. bbk using barfrc

(TRSBAR)

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) Update arrays needed for coefficients out :

A-24 (COCUPD)

kfbu for own-up ∪ guardmax , (kfbu: updated in barrierpoints only) w, vicow for all-wlp, if (lbot3d or lfulry or lhortu): vicow for own-wlp ∪ guardbox1 , if (lbot3d or lfulry): wphysi for own-wlp ∪ guard2 , if (lfulry): hkuh for own-up ∪ guard1η if (lhortu): vnu2d for own-dp ∪ guard1ds

Compute density gradient loop (stencsu ⊗ own-int-up) × all-layers modf. hksh using zksh loop own-int-wet-up × all-layers (layers ordered from k = 1 : K) modf. ddk using kfuh, kfbu, hkuh for stenc0 , rho, hksh for stencsu If horizontal turbulence model is used: Compute shear stresses, store in array bux. loop all-dp × all-layers modf. bux (= 0 in dry and boundary depth-points) using uh, kfuh for stencud , vh, kfvh for stencvd , vnu2d for stenc0 , vicow for stencsd Compute normal stresses, store in arrays bdx, bdy loop all-wlp-xdir × all-layers modf. bdx, bdy (= 0 in boundary wl-points) using uh for stencus , vh for stencvs , vnu2d for stencds , vicow for stenc0 Compute contribution of horizontal turbulence to right hand side ddk loop own-wet-up × all-layers modf. ddk using bux, kfuh for stencdu , bdx, bdy for stencsu Endif (horizontal turbulence) Compute horizontal terms: Coriolis, waterlevelgradient, non-hydrostatic pressure gradient loop

own-up × all-layers

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) modf. using

A-25

ddk kfuh, dqdx for stenc0 , vh for stencvu , ffzeta, seh for stencsu

Compute horizontal terms: horizontal advection incl. curvature loop own-up × all-layers modf. bbk, bddx, bdx, bux, buux, bddy, bdy, buy, buuy, ddk using uh for stenc1 , kfuh for stenc2 , kfbu for stenc2ξ∪1η vh for stencvu , kfvh for stenc2vu , if (lcnsrv): zksh for stencsu , qxk for stenc1ξ , qyk for stencvu Compute horizontal terms: horizontal viscosity loop own-up × all-layers modf. ddk using uh, kfuh, kfbu for stenc1 , kfvh for stencvu , if (lcrdrv): vh for stencvu , if (lfulry): zksh, wphysi for stencsu , hkuh for stenc1η , vicow for stenc1η ⊗ su Note: hkuh is not used when the corresponding u-point is dry, in particular at (open/closed) boundaries in η-direction. Wind stress, spatially varying pressure loop own-int-wet-up, layer k = 1 modf. ddk using kfuh, kfbu, windu, hkuh loop own-int-wet-up × all-layers modf. ddk using kfuh, kfbu for stenc0 , pres for stencsu Bottom friction loop own-wet-up layer k = K modf. bbk using kfuh, uh, czu, hkuh for stenc0 , vh for stencvu if (lbot3d): vicow, wphysi for stencsu , zksh for stenc1η ⊗ su Compute vertical terms loop own-wet-up × all-layers modf. aak, bbk, cck using kfuh, kfbu, hkuh for stenc0 , vicow for stencsu , if (lcnsrv): zksh for stencsu


A-26

loop own-int-wet-up × all-layers modf. aak, bbk, cck using kfuh, kfbu, hkuh for stenc0 , w for stencsu , if (lcnsrv): zksh for stencsu Reset equations at open velocity boundary points loop own-velc-bnd-up × all-layers modf. aak, bbk, cck, ddk, bddx − buuy using uh Solve system of equations kfuh, uh for own-up, zku full for own-up ∪ guard1 ⊗ 1 , aak, bbk, cck, ddk, bddx − buuy for own-wet-up

in :

up for own-up ∪ guard1 ⊗ 1

out :

A.7.2

(TRSJAM)

Subroutine TRSJAM

Goal: Solve system of equations for TRSCUE for flow-velocities vh for own-vp at half timesteps and for up for own-up at full timesteps, and update new values for all requirements of other routines. kfuh, uh for own-up, zku full for own-up ∪ guard1 ⊗ 1 , aak, bbk, cck, ddk, bddx − buuy for own-wet-up

in :

up for own-up ∪ guard1 ⊗ 1

out :

The description below is given for the calculation of up (full timesteps). Algorithm: Build decomposition of tri-diagonal structure for the vertical direction loop own-wet-up × all-layers modf. aak, bbk using aak, bbk, cck Initialise solution array loop


modf. using

up[q=0] uh

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) Update initial estimate in : out :

zku full for own-up ∪ guard1 ⊗ 1 up[q=0] for own-up ∪ guard1 ⊗ 1

Start iteration: q = 1, 2, ... If (q > 1) : Update current estimate for black points zku full for own-up ∪ guard1 ⊗ 1

in :

up[q−1] for black points in own-up ∪ guard1 ⊗ 1

out :

Compute right hand side for red points (global coordinates m + n is odd) loop (red points in own-wet-up) × all-layers modf. eek using

ddk, bbk, bddx − buuy for stenc0 , up[q−1] for stenc2

Solve tri-diagonal systems for red points loop

(red points in own-wet-up) × all-layers

modf.

up[q] , residu

using

aak, bbk, cck, eek, up[q−1]

Update current estimate for red points zku full for own-up ∪ guard1 ⊗ 1

in :

up[q] for red points in own-up ∪ guard1 ⊗ 1

out :

Compute right hand side for black points (global coordinates m + n is even) loop (black points in own-wet-up) × all-layers modf. eek using ddk, bbk, bddx − buuy for stenc0 , up[q] for stenc2 (red points), up[q−1] for stenc2 (black points) Solve tri-diagonal systems for black points loop

(black points in own-wet-up) × all-layers

modf.

up[q] , residu

using

aak, bbk, cck, eek, up[q−1]

End iteration

A-27

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) Update current estimate for black points in : out :

zku full for own-up ∪ guard1 ⊗ 1 up[q] for black points in own-up ∪ guard1 ⊗ 1

A-28


A.8 A.8.1

A-29

TRIWAQ-FLOW: Subroutine TRSSUW Subroutine TRSSUW

Goal: Calculate new waterlevels seh, flow-velocities uh, w, layer interfaces zksh, zkuh, zkvh, screens kfuh, kfvh and discharges qxk, qzk at half timesteps, or calculate new waterlevels sep, flow-velocities vp, w, layer interfaces zksp, zkup, zkvp, screens kfup, kfvp and discharges qyk, qzk at full timesteps. Documentation below is for half timesteps. in :

sep for all-wlp, up for own-up ∪ guard1 , kfup for all-up, cczu for own-up, windu for own-int-up, vh for stencvu ⊗ own-up, kfvp for stencvu ⊗ own-up, cirbou for own-bnd-wlp-xdir, qyk for all-vp, pres, rho for all-int-wlp-xdir, zkup for all-up, zksp, vicow for all-wlp-xdir, zkvp for all-vp, w for all-int-wlp-xdir, if (lhortu): vnu2d for own-dp ∪ guard1ds , vicow for own-wlp ∪ guardbox1 , if (lbot3d): zksp for own-wlp ∪ guardbox1 , if (lcnsrv): qxk for own-up ∪ guard1ξ , qyk for stencvu ⊗ own-up

out :

seh for all-wlp, uh for own-up ∪ guardbox1 , kfuh for own-up ∪ guardmax , vh for own-vp ∪ guardbox1 , kfvh for own-vp ∪ guardmax , zksh for own-wlp ∪ guardbox1 , w, qzk for all-int-wlp, zkuh for all-up, zkvh for all-vp, kfbu for own-up ∪ guard1 ⊗ 1 , if (lcnsrv): qxk for own-up ∪ guardbox1 , qyk for own-vp ∪ guardbox1 , else: qxk for stencuv ⊗ own-vp, qyk for stencvu ⊗ own-up

Algorithm: Calculate auxiliary variables for upwind flow-height computation in : out :

(TRSMEA, TRSTET)

kfup for all-up, up, zkup for all-wet-up, kfvp for all-vp, vh, zkvp for all-wet-vp, sep for all-wlp umean, tetau for all-up, vmean, tetav for all-vp

Note: the calculation of zkuh and zkvh is done redundantly for all-up resp. all-vp, among others for subroutine TRSDIF. Therefore umean, tetau etc. are also calculated redundantly. At DDHOR-boundaries redundant calculation does not work, therefore zkuh will be communicated. At DDVERT-boundaries, it must be ensured that the coarser (sub)domain uses uses the proper depth in u-/v-points on the interface. Initialise solution arrays loop

all-wlp


A-30

modf. seh[q=0] using sep loop all-up (×all-layers / all-lay-ifc) modf. kfuh[q=0] , uh[q=0] , zkuh[q=0] using kfup, up, zkup loop all-vp modf. using

kfvh[qv=0] kfvp

Check for flooding of u-points

(TRSDFV)

kfuh[0] , zkup (layers 0, K) for own-up, zksp (layers 0, K) for stencsu ⊗ own-up

in :

kfuh[0] for own-up

out :

Set up discretised momentum equations

(TRSUMO)

kfuh[0] , zkup, czu, dqdx for own-up, kfup, up for own-up ∪ guard1 , windu for own-int-up, kfvp, vh for stencvu ⊗ own-up, zksp, vicow for all-wlp-xdir, w, rho, pres for all-int-wlp-xdir, sep for stencsu ⊗ own-u-barriers, if (lhortu): vnu2d for own-dp ∪ guard1ds , vicow for own-wlp ∪ guardbox1 , if (lcnsrv): qxk for own-up ∪ guard1ξ , qyk for stencvu ⊗ own-up, if (lbot3d): zksp for own-wlp ∪ guardbox1

in :

aak, cck, ddk for own-up, kfuh[0] , kfbu for own-up ∪ guardmax

out :

Save old waterlevels at DDHOR-to-finer boundaries (inside coarser domain) loop

ddhtofiner-ifc-up

modf.

sehngh[0]

using

seh[0] for stencsu

Compute vertically integrated discharges at DDHOR-to-coarser boundaries (inside finer domain) loop

ddhtocoarser-ifc-up

modf.

qxdd[0]

using

uh[0] , zkuh[0] for stenc0

Start iteration for continuity equations: q = 1, 2, ..., until convergence or until maximum number of iterations is reached.


A-31

Perform iteration [q] for the continuity equation: insert boundary conditions, perform vertical integration, set-up and solve tridiagonal systems, compute layer-interfaces, check instability and drying, and compute residual. in :

out :

aak − ddk for own-up, qxdd[q−1] for ddhtocoarser-ifc-up, kfuh[q−1] , zkuh[q−1] , tetau, umean for all-up, qyk[q−1] , tetav for all-vp, seh[q−1] for guard1ξ , sep for all-bnd-wlp-xdir, up, zkup for own-bnd-up, zkup also for own-bnd-wlp-xdir ⊗ stencus , vmean for own-v-weirs, zksp (layer K) for own-wlp-xdir kfuh[q] , zkuh[q] for all-up, hkuq[q−1] for own-up, aak − ddk for own-bnd-up, qxdd[q] for ddhtocoarser-ifc-up, seh[q] for all-wlp, kfvh[q] , zkvh[q] , qyk[q] for all-vp, vh for own-vp, optionally (ichcon.eq.0): uh[q] , qxk[q] for own-up, flags instbl, idryv, residu

End iteration loop Compute new u-velocities and discharges when not done for the stop-criterion inside the iteration loop (i.e. when ichcon.eq.1), else compute the layer-thicknesses hkuq[q] . loop


modf.

uh[q] , qxk, hkuq[q]

using

kfuh[q] , zkuh[q] , hkuq[q−1] , aak − ddk for stenc0 , seh[q] for stencsu

Refresh coefficient sets sepu full, sepu ovl used for vertical interpolations, update discharges qxk, and update values for cross-direction (COCCOE, COCUPD) in : out :

zkuh[q] for own-up (layer 0) sepu full, sepu ovl, kfvh for own-vp ∪ guardmax , vh for own-vp ∪ guardbox1 , if (lcnsrv): qxk for own-up ∪ guardbox1 , qyk for own-vp ∪ guardbox1 , else: qxk for stencuv ⊗ own-vp, qyk for stencvu ⊗ own-up

Note: the data-analysis for coefficient sets is not worked out in detail: which values are used to refresh a coefficient set, and which values of the coefficient set are used in vertical interpolations ? Note: kfvh needs be communicated for stencil stenc1ξ⊗2η only (?) Adjust seh[q] , zkuh[q] , uh[q] → seh, zkuh, uh for conservation of mass in : out :

e for own-int-wlp, qxk, tetau, zkuh (layer K) for all-up, uh[q] , hkuq[q] for own-up seh for own-wlp ∪ guardmax , zkuh for all-up, uh for own-up

(TRSMSS)


A-32

Calculate positions of layer-interfaces in all wl-points

(TRSLAV)

in : out :

seh, zksh (layer K) for own-wlp ∪ guardbox1 zksh for own-wlp ∪ guardbox1

Calculate total waterheights in u-points loop all-up modf. hu using zkuh (layers 0, K) Refresh coefficient sets with waterlevels used in vertical interpolations out :

seps full, seps ovl for own-wlp ∪ guardmax , sepu full, sepu ovl for own-up ∪ guard?? , sepv full, sepv ovl for own-vp ∪ guard??

Update kfuh for stencmax , uh for stencbox1 in : out :

(COCCOE)

(COCUPD)

sepu full for own-up ∪ guardbox1 kfuh for own-up ∪ guardmax , uh for own-up ∪ guardbox1

Compute vertical velocities and discharges loop own-int-wlp × all-lay-ifc modf. w, qzk using zksp, zksh, d0k for stenc0 , qxk for stencus If DDHOR is used: refresh mask coefficient set khs in : out :

A.8.2

(WASKHS)

seh, zksh for own-wlp coef khs for own-wlp

Subroutine TRSMEA

Goal: Compute vertically averaged u-velocity or v-velocity. Below we describe the calculation of umean on basis of values available at the start of a timestep. in : out :

kfup for all-up, up, zkup for all-wet-up umean for all-up

Algorithm: Initialize at zero, add weighted velocity per layer, divide by total water depth. loop all-up, all-wet-up modf. umean using kfup, up, zkup


A.8.3

A-33

Subroutine TRSTET

Goal: Compute flags tetau, tetav for selection of upwind or averaged computation of flow height in u- and v-velocity points. Below we describe the calculation of tetau on basis of values available at the start of a timestep. in : out :

umean, zkup (layer K) for all-up, sep for all-wlp-xdir tetau for all-up

Algorithm: Select θ = 0.0/0.5/1.0 on basis of water depth using θ = 0.5 and average u-velocity. loop all-up modf. tetau using umean, zkup (layer K) for stenc0 , sep for stencsu

A.8.4

Subroutine TRSDFV

Goal: Perform flooding checks for u-velocity points (array kfuh[0] , first half timestep) or for v-velocity points (kfvp[0] , second half step). Below we describe the calculation of kfu on basis of values available at the start of a timestep. in : out :

kfu, zku (layers 0, K) for own-up, zks (layers 0, K) for stencsu ⊗ own-up kfu for own-up

Algorithm: Check waterdepth w.r.t. bottom level and w.r.t. crest height of weirs loop own-up modf. kfu using kfu, zku (layers 0, K) for stenc0 , zks (layers 0, K) for stencsu loop own-u-weirs modf. kfu using u for stenc0 , zks (layer 0) for stencsu

A.8.5

Subroutine TRSUMO

Goal: Compute the discretised momentum equation per layer for u-velocity discretisation points, interior to the domain and at open waterlevel boundaries, at half timesteps. Also: for v-velocity points at full timesteps.


A-34

Below we describe the calculations at half timesteps. Coefficients for open velocity boundaries and for closed boundaries will be overwritten by TRSRV1 in TRSSUW later on. in :

out :

kfuh, zkup, czu, dqdx for own-up, kfup, up for own-up ∪ guard1 , windu for own-int-up, kfvp, vh for stencvu ⊗ own-up, zksp, vicow for all-wlp-xdir, w, rho, pres for all-int-wlp-xdir, sep for stencsu ⊗ own-u-barriers, if (lhortu): vnu2d for own-dp ∪ guard1ds , vicow for own-wlp ∪ guardbox1 , if (lcnsrv): qxk for own-up ∪ guard1ξ , qyk for stencvu ⊗ own-up, if (lbot3d): zksp for own-wlp ∪ guardbox1 aak, cck, ddk for own-up, kfuh, kfbu for own-up ∪ guardmax

Algorithm: Compute coefficients for barriers

(TRSBAR)

loop own-u-barriers × all-layers modf. kfbu ((fullbox,kmax)-array), barfrc ((nbaruv,kmax)-array) using kfuh, up, zkup for stenc0 , sep for stencsu Update arrays needed for coefficients out :

(COCUPD)

kfuh, kfbu for own-up ∪ guardmax (kfbu: updated in barrierpoints only)

Compute layer thicknesses in u-points loop own-up × all-layers modf. hkup using zkup If (K > 1 and θ = 0.5) Compute vertical terms loop own-up × all-layers modf. bbk, ddk, eek, ffk using kfuh, kfbu, hkup for stenc0 , vicow for stencsu (in dry u-points bbk =ddk =eek =ffk =0.0 without using these variables) loop own-int-up × all-layers modf. ddk using up, kfuh, hkup for stenc0 , w for stencsu (used in wet points only) Else: Initialise bbk, ddk loop own-up × all-layers modf. bbk=ddk=0.0 using −


A-35

Add contribution of barriers loop own-u-barriers × all-layers modf. bbk using barfrc Compute density gradient loop own-int-wet-up × all-layers (layers ordered from k = 1 : K) modf. ddk using kfuh, kfbu, hkup for stenc0 , rho, zksp for stencsu If horizontal turbulence model is used: Berekening van shear stresses in array shrstr loop all-dp × all-layers modf. shrstr (= 0 in dry and boundary depth-points) using up, kfup for stencud , vh, kfvp for stencvd , vnu2d for stenc0 , vicow for stencsd Berekening van normal stresses in arrays strsnx, strsny loop all-wlp-xdir × all-layers modf. strsnx, strsny (= 0 in boundary wl-points) using up for stencus , vh for stencvs , vnu2d for stencds , vicow for stenc0 Berekening van bijdrage horizontale turbulentie aan rechterlid ddk van de impulsvergelijking loop own-wet-up × all-layers modf. ddk using shrstr, kfuh for stencud , strsnx, strsny for stencsu Endif (horizontal turbulence) Compute horizontal terms loop own-wet-up × all-layers modf. aak, bbk, cck, ddk using kfuh, dqdx for stenc0 , kfup, kfbu, up for stenc1 , kfvp, vh for stencvu , ffzeta for stencsu , if (lcnsrv): zksp for stencsu , qxk for stenc1ξ , qyk for stencvu


A-36

SVWP loop own-int-wet-up × all-layers modf. ddk using kfuh, kfbu for stenc0 , pres for stencsu If (θ = 0.5) Wind stress, bottom friction loop own-int-wet-up layer k = 1 modf. ddk using kfuh, kfbu, windu, hkup loop own-wet-up layer k = K modf. bbk using kfuh, kfbu, up, czu, hkup for stenc0 , vh for stencvu , if (lbot3d): vicow for stencsu , zksp for stenc1η ⊗ su If (K > 1 and θ = 0.5) Perform double sweep to eliminate eek,ffk, and scale by 1/bbk loop own-wet-up × all-layers modf. aak, bbk, cck, ddk using aak-ffk Else: scale by 1/bbk loop own-wet-up × all-layers modf. aak, cck, ddk using aak, bbk, cck, ddk

A.8.6

One iteration for the continuity equation in TRSCNT

Goal: Vertically integrate the momentum equations using positions of layer interfaces of previous iteration [q − 1], fill in boundary conditions, set up and solve tri-diagonal systems for the continuity equation and calculate new positions of layer interfaces (iteration [q]). Below we describe the calculation for half timesteps for iteration number [q]. in :

aak − ddk for own-up, kfuh[q−1] , zkuh[q−1] , tetau, upmean for all-up, qyk[q−1] , tetav for all-vp, seh[q−1] for guard1ξ , sep for all-bnd-wlp-xdir, up, zkup for own-bnd-up, zkup also for own-bnd-wlp-xdir ⊗ stencus , vmean for own-v-weirs, zksp (layer K) for own-wlp-xdir dsu for subdom-ifc-up arow, brow, crow, drow for subdom-ifc-up


A-37

kfuh[q] , zkuh[q] for all-up, hkuq[q−1] for own-up, aak − ddk for own-bnd-up, seh[q] for all-wlp, kfvh[q] , zkvh[q] , qyk[q] for all-vp, vh for own-vp, optionally (ichcon.eq.0): uh[q] , qxk[q] for own-up, flags instbl, idryv, residu arow, brow, crow, drow for subdom-ifc-up

out :

Besides the arrays listed above, additional arrays that are needed are cirbou, ciralf for own-bnd-up ⊗ stencsu , and for own-bnd-wlp-xdir

in :

The dimension of cirbou(2, noroco) can be described as all-bnd-wlp, therefore a stencil stencsu is needed for the boundary values for velocity boundaries (at ends of grid rows and columns, grid points ml and mlu). However, this does not require communication; that is because the partitioning of boundary points is chosen by partitioner COPPRE in such a way that for velocity, discharge and Riemann boundaries the velocity boundary points are assigned to the same subdomain as the corresponding waterlevel location. Therefore cirbou is not included in the precondition of one iteration. Array ciralf is not time-varying and therefore needs not be described. The arrays aa-dd are work-arrays inside this algorithm only. Also arrays d0k and e are not carried over to other iterations and are therefore not mentioned in the pre- and postconditions. Algorithm: In first iteration (q = 1), when using horizontal refinement: calculate the water level along the interface and store in dsu loop all-itf-up modf. dsu using sep for stencus ∩ own-int-wlp In first iteration (q = 1) or when drying in cross-direction occurred in previous iteration q − 1: Calculate fixed part e of right hand side of continuity equation loop

own-int-wlp × all-layers

modf.

d0k[q−1]

using qyk[q−1] for stencvs loop own-sources modf. d0k[q−1] using zksp, dischf loop own-int-wlp modf.

e[q−1]

using

sep, d0k[q−1]


A-38

Set up boundary conditions for momentum equations in :

(TRSRV1)

kfuh, up, tetau, hup for own-bnd-up, zkup for own-bnd-up (layers 0 and K), huh[q−1] , hkuh[q−1] for own-bnd-up, sep for own-bnd-up ⊗ stencsu cirbou, ciralf for stencsu ⊗ own-bnd-up note that, according to index set administration, cirbou lives at water level points. The set of values used in TRSRV1, however, live at u-velocity points. Hence, some of the entries of cirbou may be considered owned by the neighbor, while the u-velocity point belongs to this subdomain. aak, cck, ddk for own-bnd-up

out :

Only in case of WAQUA, and when using barriers: Set up discretized momentum equations for barrier points in :

out :

(WASSBC)

barcuv, uqmin[q−2] for own-u-barriers, seh[q−1] for stencsu ⊗ own-u-barriers, and same data as for interior points aak, cck, ddk, cbuv, kcond, lgubar, uqmin[q−1] for own-u-barriers

NB: the information about WASSBC has not been updated since the uniformation of TRIWAQ and WAQUA. Its pre- and postconditions are out of date. Update momentum equation for u-barriers at subdomain boundaries out :

aak, cck, ddk for all-up

Compute vertically integrated momentum equation loop own-up × all-layers modf. aa − dd using

aak − ddk, hkuh[q−1]

Update coefficients in guard band out :

aa, cc, dd for own-up ∪ guardus (=all-up)

Correction of momentum equation at DDHOR-to-finer boundaries loop ddhtofiner-ifc-up modf. aa, cc, dd using aa, cc, dd Only in first iteration:

(COCUPD)


A-39

Initialize outgoing information loop subdom-ifc-up modf. arow, brow, crow, drow, q2sep, outgo using aa, cc, dd, tetau for stenc0 sep for stencsu NB: the arrays arow-drow have the dimension (2,norows). However, they ’live’ in the points (n,mfu) and (n,ml): the first and last internal water level points. The arrays q2sep and outgo live in the u-points/interface points (n,mf) and (n,ml). Set up boundary conditions for continuity equations in :

out :

(TRSRV2)

cirbou, ciralf for own-bnd-wlp-xdir, sep, for own-int-wlp, hup, upmean, tetau, zkup (layer 0) for own-bnd-up huh[q−1] , kfuh[q−1] for own-bnd-up seh[q−1] , zksp (layer K) for guard1ξ , aa, cc, dd for own-bnd-up a, b, c, d for own-bnd-wlp-xdir, a, b, c, d for guard1ξ seh[q−1] for own-bnd-wlp-xdir

Set up tri-diagonal systems for continuity equations loop own-int-wlp modf. a, b, c, d using e[q−1] for stenc0 loop all-up modf. a, b, c, d for stencus ∩ own-int-wlp using aa, cc, dd for stencus Solve tri-diagonal systems for continuity equations (TRSSWP - TRSOUT - TRSSUB - TRSOUT - TRSSUB) in :

a, b, c, d for all-wlp-xdir tetau for subdom-ifc-up aa, bb, cc, dd for subdom-ifc-up dsu for subdom-ifc-up arow, brow, crow, drow for subdom-ifc-up

out :

seh[q] for all-wlp-xdir, arow, brow, crow, drow for subdom-ifc-up


A-40

• The arrays arow-drow from other iterations are only used at doubly coupled rows. At singly coupled rows, these arrays are local, and do not leave the iteration. • The guard band values of seh are obtained not from interpolation, but from the coupling equations. Update waterlevels at subdomain interfaces, but reset in stenc1ξ out :

(COCUPD)

seh[q] for own-wlp-xdir ∪ guard1 (=all-wlp)

Remember previous layer thicknesses out :

hkuq[q−1] for all-up

Compute new water levels in u-points in : out :

seh[q] for own-wlp-xdir, tetau for all-up, zkuh for all-up layer K zkuh[q] layer 0,

Compute new water levels in v-points in : out :

seh[q] for own-wlp-ydir, tetav for all-vp, zkvh for all-vp layer K zkvh[q] layer 0,

When using horizontal refinement: communicate water levels in v-points out :

(COCUPD)

zkvh[q] for all-vp layer 0

Compute new flow-heights in u-points in : out :

zkuh for all-up layers 0 and K huh for all-vp

Compute new flow-heights in v-points in : out :

zkvh for all-vp layers 0 and K hvh for all-vp

Compute new layer thicknesses and flow heights in u-points in : out :

huh for all-up layers 0 and K hkuh for all-up all layers

(TRSLTH)

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) Check drying of u-points, v-points and wl-points in :

A-41 (TRSDRY)

zkuh for own-up, layers 0, K, upmean for own-u-weirs, zkvh for own-vp, layers 0, K, vmean for own-v-weirs, seh, zksp (layer K) for own-wlp-xdir, seh for stencsu ⊗ own-u-weirs ∪ stencsv ⊗ own-v-weirs

out :

kfuh for all-up, kfvh, qyk for all-vp, vh for own-vp

Optionally compute velocities and discharges, and largest update of velocities in current iteration loop


modf.

uh[q] , qxk[q] , residu

using

aak − ddk, kfuh[q] , zkuh[q] , hkuq[q−1] for stenc0 , seh[q] for stencsu

A.8.7

Subroutine TRSRV1

Goal: Compute discretised momentum equations in u-boundary points at half timesteps or in v-boundary points at full timesteps. Below we describe the calculation for half timesteps. in :

out :

kfuh, up, tetau, hup for own-bnd-up, zkup for own-bnd-up (layers 0 and K), huh[q−1] , hkuh[q−1] for own-bnd-up, sep for own-bnd-up ⊗ stencsu cirbou, ciralf for stencsu ⊗ own-bnd-up note that, according to index set administration, cirbou lives at water level points. The set of values used in TRSRV1, however, live at u-velocity points. Hence, some of the entries of cirbou may be considered owned by the neighbor, while the u-velocity point belongs to this subdomain. aak, cck, ddk for own-bnd-up

Algorithm: Set up boundary equations for all rows loop own-bnd-up modf. aak, cck, ddk using kfuh, up, tetau, hup for stenc0 , zkup for stenc0 (layers 0 and K), huh[q−1] , hkuh[q−1] for stenc0 , sep, cirbou, ciralf for stencsu


A.8.8

A-42

Subroutine TRSRV2

Goal: Compute discretised continuity equations in wl-boundary points in ξ-direction at half timesteps or in wl-boundary points in η-direction at full timesteps. Below we describe the calculation for half timesteps. in :

cirbou, ciralf for own-bnd-wlp-xdir, sep, for own-int-wlp, hup, upmean, tetau, zkup (layer 0) for own-bnd-up huh[q−1] , kfuh[q−1] for own-bnd-up seh[q−1] , zksp (layer K) for guard1ξ , aa, cc, dd for own-bnd-up

out :

a, b, c, d for own-bnd-wlp-xdir, a, b, c, d for guard1ξ seh[q−1] for own-bnd-wlp-xdir

Algorithm: Set up boundary equations for all rows, using block-Jacobi equation at subdomain boundaries loop own-bnd-wlp-xdir modf. a, b, c, d using cirbou, ciralf for stenc0 , sep for stenc1ξ , hup, upmean, tetau, zkup (layer 0) for stencus huh[q−1] , kfuh[q−1] for stencus seh[q−1] , zksp (layer K) for stenc1ξ , aa, cc, dd for stencus loop

guard1ξ

modf.

seh[q−1] , a, b, c, d

using

seh[q−1] for stenc0

A.8.9

Subroutines TRSSWP - TRSOUT - TRSSUB - TRSOUT TRSSUB

Goal: Solve collection of tri-diagonal systems for computational rows or columns of the grid and obtain a new value for seh. in :

a, b, c, d for all-wlp-xdir tetau for subdom-ifc-up aa, cc, dd for subdom-ifc-up dsu for subdom-ifc-up arow, brow, crow, drow for subdom-ifc-up

out :

seh[q] for all-wlp-xdir, arow, brow, crow, drow for subdom-ifc-up


A-43

• The guard band values of seh are obtained not from interpolation, but from the coupling equations. • The arrays arow-drow from the previous iteration are only used at doubly coupled rows. At singly coupled rows, these arrays are local, and do not leave the iteration. Algorithm: Sweep collection of tri-diagonal systems for computational rows or columns of the grid and obtain a system of bi-diagonal systems. (TRSSWP) in : out :

a, b, c, d for all-wlp-xdir b, d for all-wlp-xdir, arow, brow, crow, drow for subdom-ifc-up xbj for all-wlp-xdir

• The systems are all swept from tri- to bidiagonal. Depending on the “row-color”, the sweeping operation is carried out front-to back or back-to-front. • The erased coefficient (a or c) is not reset to zero: it must not be referred to after this call. • The equations at the end (in sweeping direction) are stored in arow-drow. At the other end, the equations stored remain unchanged. • The array xbj is only calculated for “doubly coupled rows”. Calculate outgoing information and combine into systems of equations. Solve these equations to calculate interface water levels. (TRSOUT) in :

out :

tetau for subdom-ifc-up arow, brow, crow, drow for subdom-ifc-up aa, cc, dd for subdom-ifc-up dsu for subdom-ifc-up su, outgo for all-int-up

• The arrays outgo, q2sep, dcross and sucnst are used locally. Their contents are not used after the call, except the contents of outgo at dry interfaces without refinement. At such interfaces, the water level in the neighbor domain is stored in outgo. • Doubly coupled rows have one end where the inputs have not been recalculated by the latest call to TRSSWP. At these interfaces, the outgoing information is based on outdated information.

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) Obtain the solution of a bidiagonal system by means of backward substitution in :

A-44 (TRSSUB)

a, b, c, d for own-wlp-xdir xbj for own-wlp-xdir su, outgo for subdom-ifc-up aa, cc for subdom-ifc-up

seh[q] , xbj for own-wlp-xdir arow, brow, crow, drow for subdom-ifc-up • The entries in arow-drow that could not be filled in TRSSWP are filled now.

out :

• The array outgo is only addressed at dry interfaces without refinement. Calculate outgoing information and combine into systems of equations. Solve these equations to calculate interface water levels. (TRSOUT) in :

out :

tetau for subdom-ifc-up arow, brow, crow, drow for subdom-ifc-up aa, cc, dd for subdom-ifc-up dsu for subdom-ifc-up su, outgo for all-int-up

• The outgoing information is based on the latest information everywhere now. Obtain the solution of a bidiagonal system by means of backward substitution in :

out :

(TRSSUB)

seh[q] for own-wlp-xdir xbj for own-wlp-xdir su, outgo for subdom-ifc-up aa, cc for subdom-ifc-up seh[q] for own-wlp-xdir

• A scalar multiple of xbj is added to seh in every row to make the interface water level equal to su. • The array outgo is only addressed at dry interfaces without refinement.

A.8.10

Subroutine TRSDRY

Goal: Check drying of u- and v–points and optionally also of wl-points. in :

out :

zkuh for own-up, layers 0, K, upmean for own-u-weirs, zkvh for own-vp, layers 0, K, vmean for own-v-weirs, seh, zksp (layer K) for own-wlp-xdir, seh for stencsu ⊗ own-u-weirs ∪ stencsv ⊗ own-v-weirs kfuh for all-up, kfvh, qyk for all-vp, vh for own-vp

This routine is used inside the iteration-loop in TRSCNT, and for drying of v-points after termination of the iteration. It hides details of drying in DDHOR-simulations and of adjusting the momentum equation in dried points.


A-45

Algorithm: Check for drying of u-points loop own-up modf. kfuh using huh for stenc0 loop own-u-weirs modf. kfuh using upmean for stenc0 , seh for stencsu Check for drying of v-points loop own-vp modf. kfvh, vh, qyk, flag idryv using hvh for stenc0 loop own-v-weirs modf. kfvh, vh, qyk, flag idryv using vmean for stenc0 , seh for stencsv When requested: check for drying of wl-points loop own-wlp-xdir modf. idrywl for stenc0 , kfuh for stencus , kfvh, vh, qyk for stencvs , flag idryv using

seh, zksh (layer K) kfuh for stencsu kfvh for stencsv

Update drying flags near subdomain interfaces out :

kfuh for own-up ∪ guardus (=all-up) in TRIWAQ, for own-up ∪ guardmax in WAQUA kfvh, qyk, idryv for own-vp ∪ guardvs (=all-vp) idrywl for own-wlp-xdir ∪ guard1

Set screens in u-points at subdomain boundaries loop subdom-ifc-up modf. kfuh using idrywl for stencsu Set screens in v-points at subdomain boundaries loop subdom-ifc-vp modf. kfvh, vh, qyk using idrywl for stencsv

(COCUPD)


A.8.11

A-46

Subroutine TRSMSS

Goal: Calculate new velocities uh, discharges qxk and waterlevels and layer interfaces seh, zkuh in a mass-conserving way. in :

out :

e, seh for own-int-wlp, qxk, tetau, zkuh (layer K) for all-up, uh, hkuq for own-up seh for own-wlp ∪ guardmax , in TRIWAQ, for own-wlp ∪ guardbox1 , in WAQUA with weirs, for own-wlp ∪ guard1 , in WAQUA without weirs zkuh, uh, hkuh, huh for all-up

Note: the mass-correction step can be disabled by setting flag lmassc=.false. in TRSMSS. In that case the waterlevels seh are updated and zkuh is computed such that the post-condition is satisfied. Note: the mass-correction step is performed at points near subdomain boundaries only. This is documented in the algorithm below in an ad hoc way. Algorithm: Compute waterlevels from continuity equation using fixed discharges loop own-int-wlp (points mfu and ml at subdomain boundaries) modf. seh using e for stenc0 , qxk for stencus Update new seh for stencmax in TRIWAQ, for stencbox1 in WAQUA with weirs and for stenc1 in WAQUA without weirs (COCUPD) out :

seh for own-wlp ∪ guardmax , in TRIWAQ, for own-wlp ∪ guardbox1 , in WAQUA with weirs, for own-wlp ∪ guard1 , in WAQUA without weirs

Note: it is questionable whether it is still necessary to update seh for stencil stencmax . This was needed for filling coefficient sets in the guard band for vertical interpolation, but these interpolations are implemented differently since the introduction of DDH+V. Compute new positions of layer interfaces in u-points loop own-int-wlp (points mf and ml at subdomain boundaries) modf. zkuh, huh, hkuh, uh using seh for stencus , tetau, qxk for stenc0 Note: zkuh needs to be computed/updated near subdomain boundaries only, that is why this calculation is not implemented by a call to subroutine TRSLAV.


A.8.12

A-47

Subroutine TRSLAV

Goal: Calculate new positions of layer-interfaces and layer thicknesses at waterlevel, uvelocity or v-velocity points (resp. iuvwlp =jWLP, jUP or jVP). We describe the calculations for waterlevel points and for u-points, both using the values available at the start of a timestep (sep, zkup). in : out :

zksp (layers 0 and K, only when iuvwlp =jWLP) for own-wlp ∪ guardbox1 , zkup (layers 0 and K, only when iuvwlp =jUP) for all-up zksp for own-wlp ∪ guardbox1 , or zkup for all-up hksp for own-wlp ∪ guardbox1 , or hkup for all-up

Algorithm: Compute positions of interior layer interfaces loop own-wlp ∪ guardbox1 × int-lay-ifc or all-up × int-lay-ifc modf. zksp or zkup using zksp or zkup (layers 0, K) for stenc0 , hlay, hlaysh, indlay Compute layer thicknesses loop own-wlp ∪ guardbox1 × int-lay-ifc or all-up × int-lay-ifc modf. hksp or hkup using zksp or zkup for stenc0


A.9 A.9.1

A-48

WASSIM-FLOW: Subroutine WASKNU Subroutine WASKNU

Subroutine WASKNU steers the k-Nikuradse computation for WAQUA and TRIWAQ, i.e. the computation of bottom roughness parameters cmanu in u-points. It is called after the first half timestep for the calculation of flow. After the second half step a similar routine WASKNV is called for cmanv bottom roughness parameters cmanv in v-points. Goal: Calculate new bottom friction parameters cmanu. in : out :

hu (WAQUA) or zkuh (TRIWAQ) for own-up cmanu for own-up

Algorithm: In case of WAQUA subroutine WASKNU solely consists of the preparation for and the actual call of subroutine WAGKNI. In TRIWAQ WASKNU also calls TRSDHV for the actual water depth hu and converts fullbox-arrays to mnmaxk-format and vice versa.

A.9.2

Subroutine WAGKNI

Goal: Compute White-Colebrook values cmanu at u-points after the first half timestep of FLOW for WAQUA or TRIWAQ. in : out :

hu for own-up cmanu for own-up

Algorithm: If (naru > 0) : Initialise roughness values loop mnmaxk modf. cmanu using − Loop over all areas, compute values using/for corresponding grid cells. loop own-u-areas modf. cmanu using hu


A.10

WASSIM-FLOW: Subroutine WASCVU

A.10.1

Subroutine WASCVU

A-49

Subroutine WASCVU steers the computation of bottom friction parameters czu in u-points for WAQUA and TRIWAQ. It is called after the first half timestep for the calculation of flow. In case a model contains weirs, an appropriate energy loss is accounted for via the bottom roughness term. WASCVU uses WASVLU for WAQUA, and TRSCHZ and TRSCZW for TRIWAQ. After the second half step a similar routine WASCVV is called for the bottom friction parameters czv in v-points. Goal: Calculate new bottom friction parameters czu. in :

WAQUA: khuh, hu, cmanu for own-up, seh for all-wlp-xdir, TRIWAQ: khuh, uh, zkuh, cmanu for own-up, vh for stencvu ⊗ own-up

in :

uh for own-u-weirs ⊗ stenc1ξ , qx, hu or zkuh, czu for own-u-weirs, vh, qy for stencvu ⊗ own-u-weirs, seh for stenc1η ⊗ su ⊗ own-u-weirs

out :

czu for own-up, K=1 & transport: czu for all-up, ustbu for own-up (in TRIWAQ in case of Z0 -based computation)

Algorithm: In case of WAQUA subroutine WASCVU solely consists of the preparation for and the actual call of subroutine WASVLU. In TRIWAQ WASCVU first calls TRSCHZ. In case of weirs it then fills the appropriate mnmaxk-arrays, calls TRSCZW, and converts mnmaxk-array czu back to fullbox-format. In both cases the resulting czu-values are communicated when transport is used and kmax.eq.1.

A.10.2

Subroutine WASVLU

Goal: Compute Chezy-values at u-points after the first half timestep of FLOW for WAQUA. in :

out :

khuh, hu, cmanu for own-up, seh for all-wlp-xdir, uh for own-u-weirs ⊗ stenc1ξ , qx, hu, czu for own-u-weirs, vh, qy for stencvu ⊗ own-u-weirs, seh for stenc1η ⊗ su ⊗ own-u-weirs czu for own-up

Note: czu is not modified at dry u-points. This demands for proper initialisation of czu in dry points. Further it implies that when TICVAL is rather large, not enough friction may be imposed in points that are flooded.


A-50

Algorithm: Check that waterdepth is positive loop own-up modf. − using khuh, hu for stenc0 , sep for stencsu Compute field roughness (ignoring weirs)

(WAGCVL)

loop own-wet-up modf. czu using hu, cmanu Loop over own weirs, compute extra roughness at weirs and add to field roughness (WAGCVA) in : out :

A.10.3

uh for own-u-weirs ⊗ stenc1ξ , qx, hu, czu for own-u-weirs, vh, qy for stencvu ⊗ own-u-weirs, seh for stenc1η ⊗ su ⊗ own-u-weirs czu for own-u-weirs

Subroutine TRSCHZ

Goal: Compute field roughness (Chezy) values at u-points after the first half timestep of FLOW for TRIWAQ. in : out :

khuh, uh, zkuh, cmanu for own-up, vh for stencvu ⊗ own-up czu, hu, ustbu for own-up (latter only in case of Z0 -based computation)

Note: czu is not modified at dry u-points. This demands for proper initialisation of czu in dry points in WAQPRE. Further it implies that when TICVAL is rather large, not enough friction may be imposed in points that are flooded. Algorithm: Check total depth in u-points loop own-wet-up modf. hu using khuh, zkuh If roughness method is Manning, White-Colebrook or Chezy: loop own-wet-up modf. chezy using khuh, cmanu, hu


A-51

Else : Z0 -based calculation loop own-wet-up modf. chezy, ustbu using uh, zkuh for stenc0 , vh for stencvu If roughness method is Manning or Chezy : compute Chezy3D loop own-wet-up modf. chezy using zkuh, hu Finally compute czu = chzfac/chezy2 . loop own-wet-up modf. czu using chezy

A.10.4

Subroutine TRSCZW

Goal: Compute extra roughness at either u-weirs (init.eq.1, after the first half timestep for FLOW for TRIWAQ) or v-weirs (init.eq.2, after the second half timestep) and add to the field roughness value. in : out :


The data-requirements above describe the case init.eq.1, calculation for u-weirs after the first half timestep for FLOW. Note: the arrays seh, uh, vh, czu are mnmaxk-arrays, are compressed variants of TRIWAQ’s regular fullbox-arrays. On the other hand hu is a fullbox-array that is computed by TRSCHZ. Arrays qx and qy are mnmaxk-arrays, which are never computed in TRIWAQ! Note: TRSCZW just calls WAGCVA with the appropriate arguments for the weirs for which the computation is needed: own-wet-u-weirs or own-wet-v-weirs.

A.10.5

Subroutine WAGCVA

Goal: Compute extra roughness at weirs and add to field roughness (Chezy) value. in : out :



A-52

WAGCVA is used both for u-weirs after calculation of the first half timestep for FLOW as for v-weirs, after the second half timestep, and is used both in WAQUA and in TRIWAQ. The description below is for u-weirs in WAQUA. Opmerking: de afhankelijkheden van qy en s zijn veel beperkter dan hierboven aangegeven doordat per type (diagonale) overlaat er steeds maar een deel van het stencil van toepassing is. Hier valt echter geen rekening mee te houden bij het bepalen van de communicatie-tabel. Algorithm: determine weir characteristics

(WAGWCH)

loop own-wet-u-weirs modf. qloodr, wsbov, wsben, ... using uh for stenc1ξ , qx for stenc0 , vh, qy for stencvu , seh for stencsu ⊗ 1η determine flow conditions across the weir

(WAGWEN)

loop own-wet-u-weirs modf. ewbov, qvolk, ... using qloodr, vvbov, ... determine the energy loss loop own-wet-u-weirs modf. dte, ratio using qloodr, qvolk, wsben, ... transform energy loss into an extra Chezy term loop own-wet-u-weirs modf. czu using czu, hu for stenc0 , dte, ratio, ...

(WAGENL)


A.11

A-53

TRANSPORT: Subroutine WASDFC

Goal: Calculate new constituent concentrations at half or full timesteps. in :

out :

rp for own-wlp ∪ guard2ξ∪1η , sep, seh for all-wlp-xdir, khuh for all-up ∪ guard1ξ , uh, hu, czu for all-wet-up, khvh, hv, qy, czv for all-wet-vp, zwnd, dischc, sintc for own-sources, gsour, gsink for own-int-wlp, nfli, dfl, rbndc for own-bnd-wlp-xdir rp for own-wlp ∪ guardmax , nfli, dfl for own-bnd-wlp-xdir

Algorithm: Note: the subroutine executes the different actions in a specific order, such that loops may be performed for larger index sets than that are actually required. For instance the global source terms are added for index set mnmaxk instead of the required own-int-wlp, but the contribution is overwritten for boundary points and for permanently dry points later. Adjust old concentrations at non-diagonal physical boundaries - copy values from interior to boundary points loop all-bnd-wlp-xdir modf. rp using rp for stenc1ξ Note: this should be done at the end of each half timestep instead of at the beginning of the next half timestep. Calculate qhul for powerstations loop powerstations modf. qhul using dischc, rptemp for stenc0 , khuh for stencus , khvh for stencvs Initialize coefficients independent of constituents loop own-wlp-xdir modf. e, a, b, c, f using seh Initialize coefficients for computation of fluxes at domain decomposition interfaces loop all-bnd-up modf. fa, fb, fc, ff using −


A-54

Compute advective and diffusive terms in ξ-direction loop all-wet-up modf. e, a, b, c, f for stencsu , fa, fb, fc, ff for stenc0 using khuh for stenc1ξ , uh, hu, czu for stenc0 Compute fixed part of boundary conditions loop own-bnd-wlp-xdir modf. e, a, b, c, f using uh for stencus Start loop over all constituents: l = 1, . . . , lmax Initialize coefficients for constituent l loop own-wlp-xdir modf. bl, dl using b, sep, rp If (iflsou.eq.1) : Compute global source terms loop own-int-wlp modf. bl, dl using gsour, gsink If (l.eq.ltemp) : Compute special source term for transport of heat loop own-int-wlp modf. dl using rp for stenc0 , khuh for stencus , khvh for stencvs , zwnd Compute advective and diffusive terms in η-direction loop all-wet-vp modf. dl for stencsv , fluxy for stenc0 using khvh, qy, czv, hv for stenc0 , rp for stencsv Reset equations for permanently dry points loop own-int-wlp/own-int-fldbl-wlp modf. a, bl, c, dl using khuh for stencus , khvh for stencvs

(WASHTU)


A-55

Add local source terms loop own-sources modf. bl, dl using dischc, sintc, qhul Fill in boundary conditions loop own-bnd-wlp-xdir modf. dl, nfli, dfl using uh for stencus , rp, nfli, dfl, rbndc Adjust equations at points with very small water depth loop all-wlp-xdir modf. e, a, bl, c, f, dl using seh, rp Note that the modifications made here introduces small mass-errors, and that they may interfere with the flux-correction scheme for domain decomposition. Compute initial fluxes at domain decomposition interfaces in x/ξ-direction in : out :

(WASDFF)

fa, fb, fc, ff for domdec-ifc-up, rp[0] for own-wlp-xdir ∪ guard2ξ ownflx[0] for domdec-ifc-up, fluxx[0] for tocoarser-ifc-up

Exchange fluxes in x/ξ- and y/η-directions and correct right hand side dl for flux-differences. (COCUPD, WASDFF) in : out :

dl for own-int-wlp (in coarser domain), fluxx[0] , ownflx[0] for tofiner-ifc-up, fluxy for domdec-ifc-vp dl for own-int-wlp (in coarser domain)

Start iteration: q = 1, 2, . . . If (q > 1) : Update concentration values; if (q > 2) : also send fluxes at domain decomposition interfaces to coarser domain out :

rp[q−1] for own-wlp-xdir ∪ guard2ξ , fluxx[q−2] for tofiner-ifc-up

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) If (q > 1) : Correct dl w.r.t. flux-differences at domain decomposition interfaces and compute new fluxes in x/ξ-direction in : out :

out :

(WASDFF)

dl for own-int-wlp, fluxx[q−2] , ownflx[q−2] for tofiner-ifc-up, fa, fb, fc, ff for domdec-ifc-up, rp[q−1] for own-wlp-xdir ∪ guard2ξ dl for own-int-wlp (in coarser domain), ownflx[q−1] for domdec-ifc-up, fluxx[q−1] for tocoarser-ifc-up

Perform one iteration of the BJ-TWGE method for the penta-diagonal systems per row in :

A-56

(WASPND)

e, a, bl, c, f, dl for own-wlp-xdir, rp[q−1] for guard2ξ rp[q] for own-wlp-xdir

End iteration Update new concentration values rp out :

rp for own-wlp-xdir ∪ guardmax

End loop over all constituents

A.11.1

Subroutine WASDFF

Goal: Add flux corrections at iteration level [q1] to the right hand side dl for grid cells in a coarser domain, and calculate fluxes at iteration level [q2] in both domains. in : out :

dl for own-int-wlp, fluxx[q1] , ownflx[q1] for tofiner-ifc-up, fa, fb, fc, ff for domdec-ifc-up, rp[q2] for own-wlp-xdir ∪ guard2ξ dl for own-int-wlp (in coarser domain), ownflx[q2] for domdec-ifc-up, fluxx[q2] for tocoarser-ifc-up

Note: the calculations of WASDFF are quite straight-forward. For the precise iteration levels used see WASDFC and the implementation of WASDFF.


A-57

A.12

TRIWAQ-TRANSPORT: Subroutine TRSDIF

A.12.1

Subroutine TRSDIF

Goal: Compute constituents concentrations rp = c0l for l ∈ {1, .., lmax} at half timesteps for own-wlp-xdir and rp = c00l at full timesteps for own-wlp-ydir. Exchange solution between neighbouring subdomains for use in next half timestep.

in :

out :

rp for own-wlp-xdir ∪ guard3ξ∪1η , zksh for all-wlp-xdir, zksp for all-wlp, qzk, difcw for own-int-fldbl-wlp, kfuh, kfbu for own-up ∪ guardus ⊗ 2ξ , zkuh, qxk for all-wet-up, kfvh, kfbv for own-vp ∪ guardvs ⊗ 1η , zkvp, qyk for all-wet-vp, K=1: czu for all-wet-up, czv for all-wet-vp, gsour, gsink for own-wlp-xdir, dischc, fluxc for own-sources, rbndc, dfl, nfli for own-bnd-wlp-xdir, zks full for own-wlp-xdir ∪ guard3 rp for own-wlp-xdir ∪ guard3 , zksp, zksh for all-bnd-wlp-xdir

Note: equations are formed for concentration(waterlevel)-points in the current domain only. Dummy equations are used for temporarily and permanently dry waterlevel points (c0l = cl ). Special equations are used for boundary points in ξ-direction. The concentrations are not modified at boundary points in η-direction, except at diagonal openings. Note: the loops for horizontal terms over all-up and all-vp modify coefficients of two adjacent waterlevel points. For velocity-points at subdomain boundaries (e.g. mf and ml) one of these waterlevel points belongs to the neighbouring subdomain (mf and mlu). Computing contributions to these points requires that the corresponding coefficients are properly initialized. Algorithm: Correct layer-interfaces at true boundary points loop all-open-bnd-wlp-xdir × all-lay-ifc modf. zksp, zksh using zksp, zksh for stenc1ξ (neighbouring interior waterlevel points) Note: this calculation actually belongs to the FLOW-computation, which should pay attention to boundary grid cells in cross-direction. Initialize diagonals independent of constituents loop own-wlp-xdir × all-layers modf. b using zksh


A-58

loop all-wlp-xdir × all-layers modf. bdddx, bddx, bdx, bux, buux, buuux, d, adx, a, aux, cdx, c, cux (if K > 0) using

−

Initialize coefficients for computation of fluxes at domain decomposition interfaces loop all-bnd-up × all-layers modf. fbddx, fbdx, fbx, fbux, fbuux, fbuuux, fa, faux, fc, fcux (if K > 0) using

−

Compute advection in ξ-direction loop all-wet-up × all-layers modf. bdddx, bddx, bdx, b, bux, buux, buuux for stencsu , fbddx, fbdx, fb, fbux, fbuux, fbuuux for stenc0 using

qxk for stenc0 , kfuh, kfbu for stenc2ξ

Compute diffusion in ξ-direction loop all-wet-up × all-layers modf. bdx, b, bux for stencsu , fb, fbux for stenc0 using difco for stencsu , kfuh, kfbu, zkuh for stenc0 Compute parts of vertical terms (advection and diffusion) that are independent of constituents (TRSADZ) in : out :

qzk, difcw, zksh, a, b, c for own-int-fldbl-wlp a, b, c for own-int-fldbl-wlp

If (K = 1) : compute bottom friction loop all-wet-up modf. bdx, b, bux for stencsu , fb, fbux for stenc0 using kfuh, qxk, czu If (indc.eq.1) : compute implicit part of artificial creep terms in : out :

kfuh, kfbu for all-up, zkuh for all-int-up zksh for all-wlp-xdir, difco for all-int-wlp-xdir adx, a, aux, bdx, b, bux, cdx, c, cux for own-int-wlp fa, faux, fb, fbux, fc, fcux for domdec-ifc-up

Start loop over constituents, l = 1, . . . , lmax

(TRSCRI)


A-59

Adjust old concentrations at non-diagonal physical boundaries - copy values from interior to boundary points loop all-bnd-wlp-xdir × all-layers modf. rp using rp for stenc1ξ Note: this should be done at the end of each half timestep instead of at the beginning of the next half timestep. Initialize coefficients for constituent l loop own-wlp-xdir × all-layers modf. bl, if K > 1 also al, cl using a, b, c Initialize right hand side for constituent l loop own-wlp-xdir × all-layers modf. dl using rp, zksp Initialize flux in cross-direction at domain decomposition interfaces loop all-bnd-vp × all-layers modf. fluxy using − Compute advection and diffusion in η-direction loop all-wet-vp × all-layers modf. dl for stencsv , fluxy for stenc0 using kfbv, zkvp, qyk for stenc0 , kfvh for stenc1η , rp, difco for stencsv Compute parts of vertical terms (advection and diffusion) that are dependent of constituents (TRSADZ) in : out :

qzk, difcw, zksh, zksp, al, bl, cl, dl for own-int-fldbl-wlp al, bl, cl, dl for own-int-fldbl-wlp


A-60

If (K = 1) : compute bottom friction in v-points loop all-wet-vp modf. dl for stencsv , fluxy for stenc0 using kfvh, qyk, czv for stenc0 , rp for stencsv If (indc.eq.1) : compute explicit part of artificial creep terms in : out :

rp, zksp for all-wlp-ydir, difco for all-int-wlp-ydir, kfvh, kfbv for own-vp ∪ guard1η ⊗ sv , zkvp for all-int-vp dl for own-int-wlp, fluxy for domdec-ifc-vp

Set boundary conditions/reset coefficients at true boundary points. in : out :

(TRSCRE)

(TRSRVT)

rp, dfl, rbndc, nfli for own-bnd-wlp-xdir, qxk, zkuh for all-bnd-up al, bl, cl, dl, bdddx, bddx, bdx, bux, buux, buuux for own-bnd-wlp-xdir

Add global source and sink terms loop own-wlp-xdir modf. bl, dl using gsour, gsink Add local source and sink terms loop own-sources modf. bl, dl using zksh, dischc, sintc Reset equations for permanently and temporarily dry waterlevel-points. loop own-wlp-xdir modf. al, bl, cl, dl using kfuh for stencus , kfvh for stencvs , rp for stenc0 Solve systems of equations for concentrations rp for constituent l in :

out :

rp for own-wlp-xdir ∪ guard3ξ , zks full for own-wlp-xdir ∪ guard3 for ddv-sigfix neighbours, al, bl, cl, dl, bdddx − buuux, adx, aux, cdx, cux for own-wlp-xdir, fal, faux, fcl, fcux, fbl, fbddx − fbuuux for domdec-ifc-up, fluxy for domdec-ifc-vp rp for own-wlp-xdir ∪ guard3

(TRSJAC)


A-61

End loop over constituents, l = 1, . . . , lmax

A.12.2

Subroutine TRSADZ

Goal: Compute advection and diffusion in z-direction for TRSDIF. When the fixed part of these terms is requested (l==0), identical for all constituents, the data-requirements are as follows. in : out :

qzk, difcw, zksh, a, b, c for own-int-fldbl-wlp a, b, c for own-int-fldbl-wlp

For the variable part of the vertical terms (l>0), different per constituent, the data requirements are: in : out :

qzk, difcw, zksh, zksp, al, bl, cl, dl for own-int-fldbl-wlp al, bl, cl, dl for own-int-fldbl-wlp

Algorithm: If (l==0 or fall-velocities) : Compute layer-thicknesses hks required for implicit vertical terms loop own-int-wlp × all-layers modf. hksh using zksh If (l>0) : Compute layer-thicknesses hkso required for explicit vertical terms loop own-int-wlp × all-layers modf. hksp using zksp If (l==0 and no fall-velocities) : Compute implicit part (θ) of advection in z-direction loop own-int-fldbl-wlp × int-lay-ifc modf. a, b, c using qzk, hksh, a, b, c If (l>0 and fall-velocities) : Compute implicit part (θ) of advection in z-direction loop own-int-fldbl-wlp × int-lay-ifc modf. al, bl, cl using qzk, hksh, al, bl, cl


A-62

If (l>0) : Compute explicit part (1 − θ) of advection in z-direction (with separate loops for with/without fall-velocities) loop own-int-fldbl-wlp × int-lay-ifc modf. dl using qzk, hksp, rp, dl If (l==0) : Compute implicit part (θ) of diffusion in z-direction loop own-int-fldbl-wlp × int-lay-ifc modf. a, b, c using difcw, hksh If (l>0) : Compute explicit part (1 − θ) of diffusion in z-direction loop own-int-fldbl-wlp × int-lay-ifc modf. dl using difcw, hksp, rp

A.12.3

Subroutine TRSCRI

Goal: Compute artificial creep terms in ξ-direction for TRSDIF. in : out :

kfuh, kfbu for all-up, zkuh for all-int-up zksh for all-wlp-xdir, difco for all-int-wlp-xdir adx, a, aux, bdx, b, bux, cdx, c, cux for own-int-wlp fa, faux, fb, fbux, fc, fcux for domdec-ifc-up

Algorithm: Store initial values of kfuh, adjust kfuh at partially closed barriers. loop all-up modf. iwrk2, kfuh using kfuh, kfbu If K > 1 : first term: ∂(hk · ∂c0l /∂z · ∂zk /∂ξ)/∂ξ loop all-int-up × all-layers modf. adx, a, aux, bdx, b, bux, cdx, c, cux for stencus fa, faux, fb, fbux, fc, fcux for stenc0 using

kfuh, zkuh for stenc0 , zksh, difco for stencus


A-63

Second and third terms: ∂zk /∂ξ · ∂c0l /∂ξ and (∂zk /∂ξ)2 · ∂c0l /∂z. loop own-int-wlp × int-lay-ifc modf. aux, a, adx, bux, b, bdx, cux, c, cdx using difco for stenc0 , zksh for stenc1ξ , kfuh for stencsu Restore initial values of kfuh loop all-up modf. kfuh using iwrk2

A.12.4

Subroutine TRSCRE

Goal: Compute artificial creep terms in η-direction for TRSDIF. in : out :

rp, zksp for all-wlp-ydir, difco for all-int-wlp-ydir, zkvp for all-int-vp, kfvh, kfbv for own-vp ∪ guard1η ⊗ sv (= all-vp ⊗ stenc1η ) dl for own-int-wlp, fluxy for domdec-ifc-vp

Algorithm: Store initial values of kfvh, adjust kfvh at partially closed barriers. loop all-vp ⊗ stenc1η modf. iwrk2, kfvh using kfvh, kfbv Note that kfvh is used later on for all-vp ⊗ stenc1η for computation of cl z , which is needed for this index-set for computation of ∂cl /∂η at layer-interfaces. If K > 1 : first term: ∂(hk · ∂cl /∂z · ∂zk /∂η)/∂η loop all-int-vp × all-layers modf. dl for stencvs , fluxy for stenc0 using kfvh, zkvp for stenc0 , zksp, difco for stencvs Compute vertically averaged rp at layer interfaces loop all-wlp-ydir × int-lay-ifc modf. wrk1 using kfvh for stencsv , zksp, rp for stenc0


A-64

Second and third terms: ∂zk /∂η · ∂cl /∂η and (∂zk /∂η)2 · ∂cl /∂z. loop own-int-wlp × int-lay-ifc modf. dl using rp, difco for stenc0 , zksp, wrk1 for stenc1η , kfvh for stencsv Restore initial values of kfvh loop all-vp ⊗ stenc1η modf. kfvh using iwrk2

A.12.5

Subroutine TRSRVT

Goal: Set boundary conditions for transport equation in TRSDIF. in : out :

rp, dfl, rbndc, nfli for own-bnd-wlp-xdir, qxk, zkuh for all-bnd-up al, bl, cl, dl, bdddx, bddx, bdx, bux, buux, buuux for own-bnd-wlp-xdir

Algorithm: Reset all diagonals of the equations loop own-bnd-wlp-xdir × all-layers modf. al, bl, cl, dl, bdddx, bddx, bdx, bux, buux, buuux using − Set inflow and outflow boundary conditions at openings loop own-bnd-wlp-xdir × all-layers modf. dl, bdx, bl, bux using rp, dfl, rbndc, nfli for stenc0 , qxk, zkuh for stencus

A.12.6

Subroutine TRSJAC

Goal: Solve system of equations for TRSDIF for concentrations rp for constituent l for own-wlp-xdir at half timesteps or for own-wlp-ydir at full timesteps, and exchange the result for the guard band w.r.t. stencil stenc3 . in :

out :

rp for own-wlp-xdir ∪ guard3ξ , zks full for own-wlp-xdir ∪ guard3 for ddv-sigfix neighbours, al, bl, cl, dl, bdddx − buuux, adx, aux, cdx, cux for own-wlp-xdir, fal, faux, fcl, fcux, fbl, fbddx − fbuuux for domdec-ifc-up, fluxy for domdec-ifc-vp rp for own-wlp-xdir ∪ guard3


A-65

Note: the implementation refers to rp for stencil stenc3ξ without checking whether the corresponding grid points lie within the computational domain. Therefore the arrays that are used must be large enough and the corresponding coefficients for interior points must be 0. Note: the new concentrations are stored in the same array as the old ones, so no setting of the initial estimate is required. Algorithm: Build decomposition of tri-diagonal structure for the vertical direction loop own-wlp-xdir modf. bl, cl using al, bl, cl Compute initial fluxes at domain decomposition interfaces in x/ξ-direction in : out :

(TRSFLX)

rp[0] for own-wlp-xdir ∪ guard3ξ , fal, faux, fcl, fcux, fbl, fbddx − fbuuux for domdec-ifc-up ownflx[0] for domdec-ifc-up, fluxx[0] for tocoarser-ifc-up

Exchange fluxes in x/ξ- and y/η-directions and correct right hand side dl for flux-differences. (COCUPD, TRSFLX) in : out :

dl for own-int-wlp (in coarser domain), fluxx[0] , ownflx[0] for tofiner-ifc-up, fluxy for domdec-ifc-vp dl for own-int-wlp (in coarser domain)

Start iteration: q = 1, 2, ... If (q > 1) : Update current estimate for black points and send fluxes to coarser domain in : out :

zks full for own-wlp-xdir ∪ guard3ξ for ddv-sigfix neighbours rp[q−1] for black points in own-wlp-xdir ∪ guard3ξ , fluxx[q−3/2] for tofiner-ifc-up

If (q > 1) : Correct dl w.r.t. flux-differences at domain decomposition interfaces and compute new fluxes in x/ξ-direction (TRSFLX) in :

out :

dl for own-int-wlp (in coarser domain), fluxx[q−3/2] , ownflx[q−3/2] for tofiner-ifc-up, rp[q−1] for own-wlp-xdir ∪ guard3ξ , fal, faux, fcl, fcux, fbl, fbddx − fbuuux for domdec-ifc-up dl for own-int-wlp (in coarser domain), ownflx[q−1] for domdec-ifc-up, fluxx[q−1] for tocoarser-ifc-up


A-66

Compute right hand side for red points (global coordinates m + n is odd) loop (red points in own-wlp-xdir) × all-layers modf. wrk1 using

dl, bl, bdddx − buuux, adx, aux, cdx, cux for stenc0 , rp[q−1] for stenc3ξ

Solve tri-diagonal systems for red points loop

(red points in own-wlp-xdir) × all-layers

modf.

rp[q] , residu

using

al, bl, cl, wrk1, rp[q−1]

Update current estimate for red points and send fluxes to coarser domain zks full for own-wlp-xdir ∪ guard3ξ for ddv-sigfix neighbours

in :

rp[q] for red points in own-wlp-xdir ∪ guard3ξ , fluxx[q−1] for tofiner-ifc-up

out :

Correct dl w.r.t. flux-differences at domain decomposition interfaces and compute new fluxes in x/ξ-direction (TRSFLX) in :

dl for own-int-wlp (in coarser domain), fluxx[q−1] , ownflx[q−1] for tofiner-ifc-up, rp[q−1] , rp[q] for own-wlp-xdir ∪ guard3ξ , fal, faux, fcl, fcux, fbl, fbddx − fbuuux for domdec-ifc-up

out :

dl for own-int-wlp (in coarser domain), ownflx[q−1/2] for domdec-ifc-up, fluxx[q−1/2] for tocoarser-ifc-up

Compute right hand side for black points (global coordinates m + n is even) loop (black points in own-wlp-xdir) × all-layers modf. wrk1 using dl, bl, bdddx − buuux, adx, aux, cdx, cux for stenc0 , rp[q−1] , rp[q] for stenc3ξ Solve tri-diagonal systems for black points loop

(black points in own-wlp-xdir) × all-layers

modf.

rp[q] , residu

using

al, bl, cl, wrk1, rp[q−1]

End iteration


A-67

Update current estimate for all points, also in η-direction. in : out :

A.12.7

zks full for own-wlp-xdir ∪ guard3 for ddv-sigfix neighbours rp[q] for own-wlp-xdir ∪ guard3

Subroutine TRSFLX

Goal: Add flux corrections at iteration level [q1] to the right hand side dl for grid cells in a coarser domain, and calculate fluxes at iteration level [q2] in both domains. in :

rp[q2] for own-wlp-xdir ∪ guard3ξ , dl for own-int-wlp (in coarser domain), fal, faux, fcl, fcux, fbl, fbddx − fbuuux for domdec-ifc-up, fluxx[q1] , ownflx[q1] for tofiner-ifc-up

out :

dl for own-int-wlp (in coarser domain), ownflx[q2] for domdec-ifc-up, fluxx[q2] for tocoarser-ifc-up

Note: the calculations of TRSFLX are quite straight-forward. For the precise iteration levels used see TRSJAC and TRSFLX.


A-68

A.13

TRIWAQ-TURBULENCE: Subroutine TRSTUR

A.13.1

Subroutine TRSTUR

Goal: Compute turbulence parameters rturh at half timesteps and rturp at full timesteps for all-wlp. These arrays contain consecutively the turbulent kinetic energy k and turbulent energy dissipation of the k − turbulence model, in “array slices” l = 1 : 2 = ltur. in : out :

rturp, zks full for all-wlp, kfuh, uh for all-up, kfvh, vh for all-vp, zksh, w, rho, vicow, windu, windv, cfrowl, z0wl for own-int-wet-wlp rturh for all-wlp

Note: own-int-wet-wlp is a special index set for the turbulence part of TRIWAQ that originated from the corresponding computations in TRISULA. It is obtained using a temporary mask-array kfs that is set in TRSTU0. A grid-cell is called “wet” when the water depth is at least 1 · 10−6 [m], and when at least one of the four cell-faces is currently open. Algorithm: Compute intermediate variables in : out :

(TRSTU0)

kfuh, uh for all-up, kfvh, vh for all-vp zksh, rho for own-int-wet-wlp kfs for own-wlp, umea, vmea, dudz, dvdz, bruvai for own-int-wet-wlp

Initialize coefficients for first stage (time-derivative) loop own-int-wet-wlp × int-lay-ifc modf. bbk, bux, bdx, buy, bdy, cck, ddk using rturp Compute coefficients for first stage (horizontal advection) loop own-int-wet-wlp × int-lay-ifc modf. bbk, bux, bdx, buy, bdy using umea, vmea for stenc0 , kfuh for stencus , kfvh for stencvs Note that advective transport is computed at open boundaries too, which could better be avoided. Solve equations for first stage (horizontal transport) (TRSDGS) in : out :

rturp, zks full for all-wlp, kfs for own-int-wlp, umea, vmea, bbk, bdx, bux, bdy, buy, cck, ddk for own-int-wet-wlp rturh∗ for own-wlp


A-69

For l = 1, 2 (energy k, dissipation ), set-up and solve equations for the second stage (vertical terms) Initialize coefficients, set time-derivative loop own-int-wet-wlp × int-lay-ifc modf. aak, bbk, cck, ddk using rturh∗ add vertical advection and diffusion terms loop own-int-wet-wlp × int-lay-ifc modf. aak, bbk, cck using zksh, w, vicow add source and sink terms: buoyancy, production, extra production terms to account for large strain rates, dissipation loop own-int-wet-wlp × int-lay-ifc modf. bbk, ddk using vicow, bruvai, dudz, dvdz, rturp set boundary conditions at free surface and bottom loop own-int-wet-wlp, layers 0, K modf. aak, bbk, cck, ddk using windu, windv, cfrowl, z0wl, zksh for stenc0 , uh for stencus , vh for stencvs Note that windu and windv are not de-staggered! Solve tri-diagonal systems for the vertical direction loop own-int-wet-wlp × all-lay-ifc modf. rturh using aak, bbk, cck, ddk End loop l = 1, 2 Copy rturh from interior to open boundary points loop own-open-bnd-wlp × all-lay-ifc modf. rturh using rturh for adjacent own interior points


A-70

Note that this calculation is problematic at diagonal open boundaries that coincide with subdomain boundaries. This is solved by computing rturh at own boundary points before instead of after updating rturh, and by using values from own interior points only. Check lower bound (1 · 10−7 ) loop fullbox × all-lay-ifc modf. rturh using − Update rturh for stencil stenc1 in : out :

A.13.2

zks full for all-wlp for ddv-sigfix neighbours rturh for all-int-wlp

Subroutine TRSTU0

Goal: Compute intermediate quantities for TRSTUR: in : out :

kfuh, uh for all-up, kfvh, vh for all-vp zksh, rho for own-int-wet-wlp kfs for own-wlp, umea, vmea, dudz, dvdz, bruvai for own-int-wet-wlp

Algorithm: Determine array kfs as needed in turbulence part of TRIWAQ (see TRSTUR) loop fullbox modf. kfs = 0 using − loop own-int-wlp modf. kfs using zksh for stenc0 , kfuh for stencus , kfvh for stencvs Determine intermediate quantities for TRSTUR loop own-int-wet-wlp × int-lay-ifc modf. dudz, dvdz, bruvai using zksh, rho for stenc0 , uh for stencus , vh for stencvs loop own-int-wet-wlp × int-lay-ifc modf. umea, vmea using kfuh, uh for stencus , kfvh, vh for stencvs


A.13.3

A-71

Subroutine TRSDGS

Goal: Solve equations for first stage of TRSTUR. rturp, zks full for all-wlp, kfs for own-int-wlp, umea, vmea, b, bdx, bux, bdy, buy, dener, ddiss for own-int-wet-wlp

in :

rturh∗ for own-wlp

out :

Algorithm: Copy turbulence array of previous time-step: new values at boundary points and dry grid cells, initial estimate for wet interior waterlevel points loop

all-wlp × all-lay-ifc

modf. using

rturh∗[q=0] rturp

Determine maximal value in subdomain for relative stop-criterion loop own-int-wlp × int-lay-ifc modf. rtmax using

rturh∗[q=0]

Start iteration q = 1, 2, . . . If (q > 1) : update rturh∗[q−1] for stencil stenc1 in :

zks full for all-wlp for ddv-sigfix neighbours rturh∗[q−1] for all-wlp

out :

Perform one iteration of the flow-dependent Gauss-Seidel iteration method with Jacobicoupling at subdomain interfaces: four separate sweeps over the grid with special orderings of grid points, where only specific grid points are updated depending on the signs of umea(n,m,k) and vmea(n,m,k). loop

own-int-wet-wlp × int-lay-ifc

modf. using

rturh∗[q] , residu umea, vmea, b, bux, bdx, buy, bdy, dener, ddiss for stenc0 , rturh∗[q−1] or rturh∗[q] for stenc1 (it.level depending on flow-direction)

Until (residu < max(1.0, rtmax) · epsrel)


A-72

A.14

TRIWAQ-HYDRO: Subroutine WASHDY

A.14.1

Subroutine WASHDY

Goal: Perform timestep with respect to non-hydrostatic flow. in :

w, dqdz, zkso for own-int-wlp, wphysi for own-wlp ∪ guard2 , zksp, vicow, q, dq for all-wlp, zkup, up, qxk for all-up, zkvp, vp, qyk for all-vp

out :

wphysi, q, dq for all-wlp, w, qzk, dqdz for own-int-wlp, up for all-up, dqdx for own-up, qxk for own-up ∪ guardbox1 , vp for all-vp, dqdy for own-vp, qyk for own-vp ∪ guardbox1

Note: washdy is called after the flow-computations of the second half time-step (subroutine wasspv), i.e. with given flow-quantities at full timesteps. The purpose of subroutine washdy is to deliver the gradient of the non-hydrostatic pressure dqdx, dqdy in own-up and own-vp. Algorithm: Build and solve w-momentum equation in : out :

zksp, w, dqdz for own-int-wlp, wphysi for own-wlp ∪ guard2 , vicow for all-wlp, zkup, up, qxk for all-up, zkvp, vp, qyk for all-vp wphysi, kfw for own-int-wlp

Build the divergence matrix dmat in : out :

out :

(TRSGRD)

zksp for all-wlp gmatu for all-up, gmatv for all-vp, gmatw for own-int-wlp

Build Poisson equation for pressure correction in :

(TRSDIV)

zkup for all-up, zkvp for all-vp, zksp, kfw for own-int-wlp dmat for own-int-wlp

Build the gradient matrices gmatu, gmatv and gmatw in : out :

(TRSWMO)

dmat, gmatw, wphysi for own-int-wlp, gmatu, up for all-up, gmatv, vp for all-vp amatq, rhs for own-int-wlp

If model is 3D (kmax>1): use postconditioned BiCGStab solver.

(TRSPOI)


If preconditioner must be improved in current timestep: update the preconditioner in : out :

(TRSILU)

amatq for own-int-wlp, prec for all-wlp (?) prec for own-int-wlp

Solve equations using BiCGStab method in : out :

A-73

(TRSBCG)

amatq, prec, rhs for own-int-wlp, dq for all-wlp dq for own-wlp

Else: model is 2D (kmax=1): use Stone’s SIP-solver. Solve equations using Stone’s SIP-solver in : out :

(TRSSIP)

amatq, rhs for own-wlp, dq for all-wlp dq for own-wlp

End if (kmax>1) Exchange pressure correction dq with neighbouring subdomains out :

dq for all-wlp

Compute derivatives ddqdx, ddqdy, ddqdz of dq in : out :

out :

(TRSHDU)

up, zkup, ddqdx for all-up, vp, zkvp, ddqdy for all-vp, wphysi, ddqdz, kfw, w, zksp, zkso for own-int-wlp up, qxk for all-up, vp, qyk for all-vp, w, qzk for own-int-wlp, wphysi for all-wlp

Compute derivatives dqdx, dqdy, dqdz of q in : out :

(SAXPY)

q, dq for all-wlp q for all-wlp

Update velocity and pressure fields in :

(TRSDQD)

dq for all-wlp ddqdx for own-up, ddqdy for own-vp, ddqdz for own-int-wlp

Update non-hydrostatic pressure Q in : out :

(COCUPD)

q for all-wlp dqdx for own-up, dqdy for own-vp, dqdz for own-int-wlp

(TRSDQD)


A.14.2

Subroutine TRSWMO

Goal: Build and solve the w-momentum equation. in : out :

zksp, w, dqdz for own-int-wlp, wphysi for own-wlp ∪ guard2 , vicow for all-wlp, zkup, up, qxk for all-up, zkvp, vp, qyk for all-vp wphysi, kfw for own-int-wlp

Algorithm: Initialize flag-array kfw. loop all-wlp modf. kfw using zksp If (tetwfy.lt.1.): save physical w-velocities loop own-int-wlp × all-lay-ifc modf. wold using wphysi Copy physical w-velocities to boundary points (both x- and y-directions) loop all-bnd-wlp × all-lay-ifc modf. wphysi using wphysi for stenc2 Build the w-momentum equation loop own-int-wlp × all-lay-ifc modf. amatw, rhs using zksp, w, dqdz for stenc0 , wphysi, vicow for stenc1 , zkup, up, qxk for stencus , zkvp, vp, qyk for stencvs Solve the w-momentum equation using Gaussian elimination loop own-int-wlp × all-lay-ifc modf. amatw, rhs, wphysi using amatw, rhs If (tetwfy.lt.1.): re-update physical w-velocities (relaxation) loop own-int-wlp × all-lay-ifc modf. wphysi using wphysi, wold

A-74


A.14.3

A-75

Subroutine TRSDIV

Goal: Calculate the divergence operator dmat. in : out :

zkup for all-up, zkvp for all-vp, zksp, kfw for own-int-wlp dmat for own-int-wlp

Algorithm: Compute divergence matrix loop own-int-wlp × all-layers modf. dmat using zkup for stencus , zkvp for stencvs , zksp, kfw for stenc0

A.14.4

Subroutine TRSGRD

Goal: Build the gradient matrices gmatu, gmatv and gmatw. at initial timestep for all-wlp. in : out :

zksp for all-wlp gmatu for all-up, gmatv for all-vp, gmatw for own-int-wlp

Note: the array-dimensions of gmatu, gmatv and gmatw differ from most other arrays: real gmatw(2,kmax,jstart:mnmaxj), gmatu(6,kmax,jstart:mnmaxj), + gmatv(6,kmax,jstart:mnmaxj) Algorithm: Determine mask-array in waterlevel points loop own-int-wet-wlp × int-lay-ifc modf. kfw using zksp Build x-gradient matrix for non-hydrostatic pressure loop all-up × all-layers modf. gmatu using zksp for stencsu Build y-gradient matrix for non-hydrostatic pressure loop all-vp × all-layers modf. gmatv using zksp for stencsv


A-76

Build z-gradient matrix for non-hydrostatic pressure loop own-int-wlp × all-layers modf. gmatv using zksp, kfw

A.14.5

Subroutine TRSPOI

Goal: Build the Poisson equation for the pressure correction in : out :

dmat, gmatw, wphysi for own-int-wlp, gmatu, up for all-up, gmatv, vp for all-vp amatq, rhs for own-int-wlp

Algorithm: Set up Poisson equation loop own-int-wet-wlp × all-layers modf. amatq, rhs using dmat, gmatw, wphysi for stenc0 , gmatu, up for stencus , gmatv, vp for stencvs

A.14.6

Subroutine TRSILU

Goal: Build the classical incomplete factorization (RILU). in : out :

amatq for own-int-wlp, prec for all-wlp prec for own-int-wlp

Note: prec is assumed to contain zeros in boundary points and in points belonging to neighbouring subdomains, and remains zero in these points. Note: the precise computations for the preconditioner have not (yet) been studied w.r.t. parallel runs. Algorithm: Initialise work-arrays loop all-wlp × all-layers modf. vt1, vt2 using −


A-77

Compute row-sums of matrix loop own-int-wlp × all-layers modf. vt1 using amatq, vt1 Compute matrix U , MILU modification to diagonal element, and matrix L. Note: the precise data-dependencies have not yet been determined for these computations. Note: ordering of grid-points is relevant here!!! loop own-int-wlp × all-layers modf. prec using amatq for stenc0 , prec for stenc−1ξ ⊗ −1η modf. vt2 using prec for stenc0 , vt2 for stenc−1ξ ⊗ −1η modf. prec for stenc+1ξ ⊗ +1η using prec for stenc−1ξ ⊗ −1η , amatq for stenc+1ξ ⊗ +1η

A.14.7

Subroutine TRSBCG

Goal: Solve Poisson-equation using ILU-postconditioned BiCGStab algorithm. in : out :

amatq, prec, rhs for own-int-wlp, dq for all-wlp dq for own-wlp

Note: vectors q, v, etc. are initialized to zero, and stay zero in boundary points. Algorithm: Initialise work-array loop all-wlp × all-layers modf. v using − Compute resd = amatq · dq in : out :

amatq for own-int-wlp, dq for all-wlp resd for own-int-wlp

Compute initial residual norms bnorm, rnorm loop own-int-wlp × all-layers modf. resd, res0 using resd, rhs

(TRSAVM)

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) Compute global sum of bnorm, rnorm, Determine tolerance of iterative procedure.

A-78 (COCRGL)

For it = 1, 2, ... perform iteration Compute parameter ρ loop own-int-wet-wlp × all-layers modf. − using res0, resd Compute global sum of rho

(COCRGL)

Compute new vectors p and q loop own-int-wet-wlp × all-layers modf. p, q using resd, p, v Exchange vector q [it] with neighbouring subdomains out :

q for all-wlp

Compute q [it]∗ = L−1 · q [it] , exchange with neighb. subdomains in : out :

(TRSIVU, COCUPD)

q for all-wlp, prec for own-int-wlp q for all-wlp

Compute v = amatq · q [it]∗∗ in : out :

(TRSIVL, COCUPD)

q for all-wlp, prec for own-int-wlp q for all-wlp

Compute q [it]∗∗ = U −1 · q [it]∗ , exchange with neighb. subdomains in : out :

(COCUPD)

(TRSAVM)

amatq for own-int-wlp, q for all-wlp v for own-int-wlp

Compute parameter σ by summing res0 · v loop own-int-wlp × all-layers modf. − using res0, v Compute global sum of σ

(COCRGL)


A-79

Compute vectors s, dq, q and compute residual (norms) loop own-int-wlp × all-layers modf. s, dq, q using resd, v, dq, q Check convergence, exit loop when convergence is reached

(WASCHK)

Exchange vector q with neighbouring subdomains

(COCUPD)

in : out :

q for own-wlp q for all-wlp

Compute q [it]∗ = L−1 · q [it] , exchange with neighb. subdomains in : out :

prec for own-int-wlp, q[it] for all-wlp q[it]∗ for all-wlp

Compute q [it]∗∗ = U −1 · q [it]∗ , exchange with neighb. subdomains in : out :

(TRSIVU, COCUPD)

prec for own-int-wlp, q[it]∗ for all-wlp q[it]∗∗ for all-wlp

Compute t = amatq · q [it]∗∗ in : out :

(TRSIVL, COCUPD)

(TRSAVM)

amatq for own-int-wlp, q for all-wlp t for own-int-wlp

Compute parameters γ and tnorm loop own-int-wlp × all-layers modf. − using s, t Compute global sum of γ and tnorm

(COCRGL)

Update vectors dq, resd and compute residual (norms) loop own-int-wlp × all-layers modf. dq, resd using dq, q, s, t Check convergence End loop it = 1, 2, ...

(WASCHK)


A.14.8

A-80

Subroutine TRSAVM

Goal: Perform the matrix-vector multiplication for the unpreconditioned system of equations. in : out :

amatq for own-int-wlp, vin for all-wlp vout for own-int-wlp

Algorithm: Compute row-sums of matrix loop own-int-wlp × all-layers modf. vout using amatq for stenc0 , vin for stenc1

A.14.9

Subroutine TRSIVL

Goal: Perform the multiplication of a vector v by the inverse of an lower triangular matrix L. in : out :

v for all-wlp, prec for own-int-wlp v for own-int-wlp

Algorithm: Compute result-vector elements in the appropriate order loop own-int-wlp × all-layers using forward ordering! modf. v using prec, v for stenc0 , v for stenc−1ξ∪−1η

A.14.10

Subroutine TRSIVU

Goal: Perform the multiplication of a vector v by the inverse of an upper triangular matrix U. in : out :

v for all-wlp, prec for own-int-wlp v for own-int-wlp


A-81

Algorithm: Compute result-vector elements in the appropriate order loop own-int-wlp × all-layers using backwards ordering! modf. v using prec, v for stenc0 , v for stenc+1ξ∪+1η

A.14.11

Subroutine TRSSIP

Goal: Solve Poisson-equation using Stone’s SIP-solver. in : out :

amatq, rhs for own-wlp, dq for all-wlp dq for own-wlp

Algorithm: Compute factorization of amatq and norm of right hand side. Note: using specific ordering of grid points. loop own-int-wlp using forward ordering modf. cmat using amatq, rhs for stenc0 , cmat for stenc1ξ ⊗ −1η Compute global sum of bnorm, Determine tolerance of iterative procedure.

(COCRGL)

For it = 1, 2, ... perform iteration: forward and backward sweeps. Perform forward sweep. loop own-int-wet-wlp using forward ordering modf. resd using amatq for stenc0 , dq for stenc1 Exchange resd with neighbouring subdomains out :

resd for own-wlp ∪ guardbox1

Continue forward sweep. loop own-int-wet-wlp using forward ordering modf. resd using cmat for stenc0 , resd for stenc−1η ⊗ 1ξ

(COCUPD)

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) Exchange resd with neighbouring subdomains out :

A-82 (COCUPD)

resd for all-wlp ∪ guardbox1

Perform backward sweep. loop own-int-wet-wlp using backward ordering modf. resd, dq using cmat, dq for stenc0 , resd for stenc+1η ⊗ 1ξ Check convergence, exit loop when convergence is reached

(WASCHK)

If not converged yet: exchange vector dq with neighbouring subdomains

(COCUPD)

out :

dq for all-wlp

End loop it = 1, 2, ...

A.14.12

Subroutine TRSDQD

Goal: Calculate the derivatives of the non-hydrostatic pressure Q at initial timestep. in : out :

q for all-wlp dqdx for own-up, dqdy for own-vp, dqdz for own-int-wlp

Algorithm: Calculate the x-derivative of the non-hydrostatic pressure loop own-up × all-layers modf. dqdx using gmatu for stenc0 , q for stencsu Calculate the y-derivative of the non-hydrostatic pressure loop own-vp × all-layers modf. dqdy using gmatv for stenc0 , q for stencsv Calculate the z-derivative of the non-hydrostatic pressure loop own-int-wlp × all-layers modf. dqdz using gmatw, q


A.14.13

Subroutine TRSHDU

Goal: Update velocity and pressure with pressure correction. in : out :

up, zkup, ddqdx for all-up, vp, zkvp, ddqdy for all-vp, wphysi, ddqdz, kfw, w, zksp, zkso for own-int-wlp up for all-up, qxk for own-up ∪ guardbox1 , vp for all-vp, qyk for own-vp ∪ guardbox1 , w, qzk for own-int-wlp, wphysi for all-wlp

Algorithm: Update u-velocity component and discharge in ξ-direction. loop all-up × all-layers modf. up, qxk using up, ddqdx, zkup Note: could be using hkup instead of zkup. Update v-velocity component and discharge in η-direction. loop all-vp × all-layers modf. vp, qyk using vp, ddqdy, zkvp Note: could be using hkvp instead of zkvp. Update physical w-velocity component. loop own-int-wlp × all-lay-ifc except bottom k = K modf. wphysi using wphysi, ddqdz, kfw loop own-int-wlp bottom layer k = K modf. wphysi using kfw for stenc0 , up, zkup for stencus , vp, zkvp for stencvs Compute w-velocity component and discharge in z-direction. loop own-int-wlp × int-lay-ifc modf. w, qzk using zksp, zkso for stenc0 , up, zkup for stencus , vp, zkvp for stencvs loop own-int-wlp layers k = 0, K modf. w, qzk = 0. using −

A-83

VORtech Computing Technisch Rapport TR01-06 versie 2.6 (4 april 2014) Exchange wphysi, qxk and qyk with neighbouring subdomains out :

wphysi for all-wlp, qxk for own-up ∪ guardbox1 , qyk for own-vp ∪ guardbox1

A-84 (COCUPD)

Detailontwerp van de Domein Decompositie in WAQUA en TRIWAQ. Technisch Rapport TR01-06 versie 2.6 (4 april 2014)

Recommend Documents