Users:FSI/CouplingCode

From Carat++ Public Wiki
< Users:FSI(Difference between revisions)
Jump to: navigation, search
 
(5 intermediate revisions by one user not shown)
Line 1: Line 1:
 
[[Category: Users:FSI]]
 
[[Category: Users:FSI]]
  
 +
= Coupling Code CoMA =
  
 +
CoMA (Coupling for Multiphysics Analysis) is a general code coupling tool, used in the simulation of surface coupled problems. It is developed since some years at the institute. The tasks of CoMA within a coupled analysis are:
  
−
coma: data transfer, communication, controlling: coupl algo, predictor, convergence
+
* Control of the coupled computation and the single-field solvers
 +
* Convergence control
 +
* Coupling algorithms for implicit computations
 +
* Data transfer between distributed interface meshes
 +
* Communication between parallel single-field solvers and CoMA
  
−
 
+
This wiki should just give a short overview on how to use CoMA, being specific on FSI-simulation with Carat and OpenFOAM. Detailed information on programming concepts and theoretical aspects can be found in the dissertation of Thomas Gallinger.
−
 
+
−
= Coupling Code CoMA =
+
−
 
+
−
CoMA (Coupling for Multiphysics Analysis) is a general code coupling tool, used in the simulation of surface coupled problems. It is developed since some years at the institute. This wiki should just give a short overview on how to use CoMA, specific on FSI-simulation with Carat and OpenFOAM. Detailed information on programming concepts and theoretical aspects can be found in the dissertation of Thomas Gallinger.
+
  
  
Line 32: Line 34:
 
* Predictor
 
* Predictor
 
* CouplingAlgo
 
* CouplingAlgo
 +
 +
For a restart run, one block is necessary:
 +
 +
*Restart
 +
 +
 +
=== Input File: Compulsory Block Description ===
 +
 +
{| border="1" cellpadding="3" cellspacing="0"
 +
|colspan="3" style="background:#efefef;"| Block General: General control of application flow
 +
|-
 +
!Type
 +
|''fsi or ffi or wind''
 +
|defines MPI Ident tag of CoMA within MPI Environment, used by other codes to identify CoMA process
 +
|-
 +
!Method
 +
|''implicit or explicit''
 +
|implicit or explicit coupling, implicit with, explicit without inner iteration loops
 +
|-
 +
|}
 +
 +
 +
{| border="1" cellpadding="3" cellspacing="0"
 +
|colspan="3" style="background:#efefef;"| Block Processgroup: Defines a group of processes, which belong to one field
 +
|-
 +
!ID
 +
|''0 or 1''
 +
|used to order processgroups and as reference for exchanged quantities
 +
|-
 +
!Name
 +
|''string''
 +
|for output only
 +
|-
 +
!InterfaceType
 +
|''mpi or file''
 +
|type of communication between CoMA and processgroup, Warning: type file only partly implemented
 +
|-
 +
!MPIIdentTag
 +
|''1 or 2''
 +
|used to identify processes of processgroup in MPI-universe
 +
|-
 +
|}
 +
 +
 +
{| border="1" cellpadding="3" cellspacing="0"
 +
|colspan="3" style="background:#efefef;"| Block ExchangedQuantity: Defines a quantitiy to be exchanged between processgroups
 +
|-
 +
!ID
 +
|''0 or 1 or 2 ...''
 +
|used to order quantities (0 exchanged before 1 before 2...)
 +
|-
 +
!Name
 +
|''string''
 +
|for output only
 +
|-
 +
!Dimension
 +
|''int''
 +
|dofs per node, e.g. displacements 3
 +
|-
 +
!InterpolationType
 +
|''1 or 2''
 +
|1 = flux mapping (summation e.g. for forces), 2 = field mapping (interpolation e.g. for displacements)
 +
|-
 +
!SenderID
 +
|''int''
 +
|ID of processgroups, which sends this quantitiy
 +
|-
 +
!RecieverID
 +
|''int''
 +
|ID of processgroups, which recieves this quantitiy
 +
|-
 +
!MpiTagBasis
 +
|''int''
 +
|used for MPI-data exchange of this quantitiy
 +
|-
 +
!DoFType
 +
|''node''
 +
|dummy paramter, quantitiy specified per node
 +
|-
 +
!Predictor - optional parameter
 +
|''yes or no''
 +
|use a predictor for this quantitiy in the first inner iteration and do not recieve from sender, block "Predictor" is necessary
 +
|-
 +
!CouplingAlgo - optional parameter
 +
|''yes or no''
 +
|use a coupling algorithm for this quantitiy, block "CouplingAlgo" is necessary
 +
|-
 +
!Convergence - optional parameter
 +
|''yes or no''
 +
|use a convergence criterion for this quantitiy, block "ConvergenceCalculation" is necessary
 +
|-
 +
|}
 +
 +
 +
{| border="1" cellpadding="3" cellspacing="0"
 +
|colspan="3" style="background:#efefef;"| Block Mapping: Defines mapping method of exchanged quantities between surface meshes.
 +
|-
 +
!Type
 +
|''TNM, MM or NLM''
 +
|TNM: Triangular Nonmatching Mesh Mapper, MM: Matching Meshes, NLM: NURBS-Linear Mapper
 +
|-
 +
|}
 +
 +
 +
{| border="1" cellpadding="3" cellspacing="0"
 +
|colspan="3" style="background:#efefef;"| Block Output: General output of CoMA for postprocessing and simulation control
 +
|-
 +
!Path
 +
|''string''
 +
|absolute or relative path to directory for output files, created if necessary
 +
|-
 +
!Name
 +
|''string''
 +
|prefix for output file names
 +
|-
 +
!Format
 +
|''gid, vtk or rhino''
 +
|write ouput in Gid-,Vtk(Paraview), or Rhino-format, Warning: Vtk writes out the mesh in every step, so huge data amount possible
 +
|-
 +
!Frequency
 +
|''int''
 +
|ouput ever int step
 +
|-
 +
!Energy
 +
|''yes or no''
 +
|additional output of energy
 +
|-
 +
!Convergence
 +
|''yes or no''
 +
|write additional file Path/Name+.cc with iteration information
 +
|-
 +
!QuantityID
 +
|''int''
 +
|which quantity to examine in .cc-file
 +
|-
 +
!Dof
 +
|''yes or no''
 +
|write dof-history in .cc-file, yes -> define node by following four entries:
 +
|-
 +
!ProcessgroupIndex
 +
|''int''
 +
|processgroup of dof
 +
|-
 +
!MeshTagIndex
 +
|''int''
 +
|meshTag of dof
 +
|-
 +
!NodeIndex
 +
|''int''
 +
|node index of dof
 +
|-
 +
!DofIndex
 +
|''int''
 +
|dof index of dof
 +
|-
 +
|}
 +
 +
 +
