How do you use programming in your daily work 4

[Christian_S]

Hey

The last year I've been doing a lot of hobby programming, as I really enjoy solving problems by writing code. My wish is to implement some programming in my daily work as an engineer. To get some perspective and inspiration I wanted to ask here what type of challenges you use programming to solve in your work, especially structural engineering problems and what type of language you prefer for these problems.

 

[IDS]

The short answer is "everything", but frequently used applications include:

Reinforced concrete design.
Generate FEA input for independent verification of an in-house analysis program.
Extract FEA results.
Generate design report graphics.
Generate arch geometry for checking clearances etc, and check handling and erection loads.

I also have Excel spreadsheets for frame analysis and continuous beams, but those are more hobby applications.

I do all my programming using Excel, using VBA, or these days with Python for some applications.

Have a look at my blog for examples.

Doug Jenkins
Interactive Design Services

http://newtonexcelbach.wordpress.com/

 

[Lomarandil]

I don't, primarily because I work in a team with other engineers who don't share common programming languages or adeptness.

Bring able to communicate and handoff work is more important in my world than the efficiency gains provided through programming.

We stick to Excel and MathCAD.

 

[Eng16080]

Basically, the sky is the limit with this. Beyond structural calculations, I've written software to draw steel shapes, create foundation wall sections, and generate structural notes within AutoCAD. I've used it to write proposals. Any task that is repetitive can be made more efficient with a custom program. In my case, programming might mean an excel spreadsheet, a standalone program written in Python, C*, C++, or something else, or even a custom AutoCAD command written in C++/ObjectARX or LISP.

I currently work for myself, so it's easy for me to create a tool and then immediately use it. However, as Lomarandil mentions, I can see it being a potential challenge getting an entire team on board.

I'd suggest trying to write a simple program to aid you at your engineering job. In my opinion, that's the real fun. I find programming overwhelmingly difficult at times, but when you finally get to the point that the software can solve a real world problem, perhaps something that would take you hours to calculate manually, it almost seems like magic.

 

[dik]

I used to program in half a dozen languages, but haven't done any real programming for 20 years. A lot of my programs were large (approaching 1M in source) and included FEM 3D and frame programs. My first frame program ran in 64K, by swapping floppies. Later, my favourite language was Delphi, but many of my larger programs were written in BASIC. Don't laugh, I preferred BASIC over C and C++ because it used the Microsoft Fortran math library and it was faster than the C and C++ one, and math stuff was a lot faster. This was essential for programming back with early hardware. I also used to use Assembly for writing many of my Subroutines and Functions. This was essential for speed. Also, I used to program in an oddball language called Forth... it was similar to the HP RPN language that used the stack architecture of the processor. It was very fast...

I design steel connections for metal fabricators, and almost anything that I will encounter 2 or 3 times, I write a small program to do the analysis. My current SMath folder has 885 files that I've written. I also use Excel for many of my programs.

-----*****-----
So strange to see the singularity approaching while the entire planet is rapidly turning into a hellscape. -John Coates

-Dik

 

[271828]

If there's no commercial program for a given need, then I'll typically make Excel spreadsheets. More often than not, these are ad hoc, and a lot of them do not get used repeatedly later on. I've generated a library of little "code" blocks that I can copy in to check this or that limit state, so I can build these quickly.

When I was in college, they taught us a lot of programming. This was right before there were commercially available programs for almost everything. I have done a little programming in the last few years in a "real" programming language. That hasn't become a mainstay because it's frankly too difficult. I don't do it enough to stay fast and good at it, so I end up burning multiple man-hours trying to do something I could to in Excel in 30 seconds.

Excel's plotting is painfully bad, so I have quite a few programs in a Matlab free clone for plotting. Works great.

I've programmed in Mathcad a lot over the years and have some pretty impressive worksheets. I detest the annual subscription, so I dropped it 6-7 years ago. I used Smath for about three years, but (call me paranoid if you want) I'm not making it a go-to because of the geo-political situation and potential malware. I never liked it very much anyway. Definitely nowhere near as much as Mathcad. It wasn't hard to let go.

 

[human909]

but many of my larger programs were written in BASIC. Don't laugh, I preferred BASIC over C and C++

Oh I'll laugh but I'll also bow down and give you respect! BASIC was my first programming language and I was a young tacker then.

I haven't really programmed anything for engineering purposes. I've done several Excel sheets for niche calculations that I do regularly in my line of work. I do find that my structural frame software covers and FEA covers most of what I need for steel. However as I move to residential timber I suspect I'll learn on Excel much more, I also have some inherited excel sheets for timber and a whole bunch of stuff. But they are clunkily written and half my energy will be spent trying to work out what they are doing so I can use and trust them.

I don't do it enough to stay fast and good at it, so I end up burning multiple man-hours trying to do something I could to in Excel in 30 seconds.

I hear you. Excel is the jack of all trade master of none tool. So many software engineers cry at they was they see Excel used inefficiently where programming/databases could work much better. But the reality is that Excel is easy to use and that is what is usually key.

there were commercially available programs for almost everything.

That is what I figure. I lean heavily on software as I've been in the industry for a shorter time than many of the older professions here. But I do pull out the pencil/MathCAD when needed to properly understand things, I did get a mathematics major back in the day so in theory I should be good a it .

 

[271828]

Later, my favourite language was Delphi,...

I didn't think I would ever hear the name "Delphi" again! I wrote some pretty nice programs in 1997-1998 in that, and enjoyed it quite a bit. I liked their Object Pascal.

 

[271828]

