Thesis defense announcement

Addressing Cultural Factors in Mechanical Design

By Douglas Lee Van Bossuyt

Candidate for Master of Science in Mechanical Engineering

Oregon State University

Abstract

Mechanical design is often based on formal methodologies such as Quality Function Deployment (QFD). Techniques to quantitatively account for qualitative design factors such as attractability, sensory perception, and affective customer response have been successfully incorporated into these methodologies and are receiving growing acceptance across many industries. In today’s global economy, however, further work is needed to address the challenge of moving designs across cultural boundaries and facilitate the transfer of products to diverse and culturally distinct consumer groups.  This presentation describes one approach to quantitatively addressing cultural factors in the design process.

Monday, December 29, 2008

10:00 am, Rogers 226


osu-logo

School of Mechanical, Industrial, and Manufacturing Engineering

Combined Brayton – Rankine Cycle Analysis

Brenton and I wrote up a little report for our advanced power generation systems class with Dr. Peterson. He asked us to analyze a combined brayton/rankine cycle power plant and find the optimum configuration with a few parameters set. After futzing around with the code in Engineering Equation Solver, otherwise known as EES, we got a working model. Then we went a little crazy.

Instead of probing around manually using EES, we found that there was a wrapper to interface between EES and Model Center, a piece of software that is designed to explore trade spaces and can also find optimal designs on the side. Predictably, OSU had purchased the “commercial” version of EES rather than the “professional” version. This caused us some headaches because the “commercial” version is crippled. It will not accept command-line prompts which the wrapper for model center relies on.

Some quick thinking found a program called AutoHotkey that can inject keystrokes and mouse clicks into any program. A small script and some editing of the wrapper file, and we were in business. Albeit, it was a slow bit of business. Rather than running a few hundred iterations of the model in a few minutes, we could only run one per ten seconds because of the troublesome graphical interface that insisted on loading with EES every time the model ran.

After about a day of non-stop simulating with one of us babysitting the computer for the periodic crap out and explosion of EES, we had good data. All points indicated a convergence at one point. It was actually pretty darn efficient. We slapped the results and methods into a report and shoved it underneath Dr. Peterson’s door at about 2am the morning it was due.

The report is available in Microsoft Word format. Eventually I might put it on the site directly but for now, it’s an attachment only.