Skip to content

There Are Three Ways to Break, and Strength Does Not Decide Which ── Buckling Is Decided by Shape, Fracture by a Flaw, Yielding by the Crystal ── One Section of One Material Has a Different Limit Once Its Length Changes ── [Paper 262]

Aug 2026 · Zenodo (CERN European Organization for Nuclear Research)

Abstract

The sentence “the strength of this material is 250 MPa” does not settle when it breaks. This paper asks what does settle it──the answer is that there are three ways to break and a different thing decides each. Buckling is decided by shape, fracture by a flaw, and yielding by the crystal. No new mathematical theorem and no new law is claimed. Scope of this paper (scope note): No new mathematical theorem and no new law is claimed──Euler's buckling load, slenderness, Griffith's fracture condition and the yield stress are all standard. No mechanics of materials is built──what is used is three formulas and one comparison. No value fit for design is given──no safety factor, no initial imperfection and no residual stress is included. The numbers are for seeing which of the three limits is lowest, not values for design. The fence on the elastic constants is not treated──Paper 261 treats -1<nu<1/2. This paper is what happens after one is seated inside that fence, up to breaking. No theory of plasticity is built──yielding is treated as one stress value, with no hardening and no flow rule. No value of the surface energy is claimed──gamma=1.0 J/m^2 is a posited value, not a measurement on a particular material. It is used to see orders of magnitude. Fatigue and time dependence are not treated──only a single loading is examined. Griffith is not confused with another──the Griffiths appearing in Paper 173 is an algebraic geometer and a different person from the A. A. Griffith of this paper. Relation to earlier papers: Paper 261 wrote that what raises the fence on the elastic constants is the positive definiteness of the energy──this paper treats what follows, namely where a material seated inside that fence breaks. Paper 190 measured rare on a logarithmic scale──this paper likewise writes the effect of a flaw as a square root and in orders of magnitude. Paper 196 counted “pressure” as four different quantities──this paper counts that “strength” is not even one quantity. Paper 201 counted “complete” as four different claims──the same shape of roll call. What is added is computing that the buckling stress of one section moves from 164.3 to 18.3 MPa on changing only the length, putting the switching slenderness at the concrete value 88.8577, confirming that a flaw tells as sqrt1000=31.6228, and setting the three limits in one table and writing that the lowest is the actual limit. First, change only the length of one section. A square steel column of side 31.6 mm buckles at 164.3 MPa when it is 1 m long and at 18.3 MPa when it is 3 m──nothing about the material has been changed (Section 2). Second, this is the core of the paper. The slenderness at which the mode changes is lambda_c=pisqrtE/sigma_y=88.8577──slimmer than this and buckling comes first, stubbier and yielding does, so one material has its limit exchanged (Section 3). Third, the third limit is set by a flaw. By Griffith's condition a flaw of 1 mum gives 356.8 MPa and one of 1 mm gives 11.3 MPa (Section 4). Fourth, a flaw tells as a square root. A flaw 1000 times larger lowers the strength by a factor of 31.6228──which is sqrt1000 itself (Section 4). Fifth, the three do not compete. Of three upper bounds that hold at once, the lowest is the actual limit──and which is lowest is decided not by the material but by shape and flaw (Section 5). Sixth, so strength is not a property of the material. The number sigma_y=250 MPa is held, and a column 3 m long still breaks at 18.3 MPa──a factor of 13.66 apart (Section 5). the sentence “the strength of this material is 250 MPa” did not settle when it breaks. There are three ways to break and a different thing decides each──buckling by shape, fracture by a flaw, yielding by the crystal. The three do not compete, and the lowest is the actual limit. Triple the length of one section and the buckling stress falls to a ninth; admit an invisible flaw of 10 mum and the fracture stress drops below half the yield. For a column 3 m long the 250 MPa on the data sheet stands a factor of 13.66 above the real limit and never gets its turn. One thing separates them──writing down which limit is being counted. Write it down, and the occasions for changing the material separate from those for changing the shape and those for removing the flaw. Do not write it down, and one goes on looking for a stronger steel for a column that breaks at 18.3 MPa. On the making of this work: The ideas and content of this work stem from the author's own considerations. Assistance from an AI (a large language model) was used for structuring, English translation, and checking the algebra. Any remaining errors or misinterpretations are solely the author's. Feedback and corrections are sincerely appreciated. ----- 「この材料の強度は 250 MPa である」という一文は、壊れる条件を決めていない。本稿が問うのは、では何が決めているのかである──答は、壊れ方が三つあり、それぞれ別のものが決めているである。座屈は形が、破壊は傷が、降伏は結晶が決める。新しい数学定理も新しい法則も主張しない。 本稿の射程(射程注記):新しい数学定理も新しい法則も主張しない──オイラーの座屈荷重、細長比、グリフィスの破壊条件、降伏応力は、いずれも標準的である。材料力学を作らない──使うのは三つの公式と、一つの比較だけである。設計に使える値を与えない──安全率も、初期不整も、残留応力も入れていない。数値は三つの限界の大小を見るためのものであり、実際の設計値ではない。弾性定数の柵を扱わない──論文261 が -1<nu<1/2 を扱う。本稿は柵の中に座ったあと、壊れるまでの話である。塑性論を作らない──降伏を一つの応力値として扱い、硬化も流れ則も扱わない。表面エネルギーの値を主張しない──gamma=1.0 J/m^2 は置いた値であり、特定の材料の測定値ではない。桁を見るために使う。疲労と時間依存を扱わない──一回の載荷だけを見る。グリフィスは別人と混同しない──論文173 に現れる Griffiths は代数幾何学者であり、本稿の A. A. Griffith とは別人である。既刊との関係:論文261 は弾性定数の柵を立てているのがエネルギーの正定値性だと書いた──本稿はその先、柵の中に座った材料がどこで壊れるかを扱う。論文190 は「稀」を対数の目盛りで測った──本稿も、傷の効き方を平方根と桁で書く。論文196 は「圧力」が四つの別の量であることを数えた──本稿は「強度」が一つの量ですらないことを数える。論文201 は「完備」が四つの別の主張であることを数えた──同じ形の点呼である。加えたのは同じ断面で長さだけを変えて座屈応力が 164.3 から 18.3 MPa まで動くことを計算したこと、切り替わりの細長比を 88.8577 と具体的な数で出したこと、傷の効き方が sqrt1000=31.6228 であることを確かめたこと、三つの限界を一つの表に並べ、最低のものが実際の限界になると書いたことである。 第一に、同じ断面で長さだけを変える。一辺 31.6 mm の正方形鋼柱は、1 m なら 164.3 MPa、3 m なら 18.3 MPa で座屈する──材料は一切変えていない(第2節)。 第二に、これが本稿の芯である。切り替わる細長比は lambda_c=pisqrtE/sigma_y=88.8577 である──これより細長ければ座屈が先、太短ければ降伏が先で、同じ材料で限界が入れ替わる(第3節)。 第三に、三つ目の限界は傷が決める。グリフィスの式では、傷が 1 mum で 356.8 MPa、1 mm で 11.3 MPa になる(第4節)。 第四に、傷は平方根で効く。傷を 1000 倍にすると強度は 31.6228 分の 1──sqrt1000 そのものである(第4節)。 第五に、三つは競合しない。同時に成り立つ三つの上限のうち、最も低いものが実際の限界になる──どれが最低かは、材料ではなく形と傷が決めている(第5節)。 第六に、だから強度は材料の性質ではない。 sigma_y=250 MPa という数を持っていても、長さ 3 m の柱は 18.3 MPa で壊れる──その差は 13.66 倍である(第5節)。 「この材料の強度は 250 MPa である」という一文は、壊れる条件を決めていなかった。壊れ方が三つあり、それぞれ別のものが決めているからである──座屈は形、破壊は傷、降伏は結晶。三つは競合せず、最も低いものが実際の限界になる。同じ断面で長さを 3 倍にすれば座屈応力は 9 分の 1 になり、10 mum の見えない傷が入れば破壊応力は降伏の半分以下に落ちる。材料表の 250 MPa は、長さ 3 m の柱については実際の限界の 13.66 倍上にあり、一度も出番が来ない。分けるものは一つ──どの限界を数えているのかを書き出すこと。書き出せば、材料を替えるべき場面と、形を変えるべき場面と、傷を消すべき場面が分かれる。書き出さなければ、18.3 MPa で壊れる柱に、より強い鋼を探し続けることになる。 作成にあたって:本稿の着想と内容は、著者自身の考察に基づくものです。文章の構成整理や英訳、数式の確認には AI(大規模言語モデル)の助力を得ました。最終的な内容の解釈や誤りがあれば、それらはすべて著者の責に帰します。お気づきの点があれば、ご教示いただければ幸いです。

