1. Globalmeteornetwork | Main
  2. Topics

Different outcomes with different methods of orbit calculations #fireball

tegla hunter
 

Hi all,

There was a smaller fireball over Hungary, 2023. 03. 03. 00:09 UT. This event isn't important in itself, but I've tried out GMN's softwares (SkyFit2 and WMPL) and compared it to my old method (Sonotaco's UFOAnalyzer and UFOOrbit). In UFOOrbit I used the first ~0.83s of the trajectory (until reaching an altitude of 69.76 kms) for initial velocity. I got 14.66 km/s and an aphelion distance of 5.914 AU using this speed data. End altitude is 41.02 km. I did the same with WMPL (--vinith 69.76) and got 14.00 km/s entry velocity, aphelion distance of 4.504 AU and an end altitude of 35.13 km. What caused this level of difference between the two calculations? The level of coordinate inaccuracies cannot explain this.

GB 

ORB.bmp

20230303_000920_orbit_top.png

Mark McIntyre
 

Its pretty much impossible to say, since Sonotaco's software is a black box and they don't publish their algorithms as far as i am aware. 

However, as far as anyone can tell, UFOOrbit fits some sort of model through the data. This approach can't really take into account variable air density, wind, breakup events, meteoroid structure etc. WMPL uses all available points to determine the seen trajectory, and doesn't rely on any predetermined model of the meteoroid's physical characteristics or how it might be moving through the atmosphere.

TLDR: no idea, but i'd trust WMPL more.

On 08/03/2023 22:33, tegla hunter wrote:

Hi all,

There was a smaller fireball over Hungary, 2023. 03. 03. 00:09 UT. This event isn't important in itself, but I've tried out GMN's softwares (SkyFit2 and WMPL) and compared it to my old method (Sonotaco's UFOAnalyzer and UFOOrbit). In UFOOrbit I used the first ~0.83s of the trajectory (until reaching an altitude of 69.76 kms) for initial velocity. I got 14.66 km/s and an aphelion distance of 5.914 AU using this speed data. End altitude is 41.02 km. I did the same with WMPL (--vinith 69.76) and got 14.00 km/s entry velocity, aphelion distance of 4.504 AU and an end altitude of 35.13 km. What caused this level of difference between the two calculations? The level of coordinate inaccuracies cannot explain this.

GB 

rvball1
 

The reason for the difference is due to the accuracy of the sampling method. 

From: main@globalmeteornetwork.groups.io <main@globalmeteornetwork.groups.io> on behalf of tegla hunter <gubear99@...>
Sent: Thursday, 9 March 2023 6:33 AM
To: main@globalmeteornetwork.groups.io <main@globalmeteornetwork.groups.io>
Subject: [GlobalMeteorNetwork] Different outcomes with different methods of orbit calculations #fireball
 
Hi all,

There was a smaller fireball over Hungary, 2023. 03. 03. 00:09 UT. This event isn't important in itself, but I've tried out GMN's softwares (SkyFit2 and WMPL) and compared it to my old method (Sonotaco's UFOAnalyzer and UFOOrbit). In UFOOrbit I used the first ~0.83s of the trajectory (until reaching an altitude of 69.76 kms) for initial velocity. I got 14.66 km/s and an aphelion distance of 5.914 AU using this speed data. End altitude is 41.02 km. I did the same with WMPL (--vinith 69.76) and got 14.00 km/s entry velocity, aphelion distance of 4.504 AU and an end altitude of 35.13 km. What caused this level of difference between the two calculations? The level of coordinate inaccuracies cannot explain this.

GB 

Denis Vida
 

Hi,
There are two things to consider:

a) The aphelion distance is extremely sensitive to velocity. The difference you see can easily be caused by a difference in velocity. We don't read much into it unless we have lots of very smooth velocity measurements and the velocity error is low. That's why the perihelion distance and eccentricity are often given instead of the semi-major axis or the aphelion distance, they are much more robust. I suggest playing Kerbal Space Program to get a feel of orbital mechanics :)
As for the end height, you need to look at the fit residuals. If the errors are on the order of several hundreds of meters, then the measurements are not good.

