dmitryikh / nla3d Goto Github PK

Due to include sys.h everywhere which contains all this stuff:

#pragma once
#include <string>
#include <iostream>
#include <fstream>
#include <strstream>
#include <stdarg.h>
#include <assert.h>
#include <time.h>
#include <sstream>
#include <iostream>
#include <vector>
#include <algorithm>
#include <stdlib.h>

#define ELPP_STL_LOGGING
#include "easylogging++.h"

#define _USE_MATH_DEFINES
#include <math.h>

Compilation takes long time. We need to mange it somehow. For instance, use precompiler headers (doesn't supported by cmake natively, unfortunately)

We need open source (or self-written) alternative for MKL's PARDISO. It should be able to solve SLAE with ~ 100 000 DoFs.

Here is nla3d::math::EquationSolver base abstract class for linear equations system solvers. For now, here is a single realization of this class named PARDISO_EquationSolver which uses MKL' PARDISO routines to solve large sparse systems of linear equation.

We need to have an another realization of a equation solver with free license. This could be a simple in-house realization, or adapted open source version of well known solver.

Currently to solve some FE problem it's needed to write a program and compile it (examples are: test/QUADTH_test.cpp, src/main_truss.cpp). When number of tests growth it will be complicated to manage big amount of stand-alone executable programs. Also this approach lead to large cpu time to test compilations.

The idea presented there is to provide nla3d lib API to Python 2.* language. In this case we can manage many FEM tests using the same binary code in nla3d.dll.
Also this approach can be used to solve different FEM problems, to use complicated PRE and POST processing without recompilation of the binary code.

There are three possibilities to write such API:

1. Use "python sdk" to write native python module (time consuming approach).
2. Use ctypes to connect to any dll (good enough for small API)
3. Use SWIG to maintane large API between Python and C++.

For some reasons CI buildings is broken, need to fix it.

It's known, that after reordering it's faster to solve the system of linear equations. Let's try to implement some reordering mechanism or use well-known library, like MeTiS.

Please, add description to each class, field, property and function. Don't forget about function and constructor arguments. It is not easy to understand what function or class is used for without comments. And maybe you change directory structure? Separate headers and .cpp files, separate headers and .cpp files for third party libs, INSTALL text and other. Just google about it.

And another question. Why do you need your own realization of sparse matrix. I think there are thousands of such libs...

Hi, and thanks for your work. I got it working and get some nice results.
I was wondering, if I can use 10 noded tetrahedron elements (with higher order) for linear mechanics?

Also, is there a way to support skewed supports? The ones I found where just orthogonal. I could attach a beam, but I think there's better ways to do this.

subj.
For now nla3d_use_blase should be OFF in CMakeList.txt

For now, elements and other entities have an ability to register DoF etheir in nodes or in elements. That means that the element are going to use this DoF in its stiffness matrix. Here is two steps to register DoF:

1. Element in its constructor should register DoF type, for example:

ElementTRUSS3::ElementTRUSS3 () {

  ...

  Node::registerDofType(Dof::UX);
  Node::registerDofType(Dof::UY);
  Node::registerDofType(Dof::UZ);
}

1. Then in Element::pre() functions it's needed to register particular DoFs for particular nodes (elements in case of element DoF). For example:

void ElementTRUSS3::pre () {
  for (uint16 i = 0; i < Element::n_nodes(); i++) {
    storage->registerNodeDof(getNodeNumber(i), Dof::UX);
    storage->registerNodeDof(getNodeNumber(i), Dof::UY);
    storage->registerNodeDof(getNodeNumber(i), Dof::UZ);
  }
}

I think that it is excess. And we can live only with second step (without registering DoF types in step 1). For this we need to slightly rework internal registering mechanisms and data structures in FEStorage class. I believe that it could be done without any drawback in performance..

Hi!

Please, tell me. Why do you have dMat and MatSym separate classes? Do I need to merge them too? Maybe they must be hidden behind one interface?

Now here is only one FEReader: readCdbFile it pass read info directly to FEStorage and FESolver.
This approach has many limitations:

1. All read information is passed toFEStorage/Solver. Sometimes we need to read large mesh file, but use only a part of information to build model.
2. Only one type of elements can be read from input file. It would be useful to let user code to decide what to do with element with particular TYPE, MAT and REAL constants.

All this limitation can be avoided if we will read cdb (and other input) files into some intermediate mesh structure and let user code decide how to process this information (how to feed FEStorage and FESolver variables). This intermediate structure should be able to contain:

• mesh (nodes and elements) and it's attributes from native formats (like TYPE, MAT, REAL)
• Constraints: concentrated loads, fixed DoFs
• MPC equations
• Material information
• FE Components (aka NamedSelections)

Currently we use *.vtk plain files in VtkProcessor. This format has several drawbacks:

1. It's needed to write N files for N steps of simulation.
2. It doesn't support simulation time output (only indexing from 0 to N)
3. It takes a lot of disk space as far as it simple text format.

We should add capability to write out XML's based vtu format which supports time steps, compressing and could combine all stuff in a few files.

Is there a possibility to include a sample execute command for nla3d :

[s@localhost Build]$ ./nla3d
08:24:04.815 [INFO] ---=== WELCOME TO NLA PROGRAM ===---
08:24:04.815 [INFO] nla3d 'mesh file in cdb format'
[-element 'element name']
[-material 'material name' constant1 constant2 ..]
[-iterations 'number of iterations']
[-loadsteps 'number of loadsteps']
[-novtk]
[-refcurve 'file with curve']
[-threshold 'epsilob for comparison']
[-reaction 'component name' ['DoF' ..]]
[-rigidbody 'master node' 'component of slaves' ['DoF' ..]]

[s@localhost Build]$ ./nla3d ../test/3d_damper/model.cdb
08:26:08.104 [INFO] ---=== WELCOME TO NLA PROGRAM ===---
08:26:08.104 [ERROR] bool parse_args(int, char**) Please point a material model. Use -material keyword.

[s@localhost Build]$ ./nla3d ../test/3d_damper/model.cdb -material 'Compressible Neo-Hookean' G = 10, mu = 10, E = 30 d= 0.0004, K = 5000, mu = 0.499
08:34:35.171 [INFO] ---=== WELCOME TO NLA PROGRAM ===---
08:34:35.376 [ERROR] static nla3d::Material* nla3d::MaterialFactory::createMaterial(std::__cxx11::string) Can't find material Compressible Neo-Hookean
Segmentation fault (core dumped)

Another important execution example would be about vtk files .

in Fedora 28 :

% [s@localhost Build]$ uname -a
Linux localhost.localdomain 4.18.18-200.fc28.x86_64 #1 SMP Mon Nov 12 03:17:32 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[s@localhost Build]$

Thank you very much .

Mehmet Erol Sanliturk

Для реализации к примеру параллельного запуска нескольких задач с одной и той же сеткой