When I finished to read MH17 report I was disgusted with the method of searching for launch position. My main pretensionis “mathcing”. My opinion is necessary to alter the work in the right way. However, to show the essence of the objection I had to do a calculation to find the starting position. I do not strive for accuracy, on the contrary, I used a very rough approximation for brevity and laconic calculation. But the results are qualitatively similar to the true (If I dont make a dumbest mistake in my calculation like a wrong sign). The calculation is VisualStudio C++ project, so if a simplest programming is a fear for you, don’t read more.Also, do not need to tell me about the bad code, the simplest code is our choice. If anyone wants to make better, the first step is refuse by brut force minimization. About accuracy, I don’t see a big sense to make some parameters better, when other is still rough. To make all it correct is a big job First is a map. I make screenshot with a launch position picture from MH17 report. It is our map, 908*740 pixels. The last FDR position I found in Paint as [237;114]. int X_FDR=237; int Y_FDR=114; The scale is 10 km / (272-102). Forget about a map projection, ground is plane. double x_scale=10./(272-102); double y_scale=x_scale; We will find a launch area by fingering each pixel to south of FDR position. for(int X_Launch=0; X_Launch<=907; X_Launch++) { for(int Y_Launch=Y_FDR+1; Y_Launch<=739; Y_Launch++) { } } For each pixel, distance by axis to FDR point is: double dx= x_scale*(X_FDR-X_Launch); double dy=-y_scale*(Y_FDR-Y_Launch); Y with “-“ because pixels orientation for Y is reverse to latitude. A line distance is: double l=sqrt(dx*dx+dy*dy); Azimuth is (in degrees as it is for all other angles further): double az=asin(dx/l)*180/M_PI; Beta is angle of crossing Boeing axis, like 72-78 from AA presentation. double beta_nominal=(az+(180-115)); This is conditions that set limitations to possible area on map by the distance and the angle: if(l>35||l<20) continue; if(beta_nominal>50||beta_nominal<0) continue; This is code that joint the pixel color to white color making the selected area more white: Color additionalColour; additionalColour=additionalColour.White; Color pixelColour=Map->GetPixel(X_Launch, Y_Launch); pixelColour=pixelColour.FromArgb(JointColours(pixelColour, additionalColour)); Map->SetPixel(X_Launch, Y_Launch, pixelColour); And now, all of is entirely: Bitmap^ Map = gcnew Bitmap(pictureBox1->Image); int X_FDR=237; int Y_FDR=114; double x_scale=10./(272-102); double y_scale=x_scale; for(int X_Launch=0; X_Launch<=907; X_Launch++) { for(int Y_Launch=Y_FDR+1; Y_Launch<=739; Y_Launch++) { double dx= x_scale*(X_FDR-X_Launch); double dy=-y_scale*(Y_FDR-Y_Launch); double l=sqrt(dx*dx+dy*dy); double az=asin(dx/l)*180/M_PI; double beta_nominal=(az+(180-115)); if(l>35||l<20) continue; if(beta_nominal>50||beta_nominal<0) continue; Color additionalColour; additionalColour=additionalColour.White; Color pixelColour=Map->GetPixel(X_Launch, Y_Launch); pixelColour=pixelColour.FromArgb(JointColours(pixelColour, additionalColour)); Map->SetPixel(X_Launch, Y_Launch, pixelColour); } } pictureBox1->Image=Map; Map->Save("MH17_map_test.bmp"); The result is that map: It is look like our selected area 20-35 km and 0-50 degree close to MH17 report launch area. This map have increased angle range to 90, and the area with beta>30 degrees colored with yellow. The 30 degrees beta direction (to Saur-Mohila) is border between DNR forces and ukrainian army. Left(yellow) is Ukranian guild, right(white) is DNR guild. To better understand the fighting map again. And for clothing the map theme, we get right distance and angle relations. But original map is not for plane, so we get offset of location which may be up to few kilometers. Next step, we must calculate parameters of interception. It is not simple job, so it is unwelcome. And ballistic with aerodynamic was sent to map projection. Instead will be use linear approximation. This is a picture from AA presentation. This is function based on top picture that calculates a epsilon angle (elevation) by distance as linear approximation: double epsilon(double l) { double lp[5]={13, 15, 19, 22, 26}; double ep[5]={30, 22, 5, 0, -5}; int i; for(i=0; i<=2; i++) if(lp[i+1]>l) break; return ep + (l-lp)*(ep[i+1]-ep)/(lp[i+1]-lp); }; For the velocity it is much bad. I take only 2 point, and I don’t sure about second even: double velocity(double epsilon) { double vp[2]={730, 600}; double ep[2]={22, 5}; return vp[0] + (epsilon-ep[0])*(vp[1]-vp[0])/(ep[1]-ep[0]); }; The cone angle of rear fragment direction is next what we need found. I take as a base the warhead II from TNO report. double cone_angle(double velocity) { double cone_zero_velocity=112; double highest_frag_velocity=2520; double vn=highest_frag_velocity*sin(cone_zero_velocity*M_PI/180); double vt=highest_frag_velocity*cos(cone_zero_velocity*M_PI/180); double vt_new=vt+velocity; return 90-atan(vt_new/vn)*180/M_PI; }; This is a code that providing printing epsilon, velocity and cone angle. ofstream f; f.open("res.txt"); for(double l=10; l<=35; l=l+1) { f<<l<<" " <<epsilon(l)<<" " <<velocity(epsilon(l))<<" " <<cone_angle(velocity(epsilon(l))) <<endl; } f.close(); Result is (distance [km], epsilon[degree], velocity[m/s], cone_angle[degree]): 10 42 882.941 91.4972 11 38 852.353 92.2464 12 34 821.765 92.9949 13 30 791.176 93.7424 14 26 760.588 94.4886 15 22 730 95.2333 16 17.75 697.5 96.0226 17 13.5 665 96.8096 18 9.25 632.5 97.594 19 5 600 98.3756 20 3.33333 587.255 98.6813 21 1.66667 574.51 98.9864 22 0 561.765 99.2911 23 -1.25 552.206 99.5192 24 -2.5 542.647 99.7471 25 -3.75 533.088 99.9746 26 -5 523.529 100.202 27 -6.25 513.971 100.429 28 -7.5 504.412 100.655 29 -8.75 494.853 100.881 30 -10 485.294 101.107 31 -11.25 475.735 101.333 32 -12.5 466.176 101.558 33 -13.75 456.618 101.783 34 -15 447.059 102.007 35 -16.25 437.5 102.231 So, it is vary by distance like truth, but value may have a big mistake. This is value for each of them corresponds to current pixel as start location. double epsilon_blast=epsilon(l); double v_blast=velocity(epsilon_blast); double cone_blast=cone_angle(v_blast); Additionally, take a drift and Q elaboration for beta (see AA presentation). Q must be variable for distance and azimuth, but who care about it through such rough calculation. double beta_drift=-4; double beta_q=2; double beta_blast=beta_nominal-beta_drift-beta_q; And now, let’s talk about a “matching”. First, I will give my example. I take as a base the blast coordinates because I like strings much more then any computer modeling. And because MH17 report have the conclusion about it. If I were in DSB shoes, I would not accept the results contrary string model. I think, three independent simulation is a strings, microphones and one of blast computer simulation. And make note “volume less then one cubic metre”. And as I see the blast position from DSB report look like NLR coordinates So, code is: Point3D blast_point; blast_point.X=-0.25; blast_point.Y=-3.0; blast_point.Z=3.7; Point3D is my struct which have add function. struct Point3D { double X, Y, Z; }; Point3D operator+(Point3D a, Point3D b) { Point3D c; c.X=a.X+b.X; c.Y=a.Y+b.Y; c.Z=a.Z+b.Z; return c; }; And now, my match condition is coincidence of rear cone for fragments and the top of the nose septum between left and right cabin window. It is my “match point”. I select this point because it is look like a truth, and because top of window is a good mark when you get a coordinate value by pixel on B777 picture. Result is: Point3D match_point; match_point.X=1.59; match_point.Y=0; match_point.Z=1.56; Axis is that: And note: Match is expert arbitrariness, and it is theme to discuss. Farther, let's assume that match point arbitrarily located on rear cone at some distance (rho) tovertex and at some angle (phi) from down to up. The range make 0-8 metrs for rho, +/- 90 degrees for phi (left side of cone). This is cycles for exhaustive search: for(rho=0.1; rho<=8.0; rho=rho+0.1) { for(phi=-90; phi<=90; phi=phi+1) { } } Step is 0.1m for rho and 1 degree for phi. For each pair of rho and phi we must calculate h, r: double r=rho*sin(cone_blast*M_PI/180); double h=-rho*cos(cone_blast*M_PI/180); And we can now calculate length of line segment for MS, CS, CO, SO. double MS=r*cos(phi*M_PI/180); double CS=r*sin(phi*M_PI/180); double CO=h; double SO=sqrt(CO*CO+CS*CS); As result we must found omega angle. double omega=-atan(CS/CO)*180/M_PI; And make correction on epsilon(elevation) of cone axis we get theta, it is elevation from S point to vertex of the cone (O point). double theta=omega+epsilon_blast; And now go to vectors. Note: S point at same XY plane that M point, and MS is perpendicular to OS. Point3D Vector_MS; Vector_MS.Z=0; Vector_MS.X=-MS*sin(beta_blast*M_PI/180); Vector_MS.Y=-MS*cos(beta_blast*M_PI/180); Point3D Vector_SO; Vector_SO.Z=SO*sin(theta*M_PI/180); Vector_SO.X=SO*cos(theta*M_PI/180)*cos(beta_blast*M_PI/180); Vector_SO.Y=-SO*cos(theta*M_PI/180)*sin(beta_blast*M_PI/180); Sings must be match to vector direction. Correction on Boeing moving (PM). T is time that need to fragments that fly from O to M with 2520 m/s. 252 is boeing speed in m/s. double t=rho/2520; double PM=t*252; Point3D Vector_PM; Vector_PM.Z=0; Vector_PM.X=-PM*cos(beta_drift*M_PI/180); Vector_PM.Y=PM*sin(beta_drift*M_PI/180); I am not sure about this, if our blast position is “strings position” we don’t need take into consideration of PM. All vectors must be added to match point coordinates, and we found possible position of vertex of cone for some phi and rho. It is our warhead point. Point3D warhead_point; warhead_point=match_point+Vector_PM+Vector_MS+Vector_SO; So it is end, let’s take as “match function” distance from warhead point and to blast position from report. double miss=sqrt((warhead_point.X-blast_point.X)*(warhead_point.X-blast_point.X) +(warhead_point.Y-blast_point.Y)*(warhead_point.Y-blast_point.Y) +(warhead_point.Z-blast_point.Z)*(warhead_point.Z-blast_point.Z) ); For each pixel we must found minimal value. if(miss<miss_min) miss_min=miss; Last step is joint color to each pixel based on miss value. As base we take r_blast – radius for volume from report (1m3). Black color will be used for very good marching <0.5 r_blast, red for matching, yellow for miss, green for big miss, white for very big miss. double r_blast= pow((3/(4*M_PI)), 1./3); Color additionalColour; if(miss_min<0.5*r_blast) additionalColour=additionalColour.Black; else if(miss_min<1*r_blast) additionalColour=additionalColour.Red; else if(miss_min<2*r_blast) additionalColour=additionalColour.Yellow; else if(miss_min<3*r_blast) additionalColour=additionalColour.Green; else additionalColour=additionalColour.White; Color pixelColour=Map->GetPixel(X_Launch, Y_Launch); pixelColour=pixelColour.FromArgb(JointColours(pixelColour, additionalColour)); Map->SetPixel(X_Launch, Y_Launch, pixelColour); Final result is that. I attach the VS project as zip file. You may check. The full calculation takes about 1-2 hour. So I add Map_Step parameter, make it equal 5 for fast calculation. But picture will be bad. And now let’s talk about matching from TNO in context of this topic about search of launch location. 1. For a discussion of the location and guilt made sense all matching condition must be represented as math function and published (remember about expert arbitrariness). 2. It is a very bad choice – search for matching warhead angles that use it for search matching to launch location. The matching function must be project on map directly and performed as contour lines. The warhead angle is extra essence for location search. In the a prefect world we have to get rid of blast coordinates, and get something like a microphones out of sync delay projected on a map. 3. Such map must be represented for each match condition separately. 4. We should not rely on the accuracy, the good matching is not have a special sense. In contrast the bad matching with optimization is real bad for position. 5. We do not need search location as best matching for all conditions, we must exclude the field where one of it is not performed. Now about the result map, it is a better result then may look. As a sample, we take only one condition, however the “grazing” condition must be done for our good matching points for wide angle (thanks to strings). Both debatable position looks like a bad position. I don’t want to make conclusions about it.My math needs to be tested (insidious signs). However, I steel think that we should not expect that the simulation can uniquely say about the DNR guilt. In contrast, the ukranian guilt may be uniquely defined by tech expertise. So I do not expect a rapid investigation. Towards Russia is not very promising, on the part of Ukraine is politically unacceptable. Who are thinking about of impartiality, look as TNO exam AA version (I wrote earlier in topic about AA experiment). It is look like an italian strike. And fork instead lancet raises the question of competence, no matter right or wrong but it is result that must confuse. I think that correct expertise have more weight then something else, even youtube videos. And at its base are already being built version. Like that: ukrainian intelligence detects and fixes Buk on DNR side, ukranian Buk shootdown MH17, ukrainian intelligence post evidence about DNR Buk, PROFIT! Also speaking about the versions, I like area between Shahtersk and Amvrosievka, because there are fewer people, then near Torez or Snegnoe. And I like idea about long distance launch, because some witnesses say about airplane near MH17. It is make sense if we accept that they “airplain” is a BUK missile with off engine. It is all, what I have to say now.

