Naming a series and period decimal places

Hi David,
I was trying VStar to combine CRTS data and my own file and found a couple of issues that I'd like to consult you about.

Firstly, when uploading my own file, I can't find a way to name the series so the plot doesn't say "Unspecified" when referring to those observations. Is there an option to name the observations uploaded from your own file?

Secondly, when I tried to enter the VSX period of the star I was analyzing (a period to 7 decimal places) in a phase plot, even though I entered the 7 decimal places, the plot only displayed 6 and even if I changed that 7th decimal place, the result was the same. Is there a limit in the number of decimal places in a period that you enter manually? For DSCT stars, many decimal plces might be significant.
In the VStar manual the examples show 9 decimal places so I don't know what might be happening.

There's a few ways we can think about changing the the series to something other than Unspecified.

Changing the Simple File Format (user manual, page 8), e.g. adding series/band as an optional column. Certainly possible. This format has its roots in a Citizen Sky requirement. I'd want to have a conversation in this forum about this first.

Create a plug-in for a format that allows a more flexible input. Certainly possible.

Create a plug-in that changes the series/band of a set of observations. Certainly possible.

Create a new series from filter. This would give a new series in the plot view but looking at observation details or the observation list would still show the observation as having the band Unspecified. Currently possible. See user manual, p 43.

So does 1) mean that you should add a column to your file with the name you want to display instead of "Unspecified"?

I am working with a couple of VSX submitters that will add their own data so their own names or their observatorie's names (plus filter) should be displayed instead of Unspecified. E.g. "Rogers V" or "Mt. Torres Obs. V" or the like.

Another question. Even though I read page 9 on additive loads and HJD, it is not clear to me where the HJD correction is applied and when not.
E.g. I have an observer who will use CRTS data -via plug in- and then he will add his own observations.

1) Are CRTS observations converted to HJD once uploaded?
2) Are his observations going to be converted to HJD or not? Most data files form users already are in HJD because the photometry software did the conversion.

So assume a CRTS datafile and an observer's HJD datafile. Both added to VStar for analysis. What are the dates after uploading?
This situation will be a typical one for dataminers since they will use survey data and combine them with their own. No AID data involved.

To answer your second question first, thanks for prompting me to raise the priority of this. Version 2.16.2 is being prepared for release (just uploaded to SourceForge and Sara is preparing it for access from the AAVSO web). I've now implemented something that was on my list: RA and Dec are requested in non-AID loads. I've updated the user manual accordingly. In the case of a non-HJD file (such as CRTS), a subsequent additive load of a HJD file (such as AAVSO upload format can be) will result in the user being asked to enter RA and Dec (e.g. from VSX; B1950.0 are currently requested; it's on my list to move to J2000.0) and the CRTS data will be converted to HJD. I could get the RA and Dec from VSX but for file formats I've tried not to assume that there is necessarily any Net connectivity. I'm also taking the approach of starting simple and adding complexity over time. So VSX as an option is a possibility down the track.

The key thing is that one of the data sources has to indicate that it contains HJD observations.

To answer your first question, assuming AAVSO upload format is not suitable (there's a plug-in for that), I think what we want here is a new observation source plug-in that allows arbitrary columns, including arbitrary series/filter/band. We could also have directives to indicate HJD vs not etc. If this kind of plug-in is required, happy to prioritise that since an obvious need is being expressed. Let me know.

>>> In the case of a non-HJD file (such as CRTS), a subsequent additive load of a HJD file (such as AAVSO upload format can be) will result in the user being asked to enter RA and Dec and the CRTS data will be converted to HJD <<<

The problem is that sometimes the user will only use CRTS data, not combining them with any other dataset.
I think that converting to HJD should be a completely independent option with the RA and DEC window being opened by the user to do that step when necessary.

>>> The key thing is that one of the data sources has to indicate that it contains HJD observations <<<

There may be two or more datasets and none of them might have HJD which in this scenario would mean no HJD correction is possible. For short period stars this would have an impact on the analysis.

And how is it that the source indicates it contains HJD observations?
Are AAVSO AID data assumed to be in HJD? That is not the case most of the time. At least visual people report JD not HJD. I think the AID has a mix of JD and HJD, with the CCD observers mostly reporting HJD...

I think that the HJD option would be independent so the user should always have the chance to enter the star's position (e.g.: a window would pop up to remind him if he needs to apply the HJD correction and if yes, he should enter the star's position).

I think that solving the HJD issue is a higher priority than the naming series issue although both would be great improvements.

Okay, we can satisfy this in the interim by a plug-in that allows arbitrary HJD conversion. That can later become an in-built menu item if desired.

Specific observation source plug-ins like ASAS, CSS, Kepler indicate to VStar at the time a dataset is loaded that the obs are in HJD. The AAVSO upload format (WebObs) plug-in may present HJD or JD, and again, the plug-in tells VStar at load time which it is.

AID loads always use (and convert if necessary) the JD column although there is a separate HJD column. I might let Sara comment further on that one after she's done with the release

You include "CSS" in the list of sources indicating that the observations are in HJD. What do you mean with CSS? The CRTS datasets I download that include CSS observations are in MJD so 2400000.5 has to be added and the HJD correction applied.

Thanks Sebastian. My general comment about HJD and obs source plug-ins was a bit sloppy. CSS (CRTS as accessed via VSX) does not perform HJD, just as you say. Some plug-ins (like ASAS and optionally AAVSO Upload Format) do.