MétaCan
Menu
Back to cohort
Record W1898516576 · doi:10.24908/pceea.v0i0.3826

INTEGRATED ARCHITECTURAL DESIGN: THE ROLE OF SOFTWARE IN COLLABORATING WITH ENGINEERS

2011· article· en· W1898516576 on OpenAlex
Thomas M. Seebohm

Why this work is in the frame

A frame that forgets how it found something cannot be audited. These are the routes that admitted this work.

affAt least one author lists a Canadian institution in the pinned OpenAlex snapshot.
venuePublished in a venue whose home country is Canada.

Bibliographic record

VenueProceedings of the Canadian Engineering Education Association (CEEA) · 2011
Typearticle
Languageen
FieldEngineering
TopicArchitecture and Computational Design
Canadian institutionsUniversity of Waterloo
Fundersnot available
KeywordsEngineering design processProcess (computing)SustainabilityInterior designArchitectural engineeringEngineering managementEngineeringDesign processComputer scienceKnowledge managementWork in processOperations managementMechanical engineering

Abstract

fetched live from OpenAlex

With the increasing importance of designing for sustainability, that is, to leave the environment as least as good or better than before a design intervention, designing holistically is essential. By holistic design is meant a process where all issues ranging from the physical, such as energy consumption and lighting, to social issues, such as how spaces are used, are addressed, not just metaphorically, but in a rigorous and rational manner based on analysis. The traditional approach would have the architect call on engineering specialists at some stage in the design resulting in a number of problems that prevent holistic design. Among them are the following: 1) the difficulty of revising a design to meet technical requirements once it is too far advanced, 2) the difficulty of communication between architects and engineers regarding design intent, 3) the complexity of contemporary projects having outgrown the capability of a single person, the architect, to coordinate alone, and 4) professional bias on the part of the engineering consultants whereby the consultants propose solutions without providing the architect with the full range of alternatives. A solution to these problems is Integrated Design understood as a collaborative design process whereby engineering and other specialist consultants collaborate with the architect from the very beginning of a project in a mutually supportive, creative and sharing environment. One of the best examples of a firm of specialist consultants practicing in this way is the firm Transolar in Germany, headed my Mathias Schuler. This firm specializes in climate engineering. In collaborations with Transolar all design participants, whether architects, engineers or physicists are considered equal partners in the design process. While Transolar’s collaborations are a success story in terms of the collaborative process and the wonderfully creative buildings that have resulted from this process, it is proposed that to make Integrated Design more effective in general, that architects become conversant in the many discipline-specific software packages that are increasingly available and user-friendly. Ability to use such software packages with their embodied discipline-specific knowledge will allow architects to explore technical possibilities on their own without consultant bias to better prepare the architect for consultant meetings and to be in a better position to talk the same language as the engineering consultants. The paper will review some of the specialist software currently available that the author has used and how this software can assist in the Integrated Design process. As well, implications for the education of the architect will be brought into focus.

Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.

Full frame distilled prediction

Teacher imitation

Not calibrated prevalence, not ground truth. Human validation pending. Learned from the 10,348 direct Codex labels and 10,348 direct Gemma labels. Candidate is the union of thresholded teacher heads; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels or direct frontier model labels.

metaresearch head score (Codex)0.000
metaresearch head score (Gemma)0.000
Version: codex-gemma-dda1882f352aValidation status: machine_predicted_unvalidated
Candidate categoriesnone
Consensus categoriesnone
DomainCandidate signal: none · Consensus signal: none
Study designCandidate signal: Simulation or modeling · Consensus signal: none
GenreCandidate signal: Empirical · Consensus signal: Empirical
Teacher disagreement score0.554
Threshold uncertainty score0.433

Codex and Gemma teacher scores by category

CategoryCodexGemma
Metaresearch0.0000.000
Meta-epidemiology (narrow)0.0000.000
Meta-epidemiology (broad)0.0000.000
Bibliometrics0.0000.001
Science and technology studies0.0000.000
Scholarly communication0.0000.000
Open science0.0000.000
Research integrity0.0000.000
Insufficient payload (model declined to judge)0.0000.000

Machine scores (provisional)

The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.

Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.

Opus teacher head0.005
GPT teacher head0.155
Teacher spread0.150 · how far apart the two teachers sit on this one work
Validation statusscore_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from it