FEM Analyst or Developer? 1

[jacksonfem]

I have the oppurtunity to work for a company that develops a Finite Element Solver. I must choose between the next two:
1) Programming of FEM method etc, with C, C#.
2) Performing analyses to check if the solver works properly.

I have worked as a structural engineer, 10 years now, where I have performed FEM structural analyses with softwares such as SOFiSTiK, SAP etc.
From advanced FEM softwares, I have worked with NASTRAN, on static, dynamic, nonlinear (material-geometrical), contact analyses etc. Essentially,
I have done something like the second opportunity, from above. It's something that I like very very much.

If I follow the second opportunity (performing analyses), I will do what I know to do, bit in a more advanced level of course.

If I follow the first opportunity (developer), it will be something new to me. I don't even know programming.
Beside I know very well to perform analyses with FEM, I know very little from FEM theory. But I know very well Strength of Materials, Statics, Dynamics etc.
In the other hand, I 'm very interesting of how these things are programmed (element formulation, analyses methods, newton-raphson, arc-length etc.)

The thing is this: I don't want to lose the "engineering of the whole thing", in case I go for a FEM developer. I have heard that FEM programming, is 90%
programming and 10% engineering. There is no opportunity to do both developing and perfoming analyses. I don't want to be "transformed" in a developer/mathematician and leave behind engineering.

I would like to tell me your opinions.

 

[MacGyverS2000]

I hope you have serious supervision and code reviews if you go with route #1... I would hate to see something as critical as FEM software written by a non-programmer. Knowledge of what FEM does is good, but not understanding the algorithms nor how to implement them in code provides entirely too many opportunities to royally screw something up.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[IRstuff]

I don't even get the first "opportunity;" dumping someone who doesn't even know programming into a job that requires fast, efficient, operational code just doesn't make sense.

I could see it, however, if the first job were to create algorithm description documents and simulations that the coders could base their code on.

TTFN
I can do absolutely anything. I'm an expert!
faq731-376 forum1529

 

[drawoh]

I hope you have serious supervision and code reviews if you go with route #1... I would hate to see something as critical as FEM software written by a non-programmer...

I am not the expert here, but I would prefer that finite element code to be written by structural engineers who understand the structural engineering theory. They should code in a language they understand, like Fortran, if necessary. Does the C[ ]programming language even do powers yet?



--
JHG

 

[MikeHalloran]

My own experience suggests that C is really good at catalyzing bugs,
and at hiding them,
but not good for much else.



Mike Halloran
Pembroke Pines, FL, USA

 

[IRstuff]

"but I would prefer that finite element code to be written by structural engineers who understand the structural engineering theory."

Well, wait until your simulation takes a day and half to run, when it could have taken 20 minutes, and you'll see why that was not a good solution. It's the algorithm that makes or breaks the theory, not the code, per se. So long as a solid algorithm is adequately documented and presented, the coders can do the thing they're best at.

TTFN
I can do absolutely anything. I'm an expert!
faq731-376 forum1529

 

[MacGyverS2000]

I am not the expert here, but I would prefer that finite element code to be written by structural engineers who understand the structural engineering theory.

I don't disagree... but that assumes the structural engineer knows how to program. If he doesn't, that is going to be truly awful code.... bug-ridden, slow, etc.If I could only choose one skillset, it would be programmer. The non-structural programmer can implement any algorithm given to him, with sufficient description, even if he doesn't understand it... the non-programming structural engineer can't do the reverse.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[jacksonfem]

Well...the engineer, will first learn how to program and then will go on with the developing of the code. It's easier for them to learn an engineer to program, than to learn a programmer engineering.

So, I would like to learn from you if the programming, after some time becomes boring? May you 'll be lost in coding and coding and a very little of engineering? Does anybody have done both things?

 

[drawoh]

MacGyverS2000,

Anybody so specialized that they can do only one job, probably is useless. I would hope that an FEA developer would be an excellent structural engineer, and a competent programmer. The whole point of user friendly computer languages is that the code is understandable by a human who needs to understand the problem being analyzed. A lot of the literature on FEA was written back when processors were way slower than they are today, and we had to optimize code as per thread769-296406.

--
JHG

 

[IRstuff]

While computers have become much faster, so has the complexity of both the programs and problem sets. Windows used to reside on well under 1GB on the HD; it currently takes 51GB. Of course, much of that is to retain ALL the installation files from EVERY installation EVER, but still...