I suspect that is too much math for most of us - and it looks like you are after an evidential level of calculation. Debunking is not about that - it is about identifying what is nonsense. So I applaud your efforts........but it is beyond me to actually analyze them and agree or disagree.

The range for cone_zero_velocity must be within 76 - 112 The range for frag_velocity must be within 1300 - 2520 Taking these values as a constant you got a pseudoscientific "spherical horse in a vacuum" and absolutely meaningless calculation results And about meaninglessness use Almaz-Antei's trajectory data in the calculations, I wrote in this thread: https://www.metabunk.org/almaz-anteys-live-buk-explosion-tests.t6903/page-3 Sorry for my bad English

Watch carefully. The angle of rear cone have limits in dynamic. It must be more then for max ejection angle and lowest speed fragments, and it should be smaller than for max ejection angle and highest speed fragments. AA warhead simulation more like to max ejection angle and lowest speed fragments, "fork" from tno report is closet to max ejection angle and highest speed fragments. Interestingly, that both model give you similar projection on map. However if you take max speed for AA or lowest speed to TNO you will get big displacement for projection on map. TNO [112 degree, 1110 m/s] AA [126 degree, 2480 m/s] These pictures give you an idea (and limits) how to change the warhead modeling of the launch position. And not think that this 2 picture is true, in both cases it is far from the developers claims. And note: 126 from AA degree and 112 degree from TNO for max ejection angle for static it is a large discrepancy, especially for the parameter that can be verified by simple experiment. In this dispute, I would bet on AA. They had to carry out such experiments long before IL-86, whereas missile was developed. So, thinking about the launch location better to look at second picture then first. And it gives an idea of how dangerous it is for Ukraine refinement of models from the MH17 report. Before solving the problem of exact hitting the target, it is necessary to solve the problem of how to reach a distant target without engine. If the target is far away, the missile is forced to rise altitude above the target. I think that a tangage function for BUK must be optimized for reach the max of kinetic energy at the target distance. Books is true, but you should not rely on them. And one more thing, I have no particular desire to debate with those who talk about "lied" AA. And no I'm not from AA.

