(Created page with "==1 Title, abstract and keywords<!-- Your document should start with a concise and informative title. Titles are often used in information-retrieval systems. Avoid abbreviatio...")
 
Line 1: Line 1:
==1 Title, abstract and keywords<!-- Your document should start with a concise and informative title. Titles are often used in information-retrieval systems. Avoid abbreviations and formulae where possible. Capitalize the first word of the title.
+
==Abstract==
  
Provide a maximum of 6 keywords, and avoiding general and plural terms and multiple concepts (avoid, for example, 'and', 'of'). Be sparing with abbreviations: only abbreviations firmly established in the field should be used. These keywords will be used for indexing purposes.
+
To date, the modelling of crack formation during the ejection stage in powder metallurgy die compaction processes has fallen outside the scope of conventional finite element studies on this process. In this paper, we attempt to make an exploratory step in this regard by presenting a case study that exemplifies how crack simulations can be harnessed to solve real powder metallurgy manufacturing problems. The part subjected to the study is a multilevel adapter whose design to production process proved problematic to the manufacturer, to the point that simplifications in the geometry of the part were to be made. The goal here is, through finite element simulations, to clarify the reasons behind the difficulties in ejecting free crack compacts, to understand the connection of such difficulties with the geometry modifications introduced in the design and to make recommendations on the prevention of similar problems in other situations.
 
+
An abstract is required for every document; it should succinctly summarize the reason for the work, the main findings, and the conclusions of the study. Abstract is often presented separately from the article, so it must be able to stand alone. For this reason, references and hyperlinks should be avoided. If references are essential, then cite the author(s) and year(s). Also, non-standard or uncommon abbreviations should be avoided, but if essential they must be defined at their first mention in the abstract itself. -->==
+
 
+
 
+
 
+
 
+
==2 The main text<!-- You can enter and format the text of this document by selecting the ‘Edit’ option in the menu at the top of this frame or next to the title of every section of the document. This will give access to the visual editor. Alternatively, you can edit the source of this document (Wiki markup format) by selecting the ‘Edit source’ option.
+
 
+
Most of the documents in Scipedia are written in English (write your manuscript in American or British English, but not a mixture of these). Anyhow, specific publications in other languages can be published in Scipedia. In any case, the documents published in other languages must have an abstract written in English.
+
 
+
 
+
2.1 Subsections
+
 
+
Divide your article into clearly defined and numbered sections. Subsections should be numbered 1.1, 1.2, etc. and then 1.1.1, 1.1.2, ... Use this numbering also for internal cross-referencing: do not just refer to 'the text'. Any subsection may be given a brief heading. Capitalize the first word of the headings.
+
 
+
 
+
2.2 General guidelines
+
 
+
Some general guidelines that should be followed in your manuscripts are:
+
 
+
*  Avoid hyphenation at the end of a line.
+
 
+
*  Symbols denoting vectors and matrices should be indicated in bold type. Scalar variable names should normally be expressed using italics.
+
 
+
*  Use decimal points (not commas); use a space for thousands (10 000 and above).
+
 
+
*  Follow internationally accepted rules and conventions. In particular use the international system of units (SI). If other quantities are mentioned, give their equivalent in SI.
+
 
+
 
+
2.3 Tables, figures, lists and equations
+
 
+
Please insert tables as editable text and not as images. Tables should be placed next to the relevant text in the article. Number tables consecutively in accordance with their appearance in the text and place any table notes below the table body. Be sparing in the use of tables and ensure that the data presented in them do not duplicate results described elsewhere in the article.
+
 
+
Graphics may be inserted directly in the document and positioned as they should appear in the final manuscript.
+
 
+
Number the figures according to their sequence in the text. Ensure that each illustration has a caption. A caption should comprise a brief title. Keep text in the illustrations themselves to a minimum but explain all symbols and abbreviations used. Try to keep the resolution of the figures to a minimum of 300 dpi. If a finer resolution is required, the figure can be inserted as supplementary material
+
 
