Distinguish between true mass and minimum mass

[ajtribick]

At present it is not possible to distinguish between true mass and minimum mass values, this also becomes relevant for spectroscopic binary stars that may be present in exoplanetary systems.

In principle there are 4 cases:

1. True mass known - current element <mass> would remain appropriate
2. SB1 systems, including RV exoplanets - approximated by m_sin(i) in the case that the secondary is much less massive than the primary, usually quoted as m_sin(i)
3. Timing minimum mass - I think this one actually is m*sin(i) rather than merely approximated by it.
4. SB2 systems - m*(sin(i))^3, not sure if this is actually relevant to any known exoplanet host system so far but maybe worth considering in case of future discoveries.

The existence of case 4 is an argment for not calling a minimum mass element <minimummass> or something along those lines, because of the very different behaviour as inclination varies. I am not particularly sure it is worth introducing elements to distinguish between cases 2 and 3 though.

I propose introducing the elements <msini> for cases 2 and 3, and <msin3i> for case 4. Perhaps also including <massfunction> for SB1 stars where the m*sin(i) approximation may not hold. Thoughts?

[hannorein]

This came up before and I agree that this is important to figure out. The sooner the better.

Other than introducing new tags, another possibility would be an attribute in the existing mass tag:

 <mass type="msini">1.0</mass>

The advantage is that it wouldn't break any existing script that pulls out the mass. Also, there might be an argument to be made for having one tag for every physical quantity (of course, the devil is in the detail).

I think the only two relevant cases are true mass and m*sin(i). There are a few more complicated cases, for example for microlensing discoveries where there is a degeneracy between two models, but I'm not sure if it is worth designing the catalogue scheme to suit these outliers.

If we only consider the two cases for now, we could keep the true mass entries as they are and simply add an attribute to the m*sin(i) cases.

I'd be happy to hear more thoughts/opinions!

[ajtribick]

Personally don't mind using it as an attribute, so long as there is a clear and consistent way to find out what the quantity actually represents. Mass function case came up due to considering how to represent the spectroscopic binary 30 Ari A.

[hannorein]

Ok. Then let's use an attribute. Feel free to suggest/use a better attribute name than type=...

[ajtribick]

It might also be worth supporting the "nominal masses" m_nom from TTV analyses.
See, e.g. http://adsabs.harvard.edu/abs/2012ApJ...761..122L and http://adsabs.harvard.edu/abs/2014ApJS..210...25X

So kind="msini" and kind="mnom" perhaps?

[hannorein]

Sounds reasonable to me. Maybe write out nominal?