15 replies to this topic

[terrain_inconnu]

Currently when looking for photometry targets I scan the AAVSO variable star index (VSX) and click on the respective Ephemeris tab in order to find out if a star will display a minimum during a planned session (e.g. tonight or in 2 weeks, whatever). This manual process works but is inefficient. Hence my question: is there an automated way to search for suitable targets within any given time frame?

Edited by terrain_inconnu, 15 February 2025 - 08:01 AM.

[btschumy]

You might try this page:

 

https://milwaukeeast...ryEphemeria.asp

 

It is not automated, but is much more efficient than what you are doing.

 

It will give a table of minima for a wide range of eclipsing binaries.  A simpler version of this is generally posted in the AAVSO eclipsing binaries group (fewer stars).

 

One thing to be aware of.  The dates (e.g. 4-5 Feb) are for the night of that date in North America.  The times however are in UTC.

 

As he explains, the minima predictions are rounded to the nearest 30 minutes so it won’t bias you minima observation.  If you want you can use the VSX ephemeris to get a more accurate prediction once you’ve narrated the search.

Edited by btschumy, 15 February 2025 - 09:42 AM.

[terrain_inconnu]

You might try this page:

 

https://milwaukeeast...ryEphemeria.asp

 

It is not automated, but is much more efficient than what you are doing.

 

It will give a table of minima for a wide range of eclipsing binaries.  A simpler version of this is generally posted in the AAVSO eclipsing binaries group (fewer stars).

 

One thing to be aware of.  The dates (e.g. 4-5 Feb) are for the night of that date in North America.  The times however are in UTC.

 

As he explains, the minima predictions are rounded to the nearest 30 minutes so it won’t bias you minima observation.  If you want you can use the VSX ephemeris to get a more accurate prediction once you’ve narrated the search.

Fantastic, that's already a huge improvement. Thank you.

[Ed Wiley]

Try

http://www.motl.cz/dmotl/predpovedi/

 

You have to be careful, some of the data are out of date (2018), but there is an update, see:

 

https://www.aavso.or...eck_logged_in=1

 

You can cross-check the update information with ASX if you wish to do so once you have your nightly target/s

 

This tool, using the Krakow update is efficient.

 

Ed

[terrain_inconnu]

Try

http://www.motl.cz/dmotl/predpovedi/

 

You have to be careful, some of the data are out of date (2018), but there is an update, see:

 

https://www.aavso.or...eck_logged_in=1

 

You can cross-check the update information with ASX if you wish to do so once you have your nightly target/s

 

This tool, using the Krakow update is efficient.

 

Ed

I just downloaded the exe file and installed it right away, looks exactly like what I was looking for. Need to sort out the part with updating the catalogue next, but seems straightforward. Many thanks, this is a great tool.

 

[btschumy]

I was not aware of this Ephemeris app either.  I've downloaded it and updated the Krakow database.  I've notice one discrepancy with the site I mentioned but it is not clear who's right.

 

This will likely be my go to app for observation planning.

[Ed Wiley]

In order to use the ephemeris you MUST have Krakow.dat in the folder that holds ephem.exe and the other files. I check only Krakow. Otherwise your ephemeris may be out of date. And it is always a good idea to cross check with VSX, sometimes there are differences. When I encounter differences, I compensate with longer runs and try to see which is correct (or more correct).

 

Ed

Edited by Ed Wiley, 16 February 2025 - 08:52 AM.

[terrain_inconnu]

In order to use the ephemeris you MUST have Krakow.dat in the folder that holds ephem.exe and the other files. I check only Krakow. Otherwise your ephemeris may be out of date. And it is always a good idea to cross check with VSX, sometimes there are differences. When I encounter differences, I compensate with longer runs and try to see which is correct (or more correct).

 

Ed

I noticed that while the Krakow DAT file itself contains the period information one can not filter for it in the tool.

[Ed Wiley]

I noticed that while the Krakow DAT file itself contains the period information one can not filter for it in the tool.

This ephemeris is designed primarily to furnish nightlyToM information. The period information is valuable, fo course, but my experience is that there are not that many nightly EB targets in, for example, one constellation. I find it easy to look over the list for data like EW periods or EA durations (if known). So the trick is to limit your interest in some restricted part of the sky so as not to be overwhelmed by data.

 

Use of the resource depends on your ToM research program and it might be very useful or not depending on what you know about your variables. For beginners the easiest resource is the AAVSO ToM program which features nightly ephemeri with ToM predictions that you can then correlate with the Karkow information if you wish. (See AAVSO Eclipsing Binary group). You can see who well you are doing by comparing your ToM with other observers ToMs by lkearning how to use the Bob Nelson shreadsheets (also at AAVSO).  If you have a well established research program you might not need the resource at all. If you are "night-tripping" and looking for somehting to measure, then its a very nice resource. Call up a convenient area of the sky and look for something interesting. Having found it, add it to your list for future observation. Etc., etc......

 

