Fixes to habitable_locs usage to avoid dimension mismatch

[Rosejoycrocker]

habitable_locs is a BitVector which describes which locations have k>0.0. This was being used incorrectly in several places but was unnoticed due to Moore having no locations with k=0.0. For example habitable_loc_areas was reshaped to length habitable_locs', but habitable_loc_areasmay be shorter than habitable_locs' due to filtering using `habitable_locs'.

[ConnectedSystems]

What's the reason for the additional whitespace?

[ConnectedSystems]

unnoticed due to Moore having no locations with k=0.0

Not saying there isn't a problem, but I find this hard to believe as the related code hasn't changed in a long time and we were using the older representation of Moore for a long time (which does have 0 valued site areas).

I'll have to check the GBR-wide dataset too.

[Rosejoycrocker]

unnoticed due to Moore having no locations with k=0.0

Not saying there isn't a problem, but I find this hard to believe as the related code hasn't changed in a long time and we were using the older representation of Moore for a long time (which does have 0 valued site areas).

I'll have to check the GBR-wide dataset too.

Perhaps not all of these changes are necessary but some lines don't make sense to me logically. For example
habitable_loc_areas' = reshape(habitable_loc_areas, (1, 1, length(habitable_locs))) where habitable_loc_areas=vec_abs_k[habitable_locs] is bound to break because habitable_locs is a bit vector, so unless it is always all trues, habitable_loc_areas will be shorter than habitable_locs and the reshape will error.