Hi everyone -
I listed below some VSX records below involving unusual subtypes.
For DPV-type variables, the AAVSO documentation on variable types [1] mentions DPV/ELL (ellipsoidal) and DPV/E (eclipsing) but doesn't explicitly call out DPV/EA or DPV/EB. What is the correct interpretation? Could it equivalently be DPV/E+EA or DPV/E+EB?
Also, unrelated, but possible typo (?) for oid=237633. I'm guessing that should read LMXB/XR.
3067 DPV/EA LP Ara
5280 DPV/EA DD CMa
7792 DPV/EA V0495 Cen
9483 DPV/EA BF Cir
18902 DPV/EA AU Mon
20153 DPV/EA GK Nor
31842 DPV/EA V4142 Sgr
33209 DPV/EA V0393 Sco
33409 DPV/EA V0593 Sco
37555 DPV/EA DQ Vel
83457 DPV/EA V0451 CMa
121224 DPV/EA ASAS J212959-2300.1
237633 LMXB/R AX J1845.0-0433
449604 DPV/EA GDS_J1630570-510306
689898 DPV/EB MNIC V99
1217251 DPV/EA OGLE-BLG-ECL-157529
Source: [1] https://www.aavso.org/vsx/index.php?view=about.vartypes
Thank you for your continued guidance and insights.
John Rachlin (RJOJ)
Hi John,
It is correct to define DPV/E as the class because E stands for "eclipsing systems" and EB and EA are subtypes of eclipsing binaries. The definition says they are semi-detached interacting binaries so that excludes EW.
DPV/E+EA or DPV/E+EB are incorrect. They are redundant. EA and EB are subtypes of E, if you go to the E definition, you will see that E is just an eclipsing binary when a subtype has not been defined.
The way you show them, with the "+" symbol, implies that the system is triple or quadruple, with two different sets of eclipses, one without a subtype and one with a subtype. And I know that you don't mean that.
The LMXB/R, should be LMXB/XR, yes, but the period found when that type was determined wasn't correct so I just removed that subtype.
Cheers,
Sebastian
Thanks so much Sebastian. By the way, by parsing through the 2.3 million VSX records and trying to match with the AAVSO types documentation, I've been finding other possible typos and oddities. Some of these might be perfectly valid, not sure. I can send you OIDs if helpful.
Sr instead of SR (3)
PUL instead of PULS (3)
RRc instead of RRC (4)
SNIa-pec instead of SN Ia-pec (11)
SNIIn-pec instead of SN IIn-pec (1)
LPB instead of LPV (or LB?) (1)
SXPXE: (1) - probably SXPHE: (OID = 2216507)
NON-CV (29) - listed as "non-cv" in documentation
ACVO (1) - should be roAp I believe (ACVO being the older GCVS type)
GAL (1) - should be AGN ?
RPHS (5) - should be V361HYA ?
Hi John,
remarks on your findings:
In a few cases it can't be proved that some of the objects showing dips are YSOs, so for those, the DIP subtype has been used as the type.
Well, these are not variable at all, just erroneous reports, and as such they are not even actual types, what you see here is a word describing what they are.
Sr instead of SR (3)
PUL instead of PULS (3)
RRc instead of RRC (4)
SNIa-pec instead of SN Ia-pec (11)
SNIIn-pec instead of SN IIn-pec (1)
I will pass these ones to Patrick, it might be better to correct them in groups instead of one by one.
LPB is the way the GCVS Team call the SPB type so I will edit it (UPDATED: it was an ELL not an SPB).
Sure. I will update it.
NON-CV (29) - listed as "non-cv" in documentation
ACVO (1) - should be roAp I believe (ACVO being the older GCVS type)
Yes. I will update it.
GAL = Galaxy. But it was a variable AGN so it was revised.
Yes. Sent to Patrick.
No, we don't even know what they are. They might be spurious at all. We just took the types from the original NSV catalogue.
The new version of the catalogue may have better data. It is in the lists of catalogues that we are updating so probably the number of such entries will decrease in the future.
Thanks for listing these issues, it is really useful ;)
Best wishes,
Sebastian