34617: Couple Wanda to Delft3D-FLOW via DIMR Branch: https://svn.oss.deltares.nl/repos/delft3d/branches/research/Deltares/20160714_34617_flow2d3d_dimr_bmi (Deze branch is oud (en verwijderd (niet gebruiken)): https://svn.oss.deltares.nl/repos/delft3d/branches/research/Deltares/20160408_introduce_dimr ) DIMR in deze branch is identiek aan de DIMR in de OSS trunk De branch wordt alleen gebruikt om in Delft3D-FLOW de DIMR/BMI interface in te bouwen. Problemen ========= Tijdens compileren: deze meldingen zijn volgens mij nieuw: 3>c:\code\branches\dimr\src\utils_lgpl\d_hydro_lib\include\component.h(84): warning C4002: too many actual parameters for macro 'GetCurrentTime' Volgens mij is er een clash tussen de d_hydro interface (die er nog gewoon in zit) en de dimr interface. Toevoegen ========= LINUX Dit is nodig voor Anton de Fockert's project! 32bit (Delft3D-FLOW compileert niet) of 64bit (Wanda is gebaseerd op nefis3)? De h6 is niet ingericht/geschikt voor 32bit compilatie! PARALLEL WAVE Mergen van branch naar trunk: https://svn.oss.deltares.nl/repos/delft3d/branches/research/Deltares/20150429_unst-807_d-hydro En zorgen dat alles blijft werken. DOMEINDECOMPOSITIE Ik ben er nog niet uit hoe dat moet. Enkele ideeen: - Alle gdp pointers in flow2d3d.cpp opslaan in een array en naar elke draad een update call doen met de betreffende gdp pointer. = Hoe vind je de draden? = Hoe zorg je dat ze parallel worden uitgevoerd (background proces?)? - Gebruik de OLV interface (milestones, data uitwisseling) = Wijkt enorm af van single domein = Dan kunnen we dat er niet meer uit slopen - Master partitie zorgt voor BMI interface. Alle andere partities communiceren met de master partitie Vergelijk met de RTC implementatie voor DD Info ==== De entries waar dimr bij Delft3D-FLOW binnen komt, staan in flow2d3d.cpp, samen met de d-hydro entries. Zie commentaar aldaar. Via DIMR/BMI: Ik heb ervoor gekozen om zowel een DeltaresHydro instance als een Flow2D3D instance aan te maken, net zoals dat gebeurt via d-hydro. Ik durfde dit niet over te slaan. Subroutine trisim wordt tijdens initialize aangeroepen met de nieuwe vlag initOnly=1. Hij geeft de gdp pointer terug aan flow2d3d.cpp. Fortran => C : gdpC = c_loc(gdp), opslaan als "void *" C => Fortran: niets extra's (!). Gewoon een "void *" doorgeven en net doen alsof het een "type(globDat) , pointer :: gdp" is. Dat gaat goed. Alle DIMR/BMI entries in flow2d3d.cpp callen een trisim_-routine. Al deze routines staan in file trisim.F90 (inclusief hulp subroutines). Ze mogen niet in een module staan. De tijdloop staat nu in "trisim.F90::trisim_update". Daarin wordt trisim_step ge-called voor 1 tijdstap (gekopieerd van flow2d3d_openda). flow2d3d::set_var is niet nodig: flow2d3d::get_var geeft een pointer terug, zodat DIMR direct in de betreffende array een waarde kan lezen/schrijven. trism::trisim_get_var heb ik afgekeken van FM. De FM variant is verdeeld over een aantal subroutines, waardoor het geheel nogal onoverzichtelijk is geworden. trisim_get_var is gewoon recht-toe-recht-aan. Het leuke van deze eerste case is dat trisim_get_var voor "Filrtc/obs_east/water_level" een array-plek in de gdp structuur terug geeft en voor "Filbar/U-barrier1/gate_level" een array-plek in de door ESM gealloceerde arrays. En dat werkt gewoon allebei :-). Denk erom dat van trisim.F90, van de debug configuration, de property "Fortran -> Run-time -> Check Array and String Bounds" op "No" moet staan, omdat de r-i-ch arrays worden gebruikt. In "Filrtc/obs_east/water_level" en "Filbar/U-barrier1/gate_level" kan Filrtc/Filbar natuurlijk vervangen worden door iets als RTCmonitoring/barriers. Het leuke aan Filrtc/Filbar is dat je meteen ziet waar de namen obs_east/U-barrier1 vandaan komen. Ik heb de RTC administratie gebruikt (misbruikt?) voor deze case: rtcact had vroeger de waarde .true./.false. en nu noRTC(0)/RTCmodule(1)/RTCviaBMI(2). Om te zien of cbuvrt inderdaad via BMI is gezet, wordt de array op -999 geinitialiseerd. In rtc_comm_get wordt cbuvrt(1,id) op 0.0 gezet als cbuvrt(2,id)>-998.0 A3M:updbar: hack for first testcase FLOW <-> DIMR <-> WANDA! De Wanda versie/model die ik nu gebruik geeft een 11 (dicht) of een 8 (open) terug voor de gate height. Dit klopt voor de vergelijkbare FM testcase, maar de 3Dgate in Delft3D-FLOW gaat naar boven toe open, dus "dicht" is -5.0 en "open" is -4.0 (dat geeft al een flinke schok in het systeem. Zodra we een Wanda model hebbend dat bij Delft3D-FLOW past, moet de regel "cbuv(1, ibar) = -(1.0_fp/3.0_fp) * cbuvrt(2, ibar) - (4.0_fp/3.0_fp)" en de melding worden verwijderd. Toegevoegd aan mdf file: RTCact = #BMI# Ik twijfel wat de beste methode is: expliciet een regel in de mdf file als je via BMI data verwacht (= situatie nu) of zonder expliciete regel: gewoon gaan rekenen en als er via BMI iets wordt ingeprikt is dat mooi. Dit laatste implementeren is niet triviaal: in "rdsite.f90" moet "rtcact" op "RTCviaBMI" zijn gezet, voordat regel 1153 wordt bereikt. Als de Wanda binaries op de p-schijf staan, duurt het initialiseren ongeveer 2 minuten. Als ze lokaal staan ongeveer 2 seconden. Let op dat alle vier de paden naar Wanda-input en de Wanda-binaries goed staan in file "...\examples\12_flow-wanda\Wanda\model1.cfg"