It is important to compare only comparable things. When comparing two program runs
you can try to compare the time that a process A.P0 spent in a function in run A to
the time of another process B.P0 in run B with or without caring for the fact that
B.P0 did only half of the work because run B used twice as much processes.
It is quite easy to see that depending on the domain decomposition or load
balancing that is done in the application the meaningful mapping between the
processes of two runs cannot be determined automatically. There might be even no
such mapping: imagine comparing a run that did a domain decomposition of a cube into
8 processes 2x2x2 with a run that used a 3x3x3 decomposition.
But functions and function groups can be mapped between the runs just by their
fully qualified name. This works as long as the structure of modules, namespaces and
classes is not changed dramatically.
It is next to impossible to even enumerate all combinations of parameters that
might have changed between two runs. To foresee all these cases in terms of
automatically adapting GUI does not look promising.
Based on these considerations the mappings of processes, functions, communicators
and message tags between the runs are handled differently:
Communicators are mapped by their Ids. Message tags are mapped literally by their
The mapping of processes and process groups is controlled by choosing the process
aggregations for both files as outlined in Mapping of Processes
The mapping between functions and function groups is handled automatically as
outlined in Mapping of Functions
See a suitable Process Group for the comparison between a 2 and a 4 processor run
in the Process Aggregation dialog box: