Techila Distributed Computing Engine with MATLAB

Before proceeding, please add the folder containing the Techila Distributed Computing Engine MATLAB functions to the MATLAB search path. This can be done by following the steps listed below.

This will add the path containing the Techila Distributed Computing Engine MATLAB functions to the MATLAB search path and will attempt to save the search path for use in future MATLAB sessions. This is performed by saving the search path to a file called pathdef.m.

Note! You might receive a warning message if you do not have the right to modify the pathdef.m file. If this occurs, the MATLAB search path might need to be updated at the start of a new MATLAB session.

If you wish to make the path update process automatic but do not have the right to modify the pathdef.m file, you can update the MATLAB search path using the userpath or addpath commands. These commands can be added to the startup.m file in the MATLAB startup folder, which will update the MATLAB search path when launching MATLAB. Examples of the commands are shown below:

Or

The <full path> notation should be replaced with the path leading to your system’s techila folder. More information on how to modify the userpath and startup options can be accessed from MATLAB with the following commands:

To connect to your Techila Distributed Computing Engine environment, your computer must be able to establish a network connection with the Techila Server. To test that a network connection can be established, execute the following command in your MATLAB.

The function should return the value 0 if the network connection works. Any other return value is an indication of a problem. For a description of the error code values, please see Error Codes. The screenshot below shows the output when the network connection works ok.

Computational MATLAB Projects require that a local MATLAB compiler is available to compile the Techila Worker Code. Before proceeding, please ensure that the following MATLAB components are available:

When the above components are available, you can set up your MATLAB compiler by executing the following command in MATLAB:

The screen capture below illustrates what the output of the command looks like when a compiler is successfully configured:

Please note that compiled binaries are platform-specific and can only be executed on Techila Workers with a compatible platform, according to the table below.

The locally executable program used in this example is shown below.

The code contains a single for-loop, which further contains a single multiplication operation where the value of the counter variable is squared. The value of the counter variable will be replaced with the iteration number, which will be different in each iteration. The multiplication result will be stored in the result vector, which will be used to contain all multiplication results.

The locally executable program can be executed by changing your current working directory in MATLAB to the directory containing the material for this example and executing the command shown below:

Executing the command shown above will calculate 10 iterations and store the following variables in the result vector. The values generated during this simple program are illustrated in the image below.

The distributed version of the locally executable program that uses cloudfor-loops is shown below.

As can be seen, the locally executable for-loop has been replaced with a cloudfor-loop. The for and end words in the locally executable loop have been replaced with the cloudfor and cloudend keywords. This indicates that the code block in the loop structure will be executed on Techila Workers.

The stepsperjob control parameter has been used to define that two iterations should be calculated in each Job. For example, if the number of loops is set to 10, the number of Jobs will be 5 (number of loops divided by the value of the stepsperjob parameter).

The distributed version can be executed by changing your current working directory in MATLAB to the directory containing the material for this example and executing the command shown below:

After executing the command, the computational code will be compiled using the MATLAB compiler. Depending on your system, the compilation will take roughly one minute. After the compilation, the Project will be automatically created and consist of five (5) Jobs. These Jobs will be computed on Techila Workers, and the results will be streamed back to your computer. Results generated during the Jobs will be stored in the result vector at the applicable indexes. This is illustrated in the image below.

Tip! To view the effect of the stepsperjob control parameter, enter a different value for the parameter. You can also delete the line containing the control parameter entirely.

The locally executable program used in this example is shown below.

The program contains a single function, which will multiply elements in the vectors var1 and var2. The result of this multiplication will be stored in the result matrix (size of 3x3) at the coordinates indicated by the loop counter indices.

The function also defines a variable called dummyvar, created simply for illustrational purposes and is not used in the operations performed in the loop structure. The purpose of this variable is to demonstrate how using the control parameter to specify transferrable Workspace variables can reduce the amount of network transfer. This is explained in more detail later in this Chapter.

The locally executable program can be executed by changing your current working directory in MATLAB to the directory containing the material for this example and executing the command shown below:

Executing the command shown above will calculate 10 iterations and store the following variables in the result vector. The values generated during this simple program are illustrated in the image below.

The distributed version of the locally executable program is shown below.

The code contains two perfectly nested cloudfor-loops corresponding to the two perfectly nested for-loops in the locally executable program. Each cloudfor-loop also sets the value of the stepsperjob parameter to one (1), meaning the number of Jobs in the computational Project will correspond to the total number of iterations. As each loop contains three iterations, the number of Jobs in the Project will be nine (9).

The Workspace variables that should be transferred are listed on the line containing the inputparam control parameter shown below.

This parameter defines that the variables var1, var2, and result should be transferred to the Techila Workers. Variables var1 and var2 are required to perform the multiplication operation, and the result variable is required to store the multiplication result. The dummyvar variable is not used in the computation, meaning there is no need to transfer it; therefore, it is not listed.

The distributed version can be executed by changing your current working directory in MATLAB to the directory containing the material for this example and executing the command shown below:

Executing the command above will calculate each matrix element’s value in a separate Job. This is illustrated in the image below.

Tip! To see how the inputparam parameter reduces the amount of data transferred, remove the line containing the inputparam notation. This will cause the dummyvar variable to be transferred to the Techila Workers. This will raise the amount of data over the 10 Megabyte limit, meaning you will also have to override the 10 Megabyte safety limit discussed earlier in this chapter with the %cloudfor('force:largedata') parameter. After you have modified the code, you should see a much larger upload when creating the computational Project.

The locally executable program used in this example is shown below.

The program contains a single function, which includes two for-loop structures. Data files are loaded from the current working directory during the first loop. A different data file will be loaded for each iteration, and loading the data files will create two Workspace variables, x and y. These variables are used later in the code when performing conv2 and filter2 operations. These operations will create the result1 and result2 variables. These variables will be stored in an output file, and the iteration number will be included in the name of the file. These output files will be stored in the current working directory.

