Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations KootK on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

Decision which Packages you will use 2

Brad805

Structural
Oct 26, 2010
1,493
I have been working on my python skills and have plans to make some tools for clients to use. I started with a simple truss problem from Engineering Skills (snip of below). I want to automate some design tasks, and now I am certain I can. The tools I want to create for our clients will speed up my role significanly. The guys I work with are tech savvy, but not program savvy. I was fighting to get some software to run one day and I got to thinking I should be careful which packages or add-ons I use to avoid problems for people that cannot solve the problems. Any tips on how you decide what packages you might use or is this just a problem one must deal with.

Truss-EX_akna12.png
 
Replies continue below

Recommended for you

I don't write in Python, so I don't have anything to add to this discussion, but this is one of the main reasons that I do not like python, anytime I look at python code it seems I just see a whole bunch of library references with very little actual work performed by the programmer, makes maintenance and reliability hard I feel.

Subscribing to this thread because I am quite curious what others have to say on it.
 
anytime I look at python code it seems I just see a whole bunch of library references with very little actual work performed by the programmer, makes maintenance and reliability hard I feel.

That might possibly be true, but the converse is that you completely write code from scratch and you'd likely be debugging the code ad infinitum. Additionally, Python has a community of users, so suggestions, errors, etc., are likely to be caught by other users, not just you.

Furthermore, I think that the rejection of "other people" writing parts of code that you incorporate is a slippery slope; I recall someone at work that thought that even C itself was a crutch and a "real" programmer ought to be programming in assembly language. While that's an extreme position, it does raise the question of where the red line is; do you reject math libraries, graphical display libraries, PDE solvers, etc.? Do you try and become an expert in everything? Would that even be productive; would you spend 90% of your time debugging code that isn't even actually solving your problem? Certainly, that's one motivation for just COTS software, since that allows you to concentrate on solving the actual problem at hand, rather than putzing with ancillary code modules.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529 Entire Forum list
 
  • Like
Reactions: dik
I tend to use mostly mainstream packages like Numpy and Scipy. It's a balance though one which I struggle with constantly wanting to figure things out on my own and write the code myself vs finding something pre built to utilize.
 
IRstuff, you're not wrong, I understand the sentiment, but I agree 100% with Celt83, I will generally only reference mainstream things. I will of course use System.Math or System.Drawing in C#, but I don't generally want to have to vet and trust a library stored if I am not auditing the entire thing.

Call me paranoid, but there is a certain level of trust that is required to pull any random library/package available online, feel free to reference any of the recent supply chain attacks. It's also quite popular to intentionally named a trojaned package similar to a popular package with the hope that the developer pulls the wrong one, but I'm getting side tracked here.

I recall someone at work that thought that even C itself was a crutch and a "real" programmer ought to be programming in assembly language.

Ha, I've never written in Assembly, but I used to strongly believe in writing everything in C, until eventually I got tired of it, felt that moving to a more modern memory safe language would be better, and I never looked back. So it's possible in a few more years, maybe I'll hop on the python package bandwagon?
 
I do not have the patience you do Celt. I think Opensees is a good option for me for the analysis. I am working thru a few simple problems still. The University types sure use it, but it takes some patience. The AI tools are quite helpful to sort out code issues.

I will stick to the common ones. There are a lot I have found on Github where the last entry was more than 10years ago. Umm, no, not a good plan. I did find one that was not working and after reaching out to the developer he did fix it.

ChorasDen, I did not look at any other programming options. In school it was Fortran. My IT guy suggested C, but I kept finding tech types talking about Python, so... There are a ton of routine tasks that need to be automated. I have sorted out how to extract the geometry needed from our models, and I can create input files for the various packages I need. No more manually measuring things my computer already knows the answer to.
 
The most common/best maintained python packages are what tend to come up when you search "How do I...?", so you whatever you're already using is likely fine. The issue I think you're trying to get at is how to keep your end users from having to independently download (e.g., pip install <package>). (this or wrong python version are the only two things that would likely prevent a script with otherwise correct inputs from running)

One way to achieve that is to use the same python version and distribution/package manager (conda, pip, etc) as your clients and not use any packages that do not come in the standard install-this does require you and your clients agreeing on some version, and you will get headaches if somebody updates by accident.
Another option is to include a simple script that checks for the presence of the needed packages and if absent, runs the appropriate install command.
A third route would be to include an appropriate install with all the packages needed with the script.

But the best way to make your scripts usable for your clients is to include good documentation (what inputs are expected, which are required, what version of python the script is written in...) and robust error handling with clear error messages. For example, run a check for the presence of the package you're using, and if it fails, output a message like "<package> not found. This script requires <package> to run. Please install <package> using your preferred python package manager, such as <example>". This can typically be achieved with a try/except block and a print statement.

If Jupyter isn't enough to let your clients avoid the command line, you may want to consider learning something like tkinter to create a GUI-I've noticed a lot of not-program-savvy folks panic a bit if they have to deal with the command line.
 
If you want to share Python scripts with clients, the easiest way is Streamlit, or Plotly Dash, or NiceGUI. Streamlit is very easy to make data apps and share with clients online. NiceGUI has options for creating a standalone executable. They all come with dynamic tables and graphing etc. Unless you're doing this as a hobby, I think making your own system is probably going to be a waste of time. Using these, you can make an app to share with clients within a few hours.

NiceGUI (probably the others) also has easy 3d rendered shapes so you can make models etc. They all have Plotly for graphs.

If you want traditional looking math, then using Smath and saving as an exe file is the best and can be shared. It will automatically convert it into a GUI where you can input variables, and when you print to PDF it will show the full math style output including title blocks etc.
 

Part and Inventory Search

Sponsor