juliafem / fembasis.jl Goto Github PK

FEMBasis contains interpolation routines for finite element function spaces. Given ansatz and coordinates of domain, shape functions are calculated symbolically in a very general way to get efficient code. Shape functions can also be given directly and in that case partial derivatives are calculated automatically.

Home Page: https://juliafem.github.io/FEMBasis.jl/latest

License: MIT License

Julia 100.00%

fem interpolation

fembasis.jl's Introduction

JuliaFEM.jl - an open source solver for both industrial and academia usage

Everything is outdated. See other FEM options from here: https://github.com/JuliaPDE/SurveyofPDEPackages?tab=readme-ov-file#fem

JuliaFEM organization web-page: http://www.juliafem.org

The JuliaFEM project develops open-source software for reliable, scalable, distributed Finite Element Method.

The JuliaFEM software library is a framework that allows for the distributed processing of large Finite Element Models across clusters of computers using simple programming models. It is designed to scale up from single servers to thousands of machines, each offering local computation and storage. The basic design principle is: everything is nonlinear. All physics models are nonlinear from which the linearization are made as a special cases.

At the moment, users can perform the following analyses with JuliaFEM: elasticity, thermal, eigenvalue, contact mechanics, and quasi-static solutions. Typical examples in industrial applications include non-linear solid mechanics, contact mechanics, finite strains, and fluid structure interaction problems. For visualization, JuliaFEM uses ParaView which prefers XDMF file format using XML to store light data and HDF to store large data-sets, which is more or less the open-source standard.

Vision

On one hand, the vision of the JuliaFEM includes the opportunity for massive parallelization using multiple computers with MPI and threading as well as cloud computing resources in Amazon, Azure and Google Cloud services together with a company internal server. And on the other hand, the real application complexity including the simulation model complexity as well as geometric complexity. Not to forget that the reuse of the existing material models as well as the whole simulation models are considered crucial features of the JuliaFEM package.

Recreating the wheel again is definitely not anybody's goal, and thus we try to use and embrace good practices and formats as much as possible. We have implemented Abaqus / CalculiX input-file format support and maybe will in the future extend to other FEM solver formats. Using modern development environments encourages the user towards fast development time and high productivity. For developing and creating new ideas and tutorials, we have used Jupyter notebooks to make easy-to-use handouts.

The user interface for JuliaFEM is Jupyter Notebook, and Julia language itself is a real programming language. This makes it possible to use JuliaFEM as a part of a bigger solution cycle, including for example data mining, automatic geometry modifications, mesh generation, solution, and post-processing and enabling efficient optimization loops.

Installing JuliaFEM

Inside Julia REPL, type:

Pkg.add("JuliaFEM")

Initial road map

JuliaFEM current status: project planning

Version	Number of degree of freedom	Number of cores
0.1.0	1 000 000	10
0.2.0	10 000 000	100
1.0.0	100 000 000	1 000
2.0.0	1 000 000 000	10 000
3.0.0	10 000 000 000	100 000

We strongly believe in the test driven development as well as building on top of previous work. Thus all the new code in this project should be 100% tested. Also other people have wisdom in style as well:

The Zen of Python:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Errors should never pass silently.

Citing

If you like using our package, please consider citing our article