Once all the iterations in the first loop have been completed, the program proceeds to the second loop structure. During this loop, the values stored in the output files are read from the current working directory and then saved in the result variable. The function will eventually return this variable.

The locally executable program can be executed by changing your current working directory in MATLAB to the directory containing the material for this example and executing the command shown below:

The distributed version of the locally executable program is shown below.

The cloudfor and cloudend keywords mark the first loop structure for execution on the Techila Workers.

The code sets the value of the stepsperjob parameter to one (1), meaning the number of Jobs in the computational Project will correspond to the total number of iterations. This means that the number of Jobs in the Project will be three (3).

Streaming has been turned off with the parameter ('stream','false'). This ensures that the second for-loop will process output files in the same order as in the locally executable version.

The parameter ('donotimport','true') specifies that result files should not be loaded, but only added to the file list. Result files will be processed in the for-loop that will be executed after the Project has been completed.

The parameter ('resultfilevar',filelist) defines that the name and path of each output file returned from the Techila Workers will be stored in the filelist variable. The locations and names stored in this variable will be used during the second for-loop, where each output file will be unzipped to the current working directory.

The data files that will be transferred to all participating Techila Workers are listed on the lines containing the datafile control parameter shown below.

These parameters define that the files input_1.mat, input_2.mat, and input_3.mat will be transferred to the Techila Workers. There are two datafile parameter entries, meaning the data files will be placed in two separate Data Bundles. Files input_1.mat and input_2.mat will be placed in one Bundle, and file input_3.mat will be placed in another Data Bundle. All files will be copied to the same temporary working directory with the executable program on the Techila Workers. This means the data files can be loaded with the same command as in the locally executable version.

The output files that will be returned from the Techila Workers are listed on the line containing the peach OutputFiles parameter shown below.

The notation uses regular expressions and will cause all files starting with output_dist to be returned from the Techila Workers. These output files will be stored in ZIP-files, one output file per ZIP-file. Regular expressions are used because the name of the generated output file will be different in each iteration.

The second loop structure will unzip the ZIP-files containing the actual output files generated on Techila Workers. These output files will be unzipped to the current working directory, from where they will be loaded, and variables stored in the files will be loaded in the result variable.

The distributed version can be executed by changing your current working directory in MATLAB to the directory containing the material for this example and executing the command shown below:

Executing the command shown above will create a Project consisting of three Jobs. Each Job will calculate one iteration of the loop structure. The return values will be stored in the result cell array at the index indicated by the loop counter k value for each Job.

Tip! To see how using different Data Bundles for transferring different data files reduces unnecessary network transfers, modify the content of the input_3.mat file. After modifying the content, execute the run_datafile_dist command as earlier. After running the command, only one of the Data Bundles (the one containing the input_3.mat file) will be recreated and uploaded to the Techila Server. Files input_1.mat and input_2.mat do not need to be uploaded to the Techila Server because these are stored in a different Bundle.

The locally executable program used in this example is shown below.

The local_managing_results function will begin by initializing values, which will used to perform the following activities:

The program contains a single for-loop structure, which will perform two different operations. These operations are described below:

The locally executable program can be executed by changing your current working directory in MATLAB to the directory containing the material for this example and executing the command shown below:

[pi_value, primes]=local_managing_results();

After executing the above command, results should be displayed in the MATLAB Command Window containing information on the approximated value of Pi and the last 10 prime numbers found. The printout should resemble the one shown below.

The distributed version of the locally executable program is shown below.

The for and end words in the locally executable loop have been replaced with the cloudfor and cloudend keywords. These indicate the block of code that will be executed on Techila Workers. The function mcpi will be automatically included in the compilation as it is called within the cloudfor-loop structure.

The cloudfor-loop also uses control parameters to manage return values. These parameters are explained below.

%cloudfor('sum',pi_counter)

The control parameter above states that the pi_counter variables returned from the Techila Workers should be summed. This is required as the locally executable program uses the same variable to store and carry over results from previous iterations.

%cloudfor('cat',primes)

The control parameter above states that the primes variables returned from the Techila Workers should be concatenated. This is required as the locally executable program also uses concatenation.

%cloudfor('stream','false')

The control parameter above states that streaming should be disabled. This is required because the concatenated results in the primes vector must be in the same order as in the locally executable version.

%cloudfor('stepsperjob',1e4)

The control parameter above states that 10,000 iterations should be performed in each Job. This means that the Project will consist of 40 Jobs, as the total number of iterations performed is 400,000.

The cloudfor version can be executed by changing your current working directory in MATLAB to the directory containing the material for this example and executing the command shown below:

Return values received from the Jobs will be managed differently, depending on which control parameter was used. The pi_counter values will be summed, and the primes values will be concatenated. After the return values have been summed and concatenated, the final results will be displayed in the MATLAB Command Window and should resemble the ones received in the locally executable version. Please note that small deviations in the approximated value of Pi are expected because the mcpi function uses random numbers, and no fixed random number generator seeds are used.

The code for this example is shown below.

This example uses the functionality of the MyClass and MyOtherClass classes, located in the @MyClass and @MyOtherClass folders, respectively.

The source code of these classes is shown below for reference.

The cloudfor version can be executed by changing your current working directory in MATLAB to the directory containing the material for this example and executing the command shown below:

When executed, a Project with one Job will be created. During this Job, class methods multiply and divide will be used, and the return values of the methods will be returned to your computer.

The source code of the example discussed here can be found in the following file in the Techila SDK:

The code used in this example is also illustrated below for convenience.

In this example, the whoami command displays the domain and user name. When the whoami is executed for the first time (before the cloudfor-loop), it is executed on the End-User’s computer, meaning the command will return the End-User’s own AD user name. The user name will be stored in the local_username variable.

The cloudfor-loop used in this example sets the number of iterations to one. This means the Project will consist of one Job.

