A framework for developing finite element codes for multi- disciplinary applications

Latest revision as of 15:47, 27 November 2019

Abstract

The world of computing simulation has experienced great progresses in recent years and requires more exigent multidisciplinary challenges to satisfy the new upcoming demands. Increasing the importance of solving multi-disciplinary problems makes developers put more attention to these problems and deal with difficulties involved in developing software in this area.

Conventional finite element codes have several difficulties in dealing with multi-disciplinary problems. Many of these codes are designed and implemented for solving a certain type of problems, generally involving a single field. Extending these codes to deal with another field of analysis usually consists of several problems and large amounts of modifications and implementations. Some typical difficulties are: predefined set of degrees of freedom per node, data structure with fixed set of defined variables, global list of variables for all entities, domain based interfaces, IO restriction in reading new data and writing new results and algorithm definition inside the code. A common approach is to connect different solvers via a master program which implements the interaction algorithms and also transfers data from one solver to another. This approach has been used successfully in practice but results duplicated implementation and redundant overhead of data storing and transferring which may be significant depending to the solvers data structure.

The objective of this work is to design and implement a framework for building multi-disciplinary finite element programs. Generality, reusability, extendibility, good performance and memory efficiency are considered to be the main points in design and implementation of this framework. Preparing the structure for team development is another objective because usually a team of experts in different fields are involved in the development of multi-disciplinary code. Kratos, the framework created in this work, provides several tools for easy implementation of finite element applications and also provides a common platform for natural interaction of its applications in different ways. This is done not only by a number of innovations but also by collecting and reusing several existing works.

In this work an innovative variable base interface is designed and implemented which is used at different levels of abstraction and showed to be very clear and extendible. Another innovation is a very efficient and flexible data structure which can be used to store any type of data in a type-safe manner. An extendible IO is also created to overcome another bottleneck in dealing with multi-disciplinary problems. Collecting different concepts of existing works and adapting them to coupled problems is considered to be another innovation in this work. Examples are using an interpreter, different data organizations and variable number of dofs per node. The kernel and application approach is used to reduce the possible conflicts arising between developers of different fields and layers are designed to reflect the working space of different developers also considering their programming knowledge. Finally several technical details are applied in order to increase the performance and efficiency of Kratos which makes it practically usable.

This work is completed by demonstrating the framework’s functionality in practice. First some classical single field applications like thermal, fluid and structural applications are implemented and used as benchmark to prove its performance. These applications are used to solve coupled problems in order to demonstrate the natural interaction facility provided by the framework. Finally some less classical coupled finite element algorithms are implemented to show its high flexibility and extendibility.

Latest revision as of 15:47, 27 November 2019

Abstract

Document information

Document Score

Share this document

claim authorship

@@ 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.
+The world of computing simulation has experienced great progresses in recent years and requires
+more exigent multidisciplinary challenges to satisfy the new upcoming demands. Increasing the
+importance of solving multi-disciplinary problems makes developers put more attention to these
+problems and deal with difficulties involved in developing software in this area.
-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. -->==
+Conventional finite element codes have several difficulties in dealing with multi-disciplinary
+problems. Many of these codes are designed and implemented for solving a certain type of problems,
+generally involving a single field. Extending these codes to deal with another field of analysis
+usually consists of several problems and large amounts of modifications and implementations.
+Some typical difficulties are: predefined set of degrees of freedom per node, data structure with
+fixed set of defined variables, global list of variables for all entities, domain based interfaces, IO
+restriction in reading new data and writing new results and algorithm definition inside the code.
+A common approach is to connect different solvers via a master program which implements the
+interaction algorithms and also transfers data from one solver to another. This approach has been
+used successfully in practice but results duplicated implementation and redundant overhead of
+data storing and transferring which may be significant depending to the solvers data structure.
+The objective of this work is to design and implement a framework for building multi-disciplinary
+finite element programs. Generality, reusability, extendibility, good performance and memory efficiency
+are considered to be the main points in design and implementation of this framework.
+Preparing the structure for team development is another objective because usually a team of experts
+in different fields are involved in the development of multi-disciplinary code.
+Kratos, the framework created in this work, provides several tools for easy implementation
+of finite element applications and also provides a common platform for natural interaction of its
+applications in different ways. This is done not only by a number of innovations but also by
+collecting and reusing several existing works.
+In this work an innovative variable base interface is designed and implemented which is used
+at different levels of abstraction and showed to be very clear and extendible. Another innovation
+is a very efficient and flexible data structure which can be used to store any type of data in a
+type-safe manner. An extendible IO is also created to overcome another bottleneck in dealing with
+multi-disciplinary problems. Collecting different concepts of existing works and adapting them
+to coupled problems is considered to be another innovation in this work. Examples are using an
+interpreter, different data organizations and variable number of dofs per node. The kernel and
+application approach is used to reduce the possible conflicts arising between developers of different
+fields and layers are designed to reflect the working space of different developers also considering
+their programming knowledge. Finally several technical details are applied in order to increase the
+performance and efficiency of Kratos which makes it practically usable.
+This work is completed by demonstrating the framework’s functionality in practice. First some
+classical single field applications like thermal, fluid and structural applications are implemented and
+used as benchmark to prove its performance. These applications are used to solve coupled problems
+in order to demonstrate the natural interaction facility provided by the framework. Finally some
+less classical coupled finite element algorithms are implemented to show its high flexibility and
+extendibility.
-==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.
+<pdf>Media:Draft_Samper_476462424_6388_M109.pdf</pdf>
-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.
-.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 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.
-.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.
-. The first entry in this list
-. The second entry
-.1. A subentry
-. 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].
-.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.
--->==