ZOO-Kernel

Compile ZOO-Kernel using the configuration options as shown below:

No macro or processor named 'guess' found

Optionally, you can ask your ZOO-Kernel to invoke a callback service which is responsible to record execution history and data produced. In such a case you can add the --with-callback=yes option to the configure command.

FinalizeHPC WPS Service

For being informed that the remote OTB application ends on the cluster, one should invoke the FinalizeHPC service. It is responsible to connect using SSH to the HPC server to run an sacct command for extracting detailled informations about the sbatch that has been run. If the sacct command succeed, and the service is no more running on the cluster, then the informations are stored in a local conf file containing a [henv] section definition, the service connect to unix domain socket (opened by the ZOO-Kernel that has initially schedduled the service through Slurm) to inform about the end of the service run on the cluster. This makes the initial ZOO-Kernel to continue its execution by downloading output data produced over the execution of the OTB application on the cluster. So, this service should be build and deployed on your WPS server. You can use the following commands to do so.

No macro or processor named 'guess' found

You should also copy the .. note:

FinalizeHPC should be called from a daemon, responsible for reading
mails sent by the cluster to the WPS server.

Main configuration file

When HPC support is activated, you can use different HPC configuration by adding confId to your usual serviceType=HPC in your zcfg file. For being able to find which configuration a service should use, the ZOO-Kernel require to know what are the options for creating the relevant sbatch.

Also, you can define multiple configuration to run the OTB application on the cluster(s) depending on the size of the inputs. You should define in the section corresponding to your ServiceType the treshold for both raster (preview_max_pixels) and vector (preview_max_features) input. In case the raster or the vector dataset is upper the defined limit, then the fullres_conf will be used, in other case the preview_conf will be.

For each of this configurations, you will have define the parameters to connect the HPC server, by providing ssh_host, ssh_port, ssh_user and, ssh_key. Also, you should set where the input data will be stored on the HPC server, by defining remote_data_path (the default directory to store data), remote_presistent_data_path (the directory to store data considerated as shared data, see below) and, remote_work_path the directory used to store the SBATCH script created locally then, uploaded by the ZOO-Kernel.

Also, there are multiple options you can use to run your applications using SBATCH. You can define them using jobscript_header, jobscript_body and jobscript_footer or by using sbatch_options_<SBATCH_OPTION> where <SBATCH_OPTION> should be replaced by a real option name, like workdir in the following example. For creating the SBATCH file, the ZOO-Kernel create a file starting with the content of the file pointed by jobscript_header (if any, a default header is set in other case), then, any option defined in sbatch_options_* and a specific one: job-name, then, jobscript_body is added (if any, usually to load required modules), then the ZOO-Kernel add the invocation of the OTB application then, optionally the jobscript_footer is added, if any.

Finally, remote_command_opt should contains all the informations you want to be extracted by the sacct command run by the FinalizeHPC service. billing_nb_cpu is used for billing purpose to define a cost for using a specific option (preview or fullres).

In addition to the specific HPC_<ID> section and the corresponding fullres and preview ones, you should define in the [security] section using the shared parameter to set the URLs from where the downloaded data should be considerated as shared, meaning that even if this ressources requires authentication to be accessed, any authenticated user will be allowed to access the cache file even if it was created by somebody else. Also, this shared cache won't contain any authentication informations in the cache file name as it is usually the case.

No macro or processor named 'guess' found

You can see below an example of jobscript_header file.

No macro or processor named 'guess' found

You can see below an example of jobscript_body file.

No macro or processor named 'guess' found

In casse you have activated the callback service, then you should also have a [callback] section, in which you will define url to invoke the callback service, prohibited to list the services that should not require invocation of the callback sercvice if any and, template pointing to the local updateExecute.xsl file used to replace any inputs provided by value to the reference to the locally published OGC WFS/WCS web services. This execute request is provided to the callback service.

No macro or processor named 'guess' found

OGC WPS Services metadata

To produce the zcfg files corresponding to the metadata definition of the WPS services, you can use the otb2zcfg tool to produce them. You will need to replace serviceType=OTB by serviceType=HPC and, optionally, add one line containing confId=HPC_Sample for instance.

Please refer to otb2zcfg documentation to know how to use this tool.

Using the HPC support, when you define one output, there will be automatically 1 to 3 inner outputs created for the defined output:

download_link

URL to download to generated output

wms_link

URL to access the OGC WMS for this output (only in case useMapserver=true)

wcs_link/wfs_link

URL to access the OGC WCS or WFS for this output (only in case useMapserver=true)

You can see below an example of Output node resulting of the definition of one output named out and typed as geographic imagery.

No macro or processor named 'guess' found