Dear Unit0, that was quite interesting piece of work. It is very interesting methodologically, but it could neither be an evidence, nor the approach is blameless. First, let's talk about the legalities, since it was done to prove something, right? Well, the truth is that to be an evidence you should have either a true, or a false outcome. Anything between is considered just "possible" . you may plausibly convince others using 99% probability as true and 1% probability as false, but 95% confidence interval already falls in the realm of faith and not science. Thus, your work does not not even have a circumstantial evidence value, sorry. It still has a political value, but it can convince the believers only. However, it demonstrates how the proper expertise should be done and what are the limitations. Second, I am a bit troubled by the way you have used the probabilities. Let me just restate your method here: you assign some probability distribution to a position relative to the "established" blast position. Then you calculate the corresponding location on the map, assuming some model for the rocket flight. You solve it backwards, but it is what you are doing here, essentially. The probability of deviation from the assumed blast position is really arbitrary, but I am actually okay with that. I think that the blast position is pretty well established up to a blast radius. So, we are good withing the order of the magnitude here, maybe even better. What I do not like is that you use very, very crude flight model for your reasoning. You know it, right? otherwise you could pinpoint the launch area more "precisely". The problem is that you main variability is not in the blast position, it is in the flight path. Actually, this is a very easy technical problem, but impossible politically. The initial rocket velocity is known withing some interval; we could, in principle, know the guidance algorithm. Thus, the proper procedure would be: We establish some parameter space for initial conditions: velocity, location, launch angles, time of the launch. We may assign some probability distribution functions, but in the end we should just show the 99% confidence interval for the result. Then we start shooting the rocket and see how far from the blast position it would detonate. The problem become pretty complicated, so we may start using some cutoffs to save the computing time. However, we have to be very careful here, just as you were with only one, most reliable cutoff parameter. The political problem is that it would be insane for the military to share the guidance algorithm. Neither would it solve anything, anyway. We will not be, most likely, better off in the end. I suspect that the variability of the initial conditions will just point us to the same area as before, if not bigger. For example, we cannot chose any optimal angle for the shooting- there is no reason to believe the system was in order or the personnel was qualified. We do not know the rocket engine status: was it good, was it misfiring? So, the most solid evidence should come from old fashioned sources: human reports, and also from home-made pictures and videos. Also, you are somewhat prejudiced here, so this is the thing: even if there is a probability for the BUK to be in the Kiev-controlled area, it will not change anything. We come back to my starting point on "possibilities". The case against rebels is not based on fight models, but on many other factors, that agree with each other. Unless the rebels can get an alibi using a reliable flight model, the fact that Ukrainian military could have done it means nothing. Since other pro-rebel arguments were debunked and proven false so many times, the rebel supporters just run out of the good will.

