Labelling for Morita equivalence classes

We use two compatible systems for labelling Morita equivalence classes of blocks of finite groups with respect to an algebraically closed field [math]k[/math].

When the defect group is listed in the GAP SmallGroup library

M(x,y,z) is a class consisting of blocks with defect groups of order x, with a representative having defect group SmallGroup(x,y) in GAP/MAGMA labelling. It is the z-th such class.

Note that it is not known that the isomorphism class of a defect group is a Morita invariant, so it could be that M(x,y1,z1)=M(x,y2,z2) for some [math](y1,z1) \neq (y2,z2)[/math].

An excellent resource for the SmallGroup library is the Groupprops wiki site.

Alternative notation

When the defect group is not listed in the SmallGroup library or is a generic group [math]P[/math], then we use the notation M([math]P[/math],z), the z-th class of blocks with defect groups isomorphic to [math]P[/math]. When [math]P[/math] is cyclic we also use the notation M([math]|P|[/math],1,z) since the cyclic group is always labelled 1 in the SmallGroup library.

[math]\mathcal{O}[/math]-Morita equivalence classes

At present there is no known example of a [math]k[/math]-Morita equivalence class of blocks which splits into more than one Morita equivalence class with respect to a complete discrete valuation ring. If such an example arises, then we will bring in more notation for classes with respect to [math]\mathcal{O}[/math]

Incomplete classifications

When the classification for a given p-group is incomplete, this should be labelled clearly on the group's page, preferrably using the following:

CLASSIFICATION INCOMPLETE

Until the classification is known to be complete the labelling is provisional. After completion the labelling may be adjusted to conform to the usual conventions.

In cases where there are potential classes for which there is no known example (such as for blocks with cyclic defect group where there may be Brauer trees with no known block representative) these may be included as a row in the table of classes for that defect group, but with no label attached.

Conventions

There can be no canonical choice of labelling, but where possible please try to keep the following conventions in mind.

• Try to follow existing classifications for labelling where possible, provided that they have a logical basis.

• In general classifications should follow increasing number of simple modules.

• Where there is a relationship between classes for blocks with different defect groups, try to arrange the labellings accordingly.

Once established, only change a labelling in exceptional circumstances and be very careful to make the change in every effected place. Make it clear in the title of the edit precisely what changes you are making.