First Off, Go read Tips on Finding a Node First http://austargets.com/forum/index.php?topic=646.0, It is in Plain English and Norm has clearly explained the terms and what is exactly being sought. Basically, Perform a ladder test using a chronograph and log the data.

In summary, what we are after is load stability, In long range shooting super tight groups at 100m are not as useful as stable groups at 100m, It is a fact some people need to get over when it comes to load development for Long Range (LR). It is up to you the Reloader, to take responsibility for your actions and heed all necessary warnings associated with reloading, I will in no way accept any responsibility for your specific results, this is a guide on utilising Maths to find a node, not a how to reload for LR.

With all Mathematical methods the greatest flaw in the process is the amount of data available to the model for the accurate prediction of results. The more data you use the more reliable your model will become. Use simple data storage methods, hand written notes in a notebook are reliable, invaluable and very good practice when it comes to LR shooting as everytime you shoot, conditions will be different, accumulate enougb data over enough condition sets then patterns will eventuate and you will be able to jog your memory of how shoots went and you will improve. In my limited experience in trying to teach people to shoot LR, people that don't write down how they shot in wind take

Data from a handwritten notebook can easily be saved as a 2 column 'notepad file' (.txt) separate the columns by pressing the 'Tab' Key. A notepad file written as such can be opened by all computer based maths programs, Excel, Matlab, Octave, even Modellers like Solid Works and the like. Notepad is the single most useful program for programming and operating within mathematical languages.

Matlab is a well utilised example of numerical solvers and is very good for LR but it is expensive so unless it is a part of your 'other' job like me then chances are it is out of reach... Thankfully Octave Exists, (http://www.gnu.org/software/octave/) which is a free GNU software compatible with the commercial MatLab (everything written in Octave Will Run in Matlab but not necessarily the other way around as MatLab is more advanced)

I will not go into detail on how to operate Octave or MatLab, There is a plethora of Wiki's and forums out there to help in this regard, I will simply provide some simple code later on so you understand how the mathematical process can be written in a program and then run relatively instantly for all future data sets, this code you are free to use and build upon, It would be great if you could post up some developed codes, Mine is very messy and is full of user required inputs so has become a buggy mess, but it works for me. I'd be willing to help/check/refine anyone's developed code and have a master available for people that wish to try it out but for now we will start small.

So, You have a 2 variable data set, Velocity and Powder Charge and you want to know at which point along the data set the load will be the most stable so that your vertical shot spread at LR is minimised.

One can take data collected from the tests as described by norm, then type them into notepad in columns as described earlier, for example:

The process from here is actually simple Calculus, no really it is, what we are looking for is a description of the data in terms of critical points, inflections and minimum rates of change (i.e the First, Second and Third order derivatives critical points, F(x) = 0, F(x) = Min, F(x) = Max, F(x)

The trick is to take the data and fit a suitable order polynomial approximation to the data, Excel will readily fit 4th order I believe and Programs like Matlab will go to the n

Fitting the polynomial can be achieved by a number of methods and I encourage you to use available resources to source a number of different methods however I will switch to a basic code at this point so you can see a simple method that works in Octave or MatLab. In this example I have used the existence of inflection points to isolate where the minimum rates of change are. Developing the code further to plot the derivative or isolate all the critical points can be easily achieved for solving F(x) for the criteria above. For the main there will be an inflection point and this code should get people at least at a stage that their toes are wet.

Copy the code below into Notepad and Save it as a ####.m file, call it whatver you like but you need to make it easy so when you call it up from Matlab or Octave it is easy to find.

So put the above into Matlab/octave and run the code with the velocity.txt file in the same folder on your computer. The output should be as follows:

Clearly the Matlab standard polyfit is not robust enough to clearly resolve such a small amount of data... Tripling the amount of data in velocity.txt gets rid of this error for me when I tested it earlier today. The outputs also reduce to just one, 62.78 grains of powder. As I said it is just a basic code, I have tried to add as many explanations in %% marks so it is clear what I have done. It is designed to be basic, I encourage people to develop it further and post what they have done, it would be great to see some people give it a crack. As I have said I have a messy master of my own that I tweak from time to time, one day when I get a day off with miserable weather I might sit down and clean it all up but that is hours of work and is currently too low on the priority list... got better things to do like shooting!!! The first thing to do if you want to go this route is to rearrange the code so that it gives the local minima using the first derivative rather than the inflection points from the second derivative!

I should finally add, why do all this? well once set up it is as quick as typing the velocities recorded into notepad, running the program and then writing down your node from that data set. Hence with powder variations, temp variations e.t.c. the process is faster and less frustrating than plots in excel and more precise.

Cheers All,

Andy.

In summary, what we are after is load stability, In long range shooting super tight groups at 100m are not as useful as stable groups at 100m, It is a fact some people need to get over when it comes to load development for Long Range (LR). It is up to you the Reloader, to take responsibility for your actions and heed all necessary warnings associated with reloading, I will in no way accept any responsibility for your specific results, this is a guide on utilising Maths to find a node, not a how to reload for LR.

**Data**With all Mathematical methods the greatest flaw in the process is the amount of data available to the model for the accurate prediction of results. The more data you use the more reliable your model will become. Use simple data storage methods, hand written notes in a notebook are reliable, invaluable and very good practice when it comes to LR shooting as everytime you shoot, conditions will be different, accumulate enougb data over enough condition sets then patterns will eventuate and you will be able to jog your memory of how shoots went and you will improve. In my limited experience in trying to teach people to shoot LR, people that don't write down how they shot in wind take

__longer to learn to shoot well in wind.__*much*Data from a handwritten notebook can easily be saved as a 2 column 'notepad file' (.txt) separate the columns by pressing the 'Tab' Key. A notepad file written as such can be opened by all computer based maths programs, Excel, Matlab, Octave, even Modellers like Solid Works and the like. Notepad is the single most useful program for programming and operating within mathematical languages.

**The Big Scary World of Numerical Solvers**Matlab is a well utilised example of numerical solvers and is very good for LR but it is expensive so unless it is a part of your 'other' job like me then chances are it is out of reach... Thankfully Octave Exists, (http://www.gnu.org/software/octave/) which is a free GNU software compatible with the commercial MatLab (everything written in Octave Will Run in Matlab but not necessarily the other way around as MatLab is more advanced)

I will not go into detail on how to operate Octave or MatLab, There is a plethora of Wiki's and forums out there to help in this regard, I will simply provide some simple code later on so you understand how the mathematical process can be written in a program and then run relatively instantly for all future data sets, this code you are free to use and build upon, It would be great if you could post up some developed codes, Mine is very messy and is full of user required inputs so has become a buggy mess, but it works for me. I'd be willing to help/check/refine anyone's developed code and have a master available for people that wish to try it out but for now we will start small.

**An outline of the Maths / Basic Example**So, You have a 2 variable data set, Velocity and Powder Charge and you want to know at which point along the data set the load will be the most stable so that your vertical shot spread at LR is minimised.

One can take data collected from the tests as described by norm, then type them into notepad in columns as described earlier, for example:

56 2500

57 2525

58 2560

59 2580

60 2610

61 2640

62 2650

63 2655

64 2665

65 2685

66 2740

67 2785

57 2525

58 2560

59 2580

60 2610

61 2640

62 2650

63 2655

64 2665

65 2685

66 2740

67 2785

**Save the above as velocity.txt if you wish to use the code below**The process from here is actually simple Calculus, no really it is, what we are looking for is a description of the data in terms of critical points, inflections and minimum rates of change (i.e the First, Second and Third order derivatives critical points, F(x) = 0, F(x) = Min, F(x) = Max, F(x)

^{b}_{a}= (+/-) e.t.c.
F(x) is any derivative of f(x), which is our nth order polynomial, see below

^{th}order but the key here is we need it to be suitable.__My argument/opinion:__If we simplify the process of launching a projectile; we have a pressure curve that develops over time, over a variable volume that expands at an accelerating rate. We can ignore most other factors at this point as it is clear a simple model that takes into these factors would be a fourth order polynomial, Volume, time, acceleration, pressure being the simplest variables and looking at their relations from ideal gas laws and newtonian mechanics (feel free to google/wikipedia e.tc.) and a little bit of experience thrown in for good measure I'll assert fourth order is sufficient. Sure equations may possibly be developed for higher order polynomials or crude assumptions could be made to reduce the order but in reality a fourth order is a comfortable number that most solvers can handle with a minimum of fuss, even doing the derivatives by hand will not take long at all.Fitting the polynomial can be achieved by a number of methods and I encourage you to use available resources to source a number of different methods however I will switch to a basic code at this point so you can see a simple method that works in Octave or MatLab. In this example I have used the existence of inflection points to isolate where the minimum rates of change are. Developing the code further to plot the derivative or isolate all the critical points can be easily achieved for solving F(x) for the criteria above. For the main there will be an inflection point and this code should get people at least at a stage that their toes are wet.

Copy the code below into Notepad and Save it as a ####.m file, call it whatver you like but you need to make it easy so when you call it up from Matlab or Octave it is easy to find.

%% Finding a Velocity Node

% AndyBangFlop

% % A simple hopefully friendly code that can be used to determine the position of a velocity

% node from a text file without text, numbers only (banged this together quickly so

% it is not very robust), grains in first column, velocities in second.

% Units are irrelevant, what ever you put in, it will

% spit out, but remember if you GIGO, the result is Garbage In Garbage Out.

%%

%This code relies on the existence of an inflection point (to make things

%much simpler) If no such inflection point exists then determining the min

% of fG = diff(G) should suffice. The code is very basic, easily

% upgradeable, use '%%' to make it more modular and you will be good to go.

clc %engage for debugging

format shortG

%% Load velocity.txt

load velocity.txt

g = velocity(:,1);

v = velocity(:,2);

%% Develop a 4th order polynomial

disp ('Ignore the following Warning, It is because we are cheating a bit')

p = polyfit(g,v,4);

disp (' ')

%% Convert it from an array to a more friendly function

%Sort Co-efficients

c4 = p(:,1);

c3 = p(:,2);

c2 = p(:,3);

c1 = p(:,4);

c0 = p(:,5);

% Float V co-ordinates as Variables:

syms V;

G = c0 + c1*V^1 + c2*V^2 + c3*V^3 + c4*V^4;

ffG = diff(diff(G));

n = solve (ffG,0);

disp (' ')

disp ('Node is Found at Powder Weight (s) = ')

disp ('(Units are input units)')

Node = double(n)

disp ('if multiple ouputs, check to see whether there has not been a hiccup in the code from multiple inflection points')

disp ('should be identifiable as only one point will actually make sense')

% AndyBangFlop

% % A simple hopefully friendly code that can be used to determine the position of a velocity

% node from a text file without text, numbers only (banged this together quickly so

% it is not very robust), grains in first column, velocities in second.

% Units are irrelevant, what ever you put in, it will

% spit out, but remember if you GIGO, the result is Garbage In Garbage Out.

%%

%This code relies on the existence of an inflection point (to make things

%much simpler) If no such inflection point exists then determining the min

% of fG = diff(G) should suffice. The code is very basic, easily

% upgradeable, use '%%' to make it more modular and you will be good to go.

clc %engage for debugging

format shortG

%% Load velocity.txt

load velocity.txt

g = velocity(:,1);

v = velocity(:,2);

%% Develop a 4th order polynomial

disp ('Ignore the following Warning, It is because we are cheating a bit')

p = polyfit(g,v,4);

disp (' ')

%% Convert it from an array to a more friendly function

%Sort Co-efficients

c4 = p(:,1);

c3 = p(:,2);

c2 = p(:,3);

c1 = p(:,4);

c0 = p(:,5);

% Float V co-ordinates as Variables:

syms V;

G = c0 + c1*V^1 + c2*V^2 + c3*V^3 + c4*V^4;

ffG = diff(diff(G));

n = solve (ffG,0);

disp (' ')

disp ('Node is Found at Powder Weight (s) = ')

disp ('(Units are input units)')

Node = double(n)

disp ('if multiple ouputs, check to see whether there has not been a hiccup in the code from multiple inflection points')

disp ('should be identifiable as only one point will actually make sense')

Ignore the following Warning, It is because we are cheating a bit

Warning: Polynomial is badly conditioned. Add points with distinct X

values, reduce the degree of the polynomial, or try centering

and scaling as described in HELP POLYFIT.

> In polyfit at 80

In NodeCalc at 22

Node is Found at Powder Weight (s) =

(Units are input units)

Node =

57.815

62.78

if multiple ouputs, check to see whether there has not been a hiccup in the code from multiple inflection points

should be identifiable as only one point will actually make sense

Warning: Polynomial is badly conditioned. Add points with distinct X

values, reduce the degree of the polynomial, or try centering

and scaling as described in HELP POLYFIT.

> In polyfit at 80

In NodeCalc at 22

Node is Found at Powder Weight (s) =

(Units are input units)

Node =

57.815

62.78

if multiple ouputs, check to see whether there has not been a hiccup in the code from multiple inflection points

should be identifiable as only one point will actually make sense

I should finally add, why do all this? well once set up it is as quick as typing the velocities recorded into notepad, running the program and then writing down your node from that data set. Hence with powder variations, temp variations e.t.c. the process is faster and less frustrating than plots in excel and more precise.

Cheers All,

Andy.

## Comment