I hear you. Excel is the jack of all trade master of none tool. So many software engineers cry at they was they see Excel used inefficiently where programming/databases could work much better. But the reality is that Excel is easy to use and that is what is usually key.

Programming/databases could work better for THEM. LOL.

This might sound silly, but I usually steer away from "real" languages because of basic input/output. I could write the engineering calcs part about as fast, and way better organized, in the language than in Excel.

Example: One of my most common tasks is to sketch a detail for a steel connection not covered by commercial software, copy an image of the sketch to the top of the Excel spreadsheet, generate the calcs, and print to pdf. Setting up a good looking header, footer, and forcing good page breaks take seconds. I remember trying to make stuff like that look non-stupid in real languages -- it's not fast or easy.

 

[Aesur]

Honestly, no real programming in the sense of using programming languages, no need, we have tools for just about anything, why re-invent the wheel. I use excel and custom made excel sheets for many things, but this is just math in cells. To be honest, 90% of of engineering is done with simple tools like EnerCalc, few projects really need finite element modeling or custom programming.

 

[dik]

I'm not joking... BASIC used the MS Fortan math library, and C used the C math library. The Fortran library was much more optimised and a lot faster... and could be speeded up for matrix stuff by using specific Assembly language constructs. Back with the 8088, every bit helped. It became less significant with the 286 and was completely 'gone' with the 486... I have 2 or 3 BASIC programs with nearly a meg in source code... and used to control the hardware using Assembly... even wrote my own font tables... totally different time.

-----*****-----
So strange to see the singularity approaching while the entire planet is rapidly turning into a hellscape. -John Coates

-Dik

 

[dik]

It was my favourite programming language... I liked strongly typed languages. It had the ease of BASIC and speed... I don't know why it was not so popular. Another programming language I 'dabbled' with was also by Borland... their Prolog... fascinating language... and also, not very popular.

The BASIC I was using was the MS Professional Development System version, a full blown compiler, and made for large programs... not the GWBasic Interpreter that came with DOS...

I used to write a bunch of little 'knock offs' like the image attached. It was quick and very professional. Written 20 years back...

-----*****-----
So strange to see the singularity approaching while the entire planet is rapidly turning into a hellscape. -John Coates

-Dik

 

[IRstuff]

So, anyone remember Forth? ;-)

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert!

https://www.youtube.com/watch?v=BKorP55Aqvg

faq731-376 forum1529 Entire Forum list

http://www.eng-tips.com/forumlist.cfm

 

[dik]

IRS... From my first posting... This may be myth... but I recall the language was developed for observatory programming to do things in 'real time'... maybe an urban myth...

-----*****-----
So strange to see the singularity approaching while the entire planet is rapidly turning into a hellscape. -John Coates

-Dik

 

[Christian_S]

Thank you for the in depth posts, gave me some insights. What I enjoy most is when I code something I can share with coworkers to remove some of their repetitive and tedious tasks.

 

[OffshoreWindStructures]

The challenge in sharing with coworkers will be the human and IT policy factors rather than engineering or programming factors. To answer your questions:

>>> what type of challenges you use programming to solve in your work ?

>>> what type of language you prefer for these problems ?

Whatever engineering problem and code language my coworkers can handle interacting with and handle minor troubleshooting. Excel vba is more likely to succeed in this. Others often view python scripts or c# apps as blackboxes even when the code is readily available and so the potential of incorrect use or too much involvement on my part defeats the purpose. IT policy is also less likely to have an issue with excel that with installing python interpreters or c# apps on every computer.

If i do use "blackbox" scripts it's for something that others can confirm is correct by inspection or comparison after it's finished , such as generating analysis input files , taking results and formatting in a different software or printing out each step or a calc so people can sense check and have confidence in the numbers themselves rather than a hopeful confidence in me or my skills/competence .

Documenting/comments for every single line of code also helps make "blackbox" scripts less scary to others

 

[Eng16080]

Whatever language or tool you use to write software, you should spend a substantial amount of time testing it, especially if it will be used for engineering calculations. If I write a program to design a concrete footing, I'll look through every resource I have for footing design problems, and then I'll check the results of my program against that. For any critical piece of software (that I really don't want to be wrong), I assume that anything that is untested will fail.

Even if the source code of the program you write isn't readily accessible (or understandable) to others, as long as your methods are well documented (as noted in the post above) and you provide output for intermediate steps of your calculations, I think you can avoid the "blackbox" issue.

 

[dik]

I did all my coding at home on my own time, and it wasn't part of my 'job description'. I freely shared my programs with others in the office as well as elsewhere.

-----*****-----
So strange to see the singularity approaching while the entire planet is rapidly turning into a hellscape. -John Coates

-Dik

 

[sticksandtriangles]

To overcome IT work issues with installing programs and lack of awareness/overall intimidation of code by fellow co-workers, I would suggest making a website to host your code if you to dive head first into this.

You can look around for a few examples:

https://thestructuraltoolbox.com/

https://calcs.app/

I got a super beta concrete design tool on my website that you can check out.



S&T -

http://www.re-tug.com

 

[milkshakelake]

I generally wouldn't code anything unless it comes from higher ups. What might end up happening is a mishmash of code that only works for certain situations, that only one person in the office understands. In my previous job, I coded a bunch of stuff that nobody ended up using except me because nobody really understood how to modify it. I'm higher up in my current job, so it works well now and everyone uses the programs (not the code, because nobody else can code). It does need refinement of the code and listening to others about usability. For example, someone suggested to add better instructions and a button that automatically fills some values, so I did that. If a higher up isn't in charge of that process, they might see that back-and-forth as wasted time.