Difference between revisions of "Exploratory engineering"
(→Low level vs High level: added wikitodo) |
m (→The problem with excessive over-engineering) |
||
(6 intermediate revisions by the same user not shown) | |||
Line 16: | Line 16: | ||
EE is remotely akin to an existence proof in math (using inequations). | EE is remotely akin to an existence proof in math (using inequations). | ||
Giving lower bounds on the possible performance technology in our universe independent of time (and space). | Giving lower bounds on the possible performance technology in our universe independent of time (and space). | ||
− | + | It's an indirect proof in the sense of a lack of a constructive proof by example in the physical realm. | |
It's a direct proof in the sense of a the existence of a constructive proof in the theoretical realm. | It's a direct proof in the sense of a the existence of a constructive proof in the theoretical realm. | ||
Line 266: | Line 266: | ||
* Given several points in possibility space identified by EE one sometimes can deduce the possibility of things lying in-between. Somewhat like a convex hull where one can interpolate in. | * Given several points in possibility space identified by EE one sometimes can deduce the possibility of things lying in-between. Somewhat like a convex hull where one can interpolate in. | ||
− | * It's called exp''' | + | * It's called exp'''lor'''atory and not ex'''tra'''p'''ol'''atory engineering which would make sense too - even more so perhaps. |
* The book [[Nanosystems]] is a (if not the) prime example for exploratory engineering. The concept of EE may have originated from this work. | * The book [[Nanosystems]] is a (if not the) prime example for exploratory engineering. The concept of EE may have originated from this work. | ||
Line 277: | Line 277: | ||
* By exploratory engineering methodology diamond has been chosen as a particularly difficult test-case for mechanosynthesis. <br>For details see go to the main page: "[[Diamond]]" | * By exploratory engineering methodology diamond has been chosen as a particularly difficult test-case for mechanosynthesis. <br>For details see go to the main page: "[[Diamond]]" | ||
+ | |||
+ | == The problem with excessive over-engineering == | ||
+ | |||
+ | Exploratory engineering is meant for identifying far-term-targets worth aiming for. <br> | ||
+ | The sub principle of conservative design can be applied to near term R&D too. But … <br> | ||
+ | Note that being way too conservative can lead to infeasible designs too because <br> | ||
+ | over-engineering to a ridiculous level may lead to system designs that are too hard to build early on. | ||
+ | |||
+ | To give a concrete example: <br> | ||
+ | [[ReChain frame systems]] while over engineered for | ||
+ | * efficiency (less energy turnover and friction for tensioning) and | ||
+ | * deflections from machine accelerations (not so for deflections from thermal motions) | ||
+ | * working at the macroscale lacking VdW forces too | ||
+ | are much more complex to build less over engineered than | ||
+ | * [[Flex-pretensioning dovetail or firtree interlocks]] or even more simple … | ||
+ | * Designs properly exploiting the [[Van der Waals force]]. <br>That is: [[Van der Waals force sticking]] (the best interlock is no interlock - so far no high force loads are expected) | ||
= Related = | = Related = | ||
+ | * [[Nanosystems]]: A work that is applying low level exploratory engineering (EE). | ||
+ | * Several talks to establish EE as a new epistemological methodology. {{wikitodo|Search them (videos) and link them here.}} | ||
+ | ---- | ||
+ | * [[House of cards]] – about a shaky stack of conclusions – that would be riskier high level exploratory engineering rather than low level | ||
+ | * [[Castle in the sky]] – about having a target without having a [[pathways|path]] | ||
+ | ---- | ||
* [[Science vs engineering]] | * [[Science vs engineering]] | ||
* Exploratory engineering can lead to a [[theoretical overhang]] in technology. | * Exploratory engineering can lead to a [[theoretical overhang]] in technology. | ||
* Somewhat complementary: [[The source of new axiomatic wisdom]] {{speculativity warning}} | * Somewhat complementary: [[The source of new axiomatic wisdom]] {{speculativity warning}} | ||
+ | ---- | ||
+ | * [[Conservative estimation]] | ||
= External links = | = External links = |
Latest revision as of 08:36, 28 August 2023
Exploratory engineering (EE) is the exclusively usage of well established knowledge in a fail-safe wasteful way to gain rough but reliable knowledge about the lower bounds of what is in principle doable. It allows one to probe the timeless potential of technology (in some high dimensional landscape of performance parameters).
Benefits of using EE:
Exploratory engineering is capable of identifying desirable technological targets. Guiding posts (big and small).
These targets are useful in that one can:
- first further identify spots where enough science has been done to move on to more targeted development (not part of EE) and
- then march forward there (also not part of EE)
The rules of EE are:
- strict limitation to established knowledge like: textbook physics - empirical knowledge
- usage of: standard modeling techniques
- exclusive use of: conservative engineering methodology
This forms a basis for reliable inference.
EE is remotely akin to an existence proof in math (using inequations).
Giving lower bounds on the possible performance technology in our universe independent of time (and space).
It's an indirect proof in the sense of a lack of a constructive proof by example in the physical realm.
It's a direct proof in the sense of a the existence of a constructive proof in the theoretical realm.
What EE does not answer:
- EE does not give hints how to get to the goals it identifies from the current technological capabilities.
- EE does not give hints about economic viability along the way.
"Easy" predictability of a technology does not imply that it is easily accessible.
- EE does say nothing about speed of development. It makes claims about the timeless potential of technology.
- EE does not predict any scientific discoveries. These are fundamentally unknowable.
- EE does not predict specific technological developments. (it predicts general targets)
- EE does not predict winning technologies.
Testability of EE and (un)testability of the associated paths:
- The theoretical work of identification of a goal via EE is of formal nature and can be rechecked and retraced by independent groups (as has been done in the case of APM (TODO: add ref) (and sometimes reached through various theory-paths)
- The existence of at least one physical development path leading to an identified goal is not something that EE can answer. This is a separate problem that EE does not deal with.
Chances for the existence of a path toward a goal identified by EE:
- One may judge chances higher to get to a target that is indirectly proven to exist (all results of correctly conducted EE are of this kind) than to a target that may not even exist.
- Parts of the results of EE can point backward pretty close to the current level of technology. More backward pointing ends => more chances for a path. (related: preparatory development, theoretical overhang)
- In case one has a good understanding of the goal one may be able to identify starting points for paths that are ready to begin targeted engineering. More forward pointing ends => more chances for a path.
Sources of confusion:
- Exploratory engineering is not a science (despite making theoretical predictions that are somewhat general). In most respects it is actually more of a polar opposite of science. (Keyword: "testability", more on that further down.)
- Exploratory engineering is not o form of engineering either (despite outlining products that are somewhat detailed). The similarities are strong enough though for EE to keep the term "engineering" as a part of its name.
Contents
Low level vs High level
One may classify EE in low level and high level.
- Low level EE is mostly directly built on first principles
- High level EE may use many previously attained lower level EE results and maybe even mix in stuff not so much EE drifting towards the less stringent field of feasibility estimation.
Nanosystems is mostly low level EE.
Note that as of 2018-07 the wikipedia page on exploratory engineering focuses entirely on high level EE.
The more unreliable type.
(wiki-TODO: give the examples of low and high level EE on this wiki)
Comparisons
Science vs engineering (in general)
Basic purpose
- science: provides knowledge – "What knowledge can we discover?"
- (conventional) engineering: provides products – "What products can we make?"
- exploratory engineering: provides knowledge – "What capabilities does physical law permit?"
Exploratory engineering is prone to be confused with (bad) science since instead of products (like engineering) EE provides knowledge (like science). Knowledge in form of predictions. Predictions that are difficult or not even yet possible to test experimentally. No less. (Reasons why this is ok in EE later). Hence the confusion with >bad< science.
Beside that a confusion of exploratory engineering with science is problematic because EE is much nearer to engineering in most other respects. For a prime example of some consequences of such a confusion see section "best knowledge" below.
Information flow
- science: physical world => model
- (conventional) engineering: model => physical world
- exploratory engineering: same as conventional engineering but just showing a target not the path leading there
Best models
- science: best descriptions (=)
- (conventional) engineering: reliable bounds (>=)
- exploratory engineering: very reliable bounds (>>)
Confusing exploratory engineering with a science leads one to assume that it tries to make exact predictions. And exact predictions are fragile. But actually one of the core principles of exploratory engineering is to strictly follow a conservative design methodology (meaning large safety margins - example: a cable holding ten times more than the nominal load) to make predictions. And such predictions are robust.
The robustness from large safety margins is one of the reasons why EE in contrast to science is allowed to make predictions that are hard to test or not yet testable without breaking down. At least not immediately. (Another reason is noted in section: "best results")
Exploratory engineering is somewhat like conventional engineering in this regard but not quite. (See section: "larger (design) margins" for details)
Best results
- science: surprising discoveries
- (conventional) engineering: predictable behavior
- exploratory engineering: (highly reliable predictions)
When one confuses exploratory engineering with science one is lead to think that EE tries to predict surprising discoveries. Which's impossibility should be obvious when stated this way.
But EE does not aim at surprising discoveries near the fragile outermost border of our knowledge. It aims at highly reliable predictions that are implied by the deepest most solidified core of our knowledge. Predictions of things where we just don't yet know that we already know them. The "unknown knowns".
While strongly connected in "knowledge space", results of EE are detached (often hugely) in "technology space". Which is one of the aspects which distinguish EE from conventional engineering.
The focus on the innermost most solidified core of knowledge instead of the outermost most fragile part as the basis for work is one of the reasons why EE in contrast to science is allowed to make hard to test or not yet testable predictions without breaking down. At least not immediately. (An other reason for that is conservative design methodology. More on that elsewhere. See section: "best models")
Best knowledge
- science: exclude all alternatives
- (conventional) engineering: know many alternatives
- exploratory engineering: (same as conventional engineering)
- Science is more of a breadth search for new and highly unpredictable phenomena.
- Engineering is a depth search for highly predictable working designs.
At every step one of the best understood and most likely to work choices is taken.
When one confuses what is actually an engineering problem (many options -> many paths) with a scientific problem (one truth -> one path) and one finds just one step in this one technological path to be obviously broken it can lead one to a premature judgment that there is no way to get to the specific (properly theoretically derived and thus here assumed to be sound) EE target in question. A judgment that the goal is just a "castle in the sky".
With an increasing number of starting locations and an increasing target-focus of them (from "starting fronts" with a weak general direction towards more concrete strongly directed starting points) the problem of reaching a goal set by EE increasingly turns from a scientific one to a engineering one. ("Scientific" not in the sense of the confusion outlined above! "Scientific" in the sense of the need for discovering more staring points not in the sense of the need for discovering points all along one single path).
In this regard one could classify targets identified by EE in:
- As weakly accessible perceived targets
few known starting locations towards the target predetermined by EE – still much science needed to start - As strongly accessible perceived target
many known starting locations towards the target predetermined by EE – engineering already possible to start.
Drawing a line where a problem switches from a scientific one to an engineering one can be hard. There's a somewhat contradictory regime in-between.
- untargeted science <> targeted science <> untargeted engineering <> targeted engineering
Note: "untargeted" means "few relevant paths known" and "targeted" means "many relevant paths known"
While "targeted science" may sound reasonable its mirror partner is "untargeted engineering" which does not so much.
Even in cases where no relevant paths are visible yet and it's really a pure science problem (not the case in APM!) EE may have some merit. Arguably less though. Some (fundamentally unpredictable) scientific discoveries may (with a big question-mark) unlock a path later. Or the EE might lead in an unexpected direction and identify a goal that may actually already have visible starting points pointing to it.
APM: In regards to paths towards advanced forms of APM there are more than plenty of starting points.
Unfortunately there is a bit of a dilemma here:
- People only put effort in looking for and finding some paths if they closely look at and understand the targets character.
- People only put effort in closely looking at and understanding the targets character if they look for and find some paths.
Organization
- science: independent groups
- (conventional) engineering: coordinated teams
- exploratory engineering: independent groups or even individuals
In science work is usually conducted in small independent research groups with little common goal. (If there where a very precisely specified common goal then reaching it would not be a discovery and thus not a goal of science). In science having no highly precise goal is normal and A-Ok since everybody is looking at the same whole (nature) and the randomly collected pieces will eventually fit together in one big unifying picture. A newly discovered law. A good analogy are the blind men and the elephant.
In engineering though there are gazillions of ways a product can be built. Instead of a single big picture where everything converges towards there is a ginormous design space where everything runs apart. Active effort must be invested (standard interfaces) to reach specified goals. As an analogy one could use automobile part makers that just make many individually working parts. But without planning in advance the parts will never fit together though.
When moving from an EE target that is easy approachable (meaning: many entry points to paths are already unlocked) to a point where the target actually gets started to be approached (meaning: one starts to take the first steps into the paths) then one meets the problem of moving from science to engineering. This can be a major pain point.
In regards to APM this is a major pain point. Most of the early work (molecular sciences) was done in a scientific setting. By now (2017)molecular sciences have accumulated loads of results (more or less by accident). Some of these results can serve as starting points for the path to advanced APM! At least for some insiders it seems that by now there are more than enough results such that a shift towards a more targeted engineering like approach is overdue.
The multi pronged problem though is that in the field of APM:
- The science side is reluctant to move to engineering. (difficult switch of operating culture from science to engineering) (active distancing to as stigmatized perceived fields).
- The (small) engineering side is strongly focused on the exploratory engineering side. (...)
What is missing is a conventional engineering side. What is missing is a shift from molecular sciences to molecular engineering using soft nanosystems to strongly target hard/stiff nanosystems (aka more advanced APM). Incremental path.
Conventional engineering vs Exploratory engineering
Basic constraints
- conventional engineering: manufacturing
- exploratory engineering: valid modeling
- In engineering there always has to be a physical design that you can manufacture.
- In EE there has to be design that can be modeled in a valid way worthy of the name "knowledge".
Since in EE there only has to be a modeled design and no physical product one might be led to not consider EE not as a form of engineering (enginnering in general) but instead consider it a form of science. Despite the fact that EE in most respects is much more near to conventional engineering than science.
Level of design
- conventional engineering: detailed specification
- exploratory engineering: parametric model
Concept illustrations can lead one to confuse exploratory engineering with conventional engineering.
This can lead one to critique that specific implementation details are missing. Common remark: "But this is not solved yet".
(Side-note: This refers to lack of details in the far off prediction. Not to lack of details of the path there. The path is a different topic.)
But it is important to notice that the things that are not worked out in concrete detail (atomistic details, concrete geometry of robotics, ...) are only the things of which it is known that they do not matter much. In other words the things of which it is believed that it should be straightforward to solve them.
In EE going into too much detail would actually be a fallacy.
- Too much details can shrinks design margins and consequently diminishes robustness of predictions.
- Too concrete designs are likely to diverge too much from what actually will be built.
There are at least two exceptions to the "do not get too detailed" rule of EE which can lead to critique when not understood:
- Sometimes instead or additional to a general parametric model it is desirable to give some overly concrete/specific example points. While those points by themselves feature excessive detail, they are chosen such that they lie as far apart as possible (at extreme locations) while still forming a continuum that can be interpolated over. This gives a big convex hull in possibility space that is by no means too concrete / specific. (Excessive concreteness is here meant not in the sense of cutting design margins but in the sense of reducing the likelihood down to pretty much zero that either exactly the example as is or a sub instance of the example will actually be implemented in the future.)
- In some areas the design space can be quite small thus the level of detail naturally seems high. Another way to put this is that what actually must not get too high is the relative level of detail which one could informally define as the absolute level of detail divided by the design space size (RLOD = ALOD / DSS). In some areas one can get quite detailed in absolute terms. Especially when using EE to work backwards to accelerate the process of closing the gap between current technology and proposed target.
Level of design in the context of advanced APM:
An example that seems to be violating the "avoid too much details" rule would be the preliminary design of crystolecules. Concrete designs of "crystolecules" could be considered to be too detailed since the chance of one of >exactly< these crystolecule designs to actually be built and used in massive scale is very low. (Except one builds a gargantuan library maybe. But there is no economic motivation for this. Except making it into a game maybe ... solving graphically pleasing puzzles has some recreational value after all). The reason for why an overly detailed implementation here was not a violation of the "avoid too much details" rule is (as dercribed in more general terms above) that there was the strong need to have at least some prototypical examples representing this general class of objects. Since instances of the general class of crystolecules are built in large scales when advanced APM is reached. (Its part of the definition af advanced APM).
The preliminary design and analysis of tool-tips for the mechanosynthesis of diamond and its polymorphs is a good (if not the best) example for EE where it is ok (and even desirable) to be highly detailed in an absolute sense.
The other way around the "poductive nanosystems" concept video is often criticized for a lack of implementation details in some areas where EE actually has very good reasons not to work them out in too great detail, because it would be fragile and useless guesswork. Of course there are "white areas" where indeed more detailed EE is possible and likely useful. Going a bit off-topic those "white areas" are sometimes overlooked (e.g. sorting pumps). Especially if they are not depicted at all in concept visualizations (e.g. microscale Vacuum lockout).
Main cost
- conventional engineering: production, operation
- exploratory engineering: design, analysis
Design margins
- conventional engineering: enable robust products
- exploratory engineering: enable robust analyses
Pushing design margins means more tests are necessary.
In regard to the number of tests needed conventional engineering lies in between science and exploratory engineering.
Certainty that a design will work (like required in exploratory engineering) is usually not the prime objective of conventional engineering. In conventional engineering the designs must always be almost right away physically manufacturable and the fine details need to be worked out before the deadlines in the project management schedule. To be competitive one needs to push the border of what is manufacturable. One needs to minimize cost and or maximize performance. Thus one often needs to steps into not yet well understood domains and consequently needs to occasionally create and do tests with prototypes (drifting towards science). Tests/experiments are necessary not quite as often as in pure science/research but still regularly needed. For conventional engineering there is an optimal number of tests per "development unit" that lie between the very many for science and the "zero" for exploratory engineering.
Larger (design) margins
- conventional engineering: raise costs
- exploratory engineering: lower costs
Example
A prime example of successful exploratory engineering in history can be found in the preparations for making low earth orbit and beyond accessible. For non-involved people without sufficient internal knowledge of the then present technological capabilities it understandably seemed lunatic to want to go to the moon. Turned out they where wrong.
Advanced atomically precise technology (APM) suffers from a similar situation. Thus one of the goals of this wiki is to provide such sufficient internal information in a way that's somewhat digest-able for the average scientifically interested reader.
Spacial analogy
Although we'll not be able to directly test it anytime soon we know with (for all practical purposes) certainty that on a planet far away in a different solar system of our galaxy stones will fall just the same way as they fall here on earth. We can know that with (for all practical purposes) certainty due to our possession of newtons (well tested!) laws.
Just as pretty certain answers can be given for questions regarding sensibly chosen questions about some isolated stuff that resides so far away in space that we cannot jet reach and directly verify it, the same can be done for sensibly chosen questions about isolated stuff that lies in the not so near future.
The here chosen spacial example may not be very useful. It just serves as an analogy for the temporal case where it is very useful.
Notes
- Manufacturing systems identified by EE play a special role since they form bridges from lower to higher capabilities.
- Given several points in possibility space identified by EE one sometimes can deduce the possibility of things lying in-between. Somewhat like a convex hull where one can interpolate in.
- It's called exploratory and not extrapolatory engineering which would make sense too - even more so perhaps.
- The book Nanosystems is a (if not the) prime example for exploratory engineering. The concept of EE may have originated from this work.
- A good translation of "expooratory engineering" to the German language: "erkundendes Konstruktionswesen". Really bad is "erforschendes Konstruktionswesen", this would translate to "researching engineering".
- The term "science" is used here more in the narrower sense of physical sciences e.g. excluding mathematics.
- By exploratory engineering methodology diamond has been chosen as a particularly difficult test-case for mechanosynthesis.
For details see go to the main page: "Diamond"
The problem with excessive over-engineering
Exploratory engineering is meant for identifying far-term-targets worth aiming for.
The sub principle of conservative design can be applied to near term R&D too. But …
Note that being way too conservative can lead to infeasible designs too because
over-engineering to a ridiculous level may lead to system designs that are too hard to build early on.
To give a concrete example:
ReChain frame systems while over engineered for
- efficiency (less energy turnover and friction for tensioning) and
- deflections from machine accelerations (not so for deflections from thermal motions)
- working at the macroscale lacking VdW forces too
are much more complex to build less over engineered than
- Flex-pretensioning dovetail or firtree interlocks or even more simple …
- Designs properly exploiting the Van der Waals force.
That is: Van der Waals force sticking (the best interlock is no interlock - so far no high force loads are expected)
Related
- Nanosystems: A work that is applying low level exploratory engineering (EE).
- Several talks to establish EE as a new epistemological methodology. (wiki-TODO: Search them (videos) and link them here.)
- House of cards – about a shaky stack of conclusions – that would be riskier high level exploratory engineering rather than low level
- Castle in the sky – about having a target without having a path
- Science vs engineering
- Exploratory engineering can lead to a theoretical overhang in technology.
- Somewhat complementary: The source of new axiomatic wisdom Warning! you are moving into more speculative areas.
External links
Wikipedia
- Exploratory engineering
- Epistemology
- Methodology – Note that, as mentioned on the articles talk page, this article still mainly discusses research methodologies excluding engineering and many other methodologies (state 2017-10).
- Field of study (discipline)
Multimedia
- Wikipedia commons graphic: unknown knowns
- Youtube channel "FHIOxford": Eric Drexler: Physical Law and the Future of Nanotechnology (2011-11-22) features some focus on exploratory engineering.