Time is still money, so slow programs still cost the user time and money on a contract. Moreover, while the structural engineering is critical for the algorithm development, 90% of your time will be spent on programming, debugging, etc. From there on, there's unlikely to be that much SE involved with code maintenance and upgrades. It's highly unlikely that you'd be writing a simulator from scratch more than once every 10 years, although you might be adding features or modifying routines on a regular basis.

TTFN
I can do absolutely anything. I'm an expert!
faq731-376 forum1529

 

[MacGyverS2000]

Anybody so specialized that they can do only one job, probably is useless. I would hope that an FEA developer would be an excellent structural engineer, and a competent programmer. The whole point of user friendly computer languages is that the code is understandable by a human who needs to understand the problem being analyzed. A lot of the literature on FEA was written back when processors were way slower than they are today, and we had to optimize code as per thread769-296406: The Story of Mel.

Your hopes are just that... being an engineer of any sort does not guarantee a quality programmer. Newbie programmers always make HUGE mistakes that can have subtle faults, it's part of the learning process. Been there, done that... I once had a bug in some C code that I didn't figure out until years later when I pulled it back off of the shelf after having gained more experience (missed a semicolon, drastically affected how the program ran, but it compiled without error because it was syntactically correct).

"User-friendly" languages also do not guarantee good code (nor bug-free code), they merely allow someone to get into it more easily by hiding a lot of what goes on behind the scenes. The more "user-friendly" a language is, the slower it is bound to run. Being human-readable doesn't mean bug-free, either, and it's typically an inverse to speed.

