Here are some notes on a few of the most interesting points which stuck in my mind from our introductory conversation with Jane, Hugh, Axel and Roberts Klaschka and Woodbury on Monday morning; perhaps they can be of some use in the wrap-up today, and/or for later reference:
- Development cycles, shorter vs. longer – Axel pointed out that kitesurfing ideas are testable within days or weeks, while mono-/multi-hull sailing ideas typically take months or years to develop, construct and test and that kitesurfing has overtaken hulled sailing designs in a relatively short time, though was quite far behind. The lesson: spend less time designing before prototyping/testing/simulating, then redesign as needed.
- “Optimization” of sail construction as in molded (3D) sails with laminations and fiber placement targeting load paths at specific wind speeds and points of sail can be too restrictive in comparison with more flexible (stretchy) and thus versatile sails. Thus, designing for a narrowly constrained niche of conditions may carry an overall performance penalty in comparison with more redundant systems, especially when conditions are more volatile (changeable).
- Sail shape control via boundaries (e.g. halyard tension, cunningham to pull boom and foot of sail, running backstays to control mast bend, etc.) vs. possibility of more local controls (e.g. shape-changing battens, inflatable cells on sail surfaces …). Also the possibility of shape-changing not just aerofoil (sail) but also hydrofoil (mainly the keel – currently limited by and large to daggerboards, retractable keels, swinging keels, but curvable keel and other variations are also conceivable.) Bear in mind, however, the distinction between hard-to-control vs. easy-to-control systems (recall the crash video shown by Robert Woodbury) … thus, the number, type and arrangement of controls must be carfully considered – more is not necessarily better, nor is less … strive for a “sweet spot”.
- Data collection via observations and sensors at/from a single point (i.e. the boat’s own location) versus multiple locations (e.g. shared data among boats) and the dangers of information overload, or over-reaction by responding too frequently to fluctuations (e.g. calling too many tacks). Thus, again with information as with controls, more is not always better, if it cannot be processed rapidly enough and responded to with sufficient intelligence.
The last two points suggest that until automated/artificial reasoning systems become much better than they are at present, we still have to contend with the weaknesses (e.g. inconsistency, quantity) and strengths (e.g. making reasonable assumptions in the absence of actual data) of human cognition for decision-making about responding to dynamic phenomena, though automated systems can certainly help us visualize and gain insights to the data we need to evaluate. In dynamic conditions, one of the most important factors may be an ability to recognize patterns versus chaotic regimes of behavior (remember Robert Klaschka’s example of finding the wind shift cycles.) While the former allow a degree of predictive control, the latter require some balance of agility/responsiveness and a willingness to ‘ride out the bumps’, even though not knowing what’s coming next. Which leaves us with no easy answers in Designing (for) the Dynamic, and underscores the complexity for which yachting has been called the “sport of kings”, as Hugh pointed out at the very beginning (http://designingthedynamic.com/designing-the-dialogue/).
Greets again from Singapore and regrets at not having been able to get to Melbourne in person!
This is a work in progress, more content will be added soon
We have a mini wind tunnel with a fairly small throat, Vasari, Ansys, openFOAM and a big wind tunnel. What are the odds that they’ll give us results that are roughly the same? Will some way of testing give vastly misleading results?
Vasari is by far the easiest to use, but it’s ready made boundary conditions don’t seem to represent real life in any particularly meaningful way.
The tests demonstrate two models run in Vasari as a means of comparing the program against a physical model in the small wind tunnel and against the CFD results of ANSYS . One is a cube built within a box matching the dimensions of the small wind tunnel and the other is a cube with only a base built into the model.
From the results of the first wind tunnel simulation it is evident that the walls have a significant effect on the wake of the cube. The second test results have similar velocity solution to the tests run by Arup in ANSYS. The results are not as close for the pressure simulation.
Little wind tunnel
Big wind tunnel
blueCAPE are a company that make a few CFD tools for building designers. They’ve got a tool ( gbXML2STL Exporter) that allows you to export GBXML and then convert it to CFD ready stl files. They also make a cross compiled version of openFoam so that it runs in windows (which you can get around if you use my VM), but most interestingly they are about to release a wrapper around the whole lot that seems to make things nice and easy to do!
I’ve got a Ubuntu VM running openFOAM on my machine. If you install VirtualBox and you bring over a USB stick then you can have it too.
Axel Showed us the first sailrocket in his introduction
Designing the Dynamic, workshop and symposium, 21-25th November, Melbourne.