Is there a way of canonically labelling permutation groups? When working with large numbers of graphs, a canonical labelling routine is essential as, after the initial cost of canonically labelling each graph, it permits isomorphism checks to be replaced with identity checks.
Currently I am working with large numbers of transitive permutation groups; the degree is small (40ish) but the size of group can be large, and my programs are gumming up due to having to perform large numbers of - not exactly isomorphism - but conjugacy checks. (I need to check each pair of groups to see if they are conjugate in the symmetric group.) 
This process would be considerably easier if there was a known way of finding a canonical conjugate of the incoming permutation groups...
 A: This seems to be one of the biggest holes in the practical isomorphism arsenal.  Various non-trivial possibilities come to mind, but their efficiency relies a lot on a more basic question. Define (and efficiently compute) a total order on labelled finite permutation groups.  Thus, for any two permutation groups $G_1,G_2$ given by permutation generators, determine whether $G_1\lt G_2$, $G_1=G_2$ or $G_1\gt G_2$, where $G_1=G_2$ iff they are exactly the same (not just isomorphic) and the order obeys the transitivity law.  This is possible in principle: compute the entire groups and compare them lexicographically.  But naturally we don't want to compute the entire groups. 
A: In GAP, for transitive permutation groups of degree at most 30 one can use  TransitiveIdentification(G) from the package TransGrp by Alexander Hulpke. This gives the index of the (unique!) permutation group in the library that is conjugate to the given permutation group and it is apparently quite fast. See section 13 of 
Hulpke, Alexander, Constructing transitive permutation groups., J. Symb. Comput. 39, No. 1, 1-30 (2005). ZBL1131.20003 MR2168238.
A: A quick way to obtain canonical conjugates of permutation groups would of
course be nice, but hoping for that may be a bit too optimistic.
Rather than trying to go that route, in your situation I would try to reduce
the number of pairs of groups to be tested for conjugacy -- and my guess is
in practice you can usually obtain quite a big reduction. Concretely, I would
compute for each of the groups invariants like the following:


*

*group order,

*primitivity / degree of transitivity,

*number, sizes, orders of representatives and cycle structures of
representatives of conjugacy classes.
The time required for computing these invariants is no longer quadratic,
but linear in the number of groups. Finally, only pairs of groups for which
all invariants coincide need to be tested for conjugacy.
To give a rough idea of how good the mentioned invariants are in separating
non-conjugate groups: the invariants distinguish all non-conjugate transitive
permutation groups of degree less than $12$, and among the $301$ non-conjugate
transitive permutation groups of degree $12$, there are only $2$ pairs of groups for which
the invariants coincide.
A: Babai, Codenotti, and Qiao (ICALP 2012 from Babai's homepage, also in Codenotti's thesis) show how to test permutational isomorphism (=conjugacy - but this might be another good phrase to search with) of permutation groups in time that is polynomial in the order of the groups and simply exponential ($c^n$ for fixed $c$) in the size of the permutation domain. From a theoretical perspective, I believe this is the best known.
In the transitive case, the runtime is still simply exponential in the degree but only linear in the order, and in this amount of time they can in fact list all of the permutational isomorphisms. Listing the permutational isomorphisms allows you to pick a canonical labelling by, e.g., lexicographic order. (And $|G|2^{40}$ is way better than the naive bound of $|G|40!$: $2^{40} \approx 10^{12}$, while $40! \approx 10^{48}$.)
Now theoretical bounds on algorithms may not tell you anything about efficiency in practice. (Depending on how large your transitive groups are, even the linear factor of $|G|$ might be too much for you.) It is at least reasonable to think that their algorithm is not only theoretically more efficient but also more efficient in practice than the naive algorithm(s). And of course one can always hope that it will work for your instances anyways, or perhaps with a few additional heuristics.
