I have been trying to use the equation given from Vstar to overplot the data with the model light-curve using a programming language (for research purposes).
However, I find that using the given equation, with the dates of the data, often does not match the fit in the Vstar plot itself, there is a offset in the phase, such that the model curve (despite being correct in period and amplitude) does not fit the data. I have experimented with this but can see no obvious reason.
It may be worth looking at a particular example. To reproduce the problem, can I ask you to post a sample dataset, DCDFT parameters, periods and number-of-harmonics selected to created the model?
Also, the program (in python, ...?) you're using to work with the VStar model equation would be good to look at.
Thanks. I'll have a
Thanks. I'll have a look at this data.
To clarify, does the IDL code use the frequency from DCDFT and the Fourier Series coefficients A, B, C from a model (# of harmonics=1) created from that frequency in VStar?
Also, as an aside, is the data file from a particular source that might make a good candidate for an observation source plugin, or a personal format?
Apologies for the
Apologies for the silence the last couple of days. I've been focussing on preparing a new VStar release before the Silly Season gets fully underway.
I just wanted to mention that:
- As part of looking at this problem I ended up writing a Catalina Sky Survey observation source plugin for VStar. That will be available on the plugin library page when the new release is out (look for release announcement on this forum).
- I haven't tracked down the cause of the offset issue you reported yet. It appears that you are able to compensate for this but we need to understand where the problem is introduced.
I will continue to look at this when I can. The next couple of weeks will be problematic in that regard however.
I have captured this problem in a SourceForge tracker item:
Can you point me to the URL from which the data file CSS_J105923.9+394405.txt was obtained?
It's been pointed out to me that my CSS plugin needs to cater for CSV and does not currently; more details later. That plugin has had fairly minimal testing (on your sample data) so far. Any other pointers you can provide re: CSS data file format would also be appreciated.
I hope you (and all) have had a good break so far, assuming you had one of course. :)
Thanks, and no problem at all. It's that time of year. :)
I should first say thanks to John Greaves for sending me an email just before Christmas pointing out the bug in the Catalina Sky Survey (CSS) plugin. As mentioned in an earlier post, I had an unusually short amount of time to test the CSS plugin, only having used the sample data file you supplied above. I normally do a lot more testing. So, that's my fault for not being thorough.
I've replaced the space-delimiter with comma-delimiter (CSV) handling in the plugin. I plan to make a new VStar release available before the end of the month, and will ask Sara to update the plugin library page at that time.
Further to this though, the CSS format/output options seem to be numerous. This CSS usage page is fairly brief and non-specific (see Format section). The page you refer to above has an "Advanced Parameters" link which appears to be the primary reference. This has radio buttons to allow selection between output types:
and format types:
The default is ASCII + short. This results in CSV being output to the browser (View button at end of page) which can then be copied and pasted into a file or saved via the download link and right-mouse-click (or ctrl-mouse-click on Mac etc).
The changes I have made to the plugin now support this "ASCII + short" default, but nothing else.
I would appreciate guidance re: whether support for this short format is sufficient or whether there is merit in supporting other combinations. The short format column headers are:
The long format column headers are:
As an aside, John G suggested (in email) that providing VStar with a URL rather than requiring a file to be specified would be better, but this is a CGI based download page with no URL parameters, so that's not feasible.
I was thinking the same thing. From a data analysis viewpoint, it seems sufficient. Thanks for your help with this, and to John for pointing out the error. There will be a new release of VStar next week and a plugin update, including CSS.
Re: the model fit bug, no progress as yet, no. Sorry. All I've done so far is to capture it here:
and think about it a bit. If you'd like me to increase the priority, let me know. I don't want it to be a source of problems for you.
Hi Avon, all
Okay, so first: apologies for the long time since my last post to this thread. I was busy being a CHOICE course participant for the last few few weeks.
Second, I've reproduced your result by writing some R code, and I agree that the problem exists. The model equation generates a continuous curve that is offset (to the right) by a certain amount from both the observation data and the model data that the model equation purports to represent. So, this implies that the model function being generated by VStar is in error.
I've attached a bunch of files. They relate to your sample CSS data. Here's the raw and phase plots and model data points for a single period (196.783 days).
I also created a model (in VStar from DCDFT dialog) based upon that period and 4 harmonics (see 5f files below). Here's the phase plot with observations and model data points:
The attached files are:
- data.csv: the observations saved from VStar as CSV.
- model_f.csv: the single period model saved from VStar as CSV.
- model_5f.csv: the 5 period model saved from VStar as CSV.
- model_f.png: plot of observations (from data.csv), single period model data points, and single period model function.
- model_5f.png: plot of observations (from data.csv), 5 period model data points, and 5 period model function.
- model_plotter.R.txt (only has .txt suffix so I could attach it): R code that generates the last two plots.
Here are the two plots generated by the R code:
In both cases the offset of the function generated line plot from the observation and model data points is obvious.
Next step is to figure out what is apparently going wrong with model function generation.
I ran TS on the same data (converted to tab-separated form: data.tsv.txt, attached), generating a model for the 196.7829 day period.
The result is consistent with that from VStar. It would have been surprising if that weren't the case given that VStar's implementation is based upon TS.
The file ts_session.txt (attached) shows the TS run.
The following is from the end of the session output (data.ts.txt (attached)):
Frequency Period Power Amplitude cos sin const
0.005081741 196.7829 Fre01 0.3984 -0.3821 0.1128 13.0963
The file model_f_residuals.dat_.txt contains the residuals from the single-period model.
I should qualify the last post by saying that while VStar and TS agree upon Fourier coefficients for the model, TS is not taking the next step of generating an equation, so the problem may lie in how VStar does that.
I've asked Matthew Templeton about this problem and he has made some suggestions (thanks Matt) for things to look at and I'll post again when I have an update from that.
Hi Avon, all
Almost another month has elapsed since my last post on this topic!
Here's an update.
With reference to my previous post, the model (line fit) was plotted via the R code:
lines(jds, model(jds), col="blue")
In email correspondence, Matthew pointed out the need to use the same time-center of zero (or zero point) when plotting the model (blue line) as was used when the model was built. I looked at this and confirm that VStar (and TS) create a zero point and subtract it from JDs values in the range when building the Fourier series model. I'm looking further at the computation of the zero point.
Taking this into account, Avon's earlier comment about subtracting period/4 from the (zeroed) JDs gives the expected fit:
jds = jds-jd0
lines(jds+jd0-period/4, model(jds), col="blue")
where jd0 is a zero point constant (based upon, but not equal to, the first JD in the model range) subtracted from all JDs in the range before the model function is invoked on each JD (added back for the plot), and period is the fundamental period of the model, giving:
However, the same result can be obtained by subtracting period/8 without first subtracting a zero point from all JDs in the range:
lines(jds-period/8, model(jds), col="blue")
I'm continuing to look at the model creation code as I find the time.
Additional datasets and models of these datasets also need to be looked at to determine whether the findings based upon this sample dataset and model apply more generally.
Hi Avon, all
This bug is now fixed!
Thanks to Matt and Avon for their help in resolving this! Their comments guided me toward a solution.
The zero-point extracted during model creation was not being added back into the equation shown in the Analysis -> Models... dialog. Finding the right bits of the model creation code took awhile.
One of the things that will be included in SourceForge and probably elsewhere (e.g. docs) now is an R script that will plot observation and model data (saved from VStar as data.csv and model.csv) and the model function as a line plot. Here it is:
I've attached files showing another example, using LX Cyg. One plot is from VStar, the other from the R script.
This fix, along with others, will be in a new release sometime in the next week or two.