=== Input File: Optional Block Description ===
 +
 +
 +
{| border="1" cellpadding="3" cellspacing="0"
 +
|colspan="3" style="background:#efefef;"| Block Predictor: Defines a predictor for an exchanged Quantitiy used in the first inner itertation of a time step.
 +
|-
 +
!Type
 +
|''polynomial or newmark or adaptive''
 +
|Predictor type, for details see <ref name="Gallinger2010">Gallinger, T.G.: Effiziente Algorithmen zur partitionierten Lösung stark gekoppelter Probleme der Fluid-Struktur-Wechselwirkung, Dissertation, Lehrstuhl für Statik, Technische Universität München, 2010</ref>
 +
|-
 +
!Order - for Type polynomial and newmark
 +
|''int''
 +
|polynomial: 0, 1, 2, 3; newmark: 1, 2;
 +
|-
 +
!Beta - for Type newmark
 +
|''float''
 +
|time integration parameter of Newmark scheme, standard: 0.25
 +
|-
 +
!Gamma - for Type newmark
 +
|''float''
 +
|time integration parameter of Newmark scheme, standard: 0.50
 +
|-
 +
|}
 +
 +
 +
{| border="1" cellpadding="3" cellspacing="0"
 +
|colspan="3" style="background:#efefef;"| Block CouplingAlgo: Defines a coupling algorithm for an exchanged Quantitiy used in every inner itertation except the first of a time step.
 +
|-
 +
!Type
 +
|''constant or aitken or quasinewton''
 +
|Coupling algorithm type, for details see <ref name="Gallinger2010">Gallinger, T.G.: Effiziente Algorithmen zur partitionierten Lösung stark gekoppelter Probleme der Fluid-Struktur-Wechselwirkung, Dissertation, Lehrstuhl für Statik, Technische Universität München, 2010</ref>
 +
|-
 +
!Factor - for Type constant, aitken and quasinewton
 +
|''float''
 +
|underrelaxation factor used always in constant relaxation, in the first iteration with Aitken and Quasi-Newton method
 +
|-
 +
!ConstRelax - for Type quasinewton
 +
|''yes or no''
 +
|use constant relaxation in first coupling iteration
 +
|-
 +
!NumHistoryDelta - for Type quasinewton
 +
|''int''
 +
|include delta information from preceeding timesteps into minimization problem
 +
|-
 +
!MinResChange - for Type quasinewton
 +
|''float''
 +
|dummy factor - not used
 +
|-
 +
|}
 +
 +
 +
{| border="1" cellpadding="3" cellspacing="0"
 +
|colspan="3" style="background:#efefef;"| Block ConvergenceCalculation: Defines convergence properties for coupled computation.
 +
|-
 +
!By
 +
|''CoMA or Processgroup''
 +
|Which code performs convergence calculation
 +
|-
 +
!ProcessgroupID - for By processgroup
 +
|''int''
 +
|which group
 +
|-
 +
!Type - for By CoMA
 +
|''absolute or relative''
 +
|which convergence criterion should CoMA use, a absolute or relatve one
 +
|-
 +
!Limit - for By CoMA
 +
|''float''
 +
|convergence limit, if below=converged
 +
|-
 +
!CouplingSteps - for By CoMA
 +
|''int''
 +
|number of coupling steps (time steps) to be performed in total
 +
|-
 +
!MaxInnerLoopSteps - for By CoMA
 +
|''int''
 +
|number of maximum inner iteration loops
 +
|-
 +
|}
  
  
 +
{| border="1" cellpadding="3" cellspacing="0"
 +
|colspan="3" style="background:#efefef;"| Block Restart: Used for computation with restart possibility
 +
|-
 +
!RestartRun
 +
|''yes or no''
 +
|Is this run a restart run
 +
|-
 +
!RestartFromStep - for RestartRun yes
 +
|''int''
 +
|from which step should the restart be performed
 +
|-
 +
!RestartOutput
 +
|''yes or no''
 +
|shoul restart-information be written ot output
 +
|-
 +
!RestartFrequency - for RestartOutput yes
 +
|''int''
 +
|write restart info every int step
 +
|-
 +
!RestartPath - for RestartOutput yes
 +
|''string''
 +
|absolute or relative path to directory for output, created if necessary
 +
|-
 +
!RestartFileName - for RestartOutput yes
 +
|''string''
 +
|prefix of restart info file names
 +
|-
 +
!RestartInfoInstances - for RestartOutput yes
 +
|''int''
 +
|instances of restart information in output files to be kept
 +
|-
 +
!PersistPredictorOrder - for RestartOutput yes
 +
|''yes or no''
 +
|write out all info necessary to preserve predictor order in restart
 +
|-
 +
|}
  
  
 +