I make calculation for second match point (M2). Point3D match_point2; match_point2.X=0.96; match_point2.Y=-0.96; match_point2.Z=-0.26; Map is: I know that I can build rear cone for 2 points. However I think it is bad idea becaus it is squared expert arbitrariness. So, I use max condition to joint result for match_point1 and matsh_point2. miss=MAX(miss1, miss2); And I add the pink rectangle from picture https://en.wikipedia.org/wiki/File:Malaysia_Airlines_Flight_17_crash_site.png I may make mistake about the pink rectangle because intial map is wery ugly and small.

And it was a main sense. I dont like what I see in report. Yes, but it is necessery for this inverse task. Nope. Unfortunally, the wing and athmospere variations exclude the posibility to get precisely blast coordinats as trajectory calculation. You may get wide range of coordinats near nose of airplane even you know all about missle, start position and etc. Howerever the angles is much more stable then coordinates for diffrenet variations. So make calculation another way, dont take coordinates from trajectory, only angles. And use brut force search for good blast coordinates in full range to nose. There is another problem, you may calculate some coordinates as good, such that is contradiction to guidance or detonator. However it is not big a problem if you exclude bad launch positions instead search the best. You just get possible lunch area some more. And if you look at you previously quote you will see exactly that. The trajectory angles near a target is very stable to many diffrent strart variations and conditions. The long distance to target "smoothes" many of them (in angle sense). Of course, there is a inevitable angle miss. But it is more then 10 times smaller then azimuth range in this case.

