PSMILe interface proposal

-in green: IPSL last comments
-in red: WP3A new comments or WP3a old comments that still need to be discussed,
-in orange: modifications that wp3a/wp4a agreed on.
-in black and small characters: WP3a old comments on issues that are solved
-in magenta and small character: text that wp3a/wp4a agreed that should be removed

• PRISM_put
• PRISM_get
• PRISM_iput
• PRISM_iget
• PRISM_wait

Name :

PSMILe_put(varId, date, [dateBounds], X, [Y])

Description :

This function allows to put a variable into the PSMILe.

A flow diagram for the PSMILe_put function

Arguments :

varId (IN) : ID of variable.
date (IN) : date of the time step for this data is valid.
dateBounds (IN) : The dates of the bounds of the current time step.
>WP3a: OK but not as optional.
IPSL : YES
>Sophie 24/07/02: What is "date"? an integer? a vector of integers? Could it be the number of seconds since a reference date (cf Palm)? Is it the date at the beginning of the timestep? If so, dateBounds could therefore be the date at the end of the timestep? Is it really needed (cf in Palm, if the user knows that the dates at which the source model will provide the fields do not match the dates at which the target model wants to receive them, he can tell Palm to perform a nearest-neighbour time interpolation)
X, Y (IN) : data provided for this variable. For instance X could be the data and Y the table of indices over which the variable should be scattered.
>WP3a: Needs to be re-discussed. We do not really see why this scattering operation could not be specified in the SMIOC or SCC as any other operation.
>IPSL : As said above you wish to hide from the user this minimal set of operations one needs to do before the variable makes sense to the user.
>WP3a: Understood, but then why isn't it simply done in the code before the PRISM_put; needs to be discussed.

Name :

PSMILe_get(varId, date, [dateBounds], X, [Y])

Description :

This function allows to get a variable from the PSMILe.

A flow diagram for the PSMILe_get function

Arguments :

varId (IN) : ID of variable.
date (IN) : date of the time step for this data is valid.
dateBounds (IN) : The dates of the bounds of the current time step.
X (OUT) : data provided by the PSMILe.
Y (IN) : Variable which allows to perform the minimal operation. For instance Y could be used to gather the full variable on the slab effectively needed for X.

Name :

PRISM_put(var_id, date, date_bounds, data_array, ierror)

Responsible: NEC-CCRLE

Description :This function allows a blocking put of a variable into the PSMILe. A blocking operation means that the function returns when the operation is completed (and therefore when the content of data_array can be changed in the code).

Name :

PRISM_get(var_id, date, date_bounds, data_array, ierror)

Responsible: NEC-CCRLE

Description :

This function allows a blocking get of a variable into the PSMILe. A blocking operation means that the function returns when the operation is completed.

Name :

PRISM_iput(var_id, request_id, date, date_bounds, data_array, ierror)

Responsible: NEC-CCRLE

Description :This function allows a non-blocking put of a variable into the PSMILe. A non-blocking operation means that the function returns immediatly even if the operation is completed (and therefore the content of data_array should not be changed in the code).

Name :

PRISM_iget(var_id, request_id, date, date_bounds, data_array, ierror)

Responsible: NEC-CCRLE

Description :This function allows a non-blocking get of a variable into the PSMILe. A blocking operation means that the function returns when the operation is completed.

Name :

PRISM_wait(request_ids, no_request_ids)

Responsible: NEC-CCRLE

Description :This function waits until all PRISM_iput and PRISM_iget corresponding to the list of requests indicated in 'request_ids' are completed.