=== Restart Functionality ===
  
 +
The Fsi environemt offers the possibility to do a restart from a certain timestep. This may be helpful in 2 cases:
  
 +
* If computing time restrictions, e.g. on clusters, exist, the simulation has to finish before cpu time ends and do a restart from the last timestep.
 +
* If convergence problems during a long run show up, the simulation may be stopped and a restart form an earlier timestep with smaller time step size or anothe coupling algorithm may be performed.
  
−
The problem setup is based on a typical Carat++-Inputfile used for a single-field analysis.
 
  
−
To be specific for a coupled analysis, two steps have to made:
+
For a restart, all three programs have to be touched. The procedure consists of two steps:
−
* The coupled interface hast to be defined. This is the geometric representation of the coupled surface between fluid and structure field.
+
−
* A FSI-analysis is chosen, which links to an basi analysis type, e.g. a static or dynamic analysis.
+
  
 +
* During the run, all three prgrams have to write additional output necessary for a restart in certain intervalls.
 +
* For a restart, the programs have to read this information to initialize everything properly.
  
−
=== Interface Definition ===
+
Hint 1: During the run, define all three programs to have the same frequency of restart info output.
  
−
The interface is the geometric definition of the physical surface between fluid and structure field. It is based on the already exisiting Finite element model. Note the following:
+
Hint 2: For a restart run, just adapt the starttime in Carat++ and OpenFOAM, adapt the restartFromStep command in CoMA and set "restartRun yes" in all three programs.
  
