Glossary and Quick Reference Guide

[ A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z ]

A

PrePALM attribute of a communication sending an object to the buffer. It means that the object is linearly combined with a previous instance of the same object (same name, time, and tag) in the buffer. The user provides the linear cofficients for the old and the new version of the object: for instance the coefficients (1., 1.) correspond to "old + new", the coefficients (1., -1.) to "old - new", and (0.5, 0.5) to the average of the two. This is a shortcut for assembling objects in the buffer and can be replaced by a more general linear combination taken from the algebra toolbox. An object stored in the buffer via an "" communication has the "not ready" state and must be set to "ready" with an action described among the step-actions before being received.

The algebra description files describe the feature of on algebra unit or macro-unit. Some files are distributed within the algebra toolbox and cannot be modified by the users. Users can create the files for the algebra macro-units using the algebra composer. The user defined files can be exported and imported by different instances of PrePALM. This feature allows for the exchange of algebra macro-units among users. From the files the algebra composer compiles the service files used by PrePALM for the generation of the PALM files.

The algebra service files are used by PrePALM for the generation of the PALM files when algebra units are used in the application. The files for the units of the algebra toolbox are distributed with PrePALM. The files for the user defined macro-units are obtained compiling the files in the algebra composer.

PALM allows the separation of the algebra from the physics of the application. The physics are in the units, the structure of the algorithm is defined via the branches and the communications. The algebraic operations (linear combinations, linear systems solving, eigenvalues and eigenvectors computing, minimizers, ...) can be treated as special units not belonging to branches and available from a toolbox.
In order to avoid redundant storage of intermediate results, the user can combine several algebra units in a single macro-unit.

The user defined algebra macro-units are obtained by composition of units from the algebra toolbox, Fortran code and control structures. The algebra composer is the graphical tool to describe the composition. The description is stored in the files which can imported and exported by different instances of PrePALM. This feature allows for the exchange of algebra macro-units among users. Starting from the files, the composer compiles the service files used by PrePALM for the generation of the PALM files. The use of the algebra composer is explained in session ten of Tutorial One.
Top of page

B

In order to synchronize two or more branches it is possible to force a rendezvous. A barrier is enabled by the attribute of a primitive invoked by the concerned branches. The branches will be blocked until every concerned branch has reached the step.

For distributed objects: it indicates the rank of the descriptor reference unit process(or) (cf. the entry).

A branch is a sequence of PALM units. Units belonging to the same branch will be executed sequentially, but several branches can run concurrently. A branch can start at the beginning of the execution ( attribute) or can be invoked by another branch via the Start instruction.
A branch is defined by a control code in the input file. At the generation of the PALM files each branch generates a FORTRAN 90 file to be linked with the application.
The instructions in a branch are:

The buffer has to be considered as a common storage space accessible by all units. The buffer can be distributed, spanning several processors: it occupies part of the memory of the driver and can dynamically be extended over idle processors. A distributed garbage collection mechanism ensures that the processors are released when they are not needed anymore. The objects stored in the buffer can have two states: "ready" to be received or "not ready" for reception.
Objects can be inserted in the buffer by any unit (ordinary or from the algebra toolbox) via an ordinary communication. A communication with the "Insert/Replace" attribute (PL_INS keyword) inserts an object all at once. Communications with the "Add" attribute (PL_ADD keyword) contribute to an object in the buffer. In this case the state of the object being assembled is set to "not ready" till the termination of the assembling.
Objects can be recovered from the buffer via an ordinary communication, only if their state is set to "ready". In such a case the object is not consumed but it remains in the buffer until it is freed with a "delete" action described among the step-actions.
See the section on the PALM run-time components for further details.
Top of page

C

The calendar for "date to integer" conversion. (cf. the entry).
Accordingly to the NetCDF Climate and Forecast (CF) MetaData convention, the user has the choice between:

The PrePALM graphical user interface is based on the branches graph, with the units in sequence and the communication patterns plus few indications relative to the algorithm control structures (e.g. do loops) and some comment texts. The window pan where graphical items are displayed is called the "canvas".