+
For tabular summations that do not deserve to be presented as a table, lists are often used. Lists may be either numbered or bulleted. Below you see examples of both.
+
 
+
1. The first entry in this list
+
 
+
2. The second entry
+
 
+
2.1. A subentry
+
 
+
3. The last entry
+
 
+
* A bulleted list item
+
 
+
* Another one
+
 
+
You may choose to number equations for easy referencing. In that case they must be numbered consecutively with Arabic numerals in parentheses on the right hand side of the page. Below is an example of formulae that should be referenced as eq. (1].
+
 
+
 
+
2.4 Supplementary material
+
 
+
Supplementary material can be inserted to support and enhance your article. This includes video material, animation sequences, background datasets, computational models, sound clips and more. In order to ensure that your material is directly usable, please provide the files with a preferred maximum size of 50 MB. Please supply a concise and descriptive caption for each file. -->==
+
 
+
 
+
 
+
 
+
==3 Bibliography<!--
+
Citations in text will follow a citation-sequence system (i.e. sources are numbered by order of reference so that the first reference cited in the document is [1], the second [2], and so on) with the number of the reference in square brackets. Once a source has been cited, the same number is used in all subsequent references. If the numbers are not in a continuous sequence, use commas (with no spaces) between numbers. If you have more than two numbers in a continuous sequence, use the first and last number of the sequence joined by a hyphen
+
 
+
You should ensure that all references are cited in the text and that the reference list. References should preferably refer to documents published in Scipedia. Unpublished results should not be included in the reference list, but can be mentioned in the text. The reference data must be updated once publication is ready. Complete bibliographic information for all cited references must be given following the standards in the field (IEEE and ISO 690 standards are recommended). If possible, a hyperlink to the referenced publication should be given. See examples for Scipedia’s articles [1], other publication articles [2], books [3], book chapter [4], conference proceedings [5], and online documents [6], shown in references section below. -->==
+
 
+
 
+
 
+
 
+
==4 Acknowledgments<!-- Acknowledgments should be inserted at the end of the document, before the references section. -->==
+
 
+
 
+
 
+
 
+
==5 References<!--[1] Author, A. and Author, B. (Year) Title of the article. Title of the Publication. Article code. Available: http://www.scipedia.com/ucode.
+
 
+
[2] Author, A. and Author, B. (Year) Title of the article. Title of the Publication. Volume number, first page-last page.
+
 
+
[3] Author, C. (Year). Title of work: Subtitle (edition.). Volume(s). Place of publication: Publisher.
+
 
+
[4] Author of Part, D. (Year). Title of chapter or part. In A. Editor & B. Editor (Eds.), Title: Subtitle of book (edition, inclusive page numbers). Place of publication: Publisher.
+
 
+
[5] Author, E. (Year, Month date). Title of the article. In A. Editor, B. Editor, and C. Editor. Title of published proceedings. Paper presented at title of conference, Volume number, first page-last page. Place of publication.
+
 
+
[6] Institution or author. Title of the document. Year. [Online] (Date consulted: day, month and year). Available: http://www.scipedia.com/document.pdf.  
+
-->==
+

Revision as of 12:59, 8 May 2020

Abstract

To date, the modelling of crack formation during the ejection stage in powder metallurgy die compaction processes has fallen outside the scope of conventional finite element studies on this process. In this paper, we attempt to make an exploratory step in this regard by presenting a case study that exemplifies how crack simulations can be harnessed to solve real powder metallurgy manufacturing problems. The part subjected to the study is a multilevel adapter whose design to production process proved problematic to the manufacturer, to the point that simplifications in the geometry of the part were to be made. The goal here is, through finite element simulations, to clarify the reasons behind the difficulties in ejecting free crack compacts, to understand the connection of such difficulties with the geometry modifications introduced in the design and to make recommendations on the prevention of similar problems in other situations.

Back to Top

Document information

Published on 01/01/2012

DOI: 10.1179/1743290111Y.0000000017
Licence: CC BY-NC-SA license

Document Score

0

Views 1
Recommendations 0

Share this document

claim authorship

Are you one of the authors of this document?