"Howerever the angles is much more stable then coordinates for diffrenet variations...he trajectory angles near a target is very stable to many diffrent strart variations and conditions. " This is a pretty strong statement and but can you support it? I would expect for the rocket guidance system to compensate any initial condition to get close to the target, but nothing more.

You should think about this in the context of the current task. The closeness to target is too vague condition that on the basis of his talk about the proximity to the point of explosion. A simple another example. We have a rocket with unknow guidance system, but we know the maximum energy range to some kind target and agle for it. If we will talk about interception such target, I can reasonably assume that angle may be only optimal despite unknow guidance. But there is not exist a reasonable assumption for the precise coordinates. In continuation, even without knowing the details of BUK, we can take as an example a some guidance system and how it changes hit angle by algorithm for variation to the angle of fire. Of cause, it is again rough turn. However, this will not be a meaningless procedure if you dont know details about BUK. But it is not good idea to take a some other guidance system and try to find the coordinates of the explosion. Do you think that found start location for BUK in order with qualified personnel is a pointless task to investigation?

What exact position of TELAR by your calculation? Dont forget about territory control and ability for bring and withdraw TELAR to launch site, thank you.

I do not want to talk about the exact launch area because I do not think the model and input data is fairly accurate. Еspecially, I do not want to argue about the suitability or non-suitability for calculated positions. I think it's a waste of time. If you are so interesting, the center of selected area is closest to 47°53'47.0"N 38°35'45.0"E. But this result is provided "as is without warranty of any kind".

