On Wed, 29 Dec 2010 23:57:07 -0500, firstname.lastname@example.org wrote:
Code - even assembler - can be structured and commented to take care
of that. But hardly anybody did it in my experience.
Shop standards help, but they often weren't followed.
There was plenty of COBOL spaghetti coding done too.
Even a well structured program can be hard for the next guy to
COBOL helped since data naming conventions were pretty easy to
decipher, and there was more of a push for structure.
But I basically agree with you.
Writing a program that works is one thing.
Writing one that works efficiently and is easy for the next guy to
modify is something else.
On 12/29/2010 12:18 PM, email@example.com wrote:
Most had at least some passing experience with programming, but none
knew of FORTRAN as anything other than a historical curiosity.
possibly? I don't know - only programming experience that I have is a
little messing around with BASIC in middle school, and then that one
class. Oh, and a psychology experiment that I took part in partly for
the money and partly because a girl I was dating was somehow involved
in, that had something to do with studying *how* people learn to program
by using a computer-based teaching tool to teach LISP. I think I
actually picked up some stuff there, but never applied it.
In retrospect, *either* ME or CS would have been a poor choice, because
either way I probably would have been laid off eventually :/ (ME
because the automotive industry, in which I was primarily interested, is
all but dead in the US, and CS because that's slowly but inexorably
moving offshore) Unfortunately, I did graduate with a BSME... was fun,
but I'm certainly not working in my field. At least I have a job...
replace "roosters" with "cox" to reply.
When I first took ForTran in high school, they wanted to see *if* high school
students could learn it. I suppose the answer is obvious now, but they
seriously questioned it then (programming was only for math and engineering
grad students at the time).
It really isn't. There is still a *lot* of it done here, though it has
I have a BSEE, and have been working in the field since '74. I retired once
and went back for even more fun. ;-)
That you were being taught Fortran and PL/I just shows how sick the
U.S. education system is.
Both those languages were basically dead in 1980, when I started
working in IT.
Yet they were still being taught at my state U.
In fact I only needed a PL/I course to get my degree.
Didn't bother. Total waste of time, but it was the department head's
pet language. Never hurt me not having a degree either.
There was some collaboration between business and the school though.
My COBOL instructor was really an IT guy moonlighting, and got an
internship program going with one of his clients.
Picked me as the first intern. Not because I a particularly good
student, but because I was older than the other students, had a wife,
kids, a job, and a car.
He figured I'd at least show up on schedule at the client, almost 40
miles away. I showed up.
Woody Allen said "Eighty percent of success is showing up."
Probably true. Then maybe you add 10 percent luck.
When I retired 4 years ago I was running a crew of H-1B Indians.
The entire place - one of the largest IT shops in the country - was
full of Indian H-1B's.
They were well schooled in India, and cheap to buy.
Polite, and hard-working too.
Why bother looking at U.S. schools?
Nobody has a plan or America's future. It's dog eat dog.
My youngest son graduated from U of I, engineering.
He worked an IT web language job here for about a year, then moved to
Australia, where he's worked as an engineer ever since.
They offshore the engineering work too, and bring in H1-B's.
It's funny how many here think only manufacturing jobs are going away.
Think the Indians/Asians are stupid.
I was a steelworker, autoworker and had other mfg jobs before I went
into IT. Saw the writing on the wall.
Also saw the white collar writing on the wall, but my timing was
Hey, that's the other 10 percent to get to 100 percent of success -
Bullshit. Besides the '60s and '70s coming before 1980, ForTran is _still_
big in scientific disciplines (for it's imaginary support and math libraries)
and PL/I, while not being huge, is still used. Even COBOL is still used.
That's you, hardly the universe of IT.
Absolutely true, except that you make your own "luck". It takes work.
Which U of I?
Except they aren't. They are changing.
I've never heard that one. Too far to the opposite, in fact.
Sure. Unions are dead, except those on the public dole.
On Thu, 30 Dec 2010 11:47:09 -0600, " firstname.lastname@example.org"
Fortran is egghead stuff. Always has been.
Eggheads aren't IT people, but have no problem programming any
language that suits them. I suppose some are still using APL too.
My school was Northeastern Illinois and the purpose of the computer
courses was to gain skills to get a job in business, not science.
The degree wasn't even called CS then, it was InfoScience.
Hell, I didn't know algebra. Still don't.
But I spent +25 successful years in the business, working for both
major corporations and consulting companies, and never met a Fortran
So Fortran was dead for my purposes, and so was PL/I.
Everything I did was assembler, Cobol, and a smattering of other
languages that got sold to IT managers as the latest panacea.
A preferred language is often just tradition or "religion."
I could do any mathematical function in COBOL that Fortran could do
by making a subprogram call.
I could code binary bytes in COBOL, and did on occasion.
If you know it you know it.
As computers beefed up in power what became important in business
computing was program maintainability, because programmers were
expensive, and so were system glitches.
Probably not so important now. Just bring some cheap Indians in,
don't pay benefits, and have them fix things.
Anyway, I'm done arguing about languages. BTDT.
You're right on that. But then I was talking only about me.
Work is a given.
What world was that you live in?
You hear it every day and all day if you listen to the "experts" in
charge of the American economy.
"We must lead in the "new economy" by educating everybody in the new
What a crock. Half of America can't tie their shoes while India and
China pump out shiploads of engineers.
It all gets down to work ethics. They disappeared when Wall Street
said everybody would be rich.
Unions were a part of it.
But most of the non-union manufacturing is gone too.
The biggest part was U.S companies could get cheap labor offshore, and
better management that paid attention to quality.
They sold the store.
Same goes for white collar IT/engineering type jobs now that foreign
schools are geared up.
On Thu, 30 Dec 2010 14:10:12 -0600, " email@example.com"
Actually my original point was in reference to Nate saying he was
being taught PL/I and Fortran in a mid-nineties CS class.
Most CS grads were going into the business IT world, and those
languages were useless and dead for business by then.
An engineer type has no problem picking up a language like Fortran or
PL/I to suit his needs.
No sense quibbling.
I take what I said back, and now say, "Both those languages were
basically dead in the 1980 business world."
"Small" is all perspective of course.
But in terms of business IT my world was far from small.
Don't know much about C. There was some demand for it in the
I met a Bell Labs guy - Geroge - in about 1980 who was on the team
One of the C programmers under my umbrella when I was an account
manager, and whose technical skills I respected, told me it was a dead
end, since the functions had all been written, and that's where the
"fun" was. That was mid-nineties.
Believe me, you don't need to know higher math in business IT.
That's what mathematicians and accountants are for.
All you have to do is put their formulae in code and test it.
They wouldn't have it any other way.
If it's too complex to code in the language at hand, somebody has
written a sub-routine in a suitable language to call.
Just like you got those functions performed by your calculator.
Most of my experience is....mine. Can't help that. All I got.
He was at Champagne. General Engineering. Don't ask me what they do.
But he's doing fine in Australia working for a construction outfit.
Some kind of project planning work.
Right. That accounts for real 15% unemployment.
More like realistic.
Sure. The GM engineers were designing quality products, and GM
management was taking good care of customers.
It was all the workers fault with their evil unions.
Bet you liked your Chevy Vega except for the worker labor part.
BTW, my first job out of the Navy in '67 was at U.S. Steel South
Decrepit blast furnaces while the rest of the world had moved to BOP.
The millwrights I worked with could shave babbitt bearings and the
sweethearting Steelworkers union got them all of 3 bucks an hour.
There was a book written how the CEO drove that company to ruin.
After that I went to IH building dozers and dealt with the management
incompetence there. Another place that went bust, but I won't bore
you with my personal observations.
They involve production and the QC thereof, so don't count..
A book was written about how Archie McCardle drove IH to ruin too.
Never read either book, but since I was at both places as a
Steelworker and Autoworker I guess it was all my fault and I got the
You mean just because "Made in China" is stamped on damn near
everything a consumer buys, it's different?
Okay, I'll go along with that.
You might notice that imported items are getting higher marks than
Ford, GM and Chrysler in general.
That boat has sailed.
Anybody who knew BASIC could get a job teaching MIS 25 years ago.
Had a buddy who did that for a while.
Excuse me if your IT credentials don't impress me.
I would certainly pick no bones over that, except that they were never used
that heavily in the business world. ;-)
Right, but business IT is a small corner of the world of programming. A
rather important corner for IBM, however, who still like PL/I (and
derivatives) quite a lot. ;-)
Still is, but that's not my point. For *MY* purposes, it's dead. The world
in general has a *lot* of other purposes. Without a doubt, more programs are
written in C today than any other language, and probably by a few orders of
"All the functions have been written" is rather like "everything that can be
Again, not the point. I'm sure you're very good at what you do.
Yes. ForTran. ;-)
Design armys? ;-)
There is a big difference between manufacturing and manufacturing employment.
The US manufactures more than it ever has. Manufacturing is a lower
percentage of employment, however, as one would expect.
Now look at salaries, benefits, and union productivity obstacles, not to
mention union thuggery. It was *not* all management's fault that GM sank.
...and it will continue, perhaps even more rapidly now.
A lot of that is tax policy, too, as well as union work rules.
You see nothing that the unions did wrong here?
Oh, cut the bullshit. We were talking about US manufacturing. There are a
*LOT* of cars made by non-union shops, right here in the US and quite
A lot of those "imported items" are not.
Do you expect any new industry to maintain its infant growth rate forever?
Who said I was an IT professional (as I said above, I'm an EE)? We weren't
discussing one little sector of the economy, either.
On Thu, 30 Dec 2010 17:30:27 -0600, " firstname.lastname@example.org"
Depends exactly what business you are talking about, I quess.
Clarica Insurance, formerly Mutual Life of Canada, now part od Sun
Life, depended (and likely still does) very heavily on its Fortran
based programs in the actuarial sciences.
On Thu, 30 Dec 2010 17:30:27 -0600, " email@example.com"
I highly doubt that. Most of us engage in many business transactions
Just guessing, but my estimate is 90% of programming is
He was a nerd that way, but I saw his point.
There are only so many common math functions used in business.
That's not to say new processing needs don't arise or the work ends.
He just found doing anything twice boring.
And IT is basically repetition of the same concepts over and over.
You get some new stuff now and then, like new database structures and
access language, OOB and the like, most recently html and .net, blah,
I was working SAP data warehouse and ABAP when I retired, but wasn't
young enough to be excited about it.
Same old. Input, move, tweak and present data.
BTW, SAP is a fast-spreading German enterprise-wide IT solution, and
the Indians have 2 legs up on running it.
They train in India assiduously. Don't know if the Indian government
has a hand in IT training, but the Indians sure have a plan and a goal
to employ as many in IT as possible.
I see nothing like that here in the U.S.
Despite rampant unemployment.
In fact the U.S. corporate trend is to continue offshoring work,
Obama's bullshit notwithstanding.
I see what you're saying there, and you're correct.
But I didn't mean to imply that COBOL and Fortran are equal, or that
business processing touches all the scientific math areas.
My point was more to how languages gain fans in their own communities,
and that Fortran could easily be replaced by COBOL with calls to
assembler sub-routines. No Fortran at all in the mix.
But why bother disturbing Fortran fans? If it's working for them
that's good enough.
hehe. I recommended he join the FBI when he got his degree.
He looked at me like I was crazy.
You can twist figures however you want.
This might be of interest.
I'll cop to skeptical. That's it.
Same union at Ford, but huge difference in outcome.
"Union thuggery." Funny.
You going to trot out a story about how your dad was beaten with
baseball bats because he refused to strike.
Already heard that one.
Nope. There were never fat wages at U.S. Steel or IH.
Just incompetent management. I was there.
No "work rule" impediments either.
Biggest difference was when a foreman at U.S. Steel told you do
something that would get you killed, you might do it.
At IH you would tell the foreman to go fuck himself.
Nothing wrong with that "work rule" to me.
Details upon request.
You get off the union bullshit. I was talking manufacturing and now
you're ragging on unions.
Plenty of non-union manufacturing was offshored.
First off I only buy union made cars, because I like Chevys.
But most Chevys are union-made - in Canada, a foreign country.
I guess I could buy a German or Jap union-made import, or a non-union
one made here, but I'm sticking with Chevys.
Anyway cars aren't a big expense for me since I get them used and
cheap. My car costs don't even come close to $300 a year.
I wrench and so does my kid.
I just got off the phone ordering a Mexican-made Kenmore fridge for
$700 to replace the $500 Mexican-made fridge I bought about 5 years
ago and which just started making serious noise today..
A Mexican fridge for a Mexican fridge.
A few years ago I spent $600 on a Mexican GE washer and another $200
on a warranty for it.
Earlier this year I spent about a $1000 in computer components to
build a new box.
Nothing made in the U.S.
I probably spent $1000 this year on various electronic gifts for my
Nothing made in the U.S.
Spent a few hundred on power tools. None U.S.made.
Got a U.S. made nail set and hammer. Big whoop.
My next expense will be a flat screen TV.
Probably another $500 for small, at least $1000 for big..
Tell me where to find one made in the U.S.
Anybody can read a balance of trade chart for manufactured goods.
As you see if you read the article above, some of U.S. manufacturing
is non-tradeble products.
So I buy U.S. made toilet paper. All the junk mail I get is U.S.
made. That's all part of your American "manufacturing" claim.
I don't have the figures on tradable vs. non-tradable, but it's easy
to read balance of trade charts for manufactured goods.
Don't need to though when you can see everything you're buying is made
Where the hell are you getting U.S made products besides Jap and
German cars made here?
You buying Boeing airplanes?
Good on you.
But you might soon be buying Chinese airplanes. Non-union made.
Easy claim to make, but if there's no U.S. made counterpart to compare
against what's the difference?
You don't have a choice.
Ok, I'm done with this. It never goes anywhere.
You take the last shots.
I think you would be wrong, considering that even toasters have a computers in
He was myopic.
That part I understand.
That's something kids here don't do. They don't do *anything*, other than
perhaps Nintendo and maybe round-ball, assiduously.
They really have no choice. It's too expensive to hire people here. Obummer
is piling on a *lot* more crap, too.
Sure, but it's fun to tweak the zealots. Me? I do assembler (don't care
what) and VHDL. But I don't do much programming, per se. C ruined that fun.
One of our embedded programmers left a year ago to join the FBI. They asked
him whether he wanted white-collar or counter-terrorism detail. He chose
It's not twisting anything. The fact is that we *are* producing more than
ever, albeit with a smaller percentage of the workforce. Since more people
are doing non-manufacturing work, this is expected. COmpanies are off-shoring
because they simply can't afford to hire people here, and it's not only
because they want too much money. Our government forces the issue.
Prestowitz' article has a lot of holes in it.
No, skeptical means you're still looking for the strings. ;-)
Not really. Ford was on the ropes a short couple of years ago but did get
some concessions that GM didn't get. Why? ...if the government is going to
hand the keys over to you.
That's exactly what it was. Unions colluded to strike one company, forcing it
to knuckle under. If the companies had done the same they'd the bosses would
be in jail.
My father would never have worked in a union shop. Neither would I. They're
Unions aren't part of manufacturing? You whine about management, but want the
poor unions left alone? <yikes!>
Sure. I've talked about government policy as the other shoe.
Wouldn't touch one, particularly now. I had one, hated it.
That's funny. The appliances I've bought in the past couple of years were
made in the US.
I'll bet the processors were.
Few are. Some are surprising, though. I just bought a router lift, made in
We still are the #3 exporter of manufactured goods. The balance of trade is
horrible primarily because of fuel imports. Nothing will be done about that,
other to than put us deeper into a recession.
Everything *YOU* buy is made elsewhere.
At Lowes, in fact.
Certainly you have a choice. You don't even take it when it's offered.
So, you write a long screed, much of it in error, and run off? Whatever.
By what measure? Unless it is in a nonprofit or academic setting, one
could say that _everything_ is business related since that's what
companies are about.
OTOH, if one is talking of either LOC or other measures of actual code
generation, I'd venture direct financial or business applications still
remain a subset.
What one really shouldn't do is to make rash assertions w/o some basic
knowledge of the area at all.
"Theoretically possible" doesn't come even close to equating to
"easily". I would venture that you're not even aware that there is
still active development of the Fortran Standard and modern features
continually being added to the language that include object-oriented
features, etc., etc., etc., ...
What Fortran has that none of the alternatives you've mentioned have is
support for vector processing and other features suited to massive
computing that are simply not amenable to the models you've outlined nor
are there suitable compilers for much of the hardware used in those
computing environments of the type. If you were to take and try to
accomplish the computation in a fashion as you've outlined above,
besides taking orders of magnitude longer to develop you'd find that it
wouldn't have adequate performance to be of any use in the end, anyway.
By "business" I mean business transaction processing, and the
"non-scientific" internal business needs such as accounting, planning,
projections, inventory, payrolls, etc.
It would take a library books to lay them all out, and though I've run
across many of them, I'm far from an expert.
The only measure I used, and the only one I know of, is demand for
programmers and analysts, in my experience only.
I spent about 15 years with CGA and CTG, big programmer body shops.
We also did project work, but it was mostly providing bodies.
And I knew folks in other big outfits, like EMS and smaller.
Sometimes I was in management and a lot of reqs went through my hands.
I say "sometimes" because I always worked as a programmer or analyst
at a client site, but had "management" responsibilities as a field rep
and moved around quite a bit.
Suffice it to I never saw a req for a Fortran programmer.
Not saying there never was one.
I left that to take a staff position with a client about the time we
were getting reqs for C ++, late '90's.
Of course I'm near Chicago, with a lot of business corporation HQs and
processing centers, so I understand my view is skewed.
That's why I said "guessing."
Bell Labs and Argonne are nearby, but I don't recall ever serving
My brother worked at Bell Labs and told me the language he was using
for switch design was proprietary - don't remember what it was called.
He's an egghead with various engineering and CS Masters degrees.
I suppose engineering types like my brother and son just use whatever
language serves their math needs.
Business uses relatively simple math and is mostly processing simple
but massive amounts of transactions.
Anyway, I knew all the big business programming shops in this area and
the approximate size of their programming staffs.
It was a massive number.
I'm sure Silicone Valley, NASA and others have quite different overall
Just going by my experience, that's all.
Anybody else can relate theirs.
I don't know. Like I said, my only measure is bodies doing
LOC is meaningless. I can code a "Hello World" in one line or a
What I do know is every time I make a move with
my CC or bank or cell phone that movement gets processed
by millions of lines of code by the many business applications I
OTOH I'm a gamer, and my games use what I assume is advanced vector
processing, and I probably execute more instructions playing games
than my financial transactions create.
I sometimes read the "programming staff" scroll after a game.
Not many programmers at all.
All kinds of ways of looking at it.
Ok, I take "easily" back.
Yes, I was aware that Fortran continues to add to the package.
Also know that there has been some implementation of COBOL OOB.
And that there are still plenty of RPG AS/400 apps out there.
I really thought RPG would be gone by now.
I coded some, and found it atrocious using a transparent plastic
template as an aid in coding.
But it's still with us.
Then again I was always happy that I would be out of IT before Y2K
rolled around. I was wrong on that projection too.
I googled a bit and it looks like most video games - which use vector
processing - use C ++.
Also new hardware architecture provides vector support.
This is all above my pay grade.
I don't care if Fortran guys argue with C++ guys.
You can google those arguments.
Very few people care that Fortran might crunch the numbers you need in
10 minutes while C ++ takes 10 minutes and 6 second - or 12 minutes.
Usually just accurate results with available programming skills win
I dealt with relatively simple but massive business apps.
I found long ago that unless it affects the work at hand it's
pointless to argue about language.
Since hardware speed improvement allows what is commonly called
"bloatware," the language's user interface and maintainability is
often more important than efficiency for most processing.
Otherwise most code running would be BAL or its platform equivalent.
I heard of one large business CICS app in my area which was converted
from BAL to COBOL, then they had to reinstall the BAL app because the
COBOL was too slow.
Don't have the details. Might have been all BS propagated by an
On my first IT job I was chastised by the boss - an old BAL programmer
- for putting the open/close files routine out of the way at the
bottom of the program. They were running an IBM 370 model with VM.
Just did what I was taught in college - structured instead of
He said it might cause paging in the CPU memory segment.
I tested it both way, and there was no difference in CPU utilization
time, but I didn't tell him, just followed his suggestion.
His criticism was useful though, because after that I looked hard at
anything that ran long, and earned some kudos for it.
Won't bore you with details, and you probably know that CPUs are
frequently overtaxed by bad coding or flawed processes.
That first shop still preferred you eyeball - desk check - your code
for syntax/spelling errors instead of running it through the compiler.
Got your knuckles rapped for too many compiles.
Really backward in that respect. They had plenty of juice.
But most of management and programmers had teethed on 360's.
Things change. In the business world I went through the transitions
from BAL to COBOL, ISAM/VSAM files to IMS and DB2, then OOB and
There were many unmentioned languages in between.
Now, except that SAP is the "big boy" commonly used at some outfits,
and there are plenty of COBOL apps still running, I don't know
I'm retired. The headhunters even gave up on me.
Do still have a mild interest in what's happening though and still in
limited contact with the business.
And I still have my prejudices and what I think are sensible views.
One of those views is "use what works best for you."
I don't want to argue this stuff, just chatting.
Only know what I know. IT moves fast and has passed me by.
And I never was involved on the "scientific" side of it.
It was mostly just how I made a living. I was never highly technical
or one to make up computer jokes.
Just knew enough to be successful at it, and I'm happy at that.
My real loves were always women and beer.
Haven't heard you relate one iota of experience in the field of
programming, or any numbers, so maybe you're not the best one to be
telling me what to do or not do.
In COBOL I would code that as FUCK-YOU in working storage.
No you haven't heard.
40 years, BSNE, MSPhys(NucSci)
20 years eng'g code maintenance/development w/ various organizations
beginning w/ nuclear power generation design codes on mainframes (Philco
2000 series followed w/ CDC 6600/7600/Cyber w/ FORTRAN 66 thru Fortran
F77 in conjunction w/ Philco assembler and CDC Compass as required).
From there to 20 years as consulting for various clients from field of
robotics and man-replacement equipment and instrumentation for nuclear
utilities to evolving to support in I&C R&D for fossil utilities.
Not that it's any of your business.
I think so, too, any more... :) I returned to family farm when Dad
passed away about 10-12 yr ago, now...continued consulting w/ EPRI (aka
Electric Power Research Institute) which had been primary customer for
several years at their I&C Center located at the Kingston Fossil site
(TVA, west of Knoxville, TN) altho was also doing some work for CSI on
products for them thru which I was running the consulting work while
technically an employee in the new products engineering group (had just
released the wireless accelerometer product line to manufacturing the
month Dad passed away which you can look up for an idea of it altho it's
modified significantly in the 10 years hence). While most work over the
years was proprietary or internal R&D that doesn't have directly
referenceable material, another product after the switch from the
commercial nuclear to consulting was the software for a predecessor of
the Remotec ANDROS robot that you can find quite a lot of info on the
current products. The incarnation I worked on was a combination of the
base vehicle w/ a manipulator arm and instrumentation package for
man-replacement purposes in nuclear generating plants and was
Westinghouse-purchased for use in some of their units in S Korea. This
was while Remotec was still privately held by its founders (from ORNL
there in Oak Ridge) several years before was purchased. (Showing my
age, that version consisted of an onboard VME-bus two-processor 68000 w/
another operator console system w/ only a single processor. The system
ran under CP/M w/ the operating code all LMI Forth. That was my first
consulting job on own w/ one other fella' nearly 30 yr ago, now.)
I've several technical reports on models and evaluations of reactor
safety and primarily incore instrumentation which was my specialty area
outside the code maintenance (I was/am, after all, primarily an
engineer, not a programmer despite almost continuous involvement in
code-related work) while at the commercial reactor vendor. These are,
however, not of much general interest altho a couple of the papers
presented at ANS annual meetings did end up being referenced in a major
textbook on radiation detection and instrumentation which was kinda'
I won't pretend that discussions on statistical analyses of samples of
reactor containment vessel material evaluation for radiation-damage
lifetime extensions of their concomitant reactors is a worthy subject
for a.h.r so won't provide any report numbers of them or similar work... :)
Similarly, the evaluations of the nuclear design codes in comparison to
physics startup measurements at the Oconee-class reactors submitted to
and defended in front of the NRC ACRS for final licensing approval to
allow power operation is somewhat esoteric and rather dull for those
outside the field...
The more recent stuff is all pretty much tied up in EPRI owing to their
licensing agreements and can't say too much about it. The last major
task was development of technique for measurement of pulverized coal
mass flow rates in individual pipes (typically 14-20" diameter) to large
power boilers using advanced nonlinear signal processing techniques to
infer the flow from the non-stochastic but chaotic (look up Lorenz
attractor for the idea of non-random but non-repetitive processes)
turbulence noise in the pipes as picked up on a high-frequency
Anyway, enough geezer talk...
I have some understanding of the work you've been involved in enough to
know how important it is to the safety of nuclear plants especially when
it comes to predicting failure of the infrastructure. Tell me if I'm
wrong in assuming that some of the testing involves actually sort
of listening to the pipes to ascertain the condition? A good pipe has
a particular (sound) or characteristic reaction to fluid flow when it's
in good shape? I've worked with vibration sensors to monitor bearings in
chiller plants before so the early signs of failure could be detected
and equipment could be shut down and repaired before a failure
could cause catastrophic damage. I'm also wondering about the types of
failure that could be caused by high pressure, high velocity fluid flow
in pipes in a plant that's running 24/7? You mention turbulence so I
guess cavitation would be another concern? Do the high frequency
vibrations cause stress fractures in the metal of the pipes, flanges
HomeOwnersHub.com is a website for homeowners and building and maintenance pros. It is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.