The mean for a unit (or a branch) to receive (get) or to release (put) an object. The PALM paradigm is based on end-point communications. A unit simply notifies that an object is asked () or made available (). The user defines the correspondence between the two sides of the communication via the PrePALM interface. Communications can be established between two ordinary units, between a unit and the buffer and between an ordinary unit and an algebra unit. Because a get is blocking, communications might be an esay way to synchronize units.
The LIOO protocol is used.

A facility to set a user defined readonly integer variable in the shape or of the element size of a space, the branch code, the time or tag ranges of a communication in PrePALM. To ensure coherence with the analogous parameters used in the units, when the PALM files are generated a FORTRAN 90 module containing all the constant declarations is created in the file.

(Unit execution context)
When a distributed or an algebra unit are launched, the driver dynamically allocates for this purpose the needed number of idle processors: these constitute the execution context. There is no warranty that different successive instances of the same unit will use the same processors nor that two units belonging to the same branch can will share the same processors. It can be useful in certain cases (use of static variables, re-entering routines like reverse communication solvers, ...) to force successive instances of the same unit or two different units to reuse the same context. It can be obtained by selecting in PrePALM a static execution context. Notice that this strategy puts strong constraints on the dynamic allocation of resources and can lead to a deadlock of the application for lack of resources.

An algebra unit is dynamically launched by the driver. The driver has the choice between executing the operation on one of the service processes allocated to the driver, the buffer or the mailbuff or to dedicate an idle process to the algebra unit. class units are executed on the service processes and class units run on dedicated processes. The choice is operated in PrePALM when inserting or editing an algebra unit. Notice that some operations strictly need to run on dedicated processes (it is the case, for instance, of units implementing iterative algorithms in reverse communication): in such a case the user choice is neglected.

One kind of distributed objects descriptor (cf. the entry).
Top of page

D

By the means of this menu in PrePALM the user can set the calendar, the reference date and the reference time stamp for date to integer conversions and can invoke the PALM_Time_convert utility to translate GMT dates into integer time stamps (or time stamp ranges) and viceversa. This function is needed in PrePALM to express communications time ranges with the same time format used by the communication primitives PALM_Get and PALM_Put in the units.

In order to diagnostic the results of part of a simulation or to check the correctness of some data, the user can apply specific procedures to the objects exchanged via a communication. These user defined procedures are implemented in the palm_debug.f90 file which is user provided and which has to be linked with the application. Debug is activated or not according to a communication attribute (set via the PrePALM interface): The debug procedures can produce diagnostic output in the standard palm output files (unit PL_OUT) and can return an error code which is propagated back to the user code as an output argument of PALM_Get or PALM_Put. Further details are given in the chapter about the diagnostic tools.

A distributor can be described at run-time. In this case the identity card indicates the name of the user provided function which describes the distributor. A template with the proper syntax for a distribution function is provided with the PALM releases.

It is the semantic entity in the identity card of a parallel unit which describes the objects placement in the unit processes. unit. Three kinds are available A distributor description is relative to a base processor of the unit, which is numbered 0 in the distributor. It points to the first process of the distribution (notice that a distributor may not concern all the processes of a unit). For a non-distributed (SINGLE_PROC) object sent by only one process of a parallel unit, the base processor points to the process issuing Its syntax is explained in session six of Tutorial One.

The driver is the PALM orchestra conductor. It is the supervisor of the whole application and therefore it drives all the dynamic decision processes (allocation of idle processors, routing of communications through the mailbuff, distribution of the buffer , etc ...). Further details on the role of the driver are given in the section on the PALM run-time components.
Top of page

E

One of the properties which define a space (cf.).

All PALM primitives return an integer error code as last argument. The error code is 0 if no error occurred. If the error code is not 0, a mnemonic description of the error can be printed to the standard palm output files via a call to the primitive.
Top of page

F

Top of page

G

In the PALM end-point approach, this is the point of view the communication target side. See

Acronym for Graphical User Interface. See .
Top of page

H

One of the two algebra units cost classes.
Top of page

I

Description of units properties, spaces, input/output objects and distributors. Its format is described in the section on the PALM set up components.

At the beginning of a PALM application all the processors but one (the driver) are idle. The driver, then, dynamically allocates processes from the idle processors pool to branches, units or to the distributed buffer. The processors released by terminated units, finalized branches or by the shrinking of the buffer join again the idle processors pool. In case of lack of resources the driver handles a list of pending requests (N.B. this situation can lead to deadlock).

