izubiaurre

On 16/03/2021 at 17:33, alexwolf said:

This is very good question! We compute coordinates of radiants for valid range of activity from RA/Dec (J2000.0) and drift values to get the correct location of radiants (please compare to official maps: https://www.imo.net/files/meteor-shower/cal2021.pdf). Outside valid range of activity we just place radiant in location of first day of activity, but this is of course not correct by astronomical reason and correct by didactic reason (we mark location of radiant, but people will no see meteors).

 

 

So, if I'm understanding correctly, I have to calculate the position for the activity range and then add the drift value (driftAlpha * days passed since start of activity)? 

And, just not to confuse with values units, driftAlpha and driftDelta are in decimal degrees? For example, Quadrantids have DriftAlpha=3, DriftDelta= -1 values. So I have to understand that Alpha (Right Ascension) is increased by +3 decimal degress per day.

On 03/03/2021 at 07:41, alexwolf said:

Please check the values of coordinates within range of activity days

Now I can see the drifft affecting the RA and Dec values. Thanks!

But now I have another question:

should I apply the number of days (and hours and minutes) since J2000.0 times the drift to calculate the final RA and Dec for the given date within the activity days? Or, it is calculated for the first date and the drifft it is added for the rest of the dates until the end of the activity? 

Hi,

I'm making a function to calculate the topocentric position of any meteor shower for a given date, but when on the process of calculating the right-ascension and the declination it is somehow based on J2000.0 RA and declination values and a drift value for each of them. I don't really understand how this drift is applied in the calculations... For the information I have found, the drift values are per day (Stellarium handbook), but should I apply the number of days (and hours and minutes) since J2000.0 times the drift? Looking at Stellarium values of the Perseids, it seems that RA and Decl change day by day isn't as much as the drift should affect. 

Here some examples for Perseids meteor showers in Stellarium:
 

2000 January 1, 11:58:56 UTC: RA: 3h12m01.72s   Dec: +57º69'59.4"
2000 January 2, 11:58:56 UTC: RA: 3h12m01.72s   Dec: +57º59'59.4"
2000 January 3, 11:58:56 UTC: RA: 3h12m01.74s   Dec: +57º59'59.4"
2000 February 1, 11:58:56 UTC: RA: 3h12m02.00s Dec: +58º00'00.8"
2000 March 1,   11:58:56 UTC: RA:  3h12m02.38s  Dec: +58º00'02.6"

Drift values (radiant drift/per day): RA: 0h04m48.0s   Dec: +0º12'00"

As can be seen here, the difference between RA and Dec values day by day, and month by month does not fall near the drift values.

Maybe there's some other variable that I'm not counting and counters the effect of the drift?

Thank you

On 07/03/2020 at 01:31, Stu Todd said:

Ah I see what you're getting at. Does this link help with the maths?

http://articles.adsabs.harvard.edu/cgi-bin/nph-iarticle_query?bibcode=2000JIMO...28..176O&db_key=AST&page_ind=0&data_type=GIF&type=SCREEN_VIEW&classic=YES

Stu

Exactly. Thank you!

If I'm understanding correctly what you've said, no. Solar Longitude is the position (angle, 0º-360º) in the elliptic orbit around the sun starting at the vernal equinox. Also, it differs in the number of days each range 0º-90º, 90º-180º, 180º-270º and 270º-360º. Wikipedia 

Hi,

I'm trying to figure out if it's a way to calculate the date and time (JD) in a year for a solar longitude. I mean, I want to make a function that makes the calculations something like that:

double SolarLongitudeToJD(int year, double solarLongitude)
{
	// Here goes the code

	return JD;
}

I have searched in Jean Meeus book but found nothing about it (maybe it's the first time I haven't found any solution for my calculations in the book). I think that in the 24th chapter, there are the reverse calculation for what I trying to find: for a given date, various solar coordinates calculations, with the solar longitude between them.
 

Thank you for advance.

29 minutes ago, han59 said:

Note that the Moon can rise twice in one Earth rotation (23:56 minutes) due to it's own movement.

Same happens here.

33 minutes ago, pete_l said:

Perl Astro::Coords https://metacpan.org/pod/Astro::Coords

Thanks! Never heard of it before

Sometimes speaking and taking a little breath helps to get the results, even if they're not the expected ones.

 

Quote

visible (UTC): 2019 Apr 19 00:09
visible (UTC): 2019 Apr 20 00:05
visible (UTC): 2019 Apr 21 00:01
visible (UTC): 2019 Apr 21 23:57
visible (UTC): 2019 Apr 22 23:53
visible (UTC): 2019 Apr 23 23:49
visible (UTC): 2019 Apr 24 23:45
visible (UTC): 2019 Apr 25 23:42

Thanks for everything. Now I have to test more deeply if this is a correct result by chance or if the algorithm is correct for every case.

2 minutes ago, pete_l said:

When I did this, the library I used had  next_rising and next_setting functions. It was just a case of stepping through those.
Although how you handle the case of two in one day is down to your design. Personally I worked on the basis of "nights" rather than 24 hour days.

Which library was that? I'm currently using AAplus for C#, but astro rising/setting functions are mine and I'm gettting nuts trying to find a solution fot this case.

I'm getting these results:

 

Quote

 visible (UTC): 2019 Apr 17 00:17
 visible (UTC): 2019 Apr 18 00:13
 visible (UTC): 2019 Apr 19 00:09
 visible (UTC): 2019 Apr 20 00:05

NO visible : 2019 Apr 21

 visible (UTC): 2019 Apr 22 23:53
 visible (UTC): 2019 Apr 23 23:49
 visible (UTC): 2019 Apr 24 23:45

And this NO visible at 2019 Apr 21 is caused by the two risings in the same day
1st : 0:01
2nd: 23:57
The first one is before the nighttime of Apr 21th, so I'm calculating for the next day that gives 23:53, BUT the gap between Apr 21 0:01 and Apr 22 23:53 is more than 24h, my functions is returning wrong result. Maybe I should try to look this direction, if the gap between the results are bigger than 24h, treat as a special case.

Hi,

I have a curious case that calculating some random astro rising and setting times, I was getting erroneus results that for certain day (only one in the whole year) this astro wasn't rising despite I know that was otherwise. After some debug with the results for every single day of the year calculating rising times, I realized that this wrong result was caused by the fact of having two rising times in the same day. The first one at 0:01 and the second one must be at 23:57 (I'm calculating 23:57 value following the results of the next days and previous days). 

I'm following the Astronomical Algorithms from Jean Meeus book formulas for calculations. I think that the algorithms from the book are not prepared for these cases.

¿Do you know any way to solve this problem?

Thank you in advance