b) We measured the orbits of the two recent asteroid entries using RMS and wmpl, and we got an orbit which is within 2 decimal points of the telescopic orbit for all orbital elements. We can't get a better confirmation that our methods are correct. The meteorites were found exactly where predicted (once the meteorite shapes have been taken into account).

Cheers,
Denis


On Wed, Mar 8, 2023 at 7:19 PM rvball1 <rvball1@...> wrote:
The reason for the difference is due to the accuracy of the sampling method. 

From: main@globalmeteornetwork.groups.io <main@globalmeteornetwork.groups.io> on behalf of tegla hunter <gubear99@...>
Sent: Thursday, 9 March 2023 6:33 AM
To: main@globalmeteornetwork.groups.io <main@globalmeteornetwork.groups.io>
Subject: [GlobalMeteorNetwork] Different outcomes with different methods of orbit calculations #fireball
 
Hi all,

There was a smaller fireball over Hungary, 2023. 03. 03. 00:09 UT. This event isn't important in itself, but I've tried out GMN's softwares (SkyFit2 and WMPL) and compared it to my old method (Sonotaco's UFOAnalyzer and UFOOrbit). In UFOOrbit I used the first ~0.83s of the trajectory (until reaching an altitude of 69.76 kms) for initial velocity. I got 14.66 km/s and an aphelion distance of 5.914 AU using this speed data. End altitude is 41.02 km. I did the same with WMPL (--vinith 69.76) and got 14.00 km/s entry velocity, aphelion distance of 4.504 AU and an end altitude of 35.13 km. What caused this level of difference between the two calculations? The level of coordinate inaccuracies cannot explain this.

GB 

tegla hunter
 

Thank you for all the answers!

Denis, I think my measurement was fairly accurate, although it could have been better if I had more close footages.. By the way what --vinith number do you use to compute the heliocentric trajectory? 

GB

20230303_000920_all_spatial_total_residuals_height.png

20230303_000920_velocities.png

Denis Vida
 

Hi,
This looks quite good, although a third station would be necessary to be sure about the trajectory. A two-station solution can sometimes be deceiving.

By the way what --vinith number do you use to compute the heliocentric trajectory? 
The code automatically determines the best number by fitting lines using at least 25% up to 80% of the trajectory starting from the beginning and choosing the fit with the lowest standard deviation. The idea is that it will keep including more points to decrease the standard deviation, but it will start increasing once deceleration stars. This way it will find the optimal point which will always have the smallest velocity errors. More details here: https://arxiv.org/abs/1911.02979

Cheers,
Denis


On Thu, Mar 9, 2023 at 1:29 AM tegla hunter <gubear99@...> wrote:
Thank you for all the answers!

Denis, I think my measurement was fairly accurate, although it could have been better if I had more close footages.. By the way what --vinith number do you use to compute the heliocentric trajectory? 

GB

tegla hunter
 

Hi Denis,

I only have two footages. But this was my first fireball to measure using SkyFit and didn't know I had to press Ctrl in order to place the little red cross where I pointed during manual reduction. Since then I recalculated this event and now I have a bit better data. By the way I was surprised by its end altitude. It really didn't seem that big of an event.

I use --velpart 0.2 because when I recalculated the 2023. 01. 25. possible dropper over West-Ukraine using all the amateur videos that I have (just for the sake of practice) I got the same orbital period as the czech calculation using --velpart 0.2. (1.4 years for them, 1.398 for me). Aphelion distance is more sensitive for initial speed so it would have been a better parameter to make a comparison with, but they didn't publish their Q. I assume the focus was on the possibility of meteorites landing, not the heliocentric trajectory, while I'm interested in both. (by the way this WMPL is insanely powerful tool even for low-resolution amateur footages. The distance between their end point and mine is around 650 meters, which I consider insanely good given the quality of the videos and their distance from the event. The error of dynamic mass estimatiom for the end is only in one order of magnitude compared to the Czech calculation) 