Well, you found helpful to "waste of time" for spread out theory which blame Ukraine. But accidentally, your launch site is inappropriate for 9M38M1 missile. TELAR from this position can't shot down MH17. Try again and remember - even Almaz-Antey had 2 reports with same result "Ukraine did it", lol! Im only hope you, guys from Russia with propaganda in brains, learn to how produce undoubt fakes.

No, I'm not interested in your flame. I will give only one comment on the merits. The DSB report say about the 9M38-series (9M38 or 9M38M1) missle. My calculation is made for the 9M38 missile. This is the missile that gives the blue area on the this map. The small red area is area for 9M38M1. So, if you like this blue area then you like my calculation.

Yes, please provide more info about your fail. Now it 9M38 missile? Really? Nice to hear, it sunk your theory even better! Launch site "calculated by you" (same kind of lie as photoshoped by russian DoD satellite photo of 2 TELARs near Zarochenskoe) dont fit inside zone calculated by NLR. So you can try appeal to DSB report and their sketch but, in really, you just wanna cheat us with manipulated data and hope no one dont check it. Good luck, Mr. AA-2.

NLR like warhead II model with max ejection angle 112. Fake warhead give fake launch zone. AA warhead model with 126 degree for max ejection angle look as truth. Why? Take in your hand protractor and look at damage of IL-86 cabin. https://www.metabunk.org/almaz-anteys-live-buk-explosion-tests.t6903/page-3

Fact 1. You calculate launch site which dont fit in NLR zone but pronounce it same. Fact 2. Missile from your launch site cannot shot down MH17. Why? because this position too far for reach target moving with speed=250 m/s in last FDR position. Fact 3. You dont know disclosure angles of 9N314 and 9N314M warheads and blame both NLR and A-A for wrong angles. Then you should provide your own data which can be verified and approved. Right now you trying to create another lie theory like Su-25, Zarochenskoe and frozen bodies.

I do not know whether this video does show that it is claimed to show or not, but it gives some ideas about possible variations of the missile trajectory:

First 4 seconds - 1 stage engine burning with fast climb under angle near 45 degree. Then missile change trajectory for dive to ground since target fly on low alt (Low-Alt Target mode). After diving maneur missile seeker locked target and correct missile course to intercept point. Missile make hook and explode near target. Its called Lock in Air mode for Low-Alt Target.

You mean photoshoped as proved Bellingcat sect using fotoforensics.com. I'm sure for fairness you did try same tool on Paris-Match photo

Unfortunately, I was not paying attention. Calculation based on the data of the first presentation. At the time of writing a message Russian position was 9M38 missile, so I thought that it was used to simulate the data. However, in the first presentation talking about rocket 9M38M1, and graphics are for her. Appropriately, the results relating to the modification 9M38M1.