AD impersonation is enabled by setting the value of Project parameter techila_ad_impersonate to 'true'. This means all commands during the Job will be executed using the End-User’s own AD user account.

Inside the cloudfor-loop, the whoami command retrieves the user’s identity. This code line will be executed on the Techila Worker during the Job. Because AD impersonation has been enabled, this command should return the End-User’s own AD user name and domain. If AD impersonation is disabled, for example, by removing the techila_ad_impersonate Project parameter, this command would return the Techila Worker’s AD user name.

After Project completion, information about the AD user account used locally and during the computational Job will be displayed.

This example can be executed by changing your current working directory in MATLAB to the directory containing the material for this example and executing the command shown below:

After completing the Project, information about the AD user accounts will be displayed. Please note that the output generated by the program will change based on your domain and AD account user names. The example screenshot below illustrates the program output when the End-User’s own AD account name is techila and the domain name is testdomain.

The source code of the example discussed here can be found in the following file in the Techila SDK:

The code used in this example is also illustrated below for convenience.

In this example, the cloudfor loop will create a Project consisting of two Jobs. Each Job will generate a variable a and transfer the value of variable a as intermediate data back to the End-User’s computer. After the intermediate data has been received on the End-User’s computer, the data will be processed using an intermediate callback function named myfunction.

The function myfunction will display information about the data received from a Job, increase the value of variable a by 2, and send the updated value back to the same Job that sent the data using the function sendIMData. The loadIMData function call will load this updated value.

Each Job will return the updated value of the variable as the result. These results will be printed after the Project has been completed.

This example can be executed by changing your current working directory in MATLAB to the directory containing the material for this example and executing the command shown below:

The screenshot below illustrates what the output of the example looks like.

The source code of the example discussed here can be found in the following file in the Techila SDK:

The code used in this example is also illustrated below for convenience.

Code summary: The code will create a Project consisting of four Jobs. Simultaneous processing in Jobs is limited by using Project-specific and global semaphores. After completing the Project, the information about the semaphore usage will be displayed.

Below is a more detailed overview of the code.

The value of the jobs variable is set to four, which will later be used to set the number of Jobs in the Project to four.

The semaphore is created by using the Semaphore control parameter. The syntax used in this example will create a Project-specific semaphore named examplesema. The number of tokens in the semaphore will be set to two. This means that a maximum of two tokens can be reserved at any given time.

The code inside the cloudfor-loop is wrapped inside an if isdeployed statement. This is done to prevent the code from being executed on the End-User’s (your) computer when you run the example.

The current timestamp is retrieved using jobStart = clock; and will be used to mark the start of the Job.

After getting the timestamp, the Job will reserve one token from the Project-specific semaphore created using the control parameter. This command will wait indefinitely until a semaphore token has been reserved. This means the first two Jobs executing this function will reserve the tokens. The remaining Jobs will wait until semaphore tokens are released by the first two Jobs that reserved them.

After getting a semaphore token, the Job receives the current timestamp with techilaSemaphoreReserve('examplesema');. This is used to mark the start of the semaphore reservation time.

After this, the Job calls genload(30);, which will generate CPU load for 30 seconds by generating random numbers.

After generating CPU load, the elapsed time between the start of the Job (jobStart variable) and the return of the genload function call is calculated with the following two lines:

If a Job was able to reserve a token immediately, this value should be close to 0. If the Job had to wait for a semaphore token to become available (i.e., some other Jobs reserved the tokens), this value would be close to 30. Please note that you would get different values if the Jobs were started at a different time.

Information about the reservation time slot will be stored with:

After marking the reservation time slot, the token belonging to the Project-specific semaphore is released using techilaSemaphoreRelease('examplesema');.

After processing the code that uses the Project-specific semaphore, the Job attempts to reserve a token from a global semaphore called globalsema by using:

The syntax used in the call also defines that the job should be terminated if the token is reserved for over 20 seconds. The syntax also defines that the function should return, even if there were a problem with the semaphore reservation process.

If your Techila Distributed Computing Engine environment has a global semaphore called globalsema, the function will return the value true. If your Techila Distributed Computing Engine environment does not have a global semaphore called globalsema, the function will return the value false. Please note that your local Techila administrator will need to create global semaphores. This means that unless your local Techila administrator has created a semaphore named globalsema, the value returned by the function will be false.

Depending on whether or not the global semaphore could be reserved, the if-elseif branches will be executed respectively.

If the reservedok variable contains the value true, the following code block will be executed.

During these lines of code, five seconds of CPU load will be generated, and the token reservation time window will be calculated. After this, the token belonging to the global semaphore named globalsema will be released. After this, information about the time window when the Job reserved the global semaphore token will be stored in the result array.

The code block will be executed if the reservedok variable contains the value false.

In this case, a simple string containing an error message will be stored in the result variable.

The remaining code lines are outside the cloudfor-loop, meaning they will be executed after the Project has been completed. During this part, information about the semaphore reservation times will be displayed on the screen by printing the strings stored during Jobs.

The figure below illustrates how Jobs in this example are processes in an environment where all Jobs can be started simultaneously. In this example figure, the global semaphore globalsema is assumed to exist and contains only one token.

The activities taking place during the example Project are explained below.

After the Jobs have been assigned to Techila Workers, two of the Jobs are able to reserve a Project-specific semaphore token and begin generating CPU load. This processing is illustrated by the 'Computing, Project-specific semaphore reserved' bars. During this time, the remaining two Jobs will wait until semaphore tokens become available. After the first Jobs have released the Project-specific semaphores (i.e., after generating CPU load for 30 seconds), Jobs #3 and #4 can reserve semaphore tokens and start generating CPU load.

The global semaphore only contains one token, meaning only one Job can reserve a token at any given time. In the example figure below, Job #1 reserves the token and starts generating CPU load. This processing is represented by the 'Computing, global semaphore reserved' bars. After Job #1 has completed generating CPU load (i.e., after 5 seconds), the global semaphore is released, and Job #2 can start processing.