In order to optimize the performances of the execution, each processor keep a local . This is used to avoid message passing transfers between the processor and the central mailbuff for pending communications whose source and target will certainly run on the same processor. This is the case for mono-processor units belonging to the same branch or for re-entering sticky units. To avoid the local mailbuff fills up the processor memory, this feature is optionally activated by the user via PrePALM

Attribute of a communication sending an object to the buffer. It means that the object is inserted all at once and that it overrides any previous instance of the same object in the buffer. An object stored in the buffer via an "" communication has the "ready" state.

The design of PALM is based on the assumption that exchanged objects share the same grid representation on the source and on the target side. Therefore there is no grid to grid interpolation in PALM. The only interpolation performed by PALM is between different time instances of the same object (cf. the entry).
Top of page

J

calendar
The julian calendar for "date to integer" conversion. (cf. the entry).
Top of page

K

Top of page

L

The action by which a branch invokes the execution of a unit. When a branch launches a unit, it is suspended and its processor is used by the unit. If the unit is distributed over n processes, its execution actually begins only when (n-1) idle processors are available.

The PALM library. Provided with the distribution. It has to be linked with the application.

The Last In Only Out protocol for communications. Following this protocol the target of a communication will always receive the most recent version of an object produced by the source. Freshly produced versions of an object override the previous ones. With this protocol there is no need of a message queue, but some synchronization problems can arise (see the section on the PALM actions concerning the data exchange for further explanations).

One of the two algebra units cost classes.
Top of page

M

The predefined units from the algebra toolbox execute one operation at the time. Inputs are recovered and outputs are sent or stored via the ordinary PALM communication mechanism. If an algebraic treatment is constituted by a sequence of basic operations, it is more efficient to pass by address the intermediate results from one unit to the following. This can be achieved by defining a macro-unit which groups several algebraic units and defines how some output and input objects share addresses. Only some among the units inputs and outputs will be kept as inputs and outputs of the macro-unit. Moreover, the user can introduce control structures, as IF statements or loops and can operate on the intermediate results or on local variables with Fortran90 code regions. The macro units are described by the user by the means of the graphical algebra composer tool.

In order to grant a full independence between the order of objects production and reception, the produced objects which are not immediately consumed have to be stored in a memory space acting as a mailbox. To avoid confusions with the MPI mailbox, this temporary storage space has been renamed "mailbuff" because it shares its memory location with the buffer.

Starting from the input file which describes the experience, the user interface PrePALM generates the run-time input file and a number of FORTRAN 90 file to be linked with the application (branch code, user parameters, palm_init.f90 file, palm_trigger.f90 file)
PrePALM can generate the PALM files in the command line mode (cf. the section on how to set up a PALM application)

The standard message passing library on top of which PALM is built. The version 1 of MPI is largely widespread and every supercomputer constructor provides an optimized version of MPI1. The MPI1 standard covers the need of SPMD applications. Further details can be found in the official MPI web site http://www-unix.mcs.anl.gov/mpi/index.html

The new extended standard of the message passing library MPI. It covers topics on process management, one-sided communications and parallel I/O which were not addressed in the MPI1 standard. This version is needed for the implementation of MPMD applications. Further details can be found in the official MPI web site http://www-unix.mcs.anl.gov/mpi/index.html

Parallel programming algorithm in which the parallel applications consists in a collection of independent programs executing concurrently. Processes can join or leave the application dynamically. The acronym comes from Multiple Program Multiple Data.
Top of page

N

The mnemonic string which identifies an object or a space or a distributor. It has to be declared as a CHARACTER string of length . It is limited to 31 characters and it should not contain neither blanks nor dots.

calendar
The always 365 days calendar for "date to integer" conversion. (cf. the entry).

Attribute of a branch which has to be explicitly invoked by another branch. (cf. the entry).

An object stored in the buffer can be recovered by a unit issuing a get only if its state is set to "ready". This is normally the case of the objects "inserted" in the buffer ("Insert/Replace" attribute, PL_INS keyword), meanwhile objects assembled in the buffer via "Add" communications (PL_ADD keyword) or objects explicitly set to "not ready" (by the unready action) need to have their state changed by a step-actions instruction before being received. A PALM_Get trying to receive an object set to "not ready" will hang until the object changes its state to "ready".
Top of page

