Here's a message I sent earlier today to "another, related mailing list" which hasn't yet been approved by their moderator:
After all, the only proprietary bits about most software is the user interface; it's not like the underlying, basic calculations are protected by copyright.
Then again, that's just my thinking, and I'm not (currently) a Linux user.
Posts to this PipingDesign forum are never edited and only SPAM is deleted.
Paul
> 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
>
> ----- Original Message -----
> From: "Christopher Wright" <chrisw@skypoint.com>
> To: "?" <PipingDesign@yahoogroups.com>
> Sent: Monday, December 15, 2003 1:08 PM
> Subject: Re: [PipingDesign] Re: Stress calculation
>
>
> > >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 ;->
Received on Mon Dec 15 15:40:00 2003
This archive was generated by hypermail 2.1.8 : Mon Oct 27 2008 - 20:24:02 EDT