Dear Doug,

thank you for the clarification.
So to make sure, do you use this group_avg_area for each vertex also for building null distribution of maximal cluster size? The area values in .csd files are values of group_avg_area of cluster with maximal group_avg_area in each simulation step?
Looking to the source codes it seems to me that the "actual area" of vertices (named "area" in source codes) in fsaverage surfaces is by default not used for anything.

This would be reason why in cluster reports from p-map surface overlays originally generated by PALM but clustered by mri_surfcluster the p-values of clusters were not monotonous with respect to cluster area.
There was cluster with larger area, but larger p, than other cluster, which had smaller area, but also smaller p.
Which was one of the reasons why I digged onto this issue.
Now I am at least getting correspondence between PALM and mri_surfcluster cluster sizes. I "detached" lh.white from lh.white.avg.area.mgh (this file is implicitly read by mri_surfcluster), then I got values differing only by global scaling factor corresponding to the ratio of group_avg_surf_area/total_area.
PALM does not do this correction.

Apparently there is quite large region-specific variability in scaling factor between area and group_avg_area of vertices due to the fact that some regions of brain are less spatially variable (less small individual-specific folds), therefore their average surface does not lose too much folding.

Is this effect also accounted for in smoothing on average surface, i.e. are the group average distance between vertices used for smoothing instead of actual positions of the vertices?
This would require storing this info somewhere which does not seem to me.
If the real positions and distances of vertices in average surfaces are used for smoothing, but group_avg_area is used for cluster extent inference, then this effect would in fact introduce variance of spatial smoothness of data, which could have consequences to statistical inference, wouldn't it? How this is handled?

I have several related questions:

Reading source code I came across term "ripped" faces/vertices. It seems to me that these faces/vertices are effectively excluded from computations. What does this term mean? Are there any "ripped" vertices in fsaverage subject surfaces?

Do you also generate file corresponding to avg.area.mgh in make_average_surfaces? From the code it seems to me that there is only global scaling realized by setting total group_avg_area average surface file.

Which values are stored in lh.area of fsaverage? It seems to me that these values do not correspond to area of real lh.white vertices.

Thank you for your kind support.

Regards,

Antonin Skoch

It is quite confusing and took us some time to understand ourselves. 
When we create an average subject like fsaverage, we have to create a 
triangular mesh just like we do with any subject. This means that we 
have to assign an xyz to each coordinate. When trying to represent a 
group, this is not straight forward. The way we do it is to compute the 
xyz coordinate in MNI305 space for each vertex for each subject, then 
map that through the spherical registration into the common 
surface-space for each subject. We then average the MNI305 xyzs across 
subject to arrive at the xyz for that vertex in the common 
surface-space. This gives the pial surface of fsaverage its brain-like 
shape. The problem is that it is much smoother than an individual cortex 
because all the little folds have been averaged out. This means that the 
surface has much less surface area than any of the  individuals used to 
make the average (from a surface area standpoint, it is not an average 
at all!). To be able to report average surface area, we computed the 
area of each vertex of each subject and mapped this into the common 
surface space and averaged it across subjects. When we want to report an 
area for a given region, we compute the sum of the vertex average areas 
rather than the area of the vertices themselves.