I still don't know what portion of the beginning should I use to get as accurate heliocentric orbit as possible for any given dataset. The dilemma is that the more points I use the greater the spatial precision will be, but also the atmoshperic drag is increasing, and it will lower the calculated entry velocity compared to reality. So I use --velpart 0.2 because it worked for me... once.

Back to this 2023. 03. 03. event:  dynamic mass estimation for the end shows around 40g of surviving material, but the upper limit is 248 tons :D I assumed it is because of inaccuarte manual reduction for the end. Also, I only have one footage to measure the end of this event, so maybe that's why the mass range is so detached from reality.

Regards,
Bence 

20230303_000920_all_spatial_total_residuals_height.png

20230303_000920_velocities.png

20230303_000920_dyn_mass_fit.png

Denis Vida
 

Hi Bence,
Great job with this event, this looks quite good. I'd suggest that you always need at least 3 stations to be sure, if possible.

As for the --velpart option, for rocky meteoroids (e.g. meteorite-dropping fireballs), I actually suggest that you don't look at the percentage from the beginning but look at the initial height. For example, these objects don't decelerate much above ~60 km. So you can just specify --vinitht 60.
From experience, I can suggest making sure that you know the camera FPS well. We found that various security cameras can have wildly non-standard FPS values. Some even do a "Waltz" where they do something like 1/20, 1/20, skip, 1/10, ... This will all influence the velocity.

Back to this 2023. 03. 03. event:  dynamic mass estimation for the end shows around 40g of surviving material, but the upper limit is 248 tons :D I assumed it is because of inaccuarte manual reduction for the end. Also, I only have one footage to measure the end of this event, so maybe that's why the mass range is so detached from reality.
Yeah, you can tell but that one line sticking down that something is wrong. I think more measurements of the end are needed to make a better prediction. The dynamic mass equations assume that most of the mass loss is done, so by definition, you need to observe it very close to the end when it stopped fragmenting and ablating a lot.

Cheers,
Denis

On Fri, Mar 24, 2023 at 7:11 AM tegla hunter <gubear99@...> wrote:
Hi Denis,

I only have two footages. But this was my first fireball to measure using SkyFit and didn't know I had to press Ctrl in order to place the little red cross where I pointed during manual reduction. Since then I recalculated this event and now I have a bit better data. By the way I was surprised by its end altitude. It really didn't seem that big of an event.

I use --velpart 0.2 because when I recalculated the 2023. 01. 25. possible dropper over West-Ukraine using all the amateur videos that I have (just for the sake of practice) I got the same orbital period as the czech calculation using --velpart 0.2. (1.4 years for them, 1.398 for me). Aphelion distance is more sensitive for initial speed so it would have been a better parameter to make a comparison with, but they didn't publish their Q. I assume the focus was on the possibility of meteorites landing, not the heliocentric trajectory, while I'm interested in both. (by the way this WMPL is insanely powerful tool even for low-resolution amateur footages. The distance between their end point and mine is around 650 meters, which I consider insanely good given the quality of the videos and their distance from the event. The error of dynamic mass estimatiom for the end is only in one order of magnitude compared to the Czech calculation) 

I still don't know what portion of the beginning should I use to get as accurate heliocentric orbit as possible for any given dataset. The dilemma is that the more points I use the greater the spatial precision will be, but also the atmoshperic drag is increasing, and it will lower the calculated entry velocity compared to reality. So I use --velpart 0.2 because it worked for me... once.

Back to this 2023. 03. 03. event:  dynamic mass estimation for the end shows around 40g of surviving material, but the upper limit is 248 tons :D I assumed it is because of inaccuarte manual reduction for the end. Also, I only have one footage to measure the end of this event, so maybe that's why the mass range is so detached from reality.

Regards,
Bence 

tegla hunter
 

Thank you Denis! From now on I will use --vinitht 60 for the big ones
In most cases we simply don't have enough footages. If we had 10 independent videos, I would be happy to measure them all :)

Clear skies, GB

1 - 9 of 9