−
* Not all elements of the model have to be part of the interface. E.g. Shell and Membrane elements should be part of the model, because the surface type gives large influence from surrounding flow, but truss elements are not part, because wind influence on a truss may be neglected.
 
−
* Not all element types are suitable for usage within the interface. Currently only shell and membrane elements are supported.
 
−
* An export type has to be defined. Shell and membrane elements are defined by their mid-surface. It depends on the flow and the element thickness, if the mid-surface is a proper definition of the interface. If a very thin membrane element has flow influence only from one side, the mid-surface maybe a proper definition of the interface geometry. If a very thick shell is placed in a surrounding fluid (flow on top and bottom), neglecting the thickness may lead to large errors in the correct physical representation of the problem. Currently, three export types are available: (1) Use the mid-surface of the elements as the interface. (2) Do a blow-up of the mid-surface based on the thickness and a director on the surface to define a 3d representation of the model with a top and bottom surface. (3) Using approach (2) leads to wholes on the side parts of the interface. Close the whole by additional surface elements.
 
  
−
The interface contains different partitions, at least one. Every partition has a unique element type and a unique type of element treatment. A typical interface defintion in Carat++ looks like:
+
The three different programs are explained in detail:
  
−
<pre>
+
==== Restart in Carat++ ====
−
EL-IF 1
+
−
NIP 1 1 0 (1-15)  MSHTAG=1 BORDER=;
+
−
NIP 2 3 0 (20-30)  MSHTAG=1,1,2 BORDER=31,62;
+
−
</pre>
+
  
−
This interface consists of two partitions. The first partition (NIP 1) has interface export type 1 (export mid-surface only), format type 0 (dummy), sonsists of elements 1-15, the tag of the surface mesh is 1 (used to match carat and Foam interface meshes) and no border definition is necessary.
+
Restart is possible for dynamic analysis only (linear and nonlinear) and consists of different additional instructions in th dynamic analysis block. They are explained in the corresponding wiki entry.  
−
The second partition (NIP 2) has interface export type 3 (export top- and bottom surface and side mesh), format type 0 (dummy), consists of elements 20-30, the tag of the three surface meshes is 1 for the top mesh, 1 for the bottom mesh and 2 for the side mesh (used to match carat and Foam interface meshes). The side mesh is defined by defining nodes, which are part of the border.
+
  
−
Hint: More details on the interface definition can be found in the diploma thesis of Rupert Fisch.
+
==== Restart in OpenFOAM ====
  
−
=== Analysis Definition ===
+
OpenFOAM needs an additonal field "totalDisps" in the starttime directory. It is the same as the already existing pointMotionU file and used to store the deformation history of the coupled patch. Restart info is written to this file automatically together with all other fields. For a restart-run, set the parameter "restartRun yes;" in the file couplingProperties and adapt the startTime.
  
−
Defining a coupled analysis, contains of two part:
+
==== Restart in CoMA ====
  
−
* Defining a Analysis of type FSI as master analysis.
+
Same as in Carat++. Set "RestartOutput yes" and define frequency, path, filename and instance level. During restart run, set "RestartRun yes" and specify the step.
−
* Defining a sub-analysis for the specific structure field behavior (static or dynamic).
+
  
−
The defintion of the master analysis:
 
−
<pre>
 
−
PC-ANALYSIS 1: FSI
 
−
  ANALYSIS = PC-ANALYSIS 2
 
−
  METHOD  = BLACKBOX  !BLACKBOX, SUBSPACE_LP, SUBSPACE_FD
 
−
  OUTPUT  = PC-OUT 1
 
−
  INTERFACE = EL-IF 1
 
−
</pre>
 
  
−
The sub-analysis is given by Analysis 2. The method is given as black-box (standard). Additionally, the output and the interface have to be defined.
 
  
−
The sub-analysis block is the same as in a standard Carat++-analysis. Possible analysis types are static linear and static nonlinear and dynamic linear and nonlinear (all available time integration algorithms).
+
== References ==
  
−
* Hint 1: The specification of an end time in a dynamic analysis is necessary in the input block, but is overriden in the coupled analysis by CoMA.
+
<references/>
−
* Hint 2: The loads from the fluid are just added to the loads specified in the carat++-input file. So it is possible to add e.g. self weight to the structure model.
+

Latest revision as of 09:56, 8 March 2011


