Hi, I am using points on a curve with varying pipe diameters using grasshopper to control the output.
Because this represents a bar of forged metal I would like to add a volume constraint so that as I widen the diameter at a point the domain(length) of the curve that is piped will shorten. This will enable me to calculate my starting bar length before I start to forge tapers and leave swellings.
Does anyone know how I can do this please. I am using the following grasshopper file to control my pipe.

because I am forging and not machining the amount of material remains constant so being able to get feedback on different swellings and tapers would be very usefull

So if I began with the pipe only 50% of the curve length then tapered at point 4â€¦is there some way to automate the lengthening of 4 on the curve so that overall volume is maintained ?

if I cannot do this with the curve or pipe is there a way to record the change in volume of a taper so that I can then divide that volume into a unit length/volume of my untapered pipe and see how much bar I need ? Up to now I do this manually in rhino but it would be useful to get a change in volume figure as I manipulate the taper. I see that there is a volume button from Kangeroo but I cannot work out how to get a value to show up if I link this to a mesh from my pipe. Can anyone help please ?

The â€śengineâ€ť here is a C# script component which generates numbers while watching the value in named parameters of your choice, and stops when reaching a desired (max) value. The value in this case would be the original volume (the original volume value is feed into an input on the Solver). The â€śDriversâ€ť output is used to reduce the length of the curve being feed into the Pipe component, and the reduction step size are set in the â€śIncerementâ€ť input. In the example I let the Solver spin two solvers/drivers simultaneourly (you can add any number of solvers/drivers in the â€śSolversâ€ť input). Also pick a base-name for Num parameters to watch. That name will be padded with trailing numbers like â€śResultName_0â€ť, â€śResultName_1â€ť, â€śResultName_2â€ť etc. so the individual Solvers will know what value to watch. In the example the Solvers end up with different numer of runs due to the different lengths.

Hopefully youâ€™ll find this approach useful. The Solver component can show some bizzare behaviour while not all inputs and Target params are yet properly set up. Typical for quick-hack tools, but anyway.

The Solver should be able to drive also other ways of defining pipes. In this setup it careâ€™s only about the Volume results (which needs some inversion-calculation - see to the left of the round black groups - in order to arrive at a â€śmaxâ€ť value (= inital volume) since the Volume starts out â€śtoo bigâ€ť if increasing the radius, and the calculated volume values is therefore tricked with to also increase gradually as the driver values - which causes shortening of the pipes - are increasing).

thank you Rolfâ€¦I will work with this until I am sure I understand all of itâ€¦it certainly appears that you have provided me with something very usefulâ€¦thank you again
Giusseppe

Notice that the VPipe component can take multiple params, meaning, multiple radiuses along the curve, which then can be set individually with separate sliders.

Spread out the location of the radiuses between t=0â€¦1. Notice that even if doing so, nothing needs to be changed about the Solver, since the only thing the Solver really does is to compare if the current Volume of the pipe has reached the initial (constant) volume, and it will simply stop feeding increasing numer values when that happens.

The step size is probably a bit big in the example, but make it smaller if you want a smaller Volume-comparison tolerance. Example: Step size (Increment) = 0.001 would give a tolerance of Pipe Length / 1000.

I notice that it would make sense to add a â€śStart valueâ€ť to the solver when working with very small steps/incements (â€śtoleranceâ€ť) since it will take very long to step through many small steps to reach a match.

Press Reset after modifying any radius to force the Solver to try to reach a new volume match.

I updated the MaxNumSolver to use a StartValue (optional, default = 0.0) which makes it possible to speed up tests significantly.

Workflow: First test with a relatively big step-size (increment) of say 0.1, and when after trying it and thus knowing approximately at which parameter it will converge (in this case ~0.3+), then set a StartValue a little less, but close to, the value where the Solver converges. Then in a final run set the increment to a very small value (in this case I had used 0.0002 which will give you very much better precision within reasonable time.

Example: I tried using a step size of 0.0002 and StartValue from 0.3. Then the second Solver (Solver[1]) converged after 72 iterations on parameter 0.3152, and the first Solver (Solver[0]) converged after after 190 steps, on parameter 0.3380. The precision with this step size would be; Pipe Length 2000 * 0.0002 = 0.4 mm (or 0.2 mm at step size 0.0001).

not knowing much about scripting I had a go myself utilising a volume comparison with a unit length of curve/bar
Amazingly it gives me a list of lengths to cut (vol B/ vol A) and a list of finished lengths after forging