O

An object is the information chunk which is exchanged in a communication. It can be a simple control code as well as a full three dimensional field. The object definition is local to a unit and it is given in the unit's identity card, but the two definitions at the two sides of the communication (the source and the target) must be conforming and designate the same information chunk.
An object can be considered as a particular instance of a class, called a space. Each instance is identified by three fields:

The communication paradigm in PALM. To ensure modularity, a unit simply notifies that an object is asked () or made available (). The user defines the correspondence between the two communication end-points via the PrePALM interface.
Notice that there is no need of exact matching between the communication primitives in a unit and the communications which are actually performed. All the potential communications of a unit are declared in its "identity card", but only the communications described in PrePALM will be performed. For the others, the communications primitives and return immediately with non zero error code. (See also the section on the PALM Data Exchanges).
Top of page

P

PALM is a French acronym meaning "Projet d'Assimilation par Logiciel Multiméthode" which can be translated as "Project of Assimilation by Multi-method Software" or transposed to "Parallel Assimilation with a Lot of Modularity". To know something more about PALM, please, go back to beginning of this document.

Primitive to shutdown a PALM application. It ensures a clean termination and print some information about the state of the execution in the standard palm output files.
The call sequence is 
CALL PALM_Abort(err_code)

     INTEGER :: err_code
err_code
is an output integer error code. Its meaning can be explained via a call to

The file which contains the user defined debug procedures (cf. the entry). It has to be linked with the application.

A PALM application generates a standard output file for each processor where the PALM messages (verbose output and debug information) are printed. This file receives the output coming from the driver processor. (cf. ).

Prints to the standard palm output files a human readable description of error codes returned by PALM primitives.
The call sequence is 

CALL PALM_Error_explain(err_code_to_explain, err_code)

     INTEGER :: err_code_to_explain, err_code
err_code_to_explain
is an input integer error code returned by a previous call to a PALM primitive.
err_code
is an output integer error code. Its meaning can be explained via a call to itself.

The PALM primitive called by a unit when an object is needed. Its interface is described in the section on PALM actions for data exchanges. The unit calling identifies itself as the potential target of a communication.
Notice that there is no need of exact matching between the communication primitives in a unit and the communications which are actually performed. All the potential communications of a unit are declared in its "identity card", but only the communications described in PrePALM will be performed. For the others, returns immediately with non zero error code.
A call to corresponding to an actual communication is always blocking.
The call sequence is 

CALL PALM_Get(space_name, obj_name, obj_time, obj_tag, local_var, err_code)

     CHARACTER(LEN=PL_LNAME) :: space_name, obj_name
     INTEGER :: obj_time, obj_tag, err_code
     XXXX    :: local_var
space_name
is a string of predefined length identifying the object by its .
obj_name
is a string of predefined length indicating the .
obj_time
is an integer indicating the object . It can be computed from a GMT date via a previous call to .
obj_tag
is an integer indicating the object
local_var
is the local variable of type XXXX which contains the field associated to the object.
err_code
is an output integer error code. Its meaning can be explained via a call to

In order to avoid to start a PALM application with arguments on the command line, the name of the input file is declared in the palm_init.f90 file which has to be linked with the application. This file is generated by the PrePALM user interface at the generation of the PALM files.

The log output file generated on demand. It is used by the PrePALM interface to produce a graphical replay of the execution and a very simple performances analysis of the units.

Precompiled main program of a PALM application. This file has to be linked with the application. It is provided with the PALM distribution.

A PALM application generates a standard output file per process(or) where the PALM messages (verbose output and debug information) are printed. These file receive the name palm_proc_xxx.out where xxx is the process(or) number (more exactly the rank of the process in the MPI_COMM_WORLD communicator). From all the processes of the application, the output file is open as the predefined FORTRAN unit PL_OUT, therefore the user can add diagnostic output and printing to the standard output files.

The PALM primitive called in a unit when an object is produced. Its interface is described in the section on PALM actions for data exchanges. The unit calling identifies itself as the potential source of a communication.
Notice that there is no need of exact matching between the communication primitives in a unit and the communications which are actually performed. All the potential communications of a unit are declared in its "identity card", but only the communications described in PrePALM will be performed. For the others, returns immediately with non zero error code.
A call is never blocking.
The call sequence is 