Contents

Coupling Code CoMA

CoMA (Coupling for Multiphysics Analysis) is a general code coupling tool, used in the simulation of surface coupled problems. It is developed since some years at the institute. The tasks of CoMA within a coupled analysis are:

  • Control of the coupled computation and the single-field solvers
  • Convergence control
  • Coupling algorithms for implicit computations
  • Data transfer between distributed interface meshes
  • Communication between parallel single-field solvers and CoMA

This wiki should just give a short overview on how to use CoMA, being specific on FSI-simulation with Carat and OpenFOAM. Detailed information on programming concepts and theoretical aspects can be found in the dissertation of Thomas Gallinger.


Installation and Compilation

CoMA has to installed under Linux operating system, because FSI-jobs only run under Linux. There exists an svn-repository, which contains all CoMA sources. The svn-repository is hosted on the same server as the carat repository. The current IP is 129.187.141.99 and the folder is named "CoMA". Checkout the svn-repository. Open the file "makfile.in" in the src-directory. You have to adapt the variable "CoMA_DIR", which points to your CoMA installation path, and the variable "MPIHOME", pointing to your MPI installation path. Execute the shellscript "make_obj_directories" to set the directorires for the objety, and then type "make" to build CoMA software.


Problem Setup

The structure of the input file reflects the underlying programming concepts of CoMA. An example input file can be found in the svn-repository under the directory "example". The input file is block-structured. At least five different blocks have to specified:

  • General
  • Two Processgroups
  • ExchangedQuantity
  • Mapping
  • Output

For an implicit FSI-simulation, three additional blocks have to be specified:

  • ConvergenceCalculation
  • Predictor
  • CouplingAlgo

For a restart run, one block is necessary:

  • Restart


Input File: Compulsory Block Description

Block General: General control of application flow
Type fsi or ffi or wind defines MPI Ident tag of CoMA within MPI Environment, used by other codes to identify CoMA process
Method implicit or explicit implicit or explicit coupling, implicit with, explicit without inner iteration loops


Block Processgroup: Defines a group of processes, which belong to one field
ID 0 or 1 used to order processgroups and as reference for exchanged quantities
Name string for output only
InterfaceType mpi or file type of communication between CoMA and processgroup, Warning: type file only partly implemented
MPIIdentTag 1 or 2 used to identify processes of processgroup in MPI-universe


Block ExchangedQuantity: Defines a quantitiy to be exchanged between processgroups
ID 0 or 1 or 2 ... used to order quantities (0 exchanged before 1 before 2...)
Name string for output only
Dimension int dofs per node, e.g. displacements 3
InterpolationType 1 or 2 1 = flux mapping (summation e.g. for forces), 2 = field mapping (interpolation e.g. for displacements)
SenderID int ID of processgroups, which sends this quantitiy
RecieverID int ID of processgroups, which recieves this quantitiy
MpiTagBasis int used for MPI-data exchange of this quantitiy
DoFType node dummy paramter, quantitiy specified per node
Predictor - optional parameter yes or no use a predictor for this quantitiy in the first inner iteration and do not recieve from sender, block "Predictor" is necessary
CouplingAlgo - optional parameter yes or no use a coupling algorithm for this quantitiy, block "CouplingAlgo" is necessary
Convergence - optional parameter yes or no use a convergence criterion for this quantitiy, block "ConvergenceCalculation" is necessary


Block Mapping: Defines mapping method of exchanged quantities between surface meshes.
Type TNM, MM or NLM TNM: Triangular Nonmatching Mesh Mapper, MM: Matching Meshes, NLM: NURBS-Linear Mapper


Block Output: General output of CoMA for postprocessing and simulation control
Path string absolute or relative path to directory for output files, created if necessary
Name string prefix for output file names
Format gid, vtk or rhino write ouput in Gid-,Vtk(Paraview), or Rhino-format, Warning: Vtk writes out the mesh in every step, so huge data amount possible
Frequency int ouput ever int step
Energy yes or no additional output of energy
Convergence yes or no write additional file Path/Name+.cc with iteration information
QuantityID int which quantity to examine in .cc-file
Dof yes or no write dof-history in .cc-file, yes -> define node by following four entries:
ProcessgroupIndex int processgroup of dof
MeshTagIndex int meshTag of dof
NodeIndex int node index of dof
DofIndex int dof index of dof


