Re: Comments on developing pipe software.
For the three industrial pipe stress programs I've been associated with, the ratio of analysis code to User Interface (UI) code is very roughly about 10 or 20 times to 1, but takes considerably longer to write because the developer has to think about everything that a user can do wrong. At the analysis level, the majority of errors are already trapped.
UI"s today must often be graphical, and manipulating the often tremendous amount of data associated with a steam line, supports, and associated steel for example, in a graphical/textural fashion can be daunting on the variety of graphics devices available, i.e. 640x480 ... to ...
Nonlinear supports and restraints on curved pipe also provide some difficulties when starting with an existing FEA code. The public domain codes often don't include adequate boundary nonlinearities or spring design algorithms and require considerable up-front manipulation of the curved beam elements.
Then there's always the three parts of any business.
1) Producing the Product 2) Marketing the Product 3) Managing the Business
In my own small world, I find that engineers are often good at the first, think they're good at the second, and can't understand why it takes more than an idiot to do the third, ... but then I look at who's making most of the money.
Regards,
A. Paulin
> >Problem #1: finding the software, if it exists. It neednt be a piping
> >program; just one with a compatible I/O, database, processing format.
> This is the easiest thing. Plenty of simple FEA programs around. That can
> handle piping
>
> >Problem #2: finding members who have the time to commit and the
> >patience to wait for a usable solution.
> Harder, because the members who have the time may not have the necessary
> expertise.
>
> >Problem #3: Finding a coordinator to decide the architecture, split
> >it up,farm it out and then pull it all together again .
> Hardest. Deciding on architecture and needed features, especially people
> who don't know about programming, is a nightmare. Everyone wants
> everything and they want it now. You'll need to take a general
>
> >I am quite sure some clients would be absolutely
> >horrified to see the amount of absolutely erroneous crap such
> >programs can produce.
> The program produces what it's told. Crap production isn't limited to
> computer software. The best crap production comes from people trying to
> sell stuff. Nothing like combined ignorance and greed to provide super
> crap. You're right of course, but you deal with computerized crap like a
> chicken deals with a cow pie--sort the edible stuff out and enjoy... ;->
>
> >I was quite frankly appalled. Beautiful printouts, however. Apart
> >from the spikes, which apparently dont matter.
> So what do you do when you see spikes or static in instrumentation. You
> sort out what made tham, and why then you decide whether you ignore them
> or pay attention. Same for software ;->
>
> Christopher Wright P.E. |"They couldn't hit an elephant at
> chrisw@skypoint.com | this distance" (last words of Gen.
> ___________________________| John Sedgwick, Spotsylvania 1864)
> http://www.skypoint.com/~chrisw
>
>
>
>
> ========================================
> Discussion List sponsor: The fluid flow calculations website -
www.LMNOeng.com - LMNO Engineering, Research, and Software, Ltd.
> =========================================
> To leave this list, send a blank email to:
PipingDesign-unsubscribe@yahoogroups.com
> =========================================
> List home: http://groups.yahoo.com/group/PipingDesign/
> Main site: http://www.pipingdesign.com
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
Received on Mon Dec 15 15:06:00 2003
This archive was generated by hypermail 2.1.8 : Mon Oct 27 2008 - 20:24:02 EDT