CALL PALM_Put(space_name, obj_name, obj_time, obj_tag, local_var, err_code)

     CHARACTER(LEN=PL_LNAME) :: space_name, obj_name
     INTEGER :: obj_time, obj_tag, err_code
     XXXX    :: local_var
space_name
is a string of predefined length identifying the object by its .
obj_name
is a string of predefined length indicating the .
obj_time
is an integer indicating the object . It can be computed from a GMT date via a previous call to .
obj_tag
is an integer indicating the object
local_var
is the local variable of type XXXX which contains the field associated to the object.
err_code
is an output integer error code. Its meaning can be explained via a call to

The PALM primitive called by a unit to know if an asked object is going to be produced. It queries if a having the same arguments corresponds to an actual communication.
Remembre that there is no need of exact matching between the communication primitives in a unit and the communications which are actually performed. All the potential communications of a unit are declared in its "identity card", but only the communications described in PrePALM will be performed. For these communications, returns with 0 error code, for the others, with non zero error code.
The call sequence is 

CALL PALM_Query_get(space_name, obj_name, obj_time, obj_tag, err_code)

     CHARACTER(LEN=PL_LNAME) :: space_name, obj_name
     INTEGER :: obj_time, obj_tag, err_code
space_name
is a string of predefined length identifying the object by its .
obj_name
is a string of predefined length indicating the .
obj_time
is an integer indicating the object . It can be computed from a GMT date via a previous call to .
obj_tag
is an integer indicating the object
err_code
is an output integer error code. It is 0 if the a communication for the corresponding has been described, else its meaning can be explained via a call to

The PALM primitive called in a unit to know if a produced object is going to be consumed. It queries if a having the same arguments corresponds to an actual communication.
Notice that there is no need of exact matching between the communication primitives in a unit and the communications which are actually performed. All the potential communications of a unit are declared in its "identity card", but only the communications described in PrePALM will be performed. For these communications, returns with 0 error code, for the others, with non zero error code.
The call sequence is 

CALL PALM_Query_put(space_name, obj_name, obj_time, obj_tag, err_code)

     CHARACTER(LEN=PL_LNAME) :: space_name, obj_name
     INTEGER :: obj_time, obj_tag, err_code
space_name
is a string of predefined length identifying the object by its .
obj_name
is a string of predefined length indicating the .
obj_time
is an integer indicating the object . It can be computed from a GMT date via a previous call to .
obj_tag
is an integer indicating the object
err_code
is an output integer error code. It is 0 if the a communication for the corresponding has been described, else its meaning can be explained via a call to

A PALM primitive which can be called in a unit to convert in a unique way a GMT date into an integer time stamp and vice versa. This mechanism is needed to make the two sides of a end-point communication independent. The user set a reference date and chooses a reference time step in the PrePALM interface. Given a date, the PALM_Time_convert function returns the number (integer) of time steps between the reference date and the given date accordingly to the selected calendar. Given an integer time n, the PALM_Time_convert function returns the date corresponding to n time steps after the reference date accordingly to the selected calendar. To exchange an object associated to a date, the time argument of PALM_Get or PALM_Put should be set to the integer generated by PALM_Time_convert.
The call sequence is 

CALL PALM_Time_convert(direction, day, month, year, hour, min, sec, time_stamp, err_code)

     INTEGER :: direction, day, month, year, hour, min, sec, time_stamp, err_code
direction
is an integer keyword to indicate the conversion direction. It can take the or the value.
day, month, year, hour, min, sec
are integer date fields. They are input variables if the direction has been selected else output.
time_stamp
is an integer object . It is an input variable if the direction has been selected else output.
err_code
is an output integer error code. Its meaning can be explained via a call to

User defined procedure for "custom" time interpolation. (cf. the entry). It has to be linked with the application.

Contains the routine which associates the unit and branch name labels to the corresponding subroutine calls. This file has to be linked with the application. It is generated by the PrePALM user interface at the generation of the PALM files.