After Jobs #3 and #4 finish generating CPU load, the Jobs will start reserving tokens from the global semaphore.

This example can be executed by changing your current working directory in MATLAB to the directory containing the material for this example and executing the command shown below:

Please note that the output generated by the program will change based on whether or not the global semaphore named globalsema is available. The two example screenshots below illustrate the output in both scenarios.

Please also note that there might be overlap in the reported time windows. This is because the time windows are measured from the timestamp generated at the start of the if isdeployed block, which means that, e.g., initialization delays can cause the reported times to overlap.

The example screenshot below illustrates the generated output when the global semaphore exists.

The example screenshot below illustrates the generated output when the global semaphore does not exist.

Note! If the global semaphore does not exist, please contact your local Techila administrator for assistance. Creating a global semaphore requires administrative permissions, meaning only a Techila administrator can create them.

The locally executable function called local_function contains a simple algorithm that consists of a single for-loop. The algorithm of the locally executable function used in this example is shown below.

The program requires one input argument called loops, which defines the number of iterations performed in the loop structure. Each iteration performs the same arithmetic operation: 1+1. The latest iteration’s result will be appended to the result vector. The result vector for five iterations is shown below.

All arithmetic operations in the locally executable function are performed in the for-loop. There are no recursive data dependencies between iterations, meaning all the iterations can be performed simultaneously. This is done by placing the computational instructions in the Techila Worker Code in a file called distribution_dist.m.

Local Control Code (in the file run_distribution.m) will used to create the computational Project. The Techila Worker Code in the distribution_dist.m file is automatically compiled to a binary, which will be placed in the Executor Bundle and transferred to the Techila Workers, where the function distribution_dist will be executed.

The Local Control Code used to control the distribution process is shown below.

The function run_distribution requires one input parameter. This input parameter will specify the number of Jobs into which the Project should be split. This is performed by using the value of the jobs parameter to determine the length of the peachvector. Please see an illustration of the parameter dependencies in xrefstyle=short below. In this example, the params array is empty, which indicates that no parameters will be transferred to the Techila Worker Code.

In the last line, the result cell array will be converted into an ordinary array format using the cell2mat function. This conversion will take place after all Jobs have been completed and the results have been transferred back to the End-Users computer.

The Techila Worker Code executed on the Techila Workers is shown below.

Operations performed in the Techila Worker Code are equivalent to one iteration of the locally executable loop structure. As no input parameters will be transferred to the Techila Worker Code example, identical arithmetic operations are performed during all Jobs. This is illustrated below in xrefstyle=short.

The Project can be created by executing the Local Control Code using the command:

This command will create a computational Project that will consist of five Jobs. Because empty curly brackets represent the params array in the peach-function, no input parameters will be transferred to the Techila Workers. The Techila Workers will execute the computational operations in the distribution_dist function without any input parameters and return results to the Techila Server. The interaction between the Local Control Code and the Techila Worker Code is illustrated below in xrefstyle=short.

When the Local Control Code is executed using the syntax run_distribution(5), the computational operations illustrated in xrefstyle=short will take place on Techila Workers.

The algorithm for the locally executable function used in this example is shown below.

This function requires two input parameters; multip and loops. The loops parameter determines the number of iterations performed, and the parameter multip is a number that will be multiplied by the iteration number i. The result of this arithmetic operation will then be appended to a vector called result, which will be returned as the output value of the function. The result vector when five iterations are performed is shown below.

In the locally executable function, the computations performed in the for-loop have no dependencies between the iterations. Because of this, the operations in the for-loop can be performed on the Techila Workers. This can be achieved by extracting the operations into a separate piece of code, which will be compiled into an executable binary and sent to the Techila Workers for execution. Input parameters for the executable binary will be transferred with the params array (second input argument) of the peach-function.

The Local Control Code used to control the distribution process is shown below.

The run_parameters function takes two input parameters; multip and jobs. The value of the multip parameter will be identical on all Techila Workers. The value of the jobs parameter will be used to determine the length of the peachvector, meaning that the parameter also determines the number of Jobs in the Project. The peachvector elements are used as a dynamic input parameter as indicated by the <param> notation in the params array. The peach-function syntax in the Local Control Code is illustrated below in xrefstyle=short.

The Techila Worker Code executed on the Techila Workers is shown below.

The Local Control Code discussed earlier in this Chapter defined two parameters in the params array. One of these parameters was a static parameter, and the other was a dynamic parameter. In the Techila Worker Code, the static parameter is represented by a parameter called multip. multip is constant across all Jobs. The dynamic parameter in the Local Control Code is represented by the jobidx parameter, which will be replaced by a different element of the peachvector in each Job. As a result, the jobidx parameter simulates the iteration number of the locally executable function. Parameters transferred to the Techila Worker Code are illustrated in the image below.

The Project will be created by executing the Local Control Code using the command:

This will create a computational Project that will consist of five Jobs. The parameters in the params array in the peach-function call will be given values based on the input arguments of the run_parameters function. The Techila Workers execute the parameter_dist function using one static and one dynamic input parameter, as illustrated in xrefstyle=short below.

As mentioned above, the Local Control Code can be executed with the following syntax:

This will set the value of the static parameter multip to two (2). The peachvector will contain the integers from one to five. These integers define the value of the jobidx parameter in the Techila Worker Code. The computational operations resulting from the syntax shown above are illustrated below in xrefstyle=short.

The algorithm of the locally executable function used in this example is shown below.

The locally executable function local_function consists of two logical parts: loading input data into memory and performing analysis on this data. The input data is stored in a MAT-file called datafile.mat, which contains a 10x10 matrix of integers. The computational part calculates the mean values of each column in the datafile matrix. Each iteration of the loop structure calculates the mean value of a single column vector, meaning that the number of iterations is fixed to ten (10).

The distributed version consists of the same logical parts as the locally executable function: loading input data and performing some simple analysis of the data. This data is stored in the datafile.mat file, which will be transferred to Techila Workers with the files array, which is the third input argument of the peach-function.

