Distributed Calculation

Motivation

A lasting safety device of functionality and ecological compatibility of a middle to large duct system require a comprehensive and detailed modelling in space and time. In order to become fair the statistic requirements demanded in the guidelines, to be able to estimate the annual frequencies, the amounts and spaces of time realistically, it is goal-prominent and necessary to regard longterm periods and entire catchment areas as detailed as possible.

For reasons of the computing time, large simplifications are made at present and it is worked with different noncomparable calculation methods. In most cases, hydraulic functionality and security are to be guaranteed thereby by the view of model rains and if necessary rain series. These views and estimations occur usually with time-symmetrical procedures. On the contrary, those procedures whose task it is to estimate the expected annual emissions into our natural waters with their amounts, frequencies and constancies, usually work with time-asymmetrical methods. This is managed mostly in the form of longterm simulations of natural rain rows during as large a periods as possible. Beyond this, the regarded duct systems are mostly transferred into abrasive networks, in order to make the computing times more bearable.

Desirable is a time symmetrical and therefore reliable and realistic modelling and simulation of the whole network in all its details, meshing and reciprocal effects, which satisfies all these demands. By the utilization of multi processor systems, which are today supposed to be standard (this concerns also Intel core 2 and Athlon X2) and the use of free resources in the network, the computing time is diminished around the factor "1/amount of the processors ". I.e. with two available processors (e.g. Intel core 2 and Athlon X2) the computing time is halved, with four available processors, the computation time takes only a quarter of the time necessary with only one processor

Multi Core Systems in KANAL++ and DYNA

The utilization of all processors of a multi core system for hydrodynamic network calculation is possible in DYNA since its origin, because this had already been a main criterion during its development. Without further indication DYNA determines the number of processors and produces the appropriate number of "Threads", or the user determines the number of processors in order to keep processors free for other applications.

Even during the calculation, it is possible to intervene with the "Windows Task Manager" and to withdraw or reconnect processors during the running DYNA process.

This kind of acceleration is, as described above, used by DYNA automatically or manually configurable. However, it is subjected to the restrictions of the hardware. The usual multiprocessor systems are limited to 4 to 8 processors. A further development is possible with modern CCUs, but this does not leas to a significant performance increase. The situation looks different when using free network resources (autonomous computers). Here, an almost arbitrary acceleration of the computation is possible.

Utilization of the free network resources

As next step, further computers in the network can be consulted for the computation. Often, very high performance servers of the workstation of an employee are not working at full capacity after the end of a workday. These computers can now, centrally steered from one KANAL++ workstation, merged into the computation.

This way, the amount of reclaimable arithmetic and logic units (CCUs) can be increased at will.

Requirements for the Distributed Calculation with KANAL++ und DYNA

In the further process of the document, the computer, on which KANAL++ is started and therefore is supposed to be the central link of the computation, is called Client. The computers mandated with the computation of the duct system by the client, are to be called servers. All computers involved the computation procedure PCs (Client and servers) must be connected by a network.

Requirements for the Client and the KANAL++ Projekt

Auf dem Client System muss eine ordnungsgemäße Installation von KANAL++ vorhanden sein. Das Projekt muss auf einem Netzlaufwerk gespeichert werden. Über das Netzlaufwerk erfolgt der Großteil des Datenaustausches zwischen Client und Server. Die Verteilung des Rechenaufwands erfolgt über verschiedene Hydraulikvarianten. Sind diese nicht vorhanden (z.B. Langzeitsimulation mit einer Hydraulikvariante) ist diese in geeigneter Weise über die Regen aufzuteilen. Um die Ressourcen im Netzwerk optimal auszunutzen sollten gleich viele (oder mehr) Hydraulikvarianten wie Rechensysteme Vorhanden sein.

Requirements for Servers

The server must be able to perform DYNA properly. For this purpose, a separate dongle or a network dongle is necessary, as well as access to the program data obligatory for DYNA. Additionally, the supplementary program RemoteDynaCallServer.exe (is stored after the KANAL++ installation in the file winkanal/are) must be started on each server system. The program converts the steering instructions of the Client. On the server systems, a server operating system can, but must not necessarily be installed. Also Windows 2000/XP systems can be used. The user has to possess sufficient rights (at the best administrator rights) to execute DYNA and the RemoteDynaCallServer and furthermore to have full writing-/reading-access on the network drive, on which the KANAL++ project is stored.

Proceeding to start a Distributed Calculation

The exact proceeding is displayed seperately for the servers and the Client system (KANAL++ project) in a numeration list.

Proceeding Server

The following steps must be repeated singularly for each server system:

• Start the server system
• You need direct access to the server system. Concerning a server operating system, this can be done by a terminal service console, or concerning a Windows 2000/XP system, has to be done by a local access.
• Make sure to have the necessary rights to access the used network drive reading/writing.
• DAYA must be executable, but must not be started.
• The RemoteDynaCallServer must be started. If the data RemoteDynaCallServer is not yet present on the system, it must first be made accessable for the system (locally or over the network drive). A console shows the utilizability of the RemoteDynaCallServer.

These Stepps must be arranged uniquely after the restart of the server system. The start of the RemoteDynaCallServers can also be made with autostart. The user who initializes the calculation on the Client, does not have to suit the user on the server system.

Proceeding Client

One assumes you already provided a calculable KANAL++ project. This is to be parallel computed now on several computers (servers).

1. Saving your project on a net drive and/or local. The distributed calculation can only be accomplished, if all servers and the Client have unrestricted access to the project listing. You can manage this, as the project is stored from the Client on a net drive connected before (Attention! Even if the net drive lies locally on the Client PC, it must be connected on the Client PC explicitly as net drive and the project must be deposited on the explicitly connected net drive. Only that way the system can determine the necessary path instructions). A further possibility is to store the project in a file directly accessible over the network environment. Follow network environment - > entire network - > Microsoft Windows network. Select now an available PC and store the project in a file, approved by this.