module and include file
The constants defined by the user in PrePALM are saved in the FORTRAN 90 module contained in the palm_user_param.f90 file and in the FORTRAN 77 include files which are created or updated at the generation of the PALM files. The module can be "use associated" or the ".h" file included in the unit codes in order to ensure coherence between the constants used in PrePALM and the parameters used in the units.

PALM primitive which returns the currently set verbosity level for a specific category of messages (cf. the verbosity entry).
The call sequence is 

CALL PALM_Verblevel_get(category, level, err_code)

     INTEGER :: category, level, err_code
category
is the category of verbose messages. It can take the values , , , ,
level
returns the actually set verbosity level (output)
err_code
is an output integer error code. Its meaning can be explained via a call to

PALM primitive which returns the currently set maximum overall verbosity level (cf. the verbosity entry).
The call sequence is 

CALL PALM_Verblevel_overall_get(level, err_code)

     INTEGER :: level, err_code
level
returns the actually set verbosity level (output)
err_code
is an output integer error code. Its meaning can be explained via a call to

PALM primitive which sets the maximum verbosity level to 0. It switches entirely off the PALM optional messages (cf. the verbosity entry).
The call sequence is 

CALL PALM_Verblevel_overall_off(err_code)

     INTEGER :: err_code
err_code
is an output integer error code. Its meaning can be explained via a call to

PALM primitive which sets the maximum overall verbosity level (cf. the verbosity entry).
The call sequence is 

CALL PALM_Verblevel_overall_set(level, err_code)

     INTEGER :: level, err_code
level
is the verbosity level. It can take the values , , .
err_code
is an output integer error code. Its meaning can be explained via a call to

PALM primitive which sets the verbosity level for a specific category of messages (cf. the verbosity entry).
The call sequence is 

CALL PALM_Verblevel_set(category, level, err_code)

     INTEGER :: category, level, err_code
category
is the category of verbose messages. It can take the values , , , ,
level
is the verbosity level. It can take the values , , .
err_code
is an output integer error code. Its meaning can be explained via a call to

and
The FORTRAN 90 module or the FORTRAN 77 include file which have to be included in the unit routines calling any PALM primitive. of

The PALM input language file is the file which is read at run-time by the PALM application. Even if it is an ASCII file it must not be edited by the user. It is generated by the PrePALM interface.

Ppl keyword for an "" communication sending an object to the buffer.

Keyword to use instead of the tag argument in a call to , to designate all the objects with the prescribed name and time no matter what the actual tag is (it works as a jolly keyword for the "user tag" field). The first object with the right name and time which has been or will be produced is received.

Keyword to use instead of the time stamp argument in a call to , to designate all the objects with the prescribed name and tag no matter what the actual time stamp is (it works as a jolly keyword for the "time stamp" field). The first object with the right name and tag which has been or will be produced is received.

Keyword for the definition of the space element size.

Private MPI communicator of each parallel unit. It is provided by PALM via the module or the include file and it has to be used instead of MPI_COMM_WORLD.

Keyword for the definition of the space element size.

One way to apply a debug procedure (cf.).

One way to apply a debug procedure (cf.).

One way to apply a debug procedure (cf.).

Keyword for the definition of the space element size.

One kind of time interpolation (cf.).

One kind of time interpolation (cf.), namely the case without interpolation.

One kind of time interpolation (cf.).

One kind of time interpolation (cf.).

Ppl keyword for an "" communication sending an object to the buffer.

Keyword for the definition of the space element size.

Keyword for the definition of the space element size.

Predefined length for the strings containing a .

One way to apply a debug procedure (cf.), namely the case without debug.

Keyword to use instead of the tag argument in a call to , or to to indicate that the object of the communication has no specific tag assigned by the user.

Keyword to use instead of the time stamp argument in a call to , or to to indicate that the object of the communication has no time dependency.

Keyword to indicate that a communication should not be tracked (cf. the entry).

Predefined FORTRAN output unit associated to the standard output file .

Keyword for the definition of the space element size.

Keyword used in the primititve to ask a GMT date to integer time stamp conversion.

Keyword to indicate that the reference time step is one day. Used only in the file.

Keyword to indicate that the reference time step is one hour. Used only in the file.

Keyword used in the primititve to ask a time stamp to GMT date conversion.

Keyword to indicate that the reference time step is one minute. Used only in the file.

