Multithreaded sky map operations

[LiYunyang]

Use OpenMP for map operations that are thread-safe (i.e. those that do not require resizing sparse backend storage). This includes any math operations on dense maps, populating sky masks, or applying map weights.

[arahlin]

Are there any other loops of this sort in the maps package that we should parallelize? Might as well include any others in this PR too.

[LiYunyang]

The other case is the zero_nans branch of RemoveWeightsT. I just changed it too.

There are a couple of instances in maputils.cxx that have the same structure, such as getXXMask. I suppose they are not called as frequently (as opposed to coadd) to make this a bottleneck.

[arahlin]

There are a couple of instances in maputils.cxx that have the same structure, such as getXXMask. I suppose they are not called as frequently (as opposed to coadd) to make this a bottleneck.

I would probably just parallelize all those loops anyway for consistency.

(Apologies for delayed review!)

[LiYunyang]

I searched for all cases of for (size_t and changed it for GetRaDecMap, GetRaDecMask, and GetGalacticPlaneMask -- I don't think the rest are thread-safe.

While doing this, I was warned that a race condition can occur if the map is not in a dense format (this is why ReprojMap fails ). Sasha, do you think this is a concern for RemoveWeights and ApplyWeights?

[arahlin]

I searched for all cases of for (size_t and changed it for GetRaDecMap, GetRaDecMask, and GetGalacticPlaneMask -- I don't think the rest are thread-safe.

While doing this, I was warned that a race condition can occur if the map is not in a dense format (this is why ReprojMap fails ). Sasha, do you think this is a concern for RemoveWeights and ApplyWeights?

Ah, that's a really good point, and probably why this wasn't parallelized in the first place. There is almost certainly a way to make the operation thread-safe for non-dense formats, but would take quite a bit of additional care. I haven't thought about this in any detail, but perhaps there are certain operations that can be marked as critical or atomic.

As it is, I think using this for ApplyWeights is fine, because that operation doesn't create any new non-zero pixels (that's the part that is not thread-safe, because it modifies the storage structure). For RemoveWeights, the zero_nans branches should probably not be parallelized until we can figure out how to handle non-dense storage.