I'm a sparky, through and through, but I've been a firmware coder (assembly, Cobol, Pascal, C, C++, C#, etc.) for 35 years. I have interviewed countless self-proclaimed "programmers"... being able to write Java script, playing with a Raspberry Pi on the weekends, etc. does NOT make a programmer. I love it when people take an interest in programming, and I'm happy to help them wherever possible. But to throw a non-programmer into a programming job and expect quality code without several years of hitting that compile button over and over is a recipe for an over-budget project that has no useable material at the end of it. I could sugarcoat it, but that would be a disservice to all involved. Agree with me or not, that's up to you, but I'm speaking from the trenches on this one...

Dan - Owner

http://www.Hi-TecDesigns.com

 

[jacksonfem]

MacGyver,
of course an engineer is not a programmer. But also, a programmer is not an engineer.
So, the question is:
Is it better to learn a programmer engineering, or an engineer programming?

The engineer who can program, it's better from a developer who programming FEA, just by put down the equations providing in books, without knowing what is FEA.
I believe the next:
Understanding basic FEA, needs huge amount of engineering knowledge.
Understanding basic programming, it's a bit easier I think.

 

[IRstuff]

The issue is that simulation tools require fast execution, which requires knowledge beyond basic programming. A decently written algorithm description document does not require knowledge about the physics underlying the algorithm. While optimizing compilers can make up for a lot of sins, a rat's nest program might compile into something tolerable, it won't be maintainable. So, who's more likely to produce fast, maintainable, code?


And, if you're that good at the algorithms, will you stay good and stay interested, re-writing and maintaining code you wrote 4 years prior?

TTFN
I can do absolutely anything. I'm an expert!
faq731-376 forum1529

 

[MacGyverS2000]

jackson,

I covered your question already... there's no reason to teach a programmer engineering, just provide him with a proper description of the problem and the algorithm to use. You're basing your argument on a faulty premise, that good programming is easy. It's not. A 6-year old can program, given the correct language (like LOGO)... but that program will never be very complex, it definitely won't be fast, and when you try to improve on either of those two elements, the non-programmer is going to screw it up royally.

Nothing is stopping you from learning to program... but you're doing yourself a disservice if you think you'll be able to jump into complex software design with little more than a Programming for Dummies book and a few months of tinkering.

Not much else I can add to this one...

Dan - Owner

http://www.Hi-TecDesigns.com

 

[KENAT]

If we can make Engineers do their own drafting and admin work why not their own programming?

Posting guidelines faq731-376

http://eng-tips.com/market.cfm?

(probably not aimed specifically at you)
What is Engineering anyway: faq1088-1484​

 

[MikeHalloran]

KENAT, I did that. Seriously; I needed someone to write stuff to move stepping motors, and the IT department had a ten year (!) backlog, so I taught myself.
... by reading a lot of other people's code, and
by writing a lot of bad code myself.
I took about a year for me to feel at all confident,
and it took about three years for my code to justify any confidence at all.


Mike Halloran
Pembroke Pines, FL, USA

 

[drawoh]

MikeHalloran,

When you wrote the stepper motor code, did you assume infinite acceleration, or did you account for the acceleration of your inertia load up to speed?

I know a lot of about optics now, none of which was taught to me in college. Unless you are designing stuff for other mechanical engineers, you need to understand what your co-workers do as well as your end users.

--
JHG

 

[drawoh]

MikeHalloran,

I offered to write code once, but they did not take me up on it. I had just designed a differential gear mechanism with two encoders. I spent quite a lot of time hunched over a spreadsheet figuring out a functional gear ratio. On start-up, we had to read the encoders to figure out the absolute position. Since there were only 825 discrete outcomes, I would have written a C[ ]program that would have written a table to a header file to be [tt]#included[/tt] with the official program. It would have run at build time, not as part of the deliverable, so speed did not matter.

I never saw the actual code. They figured it out by studying my spreadsheet.

--
JHG

 

[MikeHalloran]

drawoh,
I studied all the stuff from Gauthier and Taft at UNH, where you predict the us timing of the first few steps to accelerate a stepper to max speed in four-ish steps for maximum performance, as in moving say, a disk drive head.

I never made use of it. The inductance of a stepper's coil severely limits the max speed. For example, the typical size 24 stepper will get to ~1000 steps/sec at rated voltage, and maybe ~2000..3000 steps/sec with a dual voltage driver.
That sounds like a lot, but there are a lot of steps in a revolution, so the RPM doesn't get very high.

... Which doesn't mean they're not useful.
You don't have to go crazy controlling the load inertia, but you do have to pay attention, at least to the first few gear passes. Basically, if the load doesn't move in 1ms, the stepper will be unable to move it.

The fastest system I did, would direct drive a Hamilton valve (tiny TFE plug valve) 1/4 turn in 50 ms, which is almost too fast to see. I think it was ramped up and down from a fixed starting speed that was determined by experiment.

{
The experiment to determine a starting speed ramped a motor and load from 1 step/s upward until it began losing steps.
As it swept slowly past ~4Hz, the floor resonated, and the machinists downstairs all ran up to see what the hell I was doing. I had to run the sweep again in their presence to convince them that the tiny apparatus on the table could induce that much vibration in a building.
}

I was using 8741 uCs then. No multiply instruction, but it didn't matter; I maintained a delay counter and a (delay x 32) counter, so a ~3 pct per step speed change was just an increment and a little bit shifting.

For another job, I used an 8080 SBC, using an 8253 for precision timing of a motor geared 180:1 to run a camshaft at 1 rpm.
After the start of each step, for which I wrote one of four values to an output to start changing the motor position, I calculated a new value to load into the timer later, did some housekeeping, and waited for an 8259 PIC to tell me that the timer had timed out, at which time I started the next step. I never did figure out how to use the 8259 with 8080 interrupts, but I was pressed for time.

The inner loop amounted to seven pages of assembler code, with high level and human interface stuff done in FORTH.

The camshaft had a 1 bit encoder to mark a 'home' position. The motor had another 1 bit encoder, and there was a little code to rock the motor back and forth to find the edges of the cam home position sensor and stop the cycle in the center of that range for consistent restarts.

... and that's probably more than you wanted to know. Sorry.







Mike Halloran
Pembroke Pines, FL, USA

 

[FeX32]

I have seen this above issue before. I agree that for commercial FEM software, it MUST be programmed by a professional programmer. Anything less than this and the software becomes garbage.
Of course, the same applies to the engineering. The software would also be garbage without a professional engineer delegating the physics to the programmer.
It is possible to have 1 engineer do both. But this is very rare and still needs the years(and edu) of both engineering and programming under the belt.

As a side note, I had the luck of working with someone that did both. He spent 15 years doing the simulations and developing the custom (one of the many) software we use in house. Programmed everything himself and developed the physics.
Mind you - while the engineering inside is good, the programming is only decent even after all these years. Compared to commercial software it is not even close to being as "user friendly".
An mind you, this guy is an extremely intelligent engineer... on a different level than the average engineer.