View source

Similar papers

#computer vision Open access Jun 2016

Software Development in Startup Companies: The Greenfield Startup Model

Software startups are newly created companies with no operating history and oriented towards producing cutting-edge products. However, despite the increasing importance of startups in the economy, few scientific studies attempt to address software engineering issues, especially for early-stage startups. If anything, startups need engineering practices of the same level or better than those of larger companies, as their time and resources are more scarce, and one failed project can put them out of business. In this study we aim to improve understanding of the software development strategies employed by startups. We performed this state-of-practice investigation using a grounded theory approach. We packaged the results in the Greenfield Startup Model (GSM), which explains the priority of startups to release the product as quickly as possible. This strategy allows startups to verify product and market fit, and to adjust the product trajectory according to early collected user feedback. The need to shorten time-to-market, by speeding up the development through low-precision engineering activities, is counterbalanced by the need to restructure the product before targeting further growth. The resulting implications of the GSM outline challenges and gaps, pointing out opportunities for future research to develop and validate engineering practices in the startup context.

Carmine Giardino, Nicolò Paternoster, M. Unterkalmsteiner et al. · 179 citations · ⚡14
#computer vision Open access Oct 2016

Software Startups - A Research Agenda

Software startup companies develop innovative, software-intensive products within limited timeframes and with few resources, searching for sustainable and scalable business models. Software startup ...