In this case, the storage path of the KANAL++ project (can be seen in the blue bar on top) should hold the following form:

\\Computername\Projectpath\Projectname.kpp

2. Distribution of the hydraulic variant. As already described, for the distributed calculation you need at least as many hydraulic variants as used network resources. If these are already present, continue reading at point 3. We assume now you have only one hydraulic variant you would like to calculate. The only meaningful distribution of a hydraulic variant occurs over the rains (hydraulic variants with only one rain can thus not be distributed). Now, build as many copies of the hydraulic variant as space is available in the network resources. Therefore, click on the hydraulic variant with the right mouse button and chose the menu option “create copy”. Thus an accurate copy of the already existing hydraulic variant is produced.

Now, the rainfalls to be calculated must be declared for each of the newly built hydraulic variants. This process must be performed for each of the copied hydraulic variants: double click on the hydraulic variant, afterwards chose the tab “rain”. Fill in the limits at “first rain to be calculated” and “last rain to be calculated”.

For the distribution of the rain intervals on the individual copies of the hydraulic variant it must be considered that each rain must occur exactly once in one of the variants and the dry periods between the distributions should be larger than the time for the emptying of the net. Thus, at the beginning of each hydraulic variant, one can assume a completely emptied net. (e.g. concerning 16 rains and 4 resources the intervals could be put in the following way: 1-4, 5-8, 9-12, 13-16 - the dry periods between rain 4 and 5, 8 and 9, 12 and 13 must be sufficiently large. Otherwise another, maybe not optimal, distribution must be found.)

3. Allocation of hydraulic variants to the network resources

Each hydraulic variant that shall be considered in the computation, a server must now be allocated, on which the computation is accomplished. This allocation takes place in the hydraulic variant dialogue in the tab “general”. At the lower end of the pop-up window the remote parameters are to be indicated. In order to implement the variant on another computer (server), the hook must set at „use remote computation”. If the hook is not set, the variant is implemented on the local system (Client). It is also possible to implement a variant or a part of a variant locally and to implement other variants remote on a server at the same time. Next, the server name must be indicated. For the identification the network names are used. KANAL++ analyses your network automatically when setting the remote hook and provides a choice of all available servers under „name of remote PC:”. This input field must be filled. In the last input field, it must be indicated by which path the file is Dyna.exe can be found on the server system. It must be considered that the path on the server, not on the Client, must possess validity.

A further important configuration parameter is „ number of threads for DYNA “. Here you indicate how many processors you fully want to occupy on the server system.

In case nothing has been indicated in the input fields “number of threads for DYNA” and “DYNA path”, the general settings for the DYNA computation are used automatically.

4. General computation settings for the DYNA computation. The selections for „comment files” and „use DNSCREEN“ are to be used just like in local computations. The “program path for DYNA “ is only relevant for the hydraulic variants, which did not indicate a „DYNA path“. Hereby you have the possibility to put down the DYNA.exe file on a net drive just as the KANAL++ project file and therefore make it accessible for all network resources. Concerning the parameter „number of Threads for DYNA “ it must be considered, if the hydraulic variant has no insertion, this one is used. If there also was no insertion (recommended), before the execution of DYNA, the number of processors on the system is determined and a 100% processor load is aimed at.

5. Starting the computation. Click „hydraulic variants“ with the right mouse button and chose the menu item “compute variants”. The dialogue below is displayed.

On the left, you see all hydraulic variants present in the project. With a double click, these can be transferred into the right chosing field on the right. The variants in the right chosing field are considered in the computation. It is important that the hook is set at “parallel”, because otherwise, the variants are executed sequentionally. If you confirm your choice with “OK”, the computation is started.

Before the actual computation with DYNA can occur, the DYNA input data must be written. This occurs sequentionally for all chosen hydraulic variants. In addition to this, the inserted storage path of the DYNA working files (if not already displayed in this form) is converted into a UNC-path. This has the advantage that project file does not have to be connected explicitly on the servers. With this UNC-path, every computer of the network can access to the DYNA working file, as long as the necessary rights are present.

After the input data has been written, the DYNA computation is started simultaneously on all displayed servers. For each hydraulic variant, a DN screen window is opened, in which the progress of the calculation can be observed.

When the computation of a hydraulic variant is finished, the result data is imported automatically by KANAL++. In the indication window, for each calculated variant the marked writing is displayed. The line “name of variant: computation successfully finished” is significant for the successful execution of the computation.

The distributed calculation is finished when each of the started hydraulic variants in the indication window is listed as “successfully finished“.

Error messages and their cause

1. Wrong name of remote PC or RemoteDynaCallServer not started of not available

Following error message is displayed, when an invalid network name has been inserted at “name of remote pc” or the RemoteDynaCallServer hast not been started on the denoted server.

Please examine the name for the remote pc inserted in the hydraulic variant. Ideally chose one of the predefined pc names. These are always correct network names.

As next step, you should examine if the RemoteDynaCallServer is started on the server (see "proceeding server").

If this does not lead to success, examine your firewall settings. The communication via RPC (Remote Procedure Call) must be released. Examine, if you have the necessary rights on the server PC.

2. Dyna could not be processed on the server system

In the message window it is indicated that the output file could not be opened. Examine the handed over parameters in the window of the RemoteDynaCallServer.

The Dyna path and the variant file must be valid on the server system. I.e. under the indicated path, it must be possible to start DYNA and the variant files must be accessible for the server (write and read) be.