Input File: Optional Block Description

Block Predictor: Defines a predictor for an exchanged Quantitiy used in the first inner itertation of a time step.
Type polynomial or newmark or adaptive Predictor type, for details see [1]
Order - for Type polynomial and newmark int polynomial: 0, 1, 2, 3; newmark: 1, 2;
Beta - for Type newmark float time integration parameter of Newmark scheme, standard: 0.25
Gamma - for Type newmark float time integration parameter of Newmark scheme, standard: 0.50


Block CouplingAlgo: Defines a coupling algorithm for an exchanged Quantitiy used in every inner itertation except the first of a time step.
Type constant or aitken or quasinewton Coupling algorithm type, for details see [1]
Factor - for Type constant, aitken and quasinewton float underrelaxation factor used always in constant relaxation, in the first iteration with Aitken and Quasi-Newton method
ConstRelax - for Type quasinewton yes or no use constant relaxation in first coupling iteration
NumHistoryDelta - for Type quasinewton int include delta information from preceeding timesteps into minimization problem
MinResChange - for Type quasinewton float dummy factor - not used


Block ConvergenceCalculation: Defines convergence properties for coupled computation.
By CoMA or Processgroup Which code performs convergence calculation
ProcessgroupID - for By processgroup int which group
Type - for By CoMA absolute or relative which convergence criterion should CoMA use, a absolute or relatve one
Limit - for By CoMA float convergence limit, if below=converged
CouplingSteps - for By CoMA int number of coupling steps (time steps) to be performed in total
MaxInnerLoopSteps - for By CoMA int number of maximum inner iteration loops


Block Restart: Used for computation with restart possibility
RestartRun yes or no Is this run a restart run
RestartFromStep - for RestartRun yes int from which step should the restart be performed
RestartOutput yes or no shoul restart-information be written ot output
RestartFrequency - for RestartOutput yes int write restart info every int step
RestartPath - for RestartOutput yes string absolute or relative path to directory for output, created if necessary
RestartFileName - for RestartOutput yes string prefix of restart info file names
RestartInfoInstances - for RestartOutput yes int instances of restart information in output files to be kept
PersistPredictorOrder - for RestartOutput yes yes or no write out all info necessary to preserve predictor order in restart


Restart Functionality

The Fsi environemt offers the possibility to do a restart from a certain timestep. This may be helpful in 2 cases:

  • If computing time restrictions, e.g. on clusters, exist, the simulation has to finish before cpu time ends and do a restart from the last timestep.
  • If convergence problems during a long run show up, the simulation may be stopped and a restart form an earlier timestep with smaller time step size or anothe coupling algorithm may be performed.


For a restart, all three programs have to be touched. The procedure consists of two steps:

  • During the run, all three prgrams have to write additional output necessary for a restart in certain intervalls.
  • For a restart, the programs have to read this information to initialize everything properly.

Hint 1: During the run, define all three programs to have the same frequency of restart info output.

Hint 2: For a restart run, just adapt the starttime in Carat++ and OpenFOAM, adapt the restartFromStep command in CoMA and set "restartRun yes" in all three programs.


The three different programs are explained in detail:

Restart in Carat++

Restart is possible for dynamic analysis only (linear and nonlinear) and consists of different additional instructions in th dynamic analysis block. They are explained in the corresponding wiki entry.

Restart in OpenFOAM

OpenFOAM needs an additonal field "totalDisps" in the starttime directory. It is the same as the already existing pointMotionU file and used to store the deformation history of the coupled patch. Restart info is written to this file automatically together with all other fields. For a restart-run, set the parameter "restartRun yes;" in the file couplingProperties and adapt the startTime.

Restart in CoMA

Same as in Carat++. Set "RestartOutput yes" and define frequency, path, filename and instance level. During restart run, set "RestartRun yes" and specify the step.


References

  1. ↑ 1.0 1.1 Gallinger, T.G.: Effiziente Algorithmen zur partitionierten Lösung stark gekoppelter Probleme der Fluid-Struktur-Wechselwirkung, Dissertation, Lehrstuhl für Statik, Technische Universität München, 2010




Whos here now:   Members 0   Guests 0   Bots & Crawlers 1
 
Retrieved from "http://carat.st.bv.tum.de/caratuserswiki/index.php/Users:FSI/CouplingCode"
Personal tools
Content for Users
Content for Developers