M. Unterkalmsteiner, P. Abrahamsson, Xiaofeng Wang et al. · 157 citations · ⚡17
#machine learning Review Open access Oct 2016

“Failures” to be celebrated: an analysis of major pivots of software startups

In the context of software startups, project failure is embraced actively and considered crucial to obtain validated learning that can lead to pivots. A pivot is the strategic change of a business concept, product or the different elements of a business model. A better understanding is needed on different types of pivots and different factors that lead to failures and trigger pivots, for software entrepreneurial teams to make better decisions under chaotic and unpredictable environment. Due to the nascent nature of the topic, the existing research and knowledge on the pivots of software startups are very limited. In this study, we aimed at identifying the major types of pivots that software startups make during their startup processes, and highlighting the factors that fail software projects and trigger pivots. To achieve this, we conducted a case survey study based on the secondary data of the major pivots happened in 49 software startups. 10 pivot types and 14 triggering factors were identified. The findings show that customer need pivot is the most common among all pivot types. Together with customer segment pivot, they are common market related pivots. The major product related pivots are zoom-in and technology pivots. Several new pivot types were identified, including market zoom-in, complete and side project pivots. Our study also demonstrates that negative customer reaction and flawed business model are the most common factors that trigger pivots in software startups. Our study extends the research knowledge on software startup pivot types and pivot triggering factors. Meanwhile it provides practical knowledge to software startups, which they can utilize to guide their effective decisions on pivoting.

Sohaib Shahid Bajwa, Xiaofeng Wang, Anh Nguyen-Duc et al. · 127 citations · ⚡15
#computer vision Review Open access May 2015

A survey study on major technical barriers affecting the decision to adopt cloud services

In the context of cloud computing, risks associated with underlying technologies, risks involving service models and outsourcing, and enterprise readiness have been recognized as potential barriers for the adoption. To accelerate cloud adoption, the concrete barriers negatively influencing the adoption decision need to be identified. Our study aims at understanding the impact of technical and security-related barriers on the organizational decision to adopt the cloud. We analyzed data collected through a web survey of 352 individuals working for enterprises consisting of decision makers as well as employees from other levels within an organization. The comparison of adopter and non-adopter sample reveals three potential adoption inhibitor, security, data privacy, and portability. The result from our logistic regression analysis confirms the criticality of the security concern, which results in an up to 26-fold increase in the non-adoption likelihood. Our study underlines the importance of the technical and security perspectives for research investigating the adoption of technology.

Nattakarn Phaphoom, Xiaofeng Wang, S. Samuel et al. · 111 citations · ⚡8
#computer vision Conference Open access Dec 2013

Affordable and Energy-Efficient Cloud Computing Clusters: The Bolzano Raspberry Pi Cloud Cluster Experiment

We present our ongoing work building a Raspberry Pi cluster consisting of 300 nodes. The unique characteristics of this single board computer pose several challenges, but also offer a number of interesting opportunities. On the one hand, a single Raspberry Pi can be purchased cheaply and has a low power consumption, which makes it possible to create an affordable and energy-efficient cluster. On the other hand, it lacks in computing power, which makes it difficult to run computationally intensive software on it. Nevertheless, by combining a large number of Raspberries into a cluster, this drawback can be (partially) offset. Here we report on the first important steps of creating our cluster: how to set up and configure the hardware and the system software, and how to monitor and maintain the system. We also discuss potential use cases for our cluster, the two most important being an inexpensive and green test bed for cloud computing research and a robust and mobile data center for operating in adverse environments.

P. Abrahamsson, S. Helmer, Nattakarn Phaphoom et al. · 110 citations · ⚡7
#computer vision Book Open access Mar 2017

On the Unhappiness of Software Developers

The happy-productive worker thesis states that happy workers are more productive. Recent research in software engineering supports the thesis, and the ideal of flourishing happiness among software developers is often expressed among industry practitioners. However, the literature suggests that a cost-effective way to foster happiness and productivity among workers could be to limit unhappiness. Psychological disorders such as job burnout and anxiety could also be reduced by limiting the negative experiences of software developers. Simultaneously, a baseline assessment of (un)happiness and knowledge about how developers experience it are missing. In this paper, we broaden the understanding of unhappiness among software developers in terms of (1) the software developer population distribution of (un)happiness, and (2) the causes of unhappiness while developing software. We conducted a large-scale quantitative and qualitative survey, incorporating a psychometrically validated instrument for measuring (un)happiness, with 2 220 developers, yielding a rich and balanced sample of 1318 complete responses. Our results indicate that software developers are a slightly happy population, but the need for limiting the unhappiness of developers remains. We also identified 219 factors representing causes of unhappiness while developing software. Our results, which are available as open data, can act as guidelines for practitioners in management positions and developers in general for fostering happiness on the job. We suggest considering happiness in future studies of both human and technical aspects in software engineering.

D. Graziotin, Fabian Fagerholm, Xiaofeng Wang et al. · 84 citations · ⚡6

Related blog posts