@article{frondelius2017juliafem,
  title={Julia{FEM} - open source solver for both industrial and academia usage},
  volume={50}, 
  url={https://rakenteidenmekaniikka.journal.fi/article/view/64224},
  DOI={10.23998/rm.64224},
  number={3},
  journal={Rakenteiden Mekaniikka},
  author={Frondelius, Tero and Aho, Jukka},
  year={2017},
  pages={229-233}
}

Contributing

Developing JuliaFEM encourages good practices, starting from unit testing both for smaller and larger functions and continuing to full integration testing of different platforms.

Interested in participating? Please start by reading contributing.

fembasis.jl's People

Contributors

Stargazers

Watchers

Forkers

tkelman sudhakaryogaraj mlubin batmanabcdefg xtalax juliatagbot bocc haoxiangmiao hsugawa8651 mfkiwl standardgalactic maumenegaz

fembasis.jl's Issues

Number of Warning messages in FEMBasis

FEMBasis seems to fill stdout log with warnings, f.ex.:
https://travis-ci.org/JuliaFEM/JuliaFEM.jl/jobs/428170944

Any idea where this roots from?

Use StaticArrays.jl

It might be useful to use non-allocating static arrays all over the place

Fix coverage up to 100 %

https://coveralls.io/builds/15280039/source?filename=src%2Fcreate_basis.jl

Looks that Coverage.jl is not understanding the content inside macro.

TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Register v0.3.1

@JuliaRegistrator register()

Use of precompile()

Result:

WARNING: eval from module __SANDBOX__ to FEMBasis:
:u = -1
  ** incremental compilation may be broken for this module **

WARNING: eval from module __SANDBOX__ to FEMBasis:
:v = -1
  ** incremental compilation may be broken for this module **

WARNING: eval from module __SANDBOX__ to FEMBasis:
:w = -1
  ** incremental compilation may be broken for this module **

WARNING: eval from module __SANDBOX__ to FEMBasis:
Expr(:call, :*, Expr(:call, :^, :u, 2)::Any, Expr(:call, :^, :v, 2)::Any, Expr(:call, :^, :w, 2)::Any)::Any
  ** incremental compilation may be broken for this module **

WARNING: eval from module __SANDBOX__ to FEMBasis:
:u = 1
  ** incremental compilation may be broken for this module **

WARNING: eval from module __SANDBOX__ to FEMBasis:
:v = -1
  ** incremental compilation may be broken for this module **

WARNING: eval from module __SANDBOX__ to FEMBasis:
:w = -1
  ** incremental compilation may be broken for this module **

WARNING: eval from module __SANDBOX__ to FEMBasis:
Expr(:call, :*, Expr(:call, :^, :u, 2)::Any, Expr(:call, :^, :v, 2)::Any, Expr(:call, :^, :w, 2)::Any)::Any
  ** incremental compilation may be broken for this module **

Implement Hermite etc. basis

We need to have methods to calculate basis with continuous derivatives. Resulting system of equations involves derivatives of functions. Concrete example p(x) = a0*1 + a1*x + a2*x^2 + a3*x^3, and equations are p(-1), p'(-1), p(1), p'(1). Calculus is able to automatically differentiate this.

Documentation index is not descriptive

Documentation is empty. Now it looks like this.

Implement hierarchical basis elements

Implement P elements

API changes to FEMBasis 0.3

In the next minor, we should somehow solve the issue of having multiple basis functions for the same topology. Motivation comes here: https://github.com/JuliaFEM/FEMPlates.jl/blob/master/src/dkt.jl#L34

It looks that this is kind of normal situation, that some basis functions need to be calculated "in the fly" based on the actual geometry. And the same topology can have different basis functions depending on the problem. We can default the basis function evaluation to Lagrange nodal basis, but we should also offer an option to create more complex basis functions which cannot necessarily be constructed beforehand.

For constructing nodal basis functions, we could have something like

struct Tri3 end
struct Lagrange end
X = ((0.0,0.0), (1.0,0.0), (0.0,1.0))
p = :(1 + u + v)
@create_basis(Lagrange, Tri3, p, X)

And after that, we can evaluate basis functions

get_basis(Lagrange(), Tri3(), xi)
get_basis(Tri3(), xi) # defaults to Lagrange..?

Then, we could also implement e.g. that DKT basis, but for that, we need the geometry of the element:

struct DKT end
function FEMBasis.get_basis(::DKT, ::Tri3, X)
    # implementation
end
get_basis(DKT(), Tri3(), X, xi)

There is even more complicated situations, where the basis functions depends not only the element geometry, but also geometry from surrounding elements, like bi-orthogonal basis in contact mechanics.

Release 0.3.2

Would it be possible to release version 0.3.2 to the General registry? Once this update is complete, several pieces of the ecosystem may begin working; c.f.:

JuliaFEM/JuliaFEM.jl#257
JuliaFEM/FEMBase.jl#70

Examples are missing

We should generate some examples from test files using Literate.jl.

Perhaps stop punning on Base functions?

FEMBasis does some "puns" on Base functions, for example:

        function Base.size(::Type{$name})
            return ($D, $N)
        end

        function Base.size(::Type{$name}, j::Int)
            j == 1 && return $D
            j == 2 && return $N
        end

        function Base.length(::Type{$name})
            return $N
        end

length is typically defined for collections (or at least when the instance of the type is a collection). AbstractBasis is not iterable and it probably shouldn't be. Instead of defining these functions I think they should have their own names ndim, nbasis.
Overloading Base functions are typically meant so you can write generic code but there is no way to write generic code with puns like this.