CASITA is a tool for automatic analysis of OTF2 trace files that have been 
generated with Score-P. It determines program activities with high impact on the
total program runtime and the load balancing. CASITA generates an OTF2 trace 
with additional information such as the critical path, waiting time, and the
cause of wait states. The same metrics are used to generate a summary profile 
which rates activities according their potential to improve the program runtime 
and the load balancing. A summary of inefficient patterns exposes waiting times
in the individual programming models and APIs.

Internally, CASITA constructs a distributed DAG, where each node represents an 
event in time and edges the dependencies between events on different locations 
(processes, threads and CUDA streams). Events on the same locations have an
implicit dependency by the happens-before relation. The local DAGs, one per 
MPI process, are connected via remote edges. Only MPI, OpenMP and CUDA nodes 
are represented in the graph. Nevertheless, events from compiler 
instrumentation are accounted.

Publications:

"CASITA: A Tool for Identifying Critical Optimization Targets in Distributed 
Heterogeneous Applications"
http://dx.doi.org/10.1109/ICPPW.2014.35

"Scalable critical-path analysis and optimization guidance for hybrid MPI-CUDA 
applications"
http://dx.doi.org/10.1177/1094342016661865

"Critical-blame analysis for OpenMP 4.0 offloading on Intel Xeon Phi"
http://dx.doi.org/10.1016/j.jss.2015.12.050

"Integrating Critical-Blame Analysis for Heterogeneous Applications into the 
Score-P Workflow"
http://dx.doi.org/10.1007/978-3-319-16012-2_8

"Analyzing Offloading Inefficiencies in Scalable Heterogeneous Applications"
http://dx.doi.org/10.1007/978-3-319-67630-2_34


CASITA analysis requirements:

The MPI analysis is currently based on reenacting the MPI communication in 
forward and backward direction, which means that the respective communication 
records have to be available in the trace. CASITA also needs the region enter 
and leave events of MPI communication functions. Currently, the MPI support is 
limited to (two-sided) point-to-point communication and blocking collectives.

The OpenMP analysis is still based on the OPARI2 instrumentation. It requires 
the fork/join, parallel begin/end, and the barrier begin/end records. Both, MPI 
and OpenMP analysis work with the default Score-P trace output. 

CUDA analysis is supported since Score-P 1.3. The respective OTF2 trace file has
to contain the following information:
* Enter and leave events of CUDA driver API functions that synchronize with the 
  device (including blocking CUDA memory copies and CUDA event queries) as well 
  as CUDA kernel launch and CUDA event record. 
* Enter and leave events of kernel launches and kernels 
* Kernel references (dependency information between launch and synchronization 
  of kernels)
The minimum set of Score-P CUDA recording features is "driver,kernel,references" 
which can be set with the environment variable SCORE_CUDA_ENABLE.

The OpenCL analysis also requires kernel dependencies, e.g. to detect the OpenCL
queue a kernel is enqueued to or synchronized with clFinish. This is currently 
implemented in a Score-P development branch. OpenACC analysis is indirectly 
supported with the low-level paradigms CUDA and OpenCL.