Keyword to indicate that the reference time step is one second. Used only in the file.

Keyword to indicate that a communication should be tracked if the right verbosity level is selected (cf. the entry).

Category for specific verbosity control. Output of information related to branch management.

Category for specific verbosity control. Output of information related to communications management.

Category for specific verbosity control. Output of information not fitting in any other category.

Category for specific verbosity control. Output of information related to steps and synchronization issues.

Category for specific verbosity control. Output of information related to units management.

Verbosity level keyword to be used as argument of verbosity control primitives. No output.

Verbosity level keyword to be used as argument of verbosity control primitives. Output of all the user relevant information.

Verbosity level keyword to be used as argument of verbosity control primitives. Output of warnings and error messages.

The PrePALM language file is the input file describing the PALM application. The graphical user interface PrePALM can help in preparing the ppl file. It can also be edited by hand even if its syntax is quite cumbersome. It serves as input for the generation of the PALM files.

The PALM graphical user interface. The PrePALM role is to build the application overall algorithm. All the information which do not depend on the algorithm and on the specific application is hardwired in the units and all the information on the algorithm and on the application is entered via PrePALM.
PrePALM helps filling the file and generates the files needed by the run-time application.
Since PrePALM is the user interface, most of this document explains the PrePALM usage.
PrePALM is written in Tcl/Tk.

environment variable
Tells PrePALM where its images and service files are installed on the system. Ask your system administrator.

environment variable
Specifies the editor used by PrePALM. Notice that it has to be a X11 application, therefore if you like to use vi set PREPALMEDITOR to xterm -e vi.

In the PALM end-point approach, this is the point of view of the communication source side. See
Top of page

Q

Top of page

R

An object stored in the buffer can be recovered by a unit issuing a get only if its state is set to "ready". This is normally the case of the objects "inserted" in the buffer ("Insert/Replace" attribute, PL_INS keyword), meanwhile objects assembled in the buffer via "Add" communications (PL_ADD keyword) or objects explicitly set to not ready need to have their state changed by a step-actions instruction before being received.

The reference date for "date to integer" conversion. (cf. the entry).

The reference time step for "date to integer" conversion. Can be "day", "hour", "minute", or "second". (cf. the entry).

One kind of of descriptor of distributed objects (cf. the entry).

The action to change the parallel distribution of an object. If an exchanged object has a different distribution on the source and on the target side of a communication, PALM automatically takes care of the redistribution following the optimal communication pattern.
Top of page

S

One kind of of descriptor of distributed objects, namely the one to be used when the object is not distributed (cf. the entry).

One of the properties which define a space (cf.).

In a communication, the source is the entity which produces the object. It can be either an ordinary unit issuing or the buffer or a unit from the algebra toolbox.

The description of the properties of the objects belonging to a unit is based to a class association. A class of objects is said to be a space. Spaces are local to units and therefore they are described in the identity cards of the units. The only exception is represented by the spaces associated at run-time to the algebra toolbox units which are therefore defined in the PrePALM interface. A space is identified by its mnemonic name (string), its shape (with the FORTRAN syntax (dim1, dim2, ...)) and its element size, i.e. the variable kindw of a single element : in the case of standard FORTRAN types, the element size is simply associated to the size of a standard type via the predefined PL_INTEGER, PL_REAL, PL_DOUBLE_PRECISION, PL_COMPLEX, PL_LOGICAL, PL_CHARACTER keywords ; in the case of a derived type, the element size is defined as a linear combination of the previous keywords.
Notice that in the definition of the shape and of the element size (in the case of derived data types) the constants defined via PrePALM can be used.

Parallel programming pradigm in which the parallel applications consists in a single program executing on more than one process. The different instances of the program can perform different tasks or handle different portions of data. The acronym means Single Program Multiple Data.

calendar
The gregorian calendar for "date to integer" conversion. (cf. the entry).

Action of beginning a new branch execution. An idle processor is allocated to the branch. Branches with attribute are automatically started by the driver since the beginning of the application. Branches with the attribute have to be explicitly started from another branch.

Attribute of a branch which runs since the beginning of the application. (cf. the entry).

