should obsconditions be in mock targets catalog or not?

[moustakas]

@forero In #207 (see especially #207 (comment)) after some discussion it was decided to not include OBSCONDITIONS in the mock targets catalog, since this is something that should be computed by the MTL on the fly.

However, in 83627e2 and f43aa0e you added this back in. (Mea culpa that I didn't ask this question sooner, since I was the reviewer on that PR!)

Perhaps @sbailey can weigh in as well, but should OBSCONDITIONS be in there or no?

[moustakas]

Following up on this question. @sbailey do you know, offhand?

[sbailey]

Thanks for the reminder.

OBSCONDITIONS is a bitmask of allowable observing conditions for a given target, which should be completely derivable from the targeting bits themselves. Having it in the targeting table itself may seem convenient, but it would be better to not have it in the table and provide utility functions instead, in case we change our mind about which bits are allowable under what conditions (then we just update targets.yaml instead of having to release a new targeting catalog just to update that column). e.g.

def get_obsconditions(desi_target):
    '''returns obsconditions mask for input array of desi_target targeting bits

    desi_target can be int or array-like; return value matches dimensionality
    '''
    ...

def ok_obsconditions(desi_target, conditions_mask):
    '''check whether desi_target can be observed under conditions_mask

    conditions_mask is int; desi_target can be int or array-like;
    return value matches dimensionality of desi_target
    '''
    ...

(or a better name than ok_obsconditions...)

[moustakas]

It was decided in #264 to not include obsconditions in the output (mock) target catalogs, so I'm closing this.