LinearElasticityBase
Documentation for LinearElasticityBase.
See the Index for the complete list of documented functions and types.
The code is hosted on GitHub, with some continuous integration services to test its validity.
This repository is created and maintained by @singularitti. You are very welcome to contribute.
Installation
The package can be installed with the Julia package manager. From the Julia REPL, type ]
to enter the Pkg REPL mode and run:
pkg> add LinearElasticityBase
Or, equivalently, via the Pkg
API:
julia> import Pkg; Pkg.add("LinearElasticityBase")
Resolving package versions... Installed LinearElasticityBase ─ v0.3.0 Updating `~/work/LinearElasticityBase.jl/LinearElasticityBase.jl/docs/build/developers/Project.toml` [c9ccf908] + LinearElasticityBase v0.3.0 Updating `~/work/LinearElasticityBase.jl/LinearElasticityBase.jl/docs/build/developers/Manifest.toml` [d360d2e6] + ChainRulesCore v1.15.7 [9e997f8a] + ChangesOfVariables v0.1.6 [bbf7d656] + CommonSubexpressions v0.3.0 [163ba53b] + DiffResults v1.1.0 [b552c78f] + DiffRules v1.12.2 [ffbed154] + DocStringExtensions v0.9.3 [b7d42ee7] + Einsum v0.4.1 [f6369f11] + ForwardDiff v0.10.34 [3587e190] + InverseFunctions v0.1.8 [92d709cd] + IrrationalConstants v0.1.1 [692b3bcd] + JLLWrappers v1.4.1 [c9ccf908] + LinearElasticityBase v0.3.0 [2ab3a3ac] + LogExpFunctions v0.3.22 [1914dd2f] + MacroTools v0.5.10 [77ba4419] + NaNMath v1.0.2 [276daf66] + SpecialFunctions v2.1.7 [90137ffa] + StaticArrays v1.5.15 [1e83bf80] + StaticArraysCore v1.4.0 [98f94333] + Tensorial v0.12.9 [efe28fd5] + OpenSpecFun_jll v0.5.5+0 [2f01184e] + SparseArrays [10745b16] + Statistics [8dfed614] + Test [05823500] + OpenLibm_jll v0.8.1+0 Precompiling project... ✓ LinearElasticityBase 1 dependency successfully precompiled in 2 seconds. 40 already precompiled. 1 dependency precompiled but a different version is currently loaded. Restart julia to access the new version
Documentation
- STABLE — documentation of the most recently tagged version.
- DEV — documentation of the in-development version.
Project status
The package is tested against, and being developed for, Julia 1.6
and above on Linux, macOS, and Windows.
Questions and contributions
Usage questions can be posted on our discussion page.
Contributions are very welcome, as are feature requests and suggestions. Please open an issue if you encounter any problems. The Contributing page has a few guidelines that should be followed when opening pull requests and contributing code.
Manual outline
- Installation Guide
- Contributing
- Code of conduct
- Join the community forum
- Improve the documentation
- File a bug report
- Contribute code to LinearElasticityBase
- Step 1: decide what to work on
- Step 2: fork LinearElasticityBase
- Step 3: install LinearElasticityBase locally
- Step 4: checkout a new branch
- Step 5: make changes
- Step 6a: test your code changes
- Step 6b: test your documentation changes
- Step 7: make a pull request
- Step 8: respond to comments
- Step 9: cleaning up
- Style Guide
- Design Principles
- Consistency vs adherence
- Community contribution guidelines
- Open source contributions are allowed to start small and grow over time
- Generic code is preferred unless code is known to be specific
- Internal types should match the types used by users when possible
- Trait definition and adherence to generic interface is preferred when possible
- Macros should be limited and only be used for syntactic sugar
- Errors should be caught as high as possible, and error messages should be contextualized for newcomers
- Subpackaging and interface packages is preferred over conditional modules via Requires.jl
- Functions should either attempt to be non-allocating and reuse caches, or treat inputs as immutable
- Out-Of-Place and Immutability is preferred when sufficient performant
- Tests should attempt to cover a wide gamut of input types
- When in doubt, a submodule should become a subpackage or separate package
- Globals should be avoided whenever possible
- Type-stable and Type-grounded code is preferred wherever possible
- Closures should be avoided whenever possible
- Numerical functionality should use the appropriate generic numerical interfaces
- Functions should capture one underlying principle
- Internal choices should be exposed as options whenever possible
- Prefer code reuse over rewrites whenever possible
- Prefer to not shadow functions
- Troubleshooting