If you are interested in ordering by period, then other databases might be better.
 

Ed

 

Resources: 

https://www.aavso.or...inaries-section

https://www.aavso.or...nimum-databases

[terrain_inconnu]

This ephemeris is designed primarily to furnish nightlyToM information. The period information is valuable, fo course, but my experience is that there are not that many nightly EB targets in, for example, one constellation. I find it easy to look over the list for data like EW periods or EA durations (if known). So the trick is to limit your interest in some restricted part of the sky so as not to be overwhelmed by data.

 

Use of the resource depends on your ToM research program and it might be very useful or not depending on what you know about your variables. For beginners the easiest resource is the AAVSO ToM program which features nightly ephemeri with ToM predictions that you can then correlate with the Karkow information if you wish. (See AAVSO Eclipsing Binary group). You can see who well you are doing by comparing your ToM with other observers ToMs by lkearning how to use the Bob Nelson shreadsheets (also at AAVSO).  If you have a well established research program you might not need the resource at all. If you are "night-tripping" and looking for somehting to measure, then its a very nice resource. Call up a convenient area of the sky and look for something interesting. Having found it, add it to your list for future observation. Etc., etc......

 

If you are interested in ordering by period, then other databases might be better.
 

Ed

 

Resources: 

https://www.aavso.or...inaries-section

https://www.aavso.or...nimum-databases

You are absolutely right, in practice I usually concentrate on one area of the sky so the amount of possible targets is limited.

 

And while I can not really complain about this very handy software, it's a shame that it is missing two filters that would have been very easy to include right away (one for period and one for depth).

[Ed Wiley]

You can always query the authors of the EB Ephemeris and make the case for a format that allows one to parse more details and see how they respond. Thery might like the suggestion.

 

Ed

[terrain_inconnu]

You can always query the authors of the EB Ephemeris and make the case for a format that allows one to parse more details and see how they respond. Thery might like the suggestion.

 

Ed

True, though it looks like the software is not supported anymore (last update was 2018). But maybe I am wrong. Might send an email to the author and see what happens.

[yuzameh]

Just go to the Krakow website directly.

 

https://www.as.up.kr...icalc/ANDTW.HTM

 

is an example.  Notice that although you can find an index there based by constellation then variable name (in sort order of variable star designation, ie R to Z then RR to RZ etc) you can simply directly edit the URL , for instance replace TW And with ZZ Boo and you'd have

 

https://www.as.up.kr...icalc/BOOZZ.HTM

 

(boozy!)

 

It's case sensitive.  Note also it takes your computer's local timezone / system time as the current time (whether it corrects all those to UT or stays in your time zone I know not as I happen to live in GMT/UT timezone so only need to check such things in Summer Time and we ain't there yet and I can't remember what happens then in terms of if it stays in GMT at Krakow).  HJD equates to UT in practice.

 

Only problem is, gee whizz, results are in HJD so you need to convert to normal JD for your lat and long, plenty of those online or downloadable if you look.

 

As for sorting on magnitude and/or amplitude, that's even simpler, VizieR version of GCVS.

 

https://vizier.cds.u...B/gcvs/gcvs_cat

 

Next to VarType you enter

 

E*

 

next to max mag you put your preference, eg 6

 

if you want an amplitue of 1.5 mag or fainter (ie depth of minimum) you put >7.5 in this case, remember the GREATER the magnitude the FAINTER the star, so fainter is greater than and brighter is less than.

 

You can also put a declination value in, eg dec >0, to crop off Southern stuff or the reverse.

 

This gives you a shortlist and if you already doing something like this you should be already well familiar enough to know which constellations are visible at your preferred observing time of night for whichever month of the year it is.  For example, in the North, late evening to early night, Orion will be currently favourable.

 

NOW, the thing with binary stars and accuracy of prediction is the last EPOCH published, that's why stuff like the Krakow O-C stuff and the Bob Nelson O-C stuff is better.

 

The simplest form of the basic calculation is

 

Predicted Eclipse time = Base Epoch + n times period, where n is the number of cycles.

 

Today is apparently JD 2460728, and decimal part will give you the UT time with online converters and some downloadable programs and maybe even a spreadsheet version for bulk conversion if you search enough.

 

This is where recentness of "Elements", ie the date of the last epoch comes in.  Preferably you want one that is JD 2455000 or later, the laterer the betterer given reliable source.  Today 5728 days have passed since then, nearly 15 years.  Given a period between eclipses of day 3.65 days (to make the arithmetic far, far simpler) that's 1500 eclipses since the last measurement.  Depending on the precision and accuracy of latest Epoch (which you use as your base Epoch) your prediction will get steadily worse the older the Base Epoch and the more imprecise the period is.  The reciprocal of 1500 is 1/1500 or 0.000666 recurring 6, if your Epoch is good to 0.0001 of a day that shouldn't be too far off (the eclipse prediction can be off by a few minutes due to such problems, and also because period varies for many objects, as shown by the O-C plots).

 

Anyway, you have your current time, you get HJD, you look up the base epoch HJD (and I haven't checked if any of the recommended software corrects HJD to GJD [H = helio G = geo].  You see the Earth has an orbit such that at Earth the eclipse time differs by +/- 8.3 minutes relative to the Sun, so that's why date matters.

 

You take base epoch HJD from today's current time HJD and the result is the number of days since the last measured/published ecipse date.

 

You take that value and divide it by the period given in your resource, preferrably the one the Base Epoch came from.  You'll end up with an integer and a decimal.  Throw the integer away, that is merely the total number of previous past eclipses since the base epoch.

 

The remaining decimal is the amount into the currect orbital period.  Eclipses occur at value 0, that is define ecilpse time as 0.  Each orbit goes from 0.000000000000 of period (the eclipse time) until just before the next eclipse, or 0.99999999999999etc.  One period is 1 orbit, a distance of one eclipse from the last eclipse, so 0 = last one, 1 = next one.  So the next ecilpse is 1 minus your decimal value, the decimal that is returned from that is then added to your current time (the one you used previously) to get the HJD time of the next eclipse.  You can convert that to GJD (usually called just JD when such pedentary is not needed) and much software and online resources can be found to convert JD to time, usually UT time, and you are probably familiar with converting UT to your timezone.

 

It seems long winded but you can set this up (how many eclipses are you going to catch in one night, seeing you can only follow one at once?) and although it is not one piece of software does all, this is basically only arithmetic and gets you far more precise than using online software that uses out of date epoch values.  Out of date epoch values are the far bigger problem, no matter how clever the software if the epoch values are out of date enough that's that, rubbish results.  Even worse if the period value is also iffy or the period value has changed a small but significant part of a decimal (remember, the more ecilpse cycles since the base epoch date the more a decimal error adds up.  A difference of 0.001 days means an error after around 1000 days, or less than 3 years and many available base epochs  in VSX and GCVS are way older than that (most of the VSX epochs for GCVS eclipsers are from an old copy of the GCVS anyway, unless they've updated to the latest updated GCVS which has newer elements, but they hadn't last time I looked a few months back).

 

If you've got the latest stuff and because deep eclipses will last several hours usually you can ignore HJD to GJD conversion because what's 16.6 minutes maximum error range (well, up to 8.3 minutes early or 8.3 minutes late, but UP TO, it will be between that and 0 depending on where the Earth was in its orbit during the base epoch measure and where it is in its orbit now).  To determine a mid eclipse well you need a good portion of the whole eclipse covered and that will be at least a couple of hours or more, and even if just eyeballing the eclipsing half an hour either size should of predicted mid eclipse should give you all you want to see for deep eclipsers.

 

Stuff like that.

[terrain_inconnu]

Just go to the Krakow website directly.

 

https://www.as.up.kr...icalc/ANDTW.HTM

 

is an example.  Notice that although you can find an index there based by constellation then variable name (in sort order of variable star designation, ie R to Z then RR to RZ etc) you can simply directly edit the URL , for instance replace TW And with ZZ Boo and you'd have

 

https://www.as.up.kr...icalc/BOOZZ.HTM

 

(boozy!)

 

It's case sensitive.  Note also it takes your computer's local timezone / system time as the current time (whether it corrects all those to UT or stays in your time zone I know not as I happen to live in GMT/UT timezone so only need to check such things in Summer Time and we ain't there yet and I can't remember what happens then in terms of if it stays in GMT at Krakow).  HJD equates to UT in practice.

 

Only problem is, gee whizz, results are in HJD so you need to convert to normal JD for your lat and long, plenty of those online or downloadable if you look.

 

As for sorting on magnitude and/or amplitude, that's even simpler, VizieR version of GCVS.

 

https://vizier.cds.u...B/gcvs/gcvs_cat

 

Next to VarType you enter

 

E*

 

next to max mag you put your preference, eg 6

 

if you want an amplitue of 1.5 mag or fainter (ie depth of minimum) you put >7.5 in this case, remember the GREATER the magnitude the FAINTER the star, so fainter is greater than and brighter is less than.

 

You can also put a declination value in, eg dec >0, to crop off Southern stuff or the reverse.

 

This gives you a shortlist and if you already doing something like this you should be already well familiar enough to know which constellations are visible at your preferred observing time of night for whichever month of the year it is.  For example, in the North, late evening to early night, Orion will be currently favourable.

 

NOW, the thing with binary stars and accuracy of prediction is the last EPOCH published, that's why stuff like the Krakow O-C stuff and the Bob Nelson O-C stuff is better.

 

The simplest form of the basic calculation is

 

Predicted Eclipse time = Base Epoch + n times period, where n is the number of cycles.

 

Today is apparently JD 2460728, and decimal part will give you the UT time with online converters and some downloadable programs and maybe even a spreadsheet version for bulk conversion if you search enough.

 

This is where recentness of "Elements", ie the date of the last epoch comes in.  Preferably you want one that is JD 2455000 or later, the laterer the betterer given reliable source.  Today 5728 days have passed since then, nearly 15 years.  Given a period between eclipses of day 3.65 days (to make the arithmetic far, far simpler) that's 1500 eclipses since the last measurement.  Depending on the precision and accuracy of latest Epoch (which you use as your base Epoch) your prediction will get steadily worse the older the Base Epoch and the more imprecise the period is.  The reciprocal of 1500 is 1/1500 or 0.000666 recurring 6, if your Epoch is good to 0.0001 of a day that shouldn't be too far off (the eclipse prediction can be off by a few minutes due to such problems, and also because period varies for many objects, as shown by the O-C plots).

 

Anyway, you have your current time, you get HJD, you look up the base epoch HJD (and I haven't checked if any of the recommended software corrects HJD to GJD [H = helio G = geo].  You see the Earth has an orbit such that at Earth the eclipse time differs by +/- 8.3 minutes relative to the Sun, so that's why date matters.

 

You take base epoch HJD from today's current time HJD and the result is the number of days since the last measured/published ecipse date.

 

You take that value and divide it by the period given in your resource, preferrably the one the Base Epoch came from.  You'll end up with an integer and a decimal.  Throw the integer away, that is merely the total number of previous past eclipses since the base epoch.

 

The remaining decimal is the amount into the currect orbital period.  Eclipses occur at value 0, that is define ecilpse time as 0.  Each orbit goes from 0.000000000000 of period (the eclipse time) until just before the next eclipse, or 0.99999999999999etc.  One period is 1 orbit, a distance of one eclipse from the last eclipse, so 0 = last one, 1 = next one.  So the next ecilpse is 1 minus your decimal value, the decimal that is returned from that is then added to your current time (the one you used previously) to get the HJD time of the next eclipse.  You can convert that to GJD (usually called just JD when such pedentary is not needed) and much software and online resources can be found to convert JD to time, usually UT time, and you are probably familiar with converting UT to your timezone.

 

It seems long winded but you can set this up (how many eclipses are you going to catch in one night, seeing you can only follow one at once?) and although it is not one piece of software does all, this is basically only arithmetic and gets you far more precise than using online software that uses out of date epoch values.  Out of date epoch values are the far bigger problem, no matter how clever the software if the epoch values are out of date enough that's that, rubbish results.  Even worse if the period value is also iffy or the period value has changed a small but significant part of a decimal (remember, the more ecilpse cycles since the base epoch date the more a decimal error adds up.  A difference of 0.001 days means an error after around 1000 days, or less than 3 years and many available base epochs  in VSX and GCVS are way older than that (most of the VSX epochs for GCVS eclipsers are from an old copy of the GCVS anyway, unless they've updated to the latest updated GCVS which has newer elements, but they hadn't last time I looked a few months back).

 

If you've got the latest stuff and because deep eclipses will last several hours usually you can ignore HJD to GJD conversion because what's 16.6 minutes maximum error range (well, up to 8.3 minutes early or 8.3 minutes late, but UP TO, it will be between that and 0 depending on where the Earth was in its orbit during the base epoch measure and where it is in its orbit now).  To determine a mid eclipse well you need a good portion of the whole eclipse covered and that will be at least a couple of hours or more, and even if just eyeballing the eclipsing half an hour either size should of predicted mid eclipse should give you all you want to see for deep eclipsers.

 

Stuff like that.

I knew some loose bits and pieces of the above, but "stuff like that" is a tour de force. Thanks a ton.

[terrain_inconnu]

Just found this searchable online database for eclipsing binaries minima by the Czech Astronomical Society: https://var.astro.cz...nimaPredictions

[terrain_inconnu]

You can always query the authors of the EB Ephemeris and make the case for a format that allows one to parse more details and see how they respond. Thery might like the suggestion.

Ed

Update: I actually did write to David Motl (the author of this utility) and today he released a new version which includes the filters for orbital period and depth.

Edited by terrain_inconnu, 14 March 2025 - 09:09 AM.