A relevant point where to perform some actions on buffer objects. Steps can be defined as communications occurrences or as explicit invocations of the primitive in the branch codes. The actions to perform when a step is reached are described in the section of the file or via the PrePALM interface.

The actions to be performed on the objects stored in the buffer when the algorithm reach some predefined points, the so-called steps. The steps can be defined as occurrences of communications or as invocation of the specific primitive in the branch codes. The actions can be: The syntax of the step-actions language is thoroughly described in the section about the PALM actions.

A way for a branch to notify that a relevant step of the computation has been reached. Useful to synchronize branches (cf. the entry) or to trigger actions described as step-actions. It has to be declared in the PrePALM interface and invoked by the branch codes.

Distributed unit for which the execution context is set by the user via PrePALM. It means that the unit "sticks" to the processors of its first execution context. Notice that this strategy puts strong constraints on the dynamic allocation of resources and can lead to a deadlock of the application for lack of resources.
Top of page

T

A user defined integer to distinguish between different objects with the same "name" and "time". An object for which it is not necessary to operate such a distinction has tag PL_NO_TAG.

In a communication, the target is the entity which will receive the object. It can be either an ordinary unit issuing or the buffer or a unit from the algebra toolbox.

The script and graphical language on which the PrePALM interface is based. You need to have Tcl/Tk installed to run PrePALM. Tcl/Tk can be freely downloaded from the Scriptics Web site http://dev.scriptics.com/software/tcltk

calendar
The 12 times 30 days calendar for "date to integer" conversion. (cf. the entry).

The time stamp is an integer which indicates the time, in the time reference of the experience, associated to an object. PALM provides a way to associate in a unique way an integer to a GMT date via the PALM_Time_convert primitive.

In the case of communications whose source is the buffer, the target can ask to get objects at times for which they have not been actually stored in the buffer. (For example is is the case of a tangent linear model recovering at each time step the reference state, even if it has been stored only every n time steps). The response of PALM to such a request depends on the time interpolation scheme selected for the communication. It can be

An algebra unit needs some information about the time stamp and the user tag of the objects it is going to send and to receive. For each object linked to something via a communication, the user must indicate how the algebra unit knows these attributes. The choice of the is amongst

According to the selected verbosity level, it is possible to track the communications. It means that some information on the ongoing communications are printed in the standard output files. Since the amount of information printed for all the communications would be overwhelming, it is possible to set an attribute ( or ) to indicate whether the communication has to be tracked or not.

The automatic launching strategy of algebra units is based on the availability of necessary input. The user must indicate at least a triggering input object for an algebra unit, but he can indicate more. The unit is not launched until all the triggering inputs are received or are available in the buffer.

A PALM communication takes place only if a possible pattern between a and a has been defined. We call such a pattern a . All possible tubes are defined in the description.
It is important to understand that a tube simply defines a potential data exchange pattern, but that there is no obligation to actually perform the corresponding communication. For this reason it is mnemonically associated to a tube line: even if the line exists, no passengers are transported unless a metro car travels on the line.
Since tubes and communications are strictly related, in the PrePALM interface the word "communication" is used to designate "communication tubes".
Top of page

U

The unit is the basic element used to build an algorithm with PALM. Units can be user defined or provided with the algebraic toolbox of PALM. A unit performs some actions on input objects to produce output objects. A unit can be a serial or a parallel code. User defined units are FORTRAN 90 subroutines with no arguments and with no COMMON blocks shared with other units (unless in the very particular case of the sticky units). Each unit is described by an identity card which lists the properties of the spaces, of the input and output objects and of the distributors used by the unit. The sequence of units execution is defined via the branch code. The action by which a branch invoke a unit is called "launch".

Action which can be prescribed as step-action to set the state of an object stored in the buffer to "not ready".
Top of page

V

PALM can issue optional run-time control messages. The verbosity control is based on several levels (, and plus some finer levels, mainly for development and debugging purposes). The verbosity level can be separately set for different categories of messages (cf. the section on the diagnostic tools for a thorough explanation). Moreover it is possible to set a maximum overall verbosity level which applies to all categories and overrides the specific levels if they are higher than the overall level.
The default overall and specific levels are set via the PrePALM interface. These values can be changed at run-time using the , , , and primitives.
Top of page

W

Top of page

X

Top of page

Y

Top of page

Z

Top of page