The Local Control Code used to control the distribution process is shown below.

The Local Control Code run_data_files requires no input parameters; the number of Jobs is defined in the control code by the variable jobs. This is done by using the parameter to determine the length of the peachvector. The peachvector elements are also used as a dynamic input parameter in the params array as indicated by the <param> notation. The files array contains the string datafile.mat. This is the name of the file that will be transferred to all Techila Workers. The peach-function syntax used in the Local Control Code is illustrated in xrefstyle=short below.

The Techila Worker Code executed on the Techila Workers is shown below.

The Local Control Code introduced earlier in this Chapter defines one dynamic input parameter. This is represented in the Techila Worker Code by the jobidx parameter, which will get replaced by a different element of the peachvector in each Job. This means the jobidx parameter can point to the correct column vector during each Job.

The Local Control Code also introduced one (1) filename in the files array. This file will be copied to the same temporary working directory at the Techila Worker with the executable binary, which means that the file datafile.mat can be loaded into memory using the same syntax as in a locally executable function.

The project can be created by executing the Local Control Code using the command:

The number of Jobs in the Project will be automatically fixed to ten as the value of the jobs parameter is defined in the Local Control Code. Parameters in the params array and the file specified in the files array will be transferred to the Techila Workers. During each Job, the executable binary will be executed with one input argument, which will be a different element of the peachvector for each Job. The datafile.mat file can be accessed similarly to the locally executable version because the file has been copied to the same temporary working directory with the executable binary. The interaction between the Local Control Code and the Techila Worker Code is illustrated in xrefstyle=short below.

The algorithm of the locally executable function used in this example is shown below.

The function requires no input parameters. Each element of the matrix A is multiplied separately inside a perfectly nested loop structure. The result of the operation will be stored in the result matrix at the subscript indices determined by the values of the loop counters.

The Local Control Code used to distribute computations that occur within a perfectly nested loop in this example is shown below.

The params array contains three parameters; one of the parameters is dynamic, and two of the parameters are static. Parameter siz contains the size of the matrix and will be used to convert jobidx to subscript format on the Techila Workers.

The Techila Worker Code executed on the Techila Workers is shown below.

Each Job will operate on one element of the two-dimensional matrix. The value of the jobidx parameter will determine which matrix element will be operated on. This is done by converting the jobidx parameter to subscript format and using it to point to the correct matrix element.

The project can be created by executing the Local Control Code using the command:

The Project will automatically be divided into nine Jobs, as the value of the jobs parameter was defined in the Local Control Code. Parameters defined in the params array will be transferred to the Techila Workers. Elements of the peachvector (stored in the jobidx variable) parameter will be converted to subscript format on the Techila Workers by using the inbuilt ind2sub function.

It is possible to test the Techila Worker Code locally. This means that it is not necessary to create a separate project for testing purposes. Local testing can be done as follows.

The locally executable function for approximating the value of Pi used in this example is shown below.

The function requires one input argument to determine the number of iterations in the for-loop. During each iteration, two random values will be generated. These will be used as the coordinates of the random point. The coordinates of the point are then used to calculate the distance of the point from the center of the unit circle. If the distance is less than one, the point is located within the unit circle, and the counter is incremented by one. As soon as all iterations have been completed, the value of Pi will be calculated.

The locally executable version of Monte Carlo Pi can be executed using the command:

This will calculate the approximated value of Pi using 10,000,000 randomly generated points.

Random number sampling is the computationally intensive part of the Monte Carlo method. The sampling is performed in the for-loop in the locally executable function. There are no dependencies between the iterations. This means the sampling process can be divided into separate functions and executed simultaneously on several Techila Workers.

Note that when using the peach-function, the seed of the random number generator is initialized automatically on the Techila Workers by the peachclient-wrapper. If you wish to use a different seeding method, please seed the random number generator directly in the code you want to execute on Techila Workers.

The Local Control Code used in this example to control the distribution process is shown below.

The Local Control Code contains two code lines with distinctly different roles. The line containing the peach-function call creates the computational Project to the Techila Distributed Computing Engine environment. The last line is executed after the Project is completed and includes the instructions for post-processing procedures.

The peach-function call defines that the function mcpi_dist will be deployed and executed on Techila Workers. The mcpi_dist function will receive one input argument called loops, defined in the params array. The peachvector is only used to control the number of Jobs in the Project.

The code executed on Techila Workers in this example is shown below.

The algorithm is very similar to the algorithm of the locally executable function. The function requires one input argument called 'loops', which is used to determine the number of iterations. During each iteration, the distance of a randomly generated point from the center will be calculated. If the distance is less than one, the point is within the unit circle, and the count is incremented by one. The only differentiating factor is that the post-processing activities, which otherwise would take place after the for-loop, are not being implemented.

The computational Project can be created with the command shown below:

This will create a Project consisting of ten Jobs, each performing 1,000,000 iterations. The Jobs are distributed to Techila Workers, where the Monte Carlo routine in the Techila Worker Code is executed.

When a Techila Worker finishes the Monte Carlo routine, it sends the results to the Techila Server. After all the Techila Workers have transferred the results to the Techila Server, the results are transferred to the End-User’s computer. After the results have been downloaded, the last line in the control code is executed, which contains the post-processing operations, which in this case consist of scaling the results according to the number of performed iterations.

The Local Control Code to create a Project using Snapshotting with default values is shown below.

When using the default values for Snapshotting, the Local Control Code will not require any changes. The two parameters controlling the Snapshotting process, the snapshot file name and the upload interval, will be set to default values inside the peach-function.

As the Local Control Code did not specify any custom settings for Snapshotting, the procedure will use default values. The upload procedure will be automatic, but the Techila Worker Code must be modified so the program can initialize properly if computations resume from a Snapshot file. The Techila Worker Code will also need to be modified to generate snapshot files at a frequency that serves the purposes of the code. The modified Techila Worker Code using Snapshotting is shown below.

Initialization of the Techila Worker Code will set values for two variables, result and iter. These initialized values will be used if no Snapshot files can be found. If a Snapshot file exists, it will indicate that the Job is being resumed after an interruption. In this case, the content of the Snapshot file will be used to override the initialized values. This will be done using the loadSnapshot function, which automatically loads the contents of the Snapshot file to the workspace. Iterations will be resumed from the last value stored in the Snapshot file.

Intermediate results will be stored in the Snapshot by calling the saveSnapshot function every 1e8th iteration. The variables stored in the snapshot file are iter and result. Variable iter will contain the number of iterations performed until the snapshot generation occurs, and result will contain the intermediate result.

The Project can be created by executing the Local Control Code using the command:

This will create a Project consisting of 10 Jobs, where each Job will consist of 1e9 iterations. Intermediate results will be saved every 1e8th iteration. Snapshot files will be transferred every 15 minutes from the Techila Worker to the Techila Server. Suppose a Job is migrated to a new Techila Worker while the Job is being computed. In that case, the latest available Snapshot file will be automatically transferred from the Techila Server to the new Techila Worker.

Snapshot data can also be viewed and downloaded using the Techila Web Interface. Instructions for this can be found in the Techila Web Interface End-User Guide.

Note that when using the syntax shown above, the execution time of a single Job is relatively short. This might result in completing the job before a Snapshot file is transferred to the Techila Server. If Snapshot data is not visible in the Techila Web Interface, consider increasing the number of iterations to increase the execution time of a Job.

The Local Control Code of the Monte Carlo Pi, where a Callback function and Streaming are used, is shown below.

The Local Control Code here consists of run_stream and summc functions. The run_stream-function will distribute the computations using the peach-function. The summc-function is the Callback function executed every time a new result gets streamed from the Techila Server to the End-User. The variables used in the Callback function are declared as globals in both functions, meaning that all functions can access these variables.

CallbackMethod defines the name of the Callback function used in handling the results. This example will call the summc-function for each result.

CallbackParams defines the input arguments of the Callback function. In this example, the Callback function will be given the value of the variable loops as the first argument, defining the number of iterations performed in each Job. The second input argument will be defined by '<result>'. This notation tells the Callback function to use the output value of the Job as its input argument. In this example, '<result>' will be replaced by the value of the result variable, which is returned by the Techila Worker Code.

The Callback function summc contains the arithmetic operations to update the approximated value of Pi continuously. This approximated value is then compared to the Pi value in MATLAB to determine the absolute error. The value of this error will be plotted on a graph every time 10 new results are received and processed.

Streaming does not require any modifications to the Techila Worker Code that will be executed on the Techila Workers. The code is identical to the basic Monte Carlo Pi implementation presented Distributing Monte Carlo Pi with the peach-Function.

The computational Project can be created by using the command:

This will create a Project consisting of 100 Jobs, where every Job will perform 200,000 iterations. Results will be streamed from the Techila Server to the End-User as they are completed, and the graph will be updated every time 10 new results have been post-processed. The interaction between the Local Control Code and results received from the Techila Workers is illustrated in the figure below.

The Local Control Code for creating a Project that uses Job-Specific Input Files is shown below.

The JobInputFiles parameter specifies files that should be used in each Job. The syntax used in this example is shown below:

This syntax assigns one input file for each Job. The file input1.png will be transferred to a Techila Worker with Job #1, input2.png will be transferred with Job #2, and so on. The number of entries in the Job Input File list equals the number of elements in the peachvector.

The JobInputFileNames parameter specifies the names of the Job Input Files on the Techila Workers. The syntax used in this example is shown below:

This syntax assigns the name quadrant.png to all Job-Specific Input Files.

The Techila Worker Code used to analyze the individual input files is shown below.

In this example, all the Jobs access their input files by using the file name quadrant.png. Each Techila Worker then calculates the number of black pixels in their image by examining the intensity values of each pixel. The number of black pixels is returned as the result.

The computational Project can be created by using the command:

This will create a Project consisting of four Jobs. The system will automatically assign a Job-specific Input File to each Job according to the file list specified in the Local Control Code. This is illustrated below in xrefstyle=short.

The code used to control the distribution process of the precompiled binaries is shown below. Note that the funcname parameter can be used quite freely in this example. This is because the names of the executable binaries are defined with the Binaries parameter.

The Local Control Code consists of two functions; run_binary and getdata:

The peach-function call contains the following parameters:

The above parameter specifies that the name of the binary for Windows Techila Workers is mcpi.exe and mcpi for Linux Techila Workers.

The above parameter specifies that the funcname parameter refers to a precompiled binary.

The above parameter specifies that a MATLAB Runtime Bundle will not be required.

The above parameter specifies that the callback function’s name is getdata. This function will load the output files' contents and retrieve the values returned from the Jobs.

The above parameter specifies the loops variable as a Project parameter, making it available for the executable binary as a Job input parameter. This input parameter is used by referring to it in the params array with the %P(loops) notation.

The above parameter specifies the name of the output file, making it available to the binary by referring to it in the params array.

The params array in the peach-function call is shown below:

This defines two input parameters and one output file for the mcpi executable. The figure below illustrates how these input parameters are transferred to the binary.

Each Techila Worker performs the Monte Carlo routine by executing the precompiled mcpi.exe or mcpi binary. The binary is executed according to the input arguments defined in the peach-function params array.

The Project can be created by executing the Local Control Code using the command:

This will create a Project consisting of 10 Jobs. The mcpi binary will be executed during each job, and a Monte Carlo routine of 100,000 iterations will be performed. After completing the Monte Carlo routine, the approximation result will be stored in a file called data. This file will be returned from the Techila Workers to the Techila Server. After completing all Jobs, the output files will be transferred to your computer.

After the output files have been transferred to your computer, each file will be processed using the getdata-function. This function will load each output file and retrieve the first value from the file, containing the number of points inside the unit circle for each Job. This value will be returned from the Callback-function, meaning the peach-function will also return it as an element of the result-vector.

After all output files have been processed, the values in the result-vector will be used to calculate the approximated value of Pi.

The Local Control Code to include MEX files in a computational Project is shown below.

The use of MEX files is defined with the following parameter:

The parameter pair defines that the file mcpi.c is required in the computations and must be compiled and transferred with each Job. This file is located in the same directory as the mcpi_wrapper.m file and other files related to this example.

The Techila Worker Code used in this example is shown below.

The executable function mcpi_wrapper is a wrapper for calling the MEX file. The syntax for calling the MATLAB executable is the same as it would call a built-in function. After the MEX has been executed, the return value will be stored in the result variable, which in turn will be returned from the Techila Worker.

The MEX code is shown below.

The algorithm in the MEX file requires using two input parameters: jobidx is used to initialize the random number generator seed, and loops is used to determine the number of iterations done in the Monte Carlo routine. The results are stored in a variable named output, which will be returned as the output value of the mcpi_wrapper function.

The Project can be created using the command:

This will create a Project of 10 Jobs, each performing 1,000,000 iterations. The mcpi.c file will be automatically compiled and transferred to Techila Workers. The Monte Carlo approximation will be done by executing the Monte Carlo algorithm in the MEX file according to the values defined in the params array.

Projects can be detached using the following parameter:

This will cause the peach-function to return immediately after the Project has been created and all computational data is transferred to the Techila Server. The peach-function call will return the Project ID number, which can be used in the download process.

Results can be downloaded by linking the peach-function call to an existing Project ID number using the following parameter pair:

It is also possible to download the results of the previously completed Project (assuming the results have not been removed from the Techila Server), even when the original Project has not been detached with the DoNotwait parameter. Results from such Projects can be downloaded by defining the Project ID number as the value of the projectid parameter. For example, the following syntax would link the peach-function call to Project 1234.

The following example demonstrates detaching a Project and downloading results using a peach-function call.

The Local Control Code for creating a Detached Project is shown below.

The Project is detached with the parameter pair:

This parameter pair causes the peach-function to return immediately after the Project has been created. The variable projectid will contain the Project ID number of the Project that has been created. This Project ID number can be used to download the results.

As soon as the Project has been completed, the results can be downloaded by performing a peach-function call. The peach-function call is linked to an existing Project ID. The algorithm of the function used to download the results is shown below.

The function download_pi_results will download the results. The peach-function will only be used to contact the Techila Server and request the results. This means that funcname and params and parameters will not be required here.

The ProjectId parameter will specify the Project ID number to which the peach-function call should be linked to. The input argument of the download_pi_results function will define the parameter’s value.

The code that is executed on the Techila Workers is shown below.

The Techila Worker Code is similar to the basic implementation shown in Distributing Monte Carlo Pi with the peach-Function. The only difference is that the result also contains the number of iterations performed during the Monte Carlo routine. The number of iterations is stored to preserve information required in the post-processing. Embedding the necessary variables in post-processing in the result files means that the post-processing activities can be performed correctly regardless of when the results are downloaded.

The computational Project can be created by executing the following command:

This creates a Project consisting of ten Jobs. After all the computational data has been transferred to the Techila Server, the Project ID number will be returned to the projectid variable. The Project ID number can be used to download the Project results after all the Jobs of the Project have been completed.

After the Project has been completed, the results can be downloaded from the Techila Server with the download_pi_results function using the syntax shown below:

The Local Control Code used to create several consecutively created Projects is shown below.

The peach-function call is placed inside a loop structure, implemented with a while statement. The while-clause is true if the error of the approximated value of Pi exceeds the threshold value. When the error is greater than the threshold value, a new computational Project will be created to improve the accuracy of the approximation. Intermediate results will be saved locally every time the latest Project results become available.

The algorithm for the Techila Worker Code is shown below.

Apart from the random number seeding method, the code is identical to the one in Distributing Monte Carlo Pi with the peach-Function. The random number seeding is done to ensure that the Jobs in the Projects generate such results that the error threshold is reached after a reasonable number of Projects.

The Local Control Code can be executed using the command:

The command shown above will create Projects consisting of 10 Jobs. Each Job will consist of 10 million iterations. Projects will be created until the error of the approximated value is smaller than the threshold value. The approximation error will be printed every time a Project has been completed.

The code for the Techila SDK example that illustrates how to use the 'sendDataToJob' and 'recvDataFromJob' functions is shown below:

The above code will create a Project consisting of two Jobs, each with one iteration. Each Job will transfer a short string to the other Job in the Project. After both Jobs have sent (and received) the data, the Project will be completed.

Below is an illustration of the interconnect data transfer operations that will be performed in this Project when the Jobs are assigned to Techila Workers.

Below is a more detailed explanation of the effect of each line in the code sample.

The below line shows a control parameter, which is used to define that the number of iterations in each Job should be set to one:

Note! If the stepsperjob parameter were removed, the Project would only contain one Job (because iterations are extremely fast, meaning they would be grouped into a single Job). In this case, when the Job would be started on a Techila Worker, the Job would execute the first if-statement. This if-statement contains a SendDataToJob command that attempts to send data to Job #2. This transfer attempt fails because there would not be Job #2 to receive the data.

When performing interconnect computations in a Techila Distributed Computing Engine environment, it is recommended that you set the number of iterations per Job manually by using the stepsperjob parameter. This will ensure that you can design your code to perform every interconnect data transfer predictably.

The line below shows the syntax for defining that only Techila Workers from the Techila Worker Group called IC Group 1 are allowed to participate. Note! This parameter is commented out in the example, meaning the Techila Worker Group limitation will not be active. If you wish to activate the limitation that only Techila Workers from Techila Worker Group IC Group 1 are allowed to participate, remove the additional %-character from the start of the line.

Note! If interconnect Techila Worker Groups are named differently in your Techila Distributed Computing Engine environment, replace IC Group 1 with the applicable name. Please get in touch with your local Techila Administrator for more details.

The code executed on Techila Workers is placed inside an if isdeployed statement. This is required to prevent the code from being executed locally on the End-User’s computer.

The computational code executed on the Techila Workers contains two if statements, determining the operations executed in each Job. Job #1 will execute the code inside the first if-statement (x==1), and Job #2 will execute the code inside the other code branch (x==2).

Job #1 will start by executing the sendDataToJob, which transfers data to Job #2. Job #2 starts by executing the recvDataFromJob command, which reads the data being transferred by Job #1.

After Job #2 has received the data, the roles are reversed, meaning Job #2 will transfer data to Job #1. After Job #1 has received the data, each Job will continue execution.

Jobs will continue execution only after all Jobs have reached and executed the waitForOthers command.

In this example, the results will be stored in the 'jobres' cell array, where each cell element corresponds to the result generated in one Job. The first element corresponds to the result generated in Job #1, and the second cell element contains the result from Job #2.

This example can be executed by changing your current working directory in MATLAB to the directory containing the material for this example and executing the command shown below:

After executing the command, the computational code will be compiled using the MATLAB compiler. After the compilation, the Project will be automatically created and consist of two (2) Jobs.

After both Jobs have been assigned to Techila Workers, the interconnect network will be automatically established. After the interconnect network has been established, the Jobs will exchange messages. After messages have been exchanged, the Jobs will be marked as complete. The exchanged messages will be returned back to your computer and stored in the jobres cell array.

The code for the Techila SDK example that illustrates how to use the cloudbc function is shown below:

The function run_broadcast takes two input arguments: the first input argument (sourcejob) defines which Job will broadcast the data, and the second input argument (jobcount) defines how many Jobs there will be in the Project.

The Job starts by creating a workspace variable called datatotransfer:

This datatotransfer variable will be a string and will always start with the fixed string `Hi from Job `. This fixed string will be concatenated with the value of the cloudfor-loop counter for each Job. For example, the table below contains the values of the data transfer variable in each Job in a Project consisting of 3 Jobs.

The following cloudbc function call broadcasts the data from one Job to all other Jobs in the Project.

The variable source job value will determine which Job will broadcast data. The data that will be transferred is defined by the value of the datatotransfer variable. For example, if the value of the sourcejob variable is 2, then Job #2 will broadcast the string Hi from Job 2 to all other Jobs in the Project.

In each Job, the cloudbc function will return the string that was broadcasted and store it in the jobres cell array at the index specified by the cloudfor-loop counter.

After data has been transferred, the waitForOthers()command will be executed. Each Job in the Project will wait until all other Jobs have also executed this command before continuing.

This example can be executed by changing your current working directory in MATLAB to the directory containing the material for this example and executing the command shown below:

When executed with the above syntax, the code will create a Project consisting of three (3) Jobs. Job #2 will broadcast data to other Jobs in the Project. The below figure illustrates the operations that occur when the code is executed with the syntax shown above.

Tip! Feel free to modify the values of the input arguments, but please note that there need to be enough available CPU cores to process each Job simultaneously. If all Jobs are not processed simultaneously, the Project will fail during the initialization phase because the interconnect network cannot be established.

The code for the Techila SDK example that illustrates how to use the sendDataToJob and recvDataFromJob functions to transfer data between all Jobs is shown below:

The above code will create a Project with 4 Jobs where simple strings will be transferred from each Job to all other Jobs in the Project.

The Job is started by creating an empty cell array called dataall that will be used to store the strings received from other Jobs in the Project.

The number of Jobs in the Project is retrieved by getting the environment variable TECHILA_JOBCOUNT value.

The Job’s index number is retrieved by getting the value of the environment variable TECHILA_JOBID_IN_PROJECT. This value will be stored in the jobidx variable, will be unique for each Job, and will range from one to four.

The switch statement will use the value of the jobidx variable to determine what message the Job will transfer to other Jobs in the Project. The table below contains the messages transferred from each Job.

After deciding which message the Job should send, the Job will execute the for-loop structure, which determines the order in which messages are transferred. The transferred messages will be concatenated to the dataall cell array and returned to the End-User’s computer.

The interconnect data transfers during the Project are illustrated in the figure below. The arrows indicate that interconnect data is being transferred. The values in parentheses correspond to the values of the src and dst loop counters. For example, the arrow with value (1,3) means that Job #1 sends the msg string to Job #3. If src equals dst (e.g. (2,2)), no data is transferred because the source and target are the same.

After all messages have been transferred, the trailing comma from the string stored in the cell array dataall will be trimmed.

This example can be executed by changing your current working directory in MATLAB to the directory containing the material for this example and executing the command shown below:

When the command is executed, the code will create a Project consisting of four (4) Jobs. Each Job will transfer a simple string to all other Jobs in the Project. These transferred strings will then be returned to the End-User’s computer. After completing the Project, the transferred messages can be viewed by accessing the cell elements. For example, the below syntax can be used to access messages transferred to Job #1.

The following code snippet illustrates how to create a Project where the smallest random number is searched and broadcasted to all Jobs using the cloudop-function.

The Job is started by generating one random number, which is stored in the inputdata variable. This is a local workspace variable, and the value will be different for each job.

After generating the random number, the cloudop function will be used to find the smallest value from the local inputdata variables using the min function. The cloudop function syntax only specifies two input arguments, meaning the result of the operation will be broadcast to all Jobs.

This example can be executed by changing your current working directory in MATLAB to the directory containing the material for this example and executing the command shown below:

Executing the command will create a Project consisting of four (4) Jobs. Each Job will start by generating a local random number. The cloudop-function will then search for the smallest numeric value from the local 'inputdata' variables. The smallest value will be returned in each Job and stored in the 'result' array, which will be returned to the End-User’s computer.