Screw and other threads
Jobst Brandt
concepts on the subject might help. All threads, internal and
external (screw and nut) have clearance so they can be assembled
without binding (or galling) because that causes damage and prevents
full engagement. Because there is clearance, that is usually filled
with a lubricant by the assembler, threads are used to hold parts
together rather than support radial loads as one finds on bicycles, a
faulty design in the first place, but then most bicycle engineers are
unaware of proper use of threads. fortunately the threadless
steertube is a step in the right direction. The threaded ones were
perpetually fretting, and the quill stem was a nightmare of bad
design, being only vertically secure at the bottom of the quill, while
rocking from side to side in use.
In an effort to secure the handlebars, quills were often tightened
enough to expand the steertube, preventing installing the lower fork
cone.
One can find threads supporting radial loads on bicycles. These are
for instance, pedal spindles in cranks, BB cups in the bottom bracket,
wheel bearing cones on axles and head bearings on forks.
Fortunately there are remedies for these problems, but the left hand
thread is not a solution because other than not unscrewing, it
displaces radially (thread clearance) enough to cause fretting damage
to the spindle interface with the crank causing failures, while BB
thread erosion occurs to the extent of wearing the threads away so
that they cannot retain required bearing adjustment.
Fretting damage to head bearings (indexed steering) was also corrected
recently by the Shimano threadless steertube.
As I mentioned, a conical face on the pedal spindles makes it immune
to this problem, the way lug nuts on auto wheels did when first
introduced to prevent losing wheels (front and rear) when traveling.
Wherever a left hand thread appears in a mechanism, other than a turn
buckle or control device, it is most likely a misplaced... as are the
ones on bicycles.
A solution to fretting threads is the clamped external thread. This
method splits the external thread with a thin saw cut and uses dual
machine screws to clamp the internal threaded element in a snug
embrace, looking much like a tandem transfer chain adjuster on a front
BB.
Progress is slow.........
--
Jobst Brandt
thirty-six
> Because I see a misunderstanding of how threads work, explaining a few
> concepts on the subject might help.
YAWN.
All threads, internal and
> external (screw and nut) have clearance so they can be assembled
> without binding (or galling) because that causes damage and prevents
> full engagement. Because there is clearance, that is usually filled
> with a lubricant by the assembler,
Usually filled means greas, an incorrect thread lubricant.
> threads are used to hold parts
> together
Even on bicycles.
>rather than support radial loads as one finds on bicycles, a
> faulty design in the first place,
Only in your mind, because you dont understand how threads work.
> but then most bicycle engineers are
> unaware of proper use of threads.
You mean those experienced in the work all have differing opinion to
you, now there's a surprise.
> fortunately the threadless
> steertube is a step in the right direction.
Created to reduce assembly time.
>The threaded ones were
> perpetually fretting,
Nope, not here they weren't, but then most of the headsets I used were
oiled, oil being the proper lubricant for this high load very low
speed bearing.
> and the quill stem was a nightmare of bad
> design, being only vertically secure at the bottom of the quill, while
> rocking from side to side in use.
You weren't using it right. I have had no problem with correctly
adjusting headsets once I pruchased the spanners made for the job.
>
> In an effort to secure the handlebars, quills were often tightened
> enough to expand the steertube, preventing installing the lower fork
> cone.
You weren't doing it right. The correct method was to remove all that
gunk you had put in there to grease the steerer, then use light oil.
the quill then grips the steerer without having to distort the
steerer. It is also best not to have the stem solidly fixed to the
steerer because some givce is required to prevent abdominal punctures.
>
> One can find threads supporting radial loads on bicycles. These are
> for instance, pedal spindles in cranks,
Only if you're doing it wrong. Again oil not grease and screw it up
TIGHT.
You really do have an abnormal aversion to oil.
> BB cups in the bottom bracket,
Yes but when the threads are oiled and done up tight the fitting does
not move. If it moves you're doing it wtrong, like using grease and
por not fully tightening the components with the proper tools.
> wheel bearing cones on axles and head bearings on forks.
They dont move when assembled with oil and done up tight. If they
do , you are doing it WRONG and are probably using grease and or not
tightrening the components sufficiently with the correct spanners.
>
> Fortunately there are remedies for these problems,
There is no problem if you use oil as all threaded fasteners require
and are designed around. Being clever and using grease takes the
assembly outside the design parameters.
> but the left hand
> thread is not a solution
It is, it's a solution to quick assembly, both pedals can be put on
together using one hand on each and spinning the cranks. Stiop
imagining false 'reasons' for bicycle design. It is likely in all
cases you are doing it wrong.
> because other than not unscrewing, it
> displaces radially (thread clearance) enough to cause fretting damage
> to the spindle interface with the crank causing failures,
Not here it doesn't, oil threads, DO NOT USE GREASE ON THREADS,
TIGHTEN FULLY.
>while BB
> thread erosion occurs to the extent of wearing the threads away so
> that they cannot retain required bearing adjustment.
You must be doing it wrong, use oil to lubricate threads, tighten
fully with correct tools and no erosion occurs.
>
> Fretting damage to head bearings (indexed steering) was also corrected
> recently by the Shimano threadless steertube.
No fretting occurs when headsets are properly lubricated with oil.
>
> As I mentioned, a conical face on the pedal spindles makes it immune
> to this problem,
How does that stop you using grease on the threads?
> the way lug nuts on auto wheels did when first
> introduced to prevent losing wheels (front and rear) when traveling.
How do you lose wheels, " Oh dear honey, look, we've lost two wheels,
wonder where they might be?"
>
> Wherever a left hand thread appears in a mechanism, other than a turn
> buckle or control device, it is most likely a misplaced... as are the
> ones on bicycles.
So fast assembly time is not a requirement for a mass-produced machine
meant to be put out at low cost then?
>
> A solution to fretting threads is the clamped external thread. This
> method splits the external thread with a thin saw cut and uses dual
> machine screws to clamp the internal threaded element in a snug
> embrace, looking much like a tandem transfer chain adjuster on a front
> BB.
Claptrap.
>
> Progress is slow.........
I cant believe you could remain so ignorant of basic mechanics for so
long. OIL NOT GREASE.
> --
> Jobst Brandt
TheCoz
Oil if it moves, grease if it fastens.
Coz
Kerry Montgomery
Coz,
Are you advocating oil for wheel bearings and BB bearings?
Just wondering,
Kerry
Dre
<snip>
>>
>>
>>> Progress is slow.........
>>
>> I cant believe you could remain so ignorant of basic mechanics for so
>> long. OIL NOT GREASE.
>>
>>> --
>>> Jobst Brandt
>
> Oil if it moves, grease if it fastens.
> Coz
Exact same experience here. I've allways lightly greased my threads and
have allways been told to use grease for fastners and oil for moving parts
(wheel bearings for example are an exception here).
I would have thought that oil would run out of a headset bearing assembly
for example much quicker than grease would?
Me, I only use oil for my chain, inside my brakes and inside my front/rear
shocks :) (well the Magura's anyway, the rest run dot 4)
Cheers Dre
Tim McNamara
<ee55ebf0-11ed-4ce1...@t20g2000yqa.googlegroups.com>,
TheCoz <cycl...@hotmail.com> wrote:
> Oil if it moves, grease if it fastens.
Nope. Try again.
--
That'll put marzipan in your pie plate, Bingo.
thirty-six
> >TheCoz wrote:
> <snip>
>
> >>> Progress is slow.........
>
> >> I cant believe you could remain so ignorant of basic mechanics for so
> >> long. OIL NOT GREASE.
>
> >>> --
> >>> Jobst Brandt
>
> > Oil if it moves, grease if it fastens.
> > Coz
>
> Exact same experience here. I've allways lightly greased my threads and
> have allways been told to use grease for fastners and oil for moving parts
> (wheel bearings for example are an exception here).
Traditional bike components were designed with oil in mind with
frequent application. Grease needs very careful selection for
bearings and bicycles offers extreme bearing conditions of high loads,
low speeds, high contamination, wide environment temperature range and
infrequent servicing (today). Sometimes a poor design though will
demand a grease, but if the bearings will hold at least some oil and
you can live with the seepage, then this is the better choice.
Mechanics always had an oily rag, erm because it drips. Grease does
not during assembly so you dont need the rag. That'll save a couple
of bob a year. Only oil is cheaper and does the job better because,
well I've said it before.
>
> I would have thought that oil would run out of a headset bearing assembly
> for example much quicker than grease would?
Yes, but it's also easy to relubricate. A few drops every couple of
weeks did it on the most open type. Mudguards are required. There
were however headsets specifically designed for remote oiling which I
guess would not have suffered the loss that typical headsets do/did.
It may be that the most recent headsets will hold oil better.
kolldata
TheCoz
That's why it's called Wheel Bearing Grease.
Coz
Sir Ridesalot
Hi there Jobst.
Can you tell me why I have never had a pedal loosen itself or
destroyed any of those parts via fretting that you mentioned above? I
have bicycles that are over 35 years ols and never had a problem with
either parts loosening or fretting.
The only time I had a headset or a left hand square-taper bottom
bracket cup loosen was on a used 1985 SLX frame Cinelli that I bought
and then road without first cleaning and reassembling everything.
Since I did clean the threads and reassembled and tightened them with
oil instead of grease that was used by the previous owner I have not
had anything loosen at all. This bicycle gets an average of 300
kilometers put on it per week eight months of the year and I've had it
for three years now. That is about 1200 kilometers a month or 9600
kilometers a year. So, after 28800 kilometers *WHEN* can I expect the
headset, the left-hand bottom bracket cup and the left-hand pedal to
loosen?
BTW, I don't over tighten my stem and it has not come loose either.
Thanks and cheers from Peter
TheCoz
> In article
> <ee55ebf0-11ed-4ce1-a705-05a1f7140...@t20g2000yqa.googlegroups.com>,
>
> TheCoz <cycled...@hotmail.com> wrote:
> > Oil if it moves, grease if it fastens.
>
> Nope. Try again.
>
> --
> That'll put marzipan in your pie plate, Bingo.
Don't need to try again. Everything is and has been functioning
properly for many years.
Coz
thirty-six
For what wheels, what machines?
Dre
> On 8 Sep, 04:51, "Dre" <andreas.bai...@gmail.com> wrote:
>>> TheCoz wrote:
>> <snip>
>>
>>>>> Progress is slow.........
>>
>>>> I cant believe you could remain so ignorant of basic mechanics for
>>>> so long. OIL NOT GREASE.
>>
>>>>> --
>>>>> Jobst Brandt
>>
>>> Oil if it moves, grease if it fastens.
>>> Coz
>>
>> Exact same experience here. I've allways lightly greased my threads
>> and have allways been told to use grease for fastners and oil for
>> moving parts (wheel bearings for example are an exception here).
>
> Traditional bike components were designed with oil in mind with
> frequent application. Grease needs very careful selection for
> bearings and bicycles offers extreme bearing conditions of high loads,
> low speeds, high contamination, wide environment temperature range and
> infrequent servicing (today). Sometimes a poor design though will
> demand a grease, but if the bearings will hold at least some oil and
> you can live with the seepage, then this is the better choice.
Very interesting you have mentioned "traditional bike conponents" as all my
stuff is post 2004 mtb stuff and the manuals generally tell you to use
grease rather than oil. This may be due to the fact that mountain bikes
operate in different conditions to road bikes. Either way, I've never ever
had a problem with any of my "greased" threads :) None have come loose and
none have ever seized.
> Mechanics always had an oily rag, erm because it drips. Grease does
> not during assembly so you dont need the rag. That'll save a couple
> of bob a year. Only oil is cheaper and does the job better because,
> well I've said it before.
>>
>> I would have thought that oil would run out of a headset bearing
>> assembly for example much quicker than grease would?
>
> Yes, but it's also easy to relubricate. A few drops every couple of
> weeks did it on the most open type. Mudguards are required. There
> were however headsets specifically designed for remote oiling which I
> guess would not have suffered the loss that typical headsets do/did.
> It may be that the most recent headsets will hold oil better.
A few drops *every few weeks*, eeeeek!! I'll pass thanks and stick to my
sealed headset/wheel/BB/pivot bearings :)
*Once* a year, I check that my bolts are tight (but never had to re-torque
anything), swap tires front to back, change my chain, change my brake pads
and give everything a very thorough clean, thats it, dont touch any
bearings, 2 odd hours worth of monkey wrenching per bike per year, beatiful
:)
Plus my bikes get dirty and wet and they all run like new.
Cheers Dre
kolldata
http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19900009424_1990009424.pdf
spent a hour or so with the Flyer but did not have acumen to inspect
fastners....
intriguing, posts about how their machinery never falls apart with
spit when my class A machinery falls apart without blue and red
locktite applied on sanitary surfaces. Often west of Kalamazooo
?
Bad Idea
> . . . threads are used to hold parts
> together rather than support radial loads as one finds on bicycles, a
> faulty design in the first place, but then most bicycle engineers are
> unaware of proper use of threads.
Sure, jobst. You’re right and everyone else is wrong. Aerospace
engineers are wrong. Automotive engineers are wrong. Ship
designers are wrong. Structural engineers are wrong. Machine tool
designers are wrong.
BTW, have engineers for Porsche ever used threads to support
radial loads? Please advise.
Jobst Brandt
>> Because I see a misunderstanding of how threads work, explaining a
>> few concepts on the subject might help.
> YAWN.
>> All threads, internal and external (screw and nut) have clearance
>>so they can be assembled without binding (or galling) because that
>>causes damage and prevents full engagement. Because there is
>>clearance, that is usually filled with a lubricant by the assembler,
> Usually filled means greas, an incorrect thread lubricant.
How about explaining the basis for your comment?
>> threads are used to hold parts together
> Even on bicycles.
>> rather than support radial loads as one finds on bicycles, a faulty
>> design in the first place.
> Only in your mind, because you dont understand how threads work.
>> but then most bicycle engineers are unaware of proper use of
>> threads.
I see you don't understand the use of threads, or you wouldn't protest
standard engineering procedure that is used at automotive, scientific,
and computer peripheral designs on which I have had the pleasure to
work.
> You mean those experienced in the work all have differing opinion to
> you, now there's a surprise.
That is true for the bicycle industry that doesn't seem to attract
engineers, skilled in the design of components, judging from the many
common failures bicycles have, like broken cranks, cracked rims,
splitting hubs, indexed steering, and loosening threads on pedals and
BB's.
>> fortunately the threadless steertube is a step in the right
>> direction.
> Created to reduce assembly time.
Too bad you can't appreciate the advances such designs have brought to
bicycling for the user. Maybe you can explain where the reduction of
assembly time was gained.
>> The threaded ones were perpetually fretting,
> Nope, not here they weren't, but then most of the headsets I used were
> oiled, oil being the proper lubricant for this high load very low
> speed bearing.
Indexed steering was a common failure on bicycles and automotive
steering gears until recently. You may not have analyzed why your
bicycle didn't steer properly.
>> and the quill stem was a nightmare of bad design, being only
>> vertically secure at the bottom of the quill, while rocking from
>> side to side in use.
> You weren't using it right. I have had no problem with correctly
> adjusting headsets once I pruchased the spanners made for the job.
There was no correct way and that is what most others discovered.
Just ask a bicycle repair shop. I'm sure Andrew Muzi or Chalo could
fill you in if you were interested.
>> In an effort to secure the handlebars, quills were often tightened
>> enough to expand the steertube, preventing installing the lower
>> fork cone.
> You weren't doing it right. The correct method was to remove all
> that gunk you had put in there to grease the steerer, then use light
> oil. the quill then grips the steerer without having to distort the
> steerer. It is also best not to have the stem solidly fixed to the
> steerer because some givce is required to prevent abdominal
> punctures.
You are a bit to little and too late to help the bicycle industry on
that one. I think they have left you behind with your odd concepts.
>> One can find threads supporting radial loads on bicycles. These are
>> for instance, pedal spindles in cranks,
> Only if you're doing it wrong. Again oil not grease and screw it up
> TIGHT. You really do have an abnormal aversion to oil.
Oh! You mean we've had left hand threads on left pedals for more than
a century because bicycle mechanics used the wrong lubricant? You
don't make much sense.
>> BB cups in the bottom bracket,
> Yes but when the threads are oiled and done up tight the fitting does
> not move. If it moves you're doing it wtrong, like using grease and
> por not fully tightening the components with the proper tools.
I see that for you its "oil" and tying and soldering spoke crossings.
A throwback to myth and lore!
>> wheel bearing cones on axles and head bearings on forks.
> They dont move when assembled with oil and done up tight. If they
> do , you are doing it WRONG and are probably using grease and or not
> tightrening the components sufficiently with the correct spanners.
>> Fortunately there are remedies for these problems,
> There is no problem if you use oil as all threaded fasteners require
> and are designed around. Being clever and using grease takes the
> assembly outside the design parameters.
>> but the left hand thread is not a solution
> It is, it's a solution to quick assembly, both pedals can be put on
> together using one hand on each and spinning the cranks. Stiop
> imagining false 'reasons' for bicycle design. It is likely in all
> cases you are doing it wrong.
I see these concepts are beyond your understanding so just let it rest.
>> because other than not unscrewing, it displaces radially (thread
>> clearance) enough to cause fretting damage to the spindle interface
>> with the crank causing failures,
> Not here it doesn't, oil threads, DO NOT USE GREASE ON THREADS,
TIGHTEN FULLY.
>> while BB thread erosion occurs to the extent of wearing the threads
>> away so that they cannot retain required bearing adjustment.
> You must be doing it wrong, use oil to lubricate threads, tighten
> fully with correct tools and no erosion occurs.
>> Fretting damage to head bearings (indexed steering) was also corrected
>> recently by the Shimano threadless steertube.
> No fretting occurs when headsets are properly lubricated with oil.
You have a vivid imagination or you ride so Little that you don't
notice common failures.
>> As I mentioned, a conical face on the pedal spindles makes it immune
>> to this problem,
> How does that stop you using grease on the threads?
>> the way lug nuts on auto wheels did when first
>> introduced to prevent losing wheels (front and rear) when traveling.
> How do you lose wheels, " Oh dear honey, look, we've lost two wheels,
> wonder where they might be?"
I guess you didn't use automobiles before WWII when these were common
failures.
>> Wherever a left hand thread appears in a mechanism, other than a
>> turn buckle or control device, it is most likely misplaced... as
>> are the ones on bicycles.
> So fast assembly time is not a requirement for a mass-produced machine
> meant to be put out at low cost then?
I think you should explain what left hand threads do for assembly time
rather than being a necessity for retaining pedals and BB cups. I
hope you noticed that front tandem cranks have their threads adapted
to their reversed crank functions where the transfer chain is on the
left.
>> A solution to fretting threads is the clamped external
>> thread. This method splits the external thread with a thin saw cut
>> and uses dual machine screws to clamp the internal threaded element
>> in a snug embrace, looking much like a tandem transfer chain
>> adjuster on a front BB.
> Claptrap.
>> Progress is slow.........
> I cant believe you could remain so ignorant of basic mechanics for
> so long. OIL NOT GREASE.
Your insulting retorts are a waste of reader time, not assembly time.
You might look for a job in the bicycle industry if you believe what
you write.
Jobst Brandt
Peter Cole
> A solution to fretting threads is the clamped external thread. This
> method splits the external thread with a thin saw cut and uses dual
> machine screws to clamp the internal threaded element in a snug
> embrace, looking much like a tandem transfer chain adjuster on a front
> BB.
>
> Progress is slow.........
My wife had a low-end bike boom bike made in the 70's (in Portugal) that
had this design on the bottom bracket shell. Once I understood how this
worked I became surprised that it wasn't more common. It made servicing
the bearings much easier, since once the clamp screws were loosened the
cups unscrewed easily. Adjusting preload was much easier, too. I don't
recall if it used left hand threads or lock rings.
Jobst Brandt
>> Progress is slow.........
With folks like Trevor Jeffrey working for you, this sort of advance
can be held off for a long time, even though it is used elsewhere.
Jobst Brandt
kolldata
http://www.nasm.si.edu/wrightbrothers/icon/study_3.html
DOES THE STRAP HOLD A SCREW FASTENED INTO BUTT ENDS ?
One could ask….the Wright’s say ‘continuous construction’ if you
say so Wilbur….
I saw the Brandt 2 screw design in HD electrical device made from
copper, 1950’s
Awful photo
http://en.wikipedia.org/wiki/File:WrightBrothersBicycle.JPG
discovered wing research design thru living at a canal whose levee/
road height allowed watching wading birds fly, land turn, at eyelevel,
and thru matching speeds of my cycling, their flight.
I should go thru Dayton some day and check that possibility out, if
not drained.
anyone know Flyer nuts at JPL ?
kolldata
leg fragility. Wings are easil seen curving, angles changing as speeds
lower to landing levels
kolldata
Tim McNamara
<dcb3e916-cf7c-4099...@h37g2000pro.googlegroups.com>,
Bad Idea <bad.i...@gmail.com> wrote:
Hi, Jim!
Tim McNamara
<31d715fa-6208-4f2d...@j18g2000yqd.googlegroups.com>,
TheCoz <cycl...@hotmail.com> wrote:
> On Sep 7, 10:52 pm, Tim McNamara <tim...@bitstream.net> wrote:
> > In article
> > <ee55ebf0-11ed-4ce1-a705-05a1f7140...@t20g2000yqa.googlegroups.com>,
> >
> > TheCoz <cycled...@hotmail.com> wrote:
> > > Oil if it moves, grease if it fastens.
> >
> > Nope. Try again.
>
> Don't need to try again. Everything is and has been functioning
> properly for many years.
You missed again. Another try?
thirty-six
which is mostly removed:
>
> I see that for you its "oil" and tying and soldering spoke crossings.
> A throwback to myth and lore! [but I felt I had to leave in this classic]
Your lies do not cover your ignorance, I have explained fully. Here
it is again, the first tangent spoked bicycle wheel, by PALMER, which
IS tied and soldered not a piece of basketware.
http://www.google.com/patents/about?id=r9ZuAAAAEBAJ&dq=359809
A much superior wheel to your magical stress-relieved jack-in-the-box
that is unable to accurately track a curve.
Your excuse"they dont make the rims like they used to" does not wash.
Your published build method is unstable on MA40 rims, identical to
your fabled MA2 in all but colour. I dont give a toss that my spokes
remain unbroken, my primary concern is a stable and safe wheel which
will corner through rough ground without losing grip. FASTER and SAFE
wheels for no rider effort. Adjusting for superior comfort is also
high on my list and not scraping my arse is part of this. Your wheels
cannot be ridden hard like a good tied and soldered wheel because your
wheels are inherently unstable.
Please note, mid 1880's. All bearings were also oiled, on what is a
small bearing diameter, hence lubrication with grease can be iffy
unless accurately specified. Good car bearing grease, for taper
bearings, is unsuitable for use on highly loaded bicycle ball bearings
during cold weather.
[more of bullshitter Brandt's ramblings snipped]
Tom Sherman °_°
> On 8 Sep, 07:25, Jobst Brandt<jbra...@sonic.net> wrote more bullshit
> which is mostly removed:
>
>>
>> I see that for you its "oil" and tying and soldering spoke crossings.
>> A throwback to myth and lore! [but I felt I had to leave in this classic]
>
> Your lies do not cover your ignorance, I have explained fully. Here
> it is again, the first tangent spoked bicycle wheel, by PALMER, which
> IS tied and soldered not a piece of basketware.
> http://www.google.com/patents/about?id=r9ZuAAAAEBAJ&dq=359809
> A much superior wheel to your magical stress-relieved jack-in-the-box
> that is unable to accurately track a curve.
>
> Your excuse"they dont make the rims like they used to" does not wash.
> Your published build method is unstable on MA40 rims, identical to
> your fabled MA2 in all but colour. I dont give a toss that my spokes
> remain unbroken, my primary concern is a stable and safe wheel which
> will corner through rough ground without losing grip.
I think we know what has lost grip here, and it ain't the wheels.
> FASTER and SAFE
> wheels for no rider effort. Adjusting for superior comfort is also
> high on my list and not scraping my arse is part of this. Your wheels
> cannot be ridden hard like a good tied and soldered wheel because your
> wheels are inherently unstable.
>
What brand of linseed oil have you been drinking?
> Please note, mid 1880's. All bearings were also oiled, on what is a
> small bearing diameter, hence lubrication with grease can be iffy
> unless accurately specified. Good car bearing grease, for taper
> bearings, is unsuitable for use on highly loaded bicycle ball bearings
> during cold weather.
>
Whale oil, I suppose?
>
> [more of bullshitter Brandt's ramblings snipped]
--
Tom Sherman - 42.435731,-83.985007
I am a vehicular cyclist.
thirty-six
Boeing is making planes using unit construction in carbon fibre,
whatdya think?
Jay Beattie
> Bad Idea <bad.idea...@gmail.com> wrote:
>
> > On Sep 7, 7:20 pm, Jobst Brandt <jbra...@sonic.net> wrote:
> > > . . . threads are used to hold parts together rather than support
> > > radial loads as one finds on bicycles, a faulty design in the first
> > > place, but then most bicycle engineers are unaware of proper use of
> > > threads.
>
> > Sure, jobst. You¹re right and everyone else is wrong. Aerospace
> > engineers are wrong. Automotive engineers are wrong. Ship designers
> > are wrong. Structural engineers are wrong. Machine tool designers
> > are wrong. BTW, have engineers for Porsche ever used threads to
> > support radial loads? Please advise.
>
> Hi, Jim!
Hope so -- it's time for some on-topic flame wars rather than the
usual political crap. -- Jay Beattie.
ADOLFSCHICKLGRUBER TRUECRISTIAN
gay anti jesus
Bill Sornson
"Jay Beattie" <jbea...@lindsayhart.com> wrote in message
news:fbca07d7-0479-4823...@h40g2000pro.googlegroups.com...
> On Sep 8, 4:18 pm, Tim McNamara <tim...@bitstream.net> wrote:
>> In article
>> <dcb3e916-cf7c-4099-8e9a-5373075ea...@h37g2000pro.googlegroups.com>,
>> Bad Idea <bad.idea...@gmail.com> wrote:
>>
>> > On Sep 7, 7:20 pm, Jobst Brandt <jbra...@sonic.net> wrote:
>> > > . . . threads are used to hold parts together rather than support
>> > > radial loads as one finds on bicycles, a faulty design in the first
>> > > place, but then most bicycle engineers are unaware of proper use of
>> > > threads.
>>
>> > Sure, jobst. Youąre right and everyone else is wrong. Aerospace
>> > engineers are wrong. Automotive engineers are wrong. Ship designers
>> > are wrong. Structural engineers are wrong. Machine tool designers
>> > are wrong. BTW, have engineers for Porsche ever used threads to
>> > support radial loads? Please advise.
>>
>> Hi, Jim!
>
> Hope so -- it's time for some on-topic flame wars rather than the
> usual political crap. -- Jay Beattie.
Screw you!
Bill "I'll wait for it" S.
Bill Sornson
kolldata
mideval race car tech
the composite warcraft stays in environmentally adjusted hangers when
not active-temp humidity pressure for nall we know, nitrogen....
Frank Krygowski
> On Sep 7, 7:20 pm, Jobst Brandt <jbra...@sonic.net> wrote:
>
> > . . . threads are used to hold parts
> > together rather than support radial loads as one finds on bicycles, a
> > faulty design in the first place, but then most bicycle engineers are
> > unaware of proper use of threads.
>
> Sure, jobst. You’re right and everyone else is wrong. Aerospace
> engineers are wrong. Automotive engineers are wrong. Ship
> designers are wrong. Structural engineers are wrong. Machine tool
> designers are wrong.
Some of them definitely are. I know a sharp engineer who's always
loved boats. For a time, he worked for a manufacturer of large
yachts, before moving on to more lucrative jobs. Anyway, while still
in school he earned his money by repairing other people's big boats.
He said "Frank, you can't believe how badly designed a lot of these
expensive boats are."
Then there are things like the Martian probe crashed because of a
mixup in units of measurement. And is there really anyone here who
can't remember a design failure of an automobile?
Engineers learn the basics in school, but lots of the practical
knowledge can't be learned in school; it must be delivered apprentice-
style, learning on the job from experienced engineers. Unfortunately,
a lot of experienced engineers are leaving the field due to retirement
or corporate cutbacks.
- Frank Krygowski
Dan O
Isn't that just the way things are and always have been? It would be
better somehow if experienced engineers worked for peanuts and
couldn't ever retire? The world's going to hell in a handbasket
because of those young whippersnappers?
Jobst Brandt
>>>> ... threads are used to hold parts together rather than support
>>>> radial loads as one finds on bicycles, a faulty design in the
>>>> first place, but then most bicycle engineers are unaware of
>>>> proper use of threads.
>>> Sure, Jobst. You're right and everyone else is wrong. Aerospace
>>> engineers are wrong. Automotive engineers are wrong. Ship
>>> designers are wrong. Structural engineers are wrong. Machine
>>> tool designers are wrong.
>> Some of them definitely are. I know a sharp engineer who's always
>> loved boats. For a time, he worked for a manufacturer of large
>> yachts, before moving on to more lucrative jobs. Anyway, while
>> still in school he earned his money by repairing other people's big
>> boats. He said "Frank, you can't believe how badly designed a lot
>> of these expensive boats are."
>> Then there are things like the Martian probe crashed because of a
>> mixup in units of measurement. And is there really anyone here who
>> can't remember a design failure of an automobile?
>> Engineers learn the basics in school, but lots of the practical
>> knowledge can't be learned in school; it must be delivered
>> apprentice- style, learning on the job from experienced engineers.
>> Unfortunately, a lot of experienced engineers are leaving the field
>> due to retirement or corporate cutbacks.
> Isn't that just the way things are and always have been? It would
> be better somehow if experienced engineers worked for peanuts and
> couldn't ever retire? The world's going to hell in a handbasket
> because of those young whippersnappers?
This stuff has got to be learned together or before school, elementary
school, high school, and advanced science, to build a background for
the scientific uderpinnings that apply. When the science teacher
presents a concept to the class, the student must put it into
practical perspective or it won't make any sense or remain in memory.
I recall fixing "coaster" brakes on bicycles in early grade school and
discovering the mechanical interactions in fifth grade science
classes. The same goes for the old cars on which I worked, just
becauzse they presented a reasonable challenge and cost savings to
"do-it-yourself". I also noticed that I was better at it than my
father who taught economics but had practical mechanical and carpentry
abilities he got from his father.
From reading "wreck.bike", I sense that this is no longer the
modus-operandi.
Jobst Brandt
James
> I recall fixing "coaster" brakes on bicycles in early grade school and
> discovering the mechanical interactions in fifth grade science
> classes.
During uni industry based learning (work experience) 6 month placement
at Motorola Communications with a switched on tech that taught me
plenty about basic antenna theory and EM waves and impedance matching,
etc.
On return to uni found the module on electromagnetics comparatively
easy while others had big trouble. For me the theory was backup to
the practical lessons everyone else had missed out on.
Yes, it's nice if the learning takes place in that order, however that
was not the norm in my experience. The mathematics subject at uni was
always ahead of the more practical subjects, and the theory was harder
to fully comprehend until after the practical application had been
seen. For instance, you learn about vector fields in mathematics, and
then see how to apply them in electromagnetics, by calculating and
plotting EM fields.
JS.
Peter Cole
> Engineers learn the basics in school, but lots of the practical
> knowledge can't be learned in school; it must be delivered apprentice-
> style, learning on the job from experienced engineers. Unfortunately,
> a lot of experienced engineers are leaving the field due to retirement
> or corporate cutbacks.
I disagree. Most of the bad engineering I have seen was the result of a
poor grasp of theory, not insufficient practice. Even in a particular
specialty, engineering training is still pretty generic. Applied
technology is so diverse and changes so rapidly that it really can't be
otherwise.
What surprised me the most after becoming a working engineer was how few
of my peers took the time to continuously educate themselves with the
theory needed to competently engineer in job-specific domains. I
frequently found it necessary to hole up in an engineering library for
long periods to fill in subjects missing from my formal education.
Treating engineering as some kind of apprentice program just leads to
the kind of "seat of the pants" approach that often ignores theory and
yields naive designs.
Peter Cole
The university I attended was/is well known for its cooperative
education program. We spent 5 years to get a BS, attending 12 months of
the year, split 50/50 between classroom and jobs in the field.
What I experienced, on the job, was a remarkable number of engineers who
had a poor grasp of theory and a reluctance to correct that. There
seemed to be a combination of arrogance and lack of intellectual curiosity.
Everything in engineering is fundamentally based on mathematics. It was
common at my university for math majors to take "hard" engineering
courses as easy electives just to pad their GPA's. That was a humbling
experience.
The other thing I learned over the years was that for virtually any
sub-specialty (like RF antenna design), you either: never need any of
the theory, or you need way more than you ever learned in school,
depending where the job market takes you.
I've had the pleasure, on occasion, of working with research scientists,
who, for a variety of reasons, were pressed into doing engineering work.
They generally made extraordinary engineers. The idea that such people
are inept at "real world" problems is just a myth engineers employ to
prop up their egos.
Engineering is applied science. You can't engineer without the science
and you can't do the science without the math. To me, it makes perfect
sense to master the abstraction of math first, then apply that to the
study of science, then finally the science to solving "real world"
problems. That was the way my curriculum was set up. I tried to learn RF
and semiconductor theory before college and became frustrated. It wasn't
until later I realized it had been a hopeless task since I lacked the
prerequisite physics and math.
Most of my coop work experience while in school was as a technician,
both in production and R&D environments. I met many intelligent
technicians who daily bumped up against their lack of formal
understanding of the things they worked with. There's a big difference
between being, for instance, a skilled auto mechanic, and a skilled
automotive designer. It's comparatively easy for a designer to be a
mechanic, but not the other way around. The really smart technicians
would ask me about theory to fill in their knowledge gaps, not try to
educate me about practice. Smart people tend to know what they don't know.
The classic example on this forum is the bicycle wheel. It did no good
to gather explanations from "master" wheel builders, since they had no
grasp of the science, and therefore no working model, and therefore no
ability to make accurate predictions. Once the physics had been applied
and the model created with mathematical precision, anybody, even those
who had never built a wheel, or ridden a bike, could knowledgeably
predict wheel behavior -- so long as they had the background to grasp
the model. Just like the math majors who kicked our butts at field theory.
Engineering is often viewed as the "realization of the abstract", but I
think it's much more accurately the "abstraction of the real". We look
at real world objects (like a bicycle wheel) and derive an abstract
model for them. Working without models is simply trial & error. Over
time a body of empirical data points may build up -- a collection of
"do's & don't's", but that has little or no predictive power. When we
see designs in production that obviously violate proven models, that
isn't engineering -- I don't know exactly what to call it, but it's not
engineering.
Cognitive science tells us that we humans mostly see the world through
models we construct. In the interest of mental efficiency, we tend to
make the models as simple as possible. From this light, humans are all
natural engineers -- history bears this out. There is a curious current
backlash to all of this -- a desire to place faith in intuition over
science. Such an outlook would have been equally unproductive when
knapping Clovis spear points. To paraphrase Einstein, models are as
complicated as they need to be.
Abstraction of the real is hard. It's much easier to use rules of thumb
or design cookbooks. I don't have much faith in "learning by doing" or
"doing before learning" in the context of engineering. Like the
technicians I worked with, coming up against the limitations of a
simple, intuitive, but inadequate, model may whet your appetite for a
more sophisticated model, but the reality is that the former must
usually be "unlearned" before the latter can be acquired. I've always
felt that it's the resistance to unlearning that's the big obstacle to
learning. The same thing is true in "reflexive" activities (e.g. golf,
tennis), trainers always first focus at unlearning "bad habits". It
always seems the most difficult concepts to learn are those that run
counter to intuition, e.g. bike wheels stand on spokes.
I don't necessarily believe that messing about with mechanisms in
childhood is so much a prerequisite to developing an engineering
aptitude as it is just a consequence of a particular type of curiosity,
and it's that curiosity that drives some to study engineering. Some kids
just prefer to collect baseball cards.
In the realm of mechanical engineering it may be true that kids these
days have less exposure to the traditional activities that laid the base
for developing curiosity (like riding and fixing bikes). At the same
time, most kids have a comparatively huge exposure to the "mechanisms"
of computer science. I think it's without question that there will be
much more future growth in computing systems than mechanical systems, so
I see nothing to worry about. Even in a purely mechanical domain, like
the development of a bicycle wheel model, the reality is that it was
computational analysis that solved the problem. The future lies in us
all interacting with computer models, which in turn interact with
reality (universal "fly by wire"). We're already well on our way there.
School "shop" these days is CAD/CAM, not blacksmithing.
Jobst Brandt
You might consider the subject line in this thread. I don't recall
the aspects of thread interfaces, thread heat treatment, or how
threads are meant to work in engineering school. These matters
resolved themselves in practice by seeing failures on designs that
followed "standard practice", be that lug nuts on cars, the use of
left hand threads for fasteners, thread lubrication, or soft steel
threaded parts that could not be heat treated... (bicycle sprockets).
I think it takes personal interest and exposure to design applications
on the job and in private. From what I read here, both of these
venues are not being examined and people are falling back on "standard
practice" that is often faulty.
Consider the lengthy disagreements expressed by "standard practice"
people on dimpled head bearings and indexed steering, a problem that
remained uncorrected in the auto industry in car steering until ball
joints and rack-and-pinion steering elbowed their way into fashion
from practical but to "standard practice" crude race car designs.
I saw it happen and was instrumental in the transition.
Jobst Brandt
kolldata
' It did no good
to gather explanations from "master" wheel builders, since they had
no
grasp of the science, and therefore no working model, and therefore
no
ability to make accurate predictions'
no grasp ? no articulation skills in English, no transfer from hands
to mouth. Applicable to mentioned mechanic- engineer skills
relationship. Common misunderstanding of hands on people by the
'educated'
I'm impressed by your skills but working from the non engineering
leading edge I see a field of opportunity in discovery and invention
from non engineers as simply stated, not uni channeled but free to
evolve with an applied environment.
Investigation of invention and creation probably finds a stable
junction of mechanic engineer and artist.
Check the uni for that...
Moving away from cart based auto enginneering into atomic structure
materials advancement skews the agruement but don't get gored by that.
The screw problem puzzles. If one screw threads made strong to support
the design do the job then why add 3 screws and a plate if weight,
cost are primary ? insisting on the inverse weakens the engineering
position.
?
The auto crit has no bearing on reality. Cost, profit..that's it. Why
add a panhard rod when the rod doesn't sell units. Fake it !
Frank Krygowski
Whether a particular engineer's job is more theoretical (i.e.
mathematical) or more practical depends on the job, and on the
engineer. Certain tasks are by nature theoretical, and can't be done
without high-level math - or with computer software (like FEA) that
has the math built in. Others are literally more "nuts and bolts"
practical. The latter jobs do rely on a broad range of experience,
and much of that experience has to be gained on the job, either with
the guidance of an engineer who's already gotten it, or by trial and
error. The guidance method is usually a lot more efficient.
Let me give two examples of the latter type of job. I worked as a
plant engineer in a place that extruded polyethylene pellets into
sheets and sheet products. Process scrap was recycled and remelted
into new pellets. One engineer spent many overtime hours trying to
perfect (or make adequate) his design for a transport augur, which was
supposed to move crudely chopped polyethylene chunks, sheets,
drippings, pellets, etc. He worked with it for months, but it still
wasn't working when I left the company for a different job. He also
left soon after.
I was of the opinion that an augur would never work. Necessary
clearance between the outside edges of the screw and its housing meant
the sheets would inevitably find their way into that gap, begin the
jamming process and stall the system. Maybe I'm wrong, maybe not - but
what mathematics would have predicted whether such a thing could
work? We've only recently gotten competent at modeling the flow of
uniform molten polyethylene into a mold. I think there's no practical
way to model the motion of solid polyethylene of widely varying shape
and size under those conditions. It requires instead some sort of
ability to visualize and anticipate the operation of a mechanism
that's never been tried. I think that comes from experience and
guidance.
For a more bike-appropriate example, let's look at Jobst's favorite:
the pedal screwed into the crank. We've now got easy access to FEA
that does the matrix math to solve for stresses in such a mechanical
connection. But two cautions are needed. First, FEA is famous for
producing outputs showing stress levels via graphics that are
interesting, colorful - and wrong! The problem is rarely with the
math; it's with the description of the loads and boundary conditions.
Getting those right requires the kind of mechanical experience and
visualization that I'm talking about - things that can be efficiently
learned from another experienced (and talented) engineer.
But more to the point, it takes a certain amount of experience and
understanding to even realize there's a question to be asked! Nothing
taught in Advanced Differential Equations class is going to tell you
that variable lateral loading will inevitably cause precession motion
in a plain screw connection. And even in a Machine Design course,
given all that needs to be taught, the professor may have time to give
only an inadequate, fifteen second warning, "Don't load threads
laterally with variable loads, here's why..." before moving on to -
say - treatment of elasticity and fatigue in a bolted connection. And
how many students do you think ever remember that fifteen second
warning?
> Most of the bad engineering I have seen was the result of a
> poor grasp of theory, not insufficient practice. Even in a particular
> specialty, engineering training is still pretty generic. Applied
> technology is so diverse and changes so rapidly that it really can't be
> otherwise.
There is much in Mechanical Engineering that is intensely practical,
can't practically be deduced from mathematical theory, but is based on
principles and theories that don't change very rapidly. Certainly,
the action of threaded connectors is the same as it was long ago.
Threadless headsets could have been done in 1950. So could freehubs
and cassettes, slant parallelogram derailleurs, etc.
The preceding designs may be said to have been caused by a poor
understanding of theory (although I don't think much of that
explanation) but I think the improvements came more because
visualization, founded on experience, enabled a talented designer to
see a new way to practically apply principles that were already well-
known.
BTW, it's my understanding that _The Data Book_ was put together to
inspire Japanese bicycle engineers. It's not a textbook on advanced
mathematics or mechanical theories of failure. It's instead a
beautiful collection of (mostly) Daniel Rebour sketches of innovative
bicycle components from the 1940s, 1950s and 1960s. It's to give
young engineers inspiration, and perhaps a little of what stands in
for experience.
- Frank Krygowski
kolldata
'improvements came more because
visualization, founded on experience, enabled a talented designer to
see a new way to practically apply principles that were already well-
known.'
and sell it to the investor/cost accountants
the university peoples' intention is producing the artist engineer
mechanic to supply that juncture in time/space where statisically,
progress comes forth.
Michael Press
<13eae6a1-d82b-4883...@p24g2000pra.googlegroups.com>,
James <james.e...@gmail.com> wrote:
I always worked with my hands, and it is good to have that.
Science students are best served taking as much pure
mathematics as possible early, and often. Starting with
geometry and proofs, then college algebra, analysis,
linear algebra, and differential equations. Then the
science courses are a doddle. Often you see science
students struggling with mathematics for sciences
because it is taught as a bunch of unconnected tricks.
Mathematics taken as a coherent discipline makes sense
of everything else.
You would be surprised at how a little point set topology
simplifies calculus. Open and closed sets, continuity,
compactness, and connectedness.
All science requires mathematics. The knowledge of
mathematical things is almost innate in us. This is the
easiest of sciences, a fact which is obvious in that no
one's brain rejects it; for laymen and people who are
utterly illiterate know how to count and reckon.
--Roger Bacon
--
Michael Press
Tom Sherman °_°
> [...]
> Everything in engineering is fundamentally based on mathematics.
Er no. Most of the problems I deal with on a daily basis are too
complicated with too many unknown to model mathematically.
> I've had the pleasure, on occasion, of working with research scientists,
> who, for a variety of reasons, were pressed into doing engineering work.
> They generally made extraordinary engineers. The idea that such people
> are inept at "real world" problems is just a myth engineers employ to
> prop up their egos.
>
In my field, there are some institutions that emphasize that professors
should also work as consultants on real world projects. Unfortunately,
there are too many that emphasize modeling with numerical methods, which
in the real world the inputs are rarely known well enough to make these
models useful.
> [...]
> The classic example on this forum is the bicycle wheel. It did no good
> to gather explanations from "master" wheel builders, since they had no
> grasp of the science, and therefore no working model, and therefore no
> ability to make accurate predictions. Once the physics had been applied
> and the model created with mathematical precision, anybody, even those
> who had never built a wheel, or ridden a bike, could knowledgeably
> predict wheel behavior -- so long as they had the background to grasp
> the model.[...]
Except for 'jim beam".
Jay Beattie
<twshermanREM...@THISsouthslope.net> wrote:
> On 9/10/2010 10:34 AM, Peter Cole wrote:
>
> > [...]
> > Everything in engineering is fundamentally based on mathematics.
>
> Er no. Most of the problems I deal with on a daily basis are too
> complicated with too many unknown to model mathematically.
Are you talking about cats again? -- Jay Beattie.
Michael Press
Peter Cole <peter...@verizon.net> wrote:
[engineering, science, mathematics]
Thanks. You got everything right (not that you need me to say so).
A further word about models. When you take mathematics
seriously, then down the road you keep finding you have
powerful, self-consistent models at your beck and call.
Saves a lot of heavy lifting.
As a technician you will never try to remove Gibb's
phenomenon from a circuit. You will never try to
talk about entropy as if it were a real thing that
has to be explained.
--
Michael Press
Michael Press
<a219586a-784d-49ca...@k11g2000vbf.googlegroups.com>,
Frank Krygowski <frkr...@gmail.com> wrote:
All well taken points. You mention mathematics only
to allege failures of mathematics. I claim that
my mathematics education is enormous help in my
practical affairs from beginning to end.
--
Michael Press
kolldata
Jobst Brandt
I think "the Bicycle Wheel" is a good example of the myth and lore
that abounds in bicycle technology. Everything in that book is the
opposite of what was believed prior to its publication and the
faithful on wreck.bike demonstrated that perception by their criticism
of the book's content.
I was aware of that difference while writing and noted that one must
be cautious when questioning religion.
Jobst Brandt
Tom Sherman °_°
Those too.
thirty-six
You're an idiot Brandt. You failed to do your research and produced
an inferior wheel to the original true tangent wheel, nearly 100 years
before you. That of Charles Palmer, patent granted in US in 1887, No
359809
http://www.google.com/patents/about?id=r9ZuAAAAEBAJ&dq=359809
So you made an inferior 'tied and solderd' wheel, which was just a
crappy production wheel with a bit of copper wire slapped on for
appearance, and declared there was no benefit. WRONG wheel, WRONG
result. You still 'miss' the obvious bowing spokes, which you failed
to include for your simplified FEA and you failed to produce a valid
test upon. Your guesswork is bollox, Scwinn would have sacked you
from the assembly line.
Tom Sherman °_°
> [...]Your guesswork is bollox, Scwinn would have sacked you
> from the assembly line.
Who is "Scwinn"?
thirty-six
wrote:
Oh, here's Tom Fu**'n Sermon , full of
whit. Shit
Tom Sherman °_°
> On 11 Sep, 01:55, Tom Sherman °_°<twshermanREM...@THISsouthslope.net>
> wrote:
>> On 9/10/2010 7:09 PM, thirty-six aka Nick L Plate aka Trevor Jeffrey wrote:
>>
>>> [...]Your guesswork is bollox, Scwinn would have sacked you
>>> from the assembly line.
>>
>> Who is "Scwinn"?
>>
>> --
>> Tom Sherman - 42.435731,-83.985007
>> I am a vehicular cyclist.
>
> Oh, here's Tom Fu**'n Sermon , full of
> whit. Shit
As "RicSilver" might write:
Scew you, Trevor, your a moran. ;)
Peter Cole
> Whether a particular engineer's job is more theoretical (i.e.
> mathematical) or more practical depends on the job, and on the
> engineer. Certain tasks are by nature theoretical, and can't be done
> without high-level math - or with computer software (like FEA) that
> has the math built in. Others are literally more "nuts and bolts"
> practical. The latter jobs do rely on a broad range of experience,
> and much of that experience has to be gained on the job, either with
> the guidance of an engineer who's already gotten it, or by trial and
> error. The guidance method is usually a lot more efficient.
From Wikipedia:
"The American Engineers' Council for Professional Development (ECPD, the
predecessor of ABET)[1] has defined "engineering" as:
[T]he creative application of scientific principles to design or
develop structures, machines, apparatus, or manufacturing processes, or
works utilizing them singly or in combination; or to construct or
operate the same with full cognizance of their design; or to forecast
their behavior under specific operating conditions; all as respects an
intended function, economics of operation and safety to life and property."
And:
As stated by Fung et al. in the revision to the classic engineering
text, Foundations of Solid Mechanics:
"Engineering is quite different from science. Scientists try to
understand nature. Engineers try to make things that do not exist in
nature. Engineers stress invention. To embody an invention the engineer
must put his idea in concrete terms, and design something that people
can use. That something can be a device, a gadget, a material, a method,
a computing program, an innovative experiment, a new solution to a
problem, or an improvement on what is existing. Since a design has to be
concrete, it must have its geometry, dimensions, and characteristic
numbers. Almost all engineers working on new designs find that they do
not have all the needed information. Most often, they are limited by
insufficient scientific knowledge. Thus they study mathematics, physics,
chemistry, biology and mechanics. Often they have to add to the sciences
relevant to their profession. Thus engineering sciences are born."
Both definitions stress the connection to science. For activities that
involve invention where science is not used, I'm not sure those can
accurately be called engineering.
> Let me give two examples of the latter type of job. I worked as a
> plant engineer in a place that extruded polyethylene pellets into
> sheets and sheet products. Process scrap was recycled and remelted
> into new pellets. One engineer spent many overtime hours trying to
> perfect (or make adequate) his design for a transport augur, which was
> supposed to move crudely chopped polyethylene chunks, sheets,
> drippings, pellets, etc. He worked with it for months, but it still
> wasn't working when I left the company for a different job. He also
> left soon after.
>
> I was of the opinion that an augur would never work. Necessary
> clearance between the outside edges of the screw and its housing meant
> the sheets would inevitably find their way into that gap, begin the
> jamming process and stall the system. Maybe I'm wrong, maybe not - but
> what mathematics would have predicted whether such a thing could
> work? We've only recently gotten competent at modeling the flow of
> uniform molten polyethylene into a mold. I think there's no practical
> way to model the motion of solid polyethylene of widely varying shape
> and size under those conditions. It requires instead some sort of
> ability to visualize and anticipate the operation of a mechanism
> that's never been tried. I think that comes from experience and
> guidance.
If an application like this one can not use applied science, then I
think it boils down to trial & error, which I would contend is not
engineering. Personally, I would classify it as a "seal" problem, more
specifically, a moving seal problem. I think there are ways to model it
as such, drawing on tribology and materials science. It may be that the
auger solution is just not workable given the constraints, or it may be
that a better auger mechanism is needed. If the problem has already been
solved -- a common situation -- then, yes, "experience and guidance" may
come into play as a more experienced engineer may have a larger library
of known solutions to select from. I'd contend that copying a solution
is not engineering, although adapting a solution from a similar, but not
exactly the same, application might well be. All this seems to say that
problem solving may involve lookup or invention, but I don't consider
lookup engineering.
> For a more bike-appropriate example, let's look at Jobst's favorite:
> the pedal screwed into the crank. We've now got easy access to FEA
> that does the matrix math to solve for stresses in such a mechanical
> connection. But two cautions are needed. First, FEA is famous for
> producing outputs showing stress levels via graphics that are
> interesting, colorful - and wrong! The problem is rarely with the
> math; it's with the description of the loads and boundary conditions.
> Getting those right requires the kind of mechanical experience and
> visualization that I'm talking about - things that can be efficiently
> learned from another experienced (and talented) engineer.
>
> But more to the point, it takes a certain amount of experience and
> understanding to even realize there's a question to be asked! Nothing
> taught in Advanced Differential Equations class is going to tell you
> that variable lateral loading will inevitably cause precession motion
> in a plain screw connection. And even in a Machine Design course,
> given all that needs to be taught, the professor may have time to give
> only an inadequate, fifteen second warning, "Don't load threads
> laterally with variable loads, here's why..." before moving on to -
> say - treatment of elasticity and fatigue in a bolted connection. And
> how many students do you think ever remember that fifteen second
> warning?
I disagree. An understanding of the standard design of threaded
fasteners reveals that there must be clearance between the parts. That
clearance can be quantified (it's a standard, typically). An analysis of
the loads and materials predicts the relative motions (fretting) and
distortions. Tribology predicts the resistance to such motion. Dynamics
predicts the unscrewing torque. Effects like mechanical precession and
backlash (in lead screws) can be easily predicted from an understanding
of the dimensions, loads, and materials involved. Such an understanding
may be reached by analysis and first principles. It does not require
passed-down lore.
> There is much in Mechanical Engineering that is intensely practical,
> can't practically be deduced from mathematical theory, but is based on
> principles and theories that don't change very rapidly. Certainly,
> the action of threaded connectors is the same as it was long ago.
> Threadless headsets could have been done in 1950. So could freehubs
> and cassettes, slant parallelogram derailleurs, etc.
Much of the advance in bicycle design has been a function of the advance
of manufacturing process and machinery, and the attendant improvements
in productivity, materials, and mechanical accuracy.
> The preceding designs may be said to have been caused by a poor
> understanding of theory (although I don't think much of that
> explanation) but I think the improvements came more because
> visualization, founded on experience, enabled a talented designer to
> see a new way to practically apply principles that were already well-
> known.
>
> BTW, it's my understanding that _The Data Book_ was put together to
> inspire Japanese bicycle engineers. It's not a textbook on advanced
> mathematics or mechanical theories of failure. It's instead a
> beautiful collection of (mostly) Daniel Rebour sketches of innovative
> bicycle components from the 1940s, 1950s and 1960s. It's to give
> young engineers inspiration, and perhaps a little of what stands in
> for experience.
The use of "cookbooks" is common practice in many engineering
disciplines. There's no point in re-inventing the wheel. That doesn't
absolve the design engineer from "verifying and validating" -- that is
proving that the particular design is both a proper fit to the specific
application, and also works as described. This means understanding the
design, often as deeply as the original designer.
A brief anecdote: I once had to design a "dual-ported" memory (digital).
I copied the design from a collection of "application notes" provided by
the chip family vendor (Intel). I did this only after completely
analyzing the design. In the process of doing that, I discovered the
design had a superfluous extra stage in a clock synchronization circuit.
I eliminated that stage, a somewhat vain "improvement", since the extra
stage added trivial cost and no degradation, and, if I was wrong, I
would have introduced subtle and random errors. I found out later that
one of the technicians was going around telling people that not only had
I "copied" the design, but I had made an error on the copy. The
technician had no understanding of "V & V", nor the skills involved to
do it. He could have copied the design, but that wouldn't make him an
engineer.
Another one: I once worked for a company that made ultra-precise
machines to measure camshafts. One day, 2 guys flew out from Detroit to
do an acceptance test. The senior guy took a master camshaft from its
padded box, mounted it, ran it through one pass, then rotated it
manually an arbitrary amount for a second pass. He compared the output
error plots and put the camshaft away. The second guy then said: When
are we going to start the tests? The first guy relied: We just finished.
After they left, our chief engineer remarked: There goes a really smart guy.
Peter Cole
> On 9/10/2010 10:34 AM, Peter Cole wrote:
>> [...]
>
>> Everything in engineering is fundamentally based on mathematics.
>
> Er no. Most of the problems I deal with on a daily basis are too
> complicated with too many unknown to model mathematically.
This is also true in my field, computer science/software engineering.
I often claim, generally with a very negative reaction from my peers,
that there is little engineering in software engineering, mostly because
there is little science in computer science. In contrast, I worked for
many years in data communications, a field with very deep theoretical roots.
The Romans invented concrete without understanding the chemistry, and
built large structures without understanding physics. You can call that
engineering. I wouldn't. Without a connection to science, design is
trial and error. Over time, a body of empirical data is created whose
predictive power is limited to: this will probably work because it has
worked before. Without a scientific model underpinning, that body of
experience can't predict effects of scale and/or new variables, and the
failures of empiricism are well known. How many of da Vinci's sketches
would have actually worked?
That some fields are just beyond current science is without question.
You may disagree with my notion of engineering, but in the context of
this thread, I'd say that screw interfaces are well enough understood to
be predictable with existing models. Further, I think those models can
be derived from first principles. The side effects of loading a screw
interface off axis shouldn't be a surprise to anyone who understands the
basic science and engineering. It does not require empiricism.
>
>> I've had the pleasure, on occasion, of working with research scientists,
>> who, for a variety of reasons, were pressed into doing engineering work.
>> They generally made extraordinary engineers. The idea that such people
>> are inept at "real world" problems is just a myth engineers employ to
>> prop up their egos.
>>
> In my field, there are some institutions that emphasize that professors
> should also work as consultants on real world projects. Unfortunately,
> there are too many that emphasize modeling with numerical methods, which
> in the real world the inputs are rarely known well enough to make these
> models useful.
Yes, this is understood, but with every passing year, and increases in
computing power, more of these problems become tractable. The trend is
established, and it's an important trend for future engineers.
Weather forecasting via computer simulations is still hardly perfectly
precise, mostly for the reasons of uncaptured complexity that you
mention, but still beats the Farmer's Almanac handily.
>
>> [...]
>> The classic example on this forum is the bicycle wheel. It did no good
>> to gather explanations from "master" wheel builders, since they had no
>> grasp of the science, and therefore no working model, and therefore no
>> ability to make accurate predictions. Once the physics had been applied
>> and the model created with mathematical precision, anybody, even those
>> who had never built a wheel, or ridden a bike, could knowledgeably
>> predict wheel behavior -- so long as they had the background to grasp
>> the model.[...]
>
> Except for 'jim beam".
Let's not go there.
(PeteCresswell)
>>
>> Er no. Most of the problems I deal with on a daily basis are too
>> complicated with too many unknown to model mathematically.
>
>This is also true in my field, computer science/software engineering.
I spent over 20 years working as a computer application developer
and user support person in a urban electric utility.
What made that IT job different from others was that I was
continually interacting with working engineers.
I came away believing that engineers and computer application
developers have very different mind sets.
When a project is fully designed, the engineer knows in his heart
that if everybody crunched the right numbers the right way it's
going to work. Trivial example: if they're pouring nine yards
of concrete, the engineer knows that there is not going to be any
overflow.
OTOH, the computer applications guy knows in his heart that, no
matter how diligently the project was coded/tested there are
going to be bugs - sometimes even on day 1 of production.
--
PeteCresswell
Tom Sherman °_°
> On 9/10/2010 6:50 PM, Tom Sherman °_° wrote:
>> On 9/10/2010 10:34 AM, Peter Cole wrote:
> [...]
>>
>>> who, for a variety of reasons, were pressed into doing engineering work.
>>> They generally made extraordinary engineers. The idea that such people
>>> are inept at "real world" problems is just a myth engineers employ to
>>> prop up their egos.
>>>
>> In my field, there are some institutions that emphasize that professors
>> should also work as consultants on real world projects. Unfortunately,
>> there are too many that emphasize modeling with numerical methods, which
>> in the real world the inputs are rarely known well enough to make these
>> models useful.
>
> Yes, this is understood, but with every passing year, and increases in
> computing power, more of these problems become tractable. The trend is
Please tell me how to get valid input parameters to model strength and
deformation characteristics of a mass consisting of human placed fill
over soil strata of varying geological origins overlying bedrock that
ranges from decomposed to relatively intact - I could certainly put it
to good use.
Often, these are more useful than any amount of mathematics could be:
<http://www.humboldtmfg.com/showitem-108.html> and
<http://www.benmeadows.com/BEN-MEADOWS-Stainless-Steel-Gopher-Auger-System_31220733/>.
Peter Cole
It seems to me that the engineering could only begin after the soil
composition was established. Computer models have to be parametrized. I
don't see how you'd expect computer models to extract those parameters.
That really isn't the topic at hand.
Tom Sherman °_°
I do not see how to extract those parameters in any way that could be
used to build a relevant mathematical model. Hence my point; give the
problem of building a structure on the variable composition mass to
someone who knows advanced mathematics, physics, chemistry, and material
science but has no practical experience in the situation; and he/she
will be completely at a loss on how to come up with a safe but
economical solution. Yet someone with the right experience and judgment
can come up with an economical but safe solution without the advanced
theoretical knowledge.
> That really isn't the topic at hand.
Yet, that is a real world engineering problem, and one where the
engineer will be held financially liable for the design.
kolldata
Do you smell gas ?
Duane Hebert
"(PeteCresswell)" <x...@y.Invalid> wrote in message
news:e05n865215aaifc9o...@4ax.com...
> Per Peter Cole:
> When a project is fully designed, the engineer knows in his heart
> that if everybody crunched the right numbers the right way it's
> going to work. Trivial example: if they're pouring nine yards
> of concrete, the engineer knows that there is not going to be any
> overflow.
>
> OTOH, the computer applications guy knows in his heart that, no
> matter how diligently the project was coded/tested there are
> going to be bugs - sometimes even on day 1 of production.
Can't argue that. But to me a big difference between an
engineer and an application developer is that the former deals in specifics
and
the latter deals in abstractions. My boss has training as an electrical
engineer and
the rest of us are trained in computer science. We have very different ways
of
approaching a problem. The engineer will keep adding to the solution where
a
developer will try to keep removing.
Frank Krygowski
I'm with Tom. Peter, you seem to have chosen a definition of
engineering that doesn't match the real world - the claim that work is
not "engineering" unless it proceeds from first principles via
mathematics.
In reality, there's a continuum between the most practical jobs and
the most theoretical. ABET used to - and probably still does - talk
about "The Technological Team" with craftsmen at the non-theoretical,
tool wielding end, and scientists at the all-theoretical calculator &
computer end of the team. They filled in the space between with
technicians, technologists and engineers. But it's foolish, I think,
to pretend any task must fit precisely into one of those bins.
More specifically, I think it's foolish to pretend that if it isn't
calculation-intensive, it's not engineering. By that standard, only a
tiny portion of the work of the world's engineers would qualify. If I
perform some fatigue analysis on my way to designing a power
transmission shaft, is that the only portion of the design process
that counts? Is the rest mere drafting?
Come to think of it, I can't even perform the fatigue analysis without
doing some conceptual sketching to lay out whether I'll have keyways
vs. splines, where and how the bearings will be located, etc. Those
decisions can't realistically be said to come from "first principles,"
through mathematics. They are made based on background knowledge of
the machine at hand, and of other shafts, gained from observation and
experience - including the experience of those that came before me.
Engineering is, or should be, practical almost by definition. From
what I've seen, a great majority of practical engineering doesn't
involve first principles and mathematics. If it did, it would take
too damned long to get anything practical done. Most engineering -
mechanical engineering, at least - involves instead a type of
visualization and judgment that's called into play before a calculator
or computer button is ever pushed, and certainly before a differential
equation is ever written on paper. If the latter happens at all, that
is! Much more often, what's written on paper instead is a sketch,
which gets pushed across the table to another guy who's wielding an
eraser and a different idea.
- Frank Krygowski
Dan O
>
> > It seems to me that the engineering could only begin after the soil
> > composition was established. Computer models have to be parametrized. I
> > don't see how you'd expect computer models to extract those parameters.
>
> I do not see how to extract those parameters in any way that could be
> used to build a relevant mathematical model. Hence my point; give the
> problem of building a structure on the variable composition mass to
> someone who knows advanced mathematics, physics, chemistry, and material
> science but has no practical experience in the situation; and he/she
> will be completely at a loss on how to come up with a safe but
> economical solution. Yet someone with the right experience and judgment
> can come up with an economical but safe solution without the advanced
> theoretical knowledge.
>
> > That really isn't the topic at hand.
>
> Yet, that is a real world engineering problem, and one where the
> engineer will be held financially liable for the design.
>
Beginning at age 14, and then several years on, I worked for a
concrete (flatwork) contractor. He really knew what he was doing. I
imagine he apprenticed as a youth, and kept on learning as he went. I
don't think he had much in the way of formal education, but he was an
amazing man - knew so much, and could do so much - impeccable judgment
on the job.
Dan O
> On Sep 11, 1:50 pm, Tom Sherman °_°
>
>
>
> <twshermanREM...@THISsouthslope.net> wrote:
> > On 9/11/2010 11:23 AM, Peter Cole wrote:
>
> > > It seems to me that the engineering could only begin after the soil
> > > composition was established. Computer models have to be parametrized. I
> > > don't see how you'd expect computer models to extract those parameters.
>
> > I do not see how to extract those parameters in any way that could be
> > used to build a relevant mathematical model. Hence my point; give the
> > problem of building a structure on the variable composition mass to
> > someone who knows advanced mathematics, physics, chemistry, and material
> > science but has no practical experience in the situation; and he/she
> > will be completely at a loss on how to come up with a safe but
> > economical solution. Yet someone with the right experience and judgment
> > can come up with an economical but safe solution without the advanced
> > theoretical knowledge.
>
> > > That really isn't the topic at hand.
>
> > Yet, that is a real world engineering problem, and one where the
> > engineer will be held financially liable for the design.
>
> I'm with Tom. Peter, you seem to have chosen a definition of
> engineering that doesn't match the real world - the claim that work is
> not "engineering" unless it proceeds from first principles via
> mathematics.
Maybe I'm falling behind. Where did he say that?
>
> In reality, there's a continuum between the most practical jobs and
> the most theoretical. ABET used to - and probably still does - talk
> about "The Technological Team" with craftsmen at the non-theoretical,
> tool wielding end, and scientists at the all-theoretical calculator &
> computer end of the team. They filled in the space between with
> technicians, technologists and engineers. But it's foolish, I think,
> to pretend any task must fit precisely into one of those bins.
Who thinks that?
>
> More specifically, I think it's foolish to pretend that if it isn't
> calculation-intensive, it's not engineering.
Did somebody suggest that?
> By that standard, only a
> tiny portion of the work of the world's engineers would qualify. If I
> perform some fatigue analysis on my way to designing a power
> transmission shaft, is that the only portion of the design process
> that counts? Is the rest mere drafting?
Well, maybe the drafting would be.
>
> Come to think of it, I can't even perform the fatigue analysis without
> doing some conceptual sketching to lay out whether I'll have keyways
> vs. splines, where and how the bearings will be located, etc. Those
> decisions can't realistically be said to come from "first principles,"
> through mathematics. They are made based on background knowledge of
> the machine at hand, and of other shafts, gained from observation and
> experience - including the experience of those that came before me.
I seriously doubt anyone is suggesting that engineering means working
in a vacuum, utterly bereft of any experience whatsoever. In fact,
that sounds kind of idiotic, Frank.
>
> Engineering is, or should be, practical almost by definition. From
> what I've seen, a great majority of practical engineering doesn't
> involve first principles and mathematics. If it did, it would take
> too damned long to get anything practical done.
I imagine it could take somewhere between too damn long and forever to
engineer a good solution to many problems without a lot of theoretical
modeling first, and I can imagine a sort of John Henry scenario where
Engineer #1 sits down in the lab and knocks out a complete solution
design in no time using his slide rules and what not, while Engineer
#2 huffs and puffs all day producing a piece of crap with his rolled
up sleeves and idiotic grin on his face.
> Most engineering -
> mechanical engineering, at least - involves instead a type of
> visualization and judgment that's called into play before a calculator
> or computer button is ever pushed, and certainly before a differential
> equation is ever written on paper. If the latter happens at all, that
> is! Much more often, what's written on paper instead is a sketch,
> which gets pushed across the table to another guy who's wielding an
> eraser and a different idea.
>
Sketching with your pals sounds like a good time if that floats your
boat, but while the visualization and judgment that I think you're
talking about *could* be derived form working with "experienced
engineers", it might very probably be even better derived from
experience completely outside of "engineering", per se.
Frank Krygowski
Yes, that's possible.
- Frank Krygowski
Dan O
> On Sep 11, 5:42 pm, Dan O <danover...@gmail.com> wrote:
>
>
>
> > Maybe I'm falling behind.
>
> Yes, that's possible.
>
I'm always the first to say, "Anything's possible." Care to address
the balance of my remarks?
Dan O
(I sense a [possible] plonk-a-thon in the offing.)
Peter Cole
It seems to me that there are 2 tasks in the scenario you sketch. First
is determining the soil characteristics. As you describe, samples must
be taken, and where soils are heterogeneous (as you describe), the
characteristics may not be simple to model in aggregate. The second task
is to design the structural foundation, given the (estimated) soil
mechanics and loads. It's the latter task that I argue is essentially
analytical and computational.
Most times designers must choose from a range of established approaches,
for a variety of reasons, in civil engineering not the least of which
are codes and liability/insurance issues. You also have to use a
technique that can be economically implemented by the contractors in the
area. At times where there is a incomplete knowledge of parameters (like
your highly varied soil), the usual approach is overkill. Where
engineering gets challenging is when overkill isn't acceptable (e.g.
aerospace).
As I've said, some problems aren't tractable analytically. Those
problems must be solved with intuition and trial and error. Over time an
empirical database accumulates of solutions that work, unfortunately it
is not usually known why they work, so frequently they don't.
The exemplar problem in the thread title is that of LH threads and
mechanical precession. Probably it was noticed that RH threads had a
tendency to unscrew in some applications, and that could be fixed by
reversing the chirality. Without understanding the physics, many
explanations could be proposed, and further designs could proceed (or
not) on those shaky assumptions.
The question is whether trial & error is engineering. That would include
the use of a (historical) body of trial & error data. I contend it
isn't, since my definition of engineering is based on the application of
science, and a strict empirical method is not science. You might call
the Romans great engineers because they built aqueducts that have stood
for millenniums, but I wouldn't.
Peter Cole
> On Sep 11, 1:50 pm, Tom Sherman °_°
> <twshermanREM...@THISsouthslope.net> wrote:
>> On 9/11/2010 11:23 AM, Peter Cole wrote:
>>
>>
>>> It seems to me that the engineering could only begin after the soil
>>> composition was established. Computer models have to be parametrized. I
>>> don't see how you'd expect computer models to extract those parameters.
>>
>> I do not see how to extract those parameters in any way that could be
>> used to build a relevant mathematical model. Hence my point; give the
>> problem of building a structure on the variable composition mass to
>> someone who knows advanced mathematics, physics, chemistry, and material
>> science but has no practical experience in the situation; and he/she
>> will be completely at a loss on how to come up with a safe but
>> economical solution. Yet someone with the right experience and judgment
>> can come up with an economical but safe solution without the advanced
>> theoretical knowledge.
>>
>>> That really isn't the topic at hand.
>>
>> Yet, that is a real world engineering problem, and one where the
>> engineer will be held financially liable for the design.
>
> I'm with Tom. Peter, you seem to have chosen a definition of
> engineering that doesn't match the real world - the claim that work is
> not "engineering" unless it proceeds from first principles via
> mathematics.
I quoted a couple of definitions which both stressed the connection with
science. Engineering is applied science.
> In reality, there's a continuum between the most practical jobs and
> the most theoretical. ABET used to - and probably still does - talk
> about "The Technological Team" with craftsmen at the non-theoretical,
> tool wielding end, and scientists at the all-theoretical calculator&
> computer end of the team. They filled in the space between with
> technicians, technologists and engineers. But it's foolish, I think,
> to pretend any task must fit precisely into one of those bins.
I didn't say that. I said that I consider only some of those tasks, or
more accurately some portions of those tasks, to be engineering. I don't
see an engineer as an evolutionary half-step between scientists and
craftsmen, either.
> More specifically, I think it's foolish to pretend that if it isn't
> calculation-intensive, it's not engineering. By that standard, only a
> tiny portion of the work of the world's engineers would qualify. If I
> perform some fatigue analysis on my way to designing a power
> transmission shaft, is that the only portion of the design process
> that counts? Is the rest mere drafting?
First, you might rethink your overuse of the term "foolish", it doesn't
win you any friends.
Second, the connection is between engineering and science, the
engineering thus is mathematical to the extent the science is.
> Come to think of it, I can't even perform the fatigue analysis without
> doing some conceptual sketching to lay out whether I'll have keyways
> vs. splines, where and how the bearings will be located, etc. Those
> decisions can't realistically be said to come from "first principles,"
> through mathematics. They are made based on background knowledge of
> the machine at hand, and of other shafts, gained from observation and
> experience - including the experience of those that came before me.
As a practical matter, engineers generally need to be concerned with
many factors outside of applied science. You may choose to call that
"engineering" simply because it is done by the guy wearing the
engineer's hat. By that token, you could call the process of sending out
RFQ's for sub-contractors and evaluating the responses "engineering".
You could call having a catalog of standard metal stock shapes and
alloys in your head "engineering". You might, I wouldn't.
> Engineering is, or should be, practical almost by definition. From
> what I've seen, a great majority of practical engineering doesn't
> involve first principles and mathematics. If it did, it would take
> too damned long to get anything practical done. Most engineering -
> mechanical engineering, at least - involves instead a type of
> visualization and judgment that's called into play before a calculator
> or computer button is ever pushed, and certainly before a differential
> equation is ever written on paper. If the latter happens at all, that
> is! Much more often, what's written on paper instead is a sketch,
> which gets pushed across the table to another guy who's wielding an
> eraser and a different idea.
Ideas can be generated, that process doesn't necessarily involve
engineering. What does involve engineering is the comparison of ideas
and the proof that any idea is in fact a workable solution. Science
involves hypotheses that progress to theories via experimental proof.
Design without hypotheses or theory isn't really engineering, although
in problem domains with insufficiently developed science, trial & error
is the natural fallback.
I don't accept the insinuation that science is "impractical" at all.
What was true in the past was that even relatively simple mechanical
structures (e.g. the bicycle wheel) were impractical to analyze with
manual calculations. These days, the science may be "baked in" to the
tools to the extent that no knowledge of science or math is necessary to
answer fairly sophisticated questions (e.g. analyticcycling.com online
calculators). That doesn't mean the science has gone away.
You can "design" a new driveshaft by copying an existing one that
appears to work, but if the application or the copy is not exact you run
the risk of failure and generally have no idea how close to failure the
design may operate or whether another design may improve upon it in some
significant way. No theory, no analysis, no prediction. Engineering is
about predicting without actually having to build it or operate it over
its design life.
This is all somewhat of a straw man argument. Jobst has contended that
hands-on experience will expose one to things like LH threads and a
curious mind will then try to understand the science. The incurious (or
uneducated) mind may instead latch onto specious explanations and defend
those uncritically. I agree in principle (if I'm not putting words in
his mouth). What I disagree with is the contention that early exposure
to machinery necessarily builds an aptitude for understanding the
science. I find it more natural to proceed from the theory to the
practice rather than the other way around. I feel that the theory
provides context for the practice, not the reverse. I'm still unlearning
things I picked up before I knew better. In the absence of real theories
we tend to invent fake ones -- or at least gullibly accept them.
That exposure whets some curiosity appetites and creates a keen interest
in theory seems apparent. At the same time, I notice my
technically-inclined son has absolutely no interest in auto repair, for
instance, despite much instruction and hands-on experience in
building/fixing bikes. On the other hand, he is absolutely gung-ho on
his latest course in computer graphics. No surprise, given the time he
has invested in graphics-intensive games. Pragmatically, even if he does
get interested in cars down the road, a lot of that will likely involve
computers anyway. No matter what occupation he winds up in I'd bet that
computers will be involved in ways we can't imagine today. In those
times, there will be much less seat-of-the-pants "engineering" since the
machines will be able to run more precise and complete science-based
models. Life will, by necessity, be much less hands-on and much more
virtual. I think a good question is whether or not the study of calculus
is already obsolete.
Michael Press
Peter Cole <peter...@verizon.net> wrote:
> The question is whether trial & error is engineering. That would include
> the use of a (historical) body of trial & error data. I contend it
> isn't, since my definition of engineering is based on the application of
> science, and a strict empirical method is not science. You might call
> the Romans great engineers because they built aqueducts that have stood
> for millenniums, but I wouldn't.
The Roman's structural failures are not with us.
Neither are any of the great cathedrals that
collapsed because they could not bear wind load.
The builders did not leave those stones lying
around; they swept them under the rug.
--
Michael Press
Michael Press
Peter Cole <peter...@verizon.net> wrote:
> I think a good question is whether or not the study of calculus
> is already obsolete.
What is your answer?
Calculus is the pons asinorum to science and engineering.
An engineer is no better than his mastery of mathematical analysis.
--
Michael Press
Tom Sherman °_°
engineer.
Frank Krygowski
> On 9/11/2010 3:14 PM, Frank Krygowski wrote:
>
> > More specifically, I think it's foolish to pretend that if it isn't
> > calculation-intensive, it's not engineering. By that standard, only a
> > tiny portion of the work of the world's engineers would qualify. If I
> > perform some fatigue analysis on my way to designing a power
> > transmission shaft, is that the only portion of the design process
> > that counts? Is the rest mere drafting?
>
> First, you might rethink your overuse of the term "foolish", it doesn't
> win you any friends.
OK, twice in one post was probably _foolish_ on my part! Substitute
"wrong" if you like.
> Second, the connection is between engineering and science, the
> engineering thus is mathematical to the extent the science is.
>
> > Come to think of it, I can't even perform the fatigue analysis without
> > doing some conceptual sketching to lay out whether I'll have keyways
> > vs. splines, where and how the bearings will be located, etc. Those
> > decisions can't realistically be said to come from "first principles,"
> > through mathematics. They are made based on background knowledge of
> > the machine at hand, and of other shafts, gained from observation and
> > experience - including the experience of those that came before me.
>
> As a practical matter, engineers generally need to be concerned with
> many factors outside of applied science. You may choose to call that
> "engineering" simply because it is done by the guy wearing the
> engineer's hat. By that token, you could call the process of sending out
> RFQ's for sub-contractors and evaluating the responses "engineering".
> You could call having a catalog of standard metal stock shapes and
> alloys in your head "engineering". You might, I wouldn't.
But if we're talking about a task that is almost always done by
engineers and nobody else, using the principles and training learned
in engineering school, plus (perhaps) guidance given by other
practicing engineers, how is it realistic to say that task is not
engineering?
> > Engineering is, or should be, practical almost by definition. From
> > what I've seen, a great majority of practical engineering doesn't
> > involve first principles and mathematics. If it did, it would take
> > too damned long to get anything practical done. Most engineering -
> > mechanical engineering, at least - involves instead a type of
> > visualization and judgment that's called into play before a calculator
> > or computer button is ever pushed, and certainly before a differential
> > equation is ever written on paper. If the latter happens at all, that
> > is! Much more often, what's written on paper instead is a sketch,
> > which gets pushed across the table to another guy who's wielding an
> > eraser and a different idea.
>
> Ideas can be generated, that process doesn't necessarily involve
> engineering. What does involve engineering is the comparison of ideas
> and the proof that any idea is in fact a workable solution. Science
> involves hypotheses that progress to theories via experimental proof.
> Design without hypotheses or theory isn't really engineering, although
> in problem domains with insufficiently developed science, trial & error
> is the natural fallback.
There are mountains of tasks that are expected to be performed by
competent engineers and nobody else, but do not fit the definition you
are trying to promote. I gave the example of designing a power
transmission shaft subjected to fatigue loading. Should a central
gear be axially located by a shoulder with a reasonable fillet, or by
a snap ring in a groove, or by a set screw, etc? It's a decision that
must be made, but there is (AFAIK) no hypothesis, nor theory or
experimental proof involved in most such decisions. Nobody is going
to waste time testing three or more alternative shaft designs until
fatigue failure occurs. In fact, a competent designer won't even have
to run calculations on each of the alternatives. Instead, he'll apply
the knowledge, gained through long practical experience and
observations by himself and others, that certain features impart large
amounts of stress concentration and are usually best avoided where
bending moments are high.
How does someone gain that knowledge, or similar knowledge? He may
get a chance to do one or two similar designs in a Machine Design
class, if he's lucky. But once on the job, he'll probably sketch up a
design and run it by his first boss. Boss will give him feedback
saying "You don't want that feature there, and here's why..." and send
him back to the drawing board - or actually, the CAD software at his
desk. Eventually, if he's good, he'll become the guy giving feedback
to others. That's how it happens.
> I don't accept the insinuation that science is "impractical" at all.
It's more that classical science is inadequate for many of the
problems that engineers have to solve each day. Physics (for example)
is wonderful stuff, and the foundation of much that engineers
accomplish. But the courses that engineers take in just Statics and
Dynamics go into far more practical detail on those topics than those
taken by any Physics major. Sure, it's still science - but then,
courses like Machine Design, Mechanism Design, Hydraulics &
Pneumatics, Manufacturing Processes, Applied Industrial Robotics etc.
treat many subjects and problems that pure scientists have seldom, if
ever, examined. Much of the material in those courses is actually the
accumulated experience of thousands of engineers, rather than
"science" fitting the pure hypothesis & test model. Yet engineers
solve these problems every day.
> This is all somewhat of a straw man argument. Jobst has contended that
> hands-on experience will expose one to things like LH threads and a
> curious mind will then try to understand the science. The incurious (or
> uneducated) mind may instead latch onto specious explanations and defend
> those uncritically. I agree in principle (if I'm not putting words in
> his mouth). What I disagree with is the contention that early exposure
> to machinery necessarily builds an aptitude for understanding the
> science.
I really doubt that anyone has said such exposure _necessarily_ builds
an aptitude for understanding the science. I'd prefer to say that
early exposure to machinery greatly aids understanding engineering.
I've seen kids who were brilliant at calculating and could ace bookish
tests easily, but literally didn't realize that two spur gears in mesh
on parallel shafts would rotate the shafts in opposite directions!
(True story!)
Really, different people have different mental strengths. In the
abstract, psychological realm, some are better at spatial perception
than others; some are better at verbal skills; some do analysis better
than synthesis, etc.
In the practical, engineering world, some are better at analyzing
failures, or visualizing mechanical motion, or doing math-intensive
calculations, or designing production processes, etc. All these, and
many more, qualify as engineering tasks, even though most fail your
definition of engineering.
- Frank Krygowski
Peter Cole
> On Sep 12, 12:53 pm, Peter Cole<peter_c...@verizon.net> wrote:
>> As a practical matter, engineers generally need to be concerned with
>> many factors outside of applied science. You may choose to call that
>> "engineering" simply because it is done by the guy wearing the
>> engineer's hat. By that token, you could call the process of sending out
>> RFQ's for sub-contractors and evaluating the responses "engineering".
>> You could call having a catalog of standard metal stock shapes and
>> alloys in your head "engineering". You might, I wouldn't.
>
> But if we're talking about a task that is almost always done by
> engineers and nobody else, using the principles and training learned
> in engineering school, plus (perhaps) guidance given by other
> practicing engineers, how is it realistic to say that task is not
> engineering?
I think, in the context of this discussion, it's meaningful to
distinguish between defining or core tasks (design or design analysis)
and those which are peripheral.
>> Ideas can be generated, that process doesn't necessarily involve
>> engineering. What does involve engineering is the comparison of ideas
>> and the proof that any idea is in fact a workable solution. Science
>> involves hypotheses that progress to theories via experimental proof.
>> Design without hypotheses or theory isn't really engineering, although
>> in problem domains with insufficiently developed science, trial& error
>> is the natural fallback.
>
> There are mountains of tasks that are expected to be performed by
> competent engineers and nobody else, but do not fit the definition you
> are trying to promote.
To be clear, the definitions I gave were not mine, although I largely
agree with them.
> I gave the example of designing a power
> transmission shaft subjected to fatigue loading. Should a central
> gear be axially located by a shoulder with a reasonable fillet, or by
> a snap ring in a groove, or by a set screw, etc? It's a decision that
> must be made, but there is (AFAIK) no hypothesis, nor theory or
> experimental proof involved in most such decisions. Nobody is going
> to waste time testing three or more alternative shaft designs until
> fatigue failure occurs. In fact, a competent designer won't even have
> to run calculations on each of the alternatives. Instead, he'll apply
> the knowledge, gained through long practical experience and
> observations by himself and others, that certain features impart large
> amounts of stress concentration and are usually best avoided where
> bending moments are high.
I think that computer modeling of such a design would reveal stresses.
Accurate modeling eliminates the need for testing.
> How does someone gain that knowledge, or similar knowledge? He may
> get a chance to do one or two similar designs in a Machine Design
> class, if he's lucky. But once on the job, he'll probably sketch up a
> design and run it by his first boss. Boss will give him feedback
> saying "You don't want that feature there, and here's why..." and send
> him back to the drawing board - or actually, the CAD software at his
> desk. Eventually, if he's good, he'll become the guy giving feedback
> to others. That's how it happens.
As I said before, many simple mechanical designs weren't tractable
before techniques like FEA. These days I wouldn't "breadboard"
electronics, I'd just run it in a simulator.
If engineering really worked they way you claim, old engineers would be
worth many times the salary of young ones. I have yet to see that.
>> I don't accept the insinuation that science is "impractical" at all.
>
> It's more that classical science is inadequate for many of the
> problems that engineers have to solve each day. Physics (for example)
> is wonderful stuff, and the foundation of much that engineers
> accomplish. But the courses that engineers take in just Statics and
> Dynamics go into far more practical detail on those topics than those
> taken by any Physics major. Sure, it's still science - but then,
> courses like Machine Design, Mechanism Design, Hydraulics&
> Pneumatics, Manufacturing Processes, Applied Industrial Robotics etc.
> treat many subjects and problems that pure scientists have seldom, if
> ever, examined. Much of the material in those courses is actually the
> accumulated experience of thousands of engineers, rather than
> "science" fitting the pure hypothesis& test model. Yet engineers
> solve these problems every day.
Maybe things have changed since I studied engineering, but my courses
EE/ME were almost pure theory.
>> This is all somewhat of a straw man argument. Jobst has contended that
>> hands-on experience will expose one to things like LH threads and a
>> curious mind will then try to understand the science. The incurious (or
>> uneducated) mind may instead latch onto specious explanations and defend
>> those uncritically. I agree in principle (if I'm not putting words in
>> his mouth). What I disagree with is the contention that early exposure
>> to machinery necessarily builds an aptitude for understanding the
>> science.
>
> I really doubt that anyone has said such exposure _necessarily_ builds
> an aptitude for understanding the science.
Perhaps I misunderstood him, but I don't think so. He has similar
beliefs about bike handling skills.
> I'd prefer to say that
> early exposure to machinery greatly aids understanding engineering.
> I've seen kids who were brilliant at calculating and could ace bookish
> tests easily, but literally didn't realize that two spur gears in mesh
> on parallel shafts would rotate the shafts in opposite directions!
> (True story!)
Sounds like he/she hadn't given it much (any) thought.
> Really, different people have different mental strengths. In the
> abstract, psychological realm, some are better at spatial perception
> than others; some are better at verbal skills; some do analysis better
> than synthesis, etc.
Sure, but my overall point is that many of those skills will become less
important or even unimportant because of better tools. The example I
gave of on-line calculators which solve complex non-linear problems
illustrates that.
> In the practical, engineering world, some are better at analyzing
> failures, or visualizing mechanical motion, or doing math-intensive
> calculations, or designing production processes, etc. All these, and
> many more, qualify as engineering tasks, even though most fail your
> definition of engineering.
Computers are great levelers, and they also shift skills around. I don't
think any of those activities you list are outside of my understanding
of engineering, in that they all involve the application of science. The
"engineering as apprenticeship" model, on the other hand, does not
really do that.
Frank Krygowski
> On 9/13/2010 12:33 AM, Frank Krygowski wrote:
>
> > I gave the example of designing a power
> > transmission shaft subjected to fatigue loading. Should a central
> > gear be axially located by a shoulder with a reasonable fillet, or by
> > a snap ring in a groove, or by a set screw, etc? It's a decision that
> > must be made, but there is (AFAIK) no hypothesis, nor theory or
> > experimental proof involved in most such decisions. Nobody is going
> > to waste time testing three or more alternative shaft designs until
> > fatigue failure occurs. In fact, a competent designer won't even have
> > to run calculations on each of the alternatives. Instead, he'll apply
> > the knowledge, gained through long practical experience and
> > observations by himself and others, that certain features impart large
> > amounts of stress concentration and are usually best avoided where
> > bending moments are high.
>
> I think that computer modeling of such a design would reveal stresses.
> Accurate modeling eliminates the need for testing.
That leads into two FEA stories, then.
Here's the first: I was at an ASME meeting maybe 15 years ago, when a
fresh engineering graduate was complaining about his boss. The kid's
task had been to design a bracket for a big piece of production
machinery, to anchor a large hydraulic cylinder to the machine's main
frame. The kid complained "My boss won't let me use FEA for that!
I'm _sure_ I could make it half the weight if he'd let me use FEA!"
My response? The boss was right! There's no benefit to saving ten
pounds on a 30,000 pound monster machine that never moves, so there's
no benefit to spending the engineering time to construct and run the
FEA model. Besides, such a simple bracket would take maybe half an
hour to design once the kid had experience. He should do it old-
school and get the experience. Save the FEA for problems where it's
really needed; there will be plenty of those.
Here's the second story. I was actually taking my first FEA class,
long after I finished my degrees, because I wanted to learn the
stuff. A good friend (later, VP of engineering for a large company)
was taking it with me. This was actually before desktop FEA was
widely available. Anyway, the friend modeled a big furnace his
company had been having problems with and got beautiful result - but
totally wrong ones! He knew that the furnace base had been cracking
at a certain place, but the model claimed no significant stress was
there.
Sure enough, we found the boundary conditions he used for his model
were wrong. Specifically, he chose a boundary condition that over-
constrained certain points, effectively tying down corners that
actually rose when load was applied. Correcting that got results that
matched their observed problem.
And that's a common problem with FEA. The math is usually fine, and
the pictures are always pretty. But if the loads and boundary
conditions are incorrect, it's Garbage In, Garbage Out.
And how does an engineer learn about those loads and boundary
conditions? It requires visualization that comes from experience,
often under the guidance of other engineers. You can get some of it
in school, but it's really valuable to have spent lots of time with
mechanical things, and with other engineers who can help you learn.
> > It's more that classical science is inadequate for many of the
> > problems that engineers have to solve each day. Physics (for example)
> > is wonderful stuff, and the foundation of much that engineers
> > accomplish. But the courses that engineers take in just Statics and
> > Dynamics go into far more practical detail on those topics than those
> > taken by any Physics major. Sure, it's still science - but then,
> > courses like Machine Design, Mechanism Design, Hydraulics&
> > Pneumatics, Manufacturing Processes, Applied Industrial Robotics etc.
> > treat many subjects and problems that pure scientists have seldom, if
> > ever, examined. Much of the material in those courses is actually the
> > accumulated experience of thousands of engineers, rather than
> > "science" fitting the pure hypothesis& test model. Yet engineers
> > solve these problems every day.
>
> Maybe things have changed since I studied engineering, but my courses
> EE/ME were almost pure theory.
I think it depends on the school, the program and the faculty.
- Frank Krygowski
Michael Press
Tom Sherman °_° <twsherm...@THISsouthslope.net> wrote:
> On 9/12/2010 8:50 PM, Michael Press wrote:
> > In article<i6j0fm$7am$1...@news.eternal-september.org>,
> > Peter Cole<peter...@verizon.net> wrote:
> >
> >> I think a good question is whether or not the study of calculus
> >> is already obsolete.
> >
> > What is your answer?
> >
> > Calculus is the pons asinorum to science and engineering.
> > An engineer is no better than his mastery of mathematical analysis.
> >
> And by this comment, Michael Press indicates that he is obviously not an
> engineer.
I take it that you do not understand the
integral and differential calculus.
--
Michael Press
Jay Beattie
> In article <i6k2id$89...@news.eternal-september.org>,
> Tom Sherman °_° <twshermanREM...@THISsouthslope.net> wrote:
>
> > On 9/12/2010 8:50 PM, Michael Press wrote:
> > > Peter Cole<peter_c...@verizon.net> wrote:
>
> > >> I think a good question is whether or not the study of calculus
> > >> is already obsolete.
>
> > > What is your answer?
>
> > > Calculus is the pons asinorum to science and engineering.
> > > An engineer is no better than his mastery of mathematical analysis.
>
> > And by this comment, Michael Press indicates that he is obviously not an
> > engineer.
>
> I take it that you do not understand the
> integral and differential calculus.
I think differential calculus is harder to get off.
http://en.wikipedia.org/wiki/Calculus_(dental) -- Jay Beattie.
Tom Sherman °_°
> On Sep 13, 2:12 pm, Peter Cole<peter_c...@verizon.net> wrote:
>> Maybe things have changed since I studied engineering, but my courses
>> EE/ME were almost pure theory.
>
> I think it depends on the school, the program and the faculty.
>
of the theory, when solving real life problems.
Tom Sherman °_°
> [...]
> If engineering really worked they way you claim, old engineers would be
> worth many times the salary of young ones. I have yet to see that.
In civil engineering, recent graduates are practically useless at
completing tasks until they gain real world experience.
Tom Sherman °_°
> In article<i6k2id$89m$2...@news.eternal-september.org>,
involves.
James
<twshermanREM...@THISsouthslope.net> wrote:
> On 9/13/2010 2:47 PM, Michael Press wrote:
>
> > Tom Sherman °_°<twshermanREM...@THISsouthslope.net> wrote:
>
> >> On 9/12/2010 8:50 PM, Michael Press wrote:
> >>> Peter Cole<peter_c...@verizon.net> wrote:
>
> >>>> I think a good question is whether or not the study of calculus
> >>>> is already obsolete.
>
> >>> What is your answer?
>
> >>> Calculus is the pons asinorum to science and engineering.
> >>> An engineer is no better than his mastery of mathematical analysis.
>
> >> And by this comment, Michael Press indicates that he is obviously not an
> >> engineer.
>
> > I take it that you do not understand the
> > integral and differential calculus.
>
> I take it that Michael Press has no clue to what the engineering I do
> involves.
Drive a train?
JS
Tom Sherman °_°
James
<twshermanREM...@THISsouthslope.net> wrote:
> On 9/13/2010 5:38 PM, James Steward wrote:
>
> > On Sep 14, 8:01 am, Tom Sherman °_°
> > <twshermanREM...@THISsouthslope.net> wrote:
> >> On 9/13/2010 2:47 PM, Michael Press wrote:
>
> >>> In article<i6k2id$89...@news.eternal-september.org>,
> >>> Tom Sherman °_°<twshermanREM...@THISsouthslope.net> wrote:
>
> >>>> On 9/12/2010 8:50 PM, Michael Press wrote:
> >>>>> In article<i6j0fm$7a...@news.eternal-september.org>,
> >>>>> Peter Cole<peter_c...@verizon.net> wrote:
>
> >>>>>> I think a good question is whether or not the study of calculus
> >>>>>> is already obsolete.
>
> >>>>> What is your answer?
>
> >>>>> Calculus is the pons asinorum to science and engineering.
> >>>>> An engineer is no better than his mastery of mathematical analysis.
>
> >>>> And by this comment, Michael Press indicates that he is obviously not an
> >>>> engineer.
>
> >>> I take it that you do not understand the
> >>> integral and differential calculus.
>
> >> I take it that Michael Press has no clue to what the engineering I do
> >> involves.
>
> > Drive a train?
>
> Knight that says Ni!
Only the true messiah denies his divinity.
J "We will say Ni to you again if you do not appease us." S.
thirty-six
> In article <i6iqn8$e...@news.eternal-september.org>,
> Peter Cole <peter_c...@verizon.net> wrote:
>
> > The question is whether trial & error is engineering. That would include
> > the use of a (historical) body of trial & error data. I contend it
> > isn't, since my definition of engineering is based on the application of
> > science, and a strict empirical method is not science. You might call
> > the Romans great engineers because they built aqueducts that have stood
> > for millenniums, but I wouldn't.
>
> The Roman's structural failures are not with us.
> Neither are any of the great cathedrals that
> collapsed because they could not bear wind load.
> The builders did not leave those stones lying
> around; they swept them under the rug.
A Persian rug.
>
> --
> Michael Press
Peter Cole
> On 9/13/2010 1:12 PM, Peter Cole wrote:
>> [...]
>> If engineering really worked they way you claim, old engineers would be
>> worth many times the salary of young ones. I have yet to see that.
>> [...]
>
> In civil engineering, recent graduates are practically useless at
> completing tasks until they gain real world experience.
>
If civil engineering is as empirical as you describe I have no
difficulty believing that.
Peter Cole
I think your FEA examples really have nothing to do with FEA. Garbage
in, garbage out, holds for any method. A typical example would be column
buckling, choice of the wrong boundary conditions would give the wrong
result. FEA would give the same wrong result, only faster.
The difficulty with many real-world problems is that they are too
complex to solve directly with classical methods. In some cases it can
be done, but only with great (and tedious) effort. The term "computer"
was originally a job title. Rooms full of human "computers" solved
equations manually and produced tables of solutions for things like
artillery firing models.
In many ways, engineering involves simplifying and partitioning problems
we can't solve (or at least pragmatically) into problems we can. Often,
important details get "simplified" out of the design analysis, sometimes
with serious consequences (e.g. Tacoma Narrows). No matter how good our
individual brains may be at "visualization", a limit is quickly reached
where even the best brain can go no further.
The main reason the the popular spreadsheet programs are so widely used
is because they allow quick "what if" scenario analysis. Many
engineering problems are similarly multi-factoral optimization
exercises. By having the model solved quickly, it becomes feasible to
iterate over a much larger set of permutations and converge on a best fit.
You mentioned marine architecture in an earlier post. I've built several
boats in the last few years. These boats were designed using open source
programs. The CAD file can be imported into programs which will compute
things like stability, displacement and speed/drag curves. It's simple
to tweak the design and quickly model the results. I've also used (again
open source) programs to quickly model propeller designs to optimize
parameters for thrust, hull speed, efficiency and shaft RPM. I can
quickly and accurately determine the characteristics of an ideal
propeller for a given application and, perhaps just as importantly,
determine the difference between perfection and the best off-the-shelf part.
In the old days, an experienced marine architect might look at a design
on paper and pronounce it needs more of this and less of that, but
before computer modeling the only way to verify was with scale models
and test tanks. Computer modeling has revealed effects that the old
timers were unaware of and produced designs that have taken marine
architecture in new directions.
My biggest disappointment after graduating engineering school was
discovering how few of the real-world problems I encountered could
actually be approached with the techniques I learned. The tedium of
prototyping and iterating by trial & error in both electrical and
mechanical designs got old quickly. Computer modeling, on the other
hand, gives the same satisfaction to the design engineer that
spreadsheets give the businessman, the instant (or nearly) gratification
of quantitative answers to "what if" questions. Not only does this
exercise produce better designs faster, it leads to deeper intuitive
understanding of the problem domain. In that light, I see computer
modeling not only as a better way to design, but as a better way to
teach engineering.
MikeWhy
Tom Sheman is a useless troll. Civil engineering tasks are typically public
works such as earthworks, roads, and bridges. These all require the
oversight of licensed civil engineers. PE licensing requires a formal 4 year
EIT. While it's completely true that recent graduates cannot complete civil
engineering tasks, by not having completed the licensing requirements, it is
no less true than for other discipline which require professional licensing.
(Say, Tom, won't you do me a favor and remove the non-ASCII characters from
your posting nym? OE apparently has trouble with non-ASCII when applying
message rules, its mechanism for implementing killfiles. Surely you can't be
that desperate for a listening audience as to force yourself on an unwilling
and soon to be very hostile audience.)
Duane Hebert
> Peter Cole wrote:
>> On 9/13/2010 6:00 PM, Tom Sherman °_° wrote:
>>> On 9/13/2010 1:12 PM, Peter Cole wrote:
>>>> [...]
> (Say, Tom, won't you do me a favor and remove the non-ASCII characters from your posting nym? OE apparently has trouble with
> non-ASCII when applying message rules, its mechanism for implementing killfiles. Surely you can't be that desperate for a
> listening audience as to force yourself on an unwilling and soon to be very hostile audience.)
>
What character set are you using? Block sender seems to work for me in OE.
Now if I could only figure out how to remove the replies to the senders that I plonk ...
Ray
> On 8 Sep, 02:20, Jobst Brandt <jbra...@sonic.net> wrote:
>
> > Because I see a misunderstanding of how threads work, explaining a few
> > concepts on the subject might help.
>
> YAWN.
> All threads, internal and
>
> > external (screw and nut) have clearance so they can be assembled
> > without binding (or galling) because that causes damage and prevents
> > full engagement. Because there is clearance, that is usually filled
> > with a lubricant by the assembler,
>
> Usually filled means greas, an incorrect thread lubricant.
>
> > threads are used to hold parts
> > together
> Even on bicycles.
> >rather than support radial loads as one finds on bicycles, a
> > faulty design in the first place,
>
> Only in your mind, because you dont understand how threads work.> but then most bicycle engineers are
> > unaware of proper use of threads.
>
> You mean those experienced in the work all have differing opinion to
> you, now there's a surprise.> fortunately the threadless
> > steertube is a step in the right direction.
>
> Created to reduce assembly time.
>
> >The threaded ones were
> > perpetually fretting,
>
> Nope, not here they weren't, but then most of the headsets I used were
> oiled, oil being the proper lubricant for this high load very low
> speed bearing.
>
> > and the quill stem was a nightmare of bad
> > design, being only vertically secure at the bottom of the quill, while
> > rocking from side to side in use.
>
> You weren't using it right. I have had no problem with correctly
> adjusting headsets once I pruchased the spanners made for the job.
>
>
>
> > In an effort to secure the handlebars, quills were often tightened
> > enough to expand the steertube, preventing installing the lower fork
> > cone.
>
> You weren't doing it right. The correct method was to remove all that
> gunk you had put in there to grease the steerer, then use light oil.
> the quill then grips the steerer without having to distort the
> steerer. It is also best not to have the stem solidly fixed to the
> steerer because some givce is required to prevent abdominal punctures.
>
>
>
> > One can find threads supporting radial loads on bicycles. These are
> > for instance, pedal spindles in cranks,
>
> Only if you're doing it wrong. Again oil not grease and screw it up
> TIGHT.
> You really do have an abnormal aversion to oil.
>
> > BB cups in the bottom bracket,
>
> Yes but when the threads are oiled and done up tight the fitting does
> not move. If it moves you're doing it wtrong, like using grease and
> por not fully tightening the components with the proper tools.
>
> > wheel bearing cones on axles and head bearings on forks.
>
> They dont move when assembled with oil and done up tight. If they
> do , you are doing it WRONG and are probably using grease and or not
> tightrening the components sufficiently with the correct spanners.
>
>
>
> > Fortunately there are remedies for these problems,
>
> There is no problem if you use oil as all threaded fasteners require
> and are designed around. Being clever and using grease takes the
> assembly outside the design parameters.
>
> > but the left hand
> > thread is not a solution
>
> It is, it's a solution to quick assembly, both pedals can be put on
> together using one hand on each and spinning the cranks. Stiop
> imagining false 'reasons' for bicycle design. It is likely in all
> cases you are doing it wrong.
>
> > because other than not unscrewing, it
> > displaces radially (thread clearance) enough to cause fretting damage
> > to the spindle interface with the crank causing failures,
>
> Not here it doesn't, oil threads, DO NOT USE GREASE ON THREADS,
> TIGHTEN FULLY.
>
> >while BB
> > thread erosion occurs to the extent of wearing the threads away so
> > that they cannot retain required bearing adjustment.
>
> You must be doing it wrong, use oil to lubricate threads, tighten
> fully with correct tools and no erosion occurs.
>
>
>
> > Fretting damage to head bearings (indexed steering) was also corrected
> > recently by the Shimano threadless steertube.
>
> No fretting occurs when headsets are properly lubricated with oil.
>
>
>
> > As I mentioned, a conical face on the pedal spindles makes it immune
> > to this problem,
>
> How does that stop you using grease on the threads?
>
> > the way lug nuts on auto wheels did when first
> > introduced to prevent losing wheels (front and rear) when traveling.
>
> How do you lose wheels, " Oh dear honey, look, we've lost two wheels,
> wonder where they might be?"
>
> > Wherever a left hand thread appears in a mechanism, other than a turn
> > buckle or control device, it is most likely a misplaced... as are the
> > ones on bicycles.
>
> So fast assembly time is not a requirement for a mass-produced machine
> meant to be put out at low cost then?
>
>
>
> > A solution to fretting threads is the clamped external thread. This
> > method splits the external thread with a thin saw cut and uses dual
> > machine screws to clamp the internal threaded element in a snug
> > embrace, looking much like a tandem transfer chain adjuster on a front
> > BB.
>
> Claptrap.
>
>
>
> > Progress is slow.........
>
> I cant believe you could remain so ignorant of basic mechanics for so
> long. OIL NOT GREASE.
>
> > --
> > Jobst Brandt
This talk about oil vs. grease accounting for part failures is
laughable. Where do you come up with such ideas? Tied-and-soldered
wheels are stronger? Hobbit talk.
Look at the part failures on my website ( http://www.bayareabikehub.com/links/failures.htm
) and "Pardo's" ( http://pardo.net/bike/pic/ ) and you'll get the
picture. Jobst is a strong rider who has ridden gazillions of miles.
The bicycle industry isn't so concerned about part failures compared
to the auto industry because most bikes aren't ridden far. I read
somewhere 90 percent of all bikes are retired to the garage after
fewer than 100 miles on the road.
Jobst Brandt
I believe it would be far too time consuming to include all the
complex facets of an engineering application in a college course or
include it in FEA applications.
In that line I can best cite "the Bicycle Wheel" which I wrote from
practical experience using the stress analyses that I saw in school.
Although all the concepts in that book were opposite to what was
widely believed at the time of publications, it was all self evident
for me from experience gained parallel to engineering school.
My summer jobs at Food Machinery Corp, Western Pacific RR, and working
as a tree-faller in a timber company along with auto and bicycle
repair, filled all the gaps I found necessary to understand how things
worked or did not work. My education, theoretical and practical, came
in handy when designing optical equipment, disk storage, as well as
high voltage isolators among other things.
Jobst Brandt
Frank Krygowski
>
> My biggest disappointment after graduating engineering school was
> discovering how few of the real-world problems I encountered could
> actually be approached with the techniques I learned.
I believe you're making my point! Yes, the world outside the
classroom is infinitely more complex than the world within the
classroom. Teachers can typically assign a problem of no more
complexity than that allowing completion in perhaps 20 hours, max -
and that would be in an unusual situation like a project course. Most
problems must be completed in an hour. But on the job, projects
requiring weeks of solid work are quite common.
Furthermore, most in-class problems are simplified and straightforward
in structure, even if complex in their math solution. I can recall
solving diff equations to determine the temperature distribution of a
two-dimensional fin (infinitely long in the third dimension) with a
constant temperature heat source at its base and a constant convection
coefficient along its dimension away from that heat source. Um... so
how often does that come up?
The real world is messier, less well understood, requires longer
solutions and often multiple iterations at solutions. There is much
more judgment necessary than in a classroom, there are many more
factors involved in such judgment, and much more experience is needed
to make good judgments. This gets learned on the job.
> The tedium of
> prototyping and iterating by trial & error in both electrical and
> mechanical designs got old quickly. Computer modeling, on the other
> hand, gives the same satisfaction to the design engineer that
> spreadsheets give the businessman, the instant (or nearly) gratification
> of quantitative answers to "what if" questions. Not only does this
> exercise produce better designs faster, it leads to deeper intuitive
> understanding of the problem domain. In that light, I see computer
> modeling not only as a better way to design, but as a better way to
> teach engineering.
It's being used. But hopefully, the people who are doing it are also
teaching more basics as well. You can't do much with a computer if
you don't understand the forces being applied; and many kids have, at
first, _no_ understanding of forces.
I know you're an EE, and you know I'm an ME. I wonder how much of our
differences in opinion are based on those differences?
- Frank Krygowski
Peter Cole
> On Sep 14, 9:45 am, Peter Cole<peter_c...@verizon.net> wrote:
>>
>> My biggest disappointment after graduating engineering school was
>> discovering how few of the real-world problems I encountered could
>> actually be approached with the techniques I learned.
>
> I believe you're making my point! Yes, the world outside the
> classroom is infinitely more complex than the world within the
> classroom. Teachers can typically assign a problem of no more
> complexity than that allowing completion in perhaps 20 hours, max -
> and that would be in an unusual situation like a project course. Most
> problems must be completed in an hour. But on the job, projects
> requiring weeks of solid work are quite common.
I think you missed my point. I wasn't referring to mere complexity, at
least not directly, I was describing the all too common scenarios where
the problem at hand doesn't match theoretically described models close
enough to use them. An example might be Euler buckling. You can only use
the formulas if the beam geometrically matches the range of assumptions
of the formulas -- then it becomes solvable. If not, you have to try to
express the problem you can't solve in terms of sub-problems you can, or
at least bound the problem between configurations with known solutions.
The advent of computer modeling allows the use of "brute force"
numerical methods which allows finding the solution to previously
unsolvable problems. The net of this is much less reliance on empirical
data. You don't have to rely on your boss to dig up a solution that
worked in the past, you can model your own, and, unlike your boss, you
can prove it will work, and by exactly how much.
http://userweb.elec.gla.ac.uk/y/yunli/ga_demo/
>> The tedium of
>> prototyping and iterating by trial& error in both electrical and
>> mechanical designs got old quickly. Computer modeling, on the other
>> hand, gives the same satisfaction to the design engineer that
>> spreadsheets give the businessman, the instant (or nearly) gratification
>> of quantitative answers to "what if" questions. Not only does this
>> exercise produce better designs faster, it leads to deeper intuitive
>> understanding of the problem domain. In that light, I see computer
>> modeling not only as a better way to design, but as a better way to
>> teach engineering.
>
> It's being used. But hopefully, the people who are doing it are also
> teaching more basics as well. You can't do much with a computer if
> you don't understand the forces being applied; and many kids have, at
> first, _no_ understanding of forces.
My claim is that you'll get a better understanding of forces with a
model than a wrench.
I'm sure you've seen displays in science museums like ours in Boston
with scale models of gears and pulleys and hydraulics. These are used to
teach basic mechanical principles. I didn't need to tear down a
Studebaker to see a differential in action. These days I'd be much
better served by a simulation that would allow me to change things and
observe the results, much more information could be imparted more
quickly than by watching a motorized model or simply fiddling with the
part itself. One picture is worth a thousand words, and one model is
worth a thousand pictures.
> I know you're an EE, and you know I'm an ME. I wonder how much of our
> differences in opinion are based on those differences?
I doubt it. My degree was EE major, ME minor. I studied statics,
dynamics, thermo, material science and mechanical drawing among other
things. I also studied numerical methods and programming.
I don't think much of the theory I studied was of any use, either to
directly apply to work problems or even just to give "insight", any more
than classical physics was any help in studying quantum mechanics.
Frank Krygowski
> On 9/14/2010 12:54 PM, Frank Krygowski wrote:
>
> > On Sep 14, 9:45 am, Peter Cole<peter_c...@verizon.net> wrote:
> >
> >> prototyping and iterating by trial& error in both electrical and
> >> mechanical designs got old quickly. Computer modeling, on the other
> >> hand, gives the same satisfaction to the design engineer that
> >> spreadsheets give the businessman, the instant (or nearly) gratification
> >> of quantitative answers to "what if" questions. Not only does this
> >> exercise produce better designs faster, it leads to deeper intuitive
> >> understanding of the problem domain. In that light, I see computer
> >> modeling not only as a better way to design, but as a better way to
> >> teach engineering.
>
> > It's being used. But hopefully, the people who are doing it are also
> > teaching more basics as well. You can't do much with a computer if
> > you don't understand the forces being applied; and many kids have, at
> > first, _no_ understanding of forces.
>
> My claim is that you'll get a better understanding of forces with a
> model than a wrench.
I guess that's where we differ. One of the things I'm saying is that
if you've never handled a wrench, you'll be unlikely to construct the
model properly. Most specifically, you'll likely get some of the
loads and boundary conditions wrong in any computer model you
construct. What can I say? I've seen it happen.
When I was teaching a sophomore intro to machine design (poorly named
- at that level, they certainly weren't designing machines!) I
developed a lab exercise in which teams of students would disassemble
small engines, draw free body diagrams of the components, show the
nature (not calculate the magnitudes) of the forces, and much else.
For one specific example - briefly related to some posts here -
occasionally students would not realize that the connecting rod's
major force changed from compression to tension. It was common for
students to omit the lateral reaction force on the piston, where it
was supported by the cylinder wall. It was rare for them to correctly
describe the forces and moments on the crankshaft. And so on, and so
on.
Most of them could probably do a fine job of drawing the solid model
of the crank, getting the software to generate the mesh, etc. But if
they can't show the loads properly, their model won't do much good.
These kids generally did learn, and most of them eventually found
their way into an "engineering" job in which they succeeded. But I
contend that they must have learned a lot on the job, under the
guidance of experienced engineers.
Come to think of it, that's a requirement for a PE license!
- Frank Krygowski
Michael Press
Peter Cole <peter...@verizon.net> wrote:
> I don't think much of the theory I studied was of any use, either to
> directly apply to work problems or even just to give "insight", any more
> than classical physics was any help in studying quantum mechanics.
Then you did not study classical mechanics
and quantum mechanics, even if you passed some classes.
Hamilton's equation, Poisson brackets, Lie Algebras.
SO(3) is the rotation group in three space.
SU(2) is the special unitary group seen in quantum mechanics.
SO(3) and SU(2) are locally isomorphic
but they are not globally isomorphic.
SU(2) is simply connected.
SO(3) is not simply connected.
This latter fact is the mathematical origin of gimbal lock.
Modern treatments of rotations use quaternions.
Quaternions are isomorphic to Pauli spin matrices.
All this is covered in books on classical mechanics.
SU(2) is used in the quantum mechanics description of spin 1/2 particles.
Classical mechanics and quantum mechanics use many of the same tools.
Nobody will get anywhere in physics without knowing this.
--
Michael Press
Michael Press
"MikeWhy" <boat042...@yahoo.com> wrote:
Sherman's From: header line complies with RFC 1342
Representation of Non-ASCII Text in Internet Message Headers
Since OE does not deal with mail and usenet standards
you have some choices to make. You can continue with OE
and live with its foibles. You can find another
newsreader that knows how to decode these things. You
can ask that others compensate for Microsoft OE's way
of doing things.
"Whenever such words appear in a header being displayed, an enlightened
mail reader will decode the text and render it appropriately."
Another possibility is that your installation
has some settings that interfere with decoding.
--
Michael Press
Jobst Brandt
>>>> The tedium of prototyping and iterating by trial & error in both
>>>> electrical and mechanical designs got old quickly. Computer
>>>> modeling, on the other hand, gives the same satisfaction to the
>>>> design engineer that spreadsheets give the businessman, the
>>>> instant (or nearly) gratification of quantitative answers to
>>>> "what if" questions. Not only does this exercise produce better
>>>> designs faster, it leads to deeper intuitive understanding of the
>>>> problem domain. In that light, I see computer modeling not only
>>>> as a better way to design, but as a better way to teach
>>>> engineering.
Modeling the bicycle wheel used a homemade pressure vessel program,
because a bicycle wheel is a slice out of a tubular pressure vessel
and one of my fellow engineers had developed that program for his
master's thesis. I easily changed its input prompts to allow spokes
and rims.
>>> It's being used. But I hope, the people who are doing it are
>>> also teaching basics as well. You can't do much with a computer
>>> if you don't understand the forces being applied; and at first,
>>> many have, no understanding of forces.
>> My claim is that you'll get a better understanding of forces with a
>> model than a wrench.
> I guess that's where we differ. One of the things I'm saying is
> that if you've never handled a wrench, you'll be unlikely to
> construct the model properly. Most specifically, you'll likely get
> some of the loads and boundary conditions wrong in any computer
> model you construct. What can I say? I've seen it happen.
> When I was teaching a sophomore intro to machine design (poorly
> named - at that level, they certainly weren't designing machines!) I
> developed a lab exercise in which teams of students would
> disassemble small engines, draw free body diagrams of the
> components, show the nature (not calculate the magnitudes) of the
> forces, and much else.
> For one specific example - briefly related to some posts here -
> occasionally students would not realize that the connecting rod's
> major force changed from compression to tension. It was common for
> students to omit the lateral reaction force on the piston, where it
> was supported by the cylinder wall. It was rare for them to
> correctly describe the forces and moments on the crankshaft. And so
> on, and so on.
I guess I never had a problem because I observed steam RR engines
whose main-rod was attaches to the cross-head to link it to the piston
rod. Cross-heads traditionally clanked when the main rod went through
the centerline and absorbed cross-head clearance. Of course this is
all in the open where it can be seen, but the reason for thew clank
may not have been obvious to some observers. I took it for granted
that all piston engines had this problem and never questioned it on
the automotive engines that I maintained from Model-T to Ford v-12.
Of course my single cylinder motorcycles were part of that genre.
> Most of them could probably do a fine job of drawing the solid model
> of the crank, getting the software to generate the mesh, etc. But
> if they can't show the loads properly, their model won't do much
> good.
I think there is a natural tendency for mechanically inclined people
to seek the paths of forces in machines. At least, I always felt that
way.
> These kids generally did learn, and most of them eventually found
> their way into an "engineering" job in which they succeeded. But I
> contend that they must have learned a lot on the job, under the
> guidance of experienced engineers.
I did not find that as part of my experience. Most of these things
were obvious, but sometimes I asked someone who had experience with
such a machine to support my perception of it.
> Come to think of it, that's a requirement for a PE license!
I'm glad I never needed such a license. It seems so tedious.
Jobst Brandt
Tom Sherman °_°
>
> This talk about oil vs. grease accounting for part failures is
> laughable. Where do you come up with such ideas? Tied-and-soldered
Trevor (aka thirty-six) drinks boiled linseed oil.
Duane Hebert
"Michael Press" <rub...@pacbell.net> wrote in message
news:rubrum-613336....@news.albasani.net...
> In article <i6nvk6$8p0$1...@news.eternal-september.org>,
> Since OE does not deal with mail and usenet standards
> you have some choices to make. You can continue with OE
> and live with its foibles. You can find another
> newsreader that knows how to decode these things. You
> can ask that others compensate for Microsoft OE's way
> of doing things.
>
> "Whenever such words appear in a header being displayed, an enlightened
> mail reader will decode the text and render it appropriately."
>
> Another possibility is that your installation
> has some settings that interfere with decoding.
In OE if you click on the post and got to "message" and then "block
sender" it will add the user to your blocked list based on the "from"
address. Not that I think that OE isn't broken but ...
Tom Sherman °_°
> Frank Krygowski wrote:
> [...]
>> Come to think of it, that's a requirement for a PE license!
>
> I'm glad I never needed such a license. It seems so tedious.
>
Too bad other types of "consultants" are not similarly held accountable,
as it would put an end to many nepotism and favoritism government contracts.
Tom Sherman °_°
Other than some types of structural engineering where all the parameters
are well defined, it by necessity is.
My particular specialty, geotechnical, is as much art as science.
Geological process results are to complex to model accurately in most cases.