kanapy Documentation

33
kanapy Documentation Release 0.0.1 Mahesh R.G Prasad Jul 03, 2019

Transcript of kanapy Documentation

Page 1: kanapy Documentation

kanapy DocumentationRelease 0.0.1

Mahesh R.G Prasad

Jul 03, 2019

Page 2: kanapy Documentation
Page 3: kanapy Documentation

Contents

1 Overview 11.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Running tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.6 License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.7 About . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Usage 52.1 Running examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Detailed tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Modeling approach 133.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Code documentation 194.1 Module collision_detect_react . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2 Module entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.3 Module input_output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.4 Module packing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.5 Module voxelization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5 Contributing 215.1 Types of Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.2 Get Started! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.3 Pull Request Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.4 Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6 Credits 256.1 Developers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.2 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

7 History 277.1 0.0.1 (2019-07-01) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

i

Page 4: kanapy Documentation

8 Indices and tables 29

ii

Page 5: kanapy Documentation

CHAPTER 1

Overview

A python package for generating complex synthetic polycrystalline microstructures. The general implementation isdone in Python with performance critical part implemented in C++. Python bindings for the code written in C++ isgenerated using the lightweight header-only library pybind11. The C++ part of the implementation utilizes the Eigenlibrary for efficient linear algebra calculations.

1.1 Features

• User interface to kanapy through scripts are written in pure Python.

• Efficient collision handling through a two-layer collision detection method employing the Octree spatial datastructure and the bounding sphere hierarchy.

• Efficient in-built hexahedral mesh generator for complex polycrystalline microstructures.

• Independent execution of individual modules through easy data storage and handling.

• Flexibility in the choice of particle packing time step to be sent for voxelization (meshing).

• Option to generate spherical particle position and radius files that can be read by voronoi tessellation softwareNeper.

• Option to generate input files for commercial finite-element software Abaqus.

• High-performance for the critical part of the code using Python-C++ bindings.

1.2 Installation

The preferred method to install kanapy is through Anaconda or Miniconda python distributions. Follow the anacondaor the miniconda documentation to install it.

Once done, create a virtual environment for installing python specific packages required for kanapy.

1

Page 6: kanapy Documentation

kanapy Documentation, Release 0.0.1

$ conda create -n myenv python=3.6

Note:

1. myenv can be replaced with any name for your environment.

2. This will install python 3.6 as the default python interpretor within this environment.

Tip: To learn more on managing environments see Anaconda documentation.

Activate the environment using:

$ conda activate myenv

Note: myenv can be replaced with the name of your environment.

The sources for kanapy can be downloaded from the Github repo. You can clone the public repository into a desiredlocation:

$ git clone git://github.com/mrgprasad/kanapy

Once you have a copy of the source, move into the cloned local repository and install the dependencies and kanapyusing:

$ cd kanapy/$ pip install -r requirements.txt$ pip install .

Note: The requirements.txt file contains all the dependencies of kanapy with their specific versions.

1.3 Dependencies

kanapy requires a working C/C++ compiler on your machine. On Linux/OS X the gcc toolchain will work well. Thelightweight header-only library pybind11 is used to create Python bindings for the code written in C++. The C++function kanapy.overlapDetect.collideDetect() can be complied by linking the Eigen library (presentin the directory /kanapy/libs/) using this command. From the kanapy main directory:

$ cd kanapy/$ g++ -O3 -Wall -shared -std=c++11 -fPIC `python3 -m pybind11 --includes` -I ../libs/→˓eigen_cpp/ overlapDetect.cpp -o overlapDetect`python3-config --extension-suffix`

1.3.1 Core dependencies

Below are the listed dependencies for running kanapy:

• NumPy for array manipulation.

2 Chapter 1. Overview

Page 7: kanapy Documentation

kanapy Documentation, Release 0.0.1

• Scipy for functionalities like Convexhull and KDTree.

• pybind11 for creating python bindings for C++ code.

• Eigen for C++ linear algebra operations.

• pytest for running kanapy unit tests.

• sphinx for generating documentation.

1.3.2 Optional dependencies

• Matplotlib for plotting and visualizing.

• OVITO for visualizing simulation data.

1.4 Running tests

kanapy uses pytests to perform all its testing. From the kanapy main directory run the tests using pytest:

$ py.test -v

1.5 Documentation

Documentation for kanapy is generated using Sphinx. The following command generates HTML-based referencedocumentation; for other formats please refer to the Sphinx manual. From the kanapy main directory:

$ cd docs/$ make clean$ make html

Note: The HTML documentation can be found at /kanapy/docs/_build/html/index.html

1.6 License

kanapy is made available under the MIT license

1.7 About

The name kanapy is derived from the sanskrit word káa meaning particle. It is primarily developed at the Interdis-ciplinary Center for Advanced Materials Simulation (ICAMS), Ruhr-University Bochum - Germany. Our goal is tobuild a complete synthetic microstructure generation tool for reasearch and industry use.

1.4. Running tests 3

Page 8: kanapy Documentation

kanapy Documentation, Release 0.0.1

4 Chapter 1. Overview

Page 9: kanapy Documentation

CHAPTER 2

Usage

2.1 Running examples

Two examples come bundled along with the kanapy package. You can run them individually by navigating into thecorresponding directory and executing them as shown:

$ cd kanapy/examples/$ cd sphere_packing/$ python sphere_pack.py

You can view the data generated by the simulation (after the simulation is complete or during the simulation) by launch-ing OVITO and reading in the dump files generated by kanapy from the ../sphere_packing/dump_files/directory. The UI should look similar to this:

5

Page 10: kanapy Documentation

kanapy Documentation, Release 0.0.1

By default OVITO loads the particles as spheres, to change this option to ellipsoids click on Edit columnmapping option (at the bottom right corner of the GUI) and assign the required particle properties and componentsas shown:

6 Chapter 2. Usage

Page 11: kanapy Documentation

kanapy Documentation, Release 0.0.1

For further viewing customization refer to OVITO’s documentation.

2.2 Detailed tutorial

A detailed description of the default examples that come packaged with kanapy is presented here. The two examplessphere_packing and ellipsoid_packing depict the different workflows that has to be setup for generatingsynthetic microstructures with equiaxed and elongated grains respectively. Both these examples contain an input filewherein the user can specify the statistical parameters required for the complete simulation. For a detailed understand-ing of the general framework of packing simulations please refer to: Modeling approach

Note:

1. New examples must be created in a separate directory under the kanapy/examples/ directory structure. Itallows the various kanapy modules an easy access to the json and dump files created by kanapy.

2. The json and dump files help in making the various kanapy modules independent of one another during execu-tion.

3. The input file must always be named as: stat_input.txt to be read by kanapy.

2.2. Detailed tutorial 7

Page 12: kanapy Documentation

kanapy Documentation, Release 0.0.1

2.2.1 Input file structure

An exemplary structure of the input file: stat_input.txt is shown below:

It is built with the following keywords: @ Equivalent diameter, @ Aspect ratio, @Orientation, @ RVE, @ Simulation.

• The keyword @ Equivalent diameter takes in four arguments to generate a log-normal distribution forparticle’s equivalent diameter, they are the Log-normal distribution’s standard deviation and mean, and theminimum and maximum cut-off values for the diameter.

• The @ Aspect ratio takes only the mean value as input. If the resultant microstructure should containequiaxed grains then this value should be set to 1.

• The @ Orientation keyword represents the tilt angle of particles with respect to the positive x-axis. Hence,to generate a distribution it takes in two arguments: the normal distribution’s mean and the standard deviation.

• The @ RVE keyword takes two inputs: the side length of the final RVE required and the number of voxels perRVE side length.

• The @ Simulation keyword takes in two inputs: The total number of time steps and a boolean value forperiodicity (True/False).

Note:

1. The user may choose not to use the built-in voxelization (meshing) routine for meshing the final RVE. Never-theless, a value for voxel_per_side has to be provided.

2. A good estimate for voxel_per_side value can be made by keeping the following in mind: Smallest dimensionof the smallest ellipsoid/sphere should contain atleast 2 voxels.

3. The nsteps value determines the growth of the particle during the simulation. At the start of the simulation allparticles are initialized with null volume. And at each time step they grow in size by the value: diameter/nsteps.So naturally, the last timestep would contain particles in their actual size.

2.2.2 Example workflows

Sphere packing

This example demonstrates the workflow for generating synthetic microstructures with equiaxed grains. The principleinvolved in generating such microstructures are described in the sub-section Microstructure with equiaxed grains.With respect to the final RVE mesh, the user has the flexibility to choose between the in-built voxelization routine andexternal meshing softwares.

If external meshing is required then the positions and weights of the particles (spheres) after packing can be written outto be post-processed. Voronoi tessellation and meshing software Neper can be used to read the positions and weightsfor generating tessellations and FEM mesh. For more details refer to Neper’s documentation.

If the in-built voxelization routine is prefered, then the Module voxelization will generate hexahedral element (C3D8)mesh that can be read by commercial FEM software Abaqus.

Imports: This example requires the following imports from the python standard and kanapy modules.

import osimport syssys.path.append('../..')

(continues on next page)

8 Chapter 2. Usage

Page 13: kanapy Documentation

kanapy Documentation, Release 0.0.1

(continued from previous page)

import kanapyfrom kanapy.input_output import particleStatGeneratorfrom kanapy.input_output import write_position_weightsfrom kanapy.packing import packingRoutine

The methods for generating particle distribution statistics and outputing particle position and weights are importedfrom the input_output module. The routine for the actual particle packing simulation is imported from thepacking module.

Workflow: The complete process consists of 3 stages:

• Particle data generation.

• Particle packing simulation.

• Writing output files.

def main():inputFile = os.getcwd() + '/stat_input.txt'particleStatGenerator(inputFile)packingRoutine()write_position_weights(800)return

if __name__ == '__main__':main()

Note:

1. Individual stages can be run by commenting out the other stages but should be done sequentially.

2. The kanapy.input_output.particleStatGenerator() method requires the stat_input.txtas input.

3. The kanapy.input_output.write_position_weights() method requires the simulation timestepas input. The choice of the timestep is very important. It is suggested to choose the time step at which thespheres are tightly packed and there is least amount of overlap. The remaining empty spaces will get assignedto the closest sphere when it is sent to the tessellation and meshing routine. Please refer to Microstructure withequiaxed grains for more details.

The data required for packing simulation contained in the user defined input file: stat_input.txt is read by themethod kanapy.input_output.particleStatGenerator(). It creates the necessary particle distribution, RVE and simulation information and writes it to json files for future access of other methods. The method kanapy.packing.packingRoutine() when called looks for the json files generated by kanapy.input_output.particleStatGenerator() and reads the files for extracting information required for the packing simulation.At each time step of the packing simulation the kanapy.packing.particle_grow() method will write out adump file containing information of particle positions and other attributes.

Finally, the kanapy.input_output.write_position_weights() method can be called to write out theposition and weights files required for further post-processing. This function takes in the timestep value as an inputparameter and reads the corresponding dump file generated previously. By extracting the particle’s position anddimensions it creates the sphere_positions.txt & sphere_weights.txt files.

If the built-in voxelization is prefered then the kanapy.voxelization.voxelizationRoutine() methodcan be called to generate the hexahedral mesh. This function also takes in the timestep value as an input parameter andreads the corresponding dump file generated previously. The kanapy.input_output.write_abaqus_inp()method can be called to write out Abaqus (.inp) input file. The workflow now looks like:

2.2. Detailed tutorial 9

Page 14: kanapy Documentation

kanapy Documentation, Release 0.0.1

from kanapy.voxelization import voxelizationRoutinefrom kanapy.input_output import write_abaqus_inp

def main():inputFile = os.getcwd() + '/stat_input.txt'particleStatGenerator(inputFile)packingRoutine()voxelizationRoutine(800)write_abaqus_inp()return

if __name__ == '__main__':main()

Storing information in json & dump files is effective in making the workflow stages independent of one another. Butthe sequence of the workflow is important, for example: Running the packing routine before the statistics generationis not advised as the packing routine would not have any input to work on. Both the json and dump files are humanreadable and hence they help the user debug the code in case of simulation problems. As mentioned earlier, the dumpfiles can be read by visualization software OVITO, this provides the user a visual aid to understand the physics behindpacking.

Ellipsoid packing

This example demonstrates the workflow for generating synthetic microstructures with elongated grains. The prin-ciple involved in generating such microstructures are described in the sub-section Microstructure with elongatedgrains. With respect to the final RVE mesh, the built-in voxelization routine has to be used due to the inavailabil-ity of anisotropic tessellation techniques. The Module voxelization will generate hexahedral element (C3D8) meshthat can be read by commercial FEM software Abaqus.

Imports: This example requires the following methods to be imported from kanapy modules.

import osimport syssys.path.append('../..')

import kanapyfrom kanapy.input_output import particleStatGeneratorfrom kanapy.input_output import write_abaqus_inpfrom kanapy.packing import packingRoutinefrom kanapy.voxelization import voxelizationRoutine

The methods for generating particle distribution statistics and outputing Abaqus input file are imported from theinput_output module. The routine for the actual particle packing simulation is imported from the packingmodule. And the routine for generating hexahedral mesh is imported from voxelization module.

Workflow: The complete process consists of 4 stages:

• Particle data generation.

• Particle packing simulation.

• RVE voxelization.

• Writing output files.

def main():inputFile = os.getcwd() + '/stat_input.txt'

(continues on next page)

10 Chapter 2. Usage

Page 15: kanapy Documentation

kanapy Documentation, Release 0.0.1

(continued from previous page)

particleStatGenerator(inputFile)packingRoutine()voxelizationRoutine(800)write_abaqus_inp()return

if __name__ == '__main__':main()

Note:

1. As mentioned previously, individual stages can be run by commenting out the other stages but should be donesequentially.

2. The kanapy.input_output.particleStatGenerator() method requires the stat_input.txtas input.

3. The kanapy.voxelization.voxelizationRoutine() method requires the simulation timestep asinput. The choice of the timestep is very important. It is suggested to choose the time step at which theellipsoids are tightly packed and there is least amount of overlap. The remaining empty spaces will get assignedto the closest ellipsoid when it is sent to the voxelization (meshing) routine. Please refer to Microstructure withelongated grains for more details.

The process of the methods kanapy.input_output.particleStatGenerator() and kanapy.packing.packingRoutine() is similar to that described in Sphere packing. But for voxelization the kanapy.voxelization.voxelizationRoutine() method is called to generate the hexahedral mesh. It takes in thetimestep value as an input parameter and reads the corresponding dump file generated previously. By extractingthe particle’s position and dimensions it creates the final FEM mesh. Finally, the kanapy.input_output.write_abaqus_inp() method can be called to write out Abaqus (.inp) input file.

2.2. Detailed tutorial 11

Page 16: kanapy Documentation

kanapy Documentation, Release 0.0.1

12 Chapter 2. Usage

Page 17: kanapy Documentation

CHAPTER 3

Modeling approach

3.1 Method

Grains in polycrystalline microstructures can be approximated by ellipsoids due to their convex nature. Thus packingthe particles (ellipsoids) which follow a particular size distribution into a pre-defined domain becomes the objective.The general framework employed in this regard is the collision detection and response system for particles underconstant random motion in the box. Each particle 𝑖 in the domain is defined as an ellipsoid in three-dimensionalEuclidean space R3, and random position and velocity vectors r𝑖, v𝑖 are assigned to it. During their motion, theparticles interact with each other and with the simulation box. The interaction between particles can be modeledby breaking it down into stages of collision detection and response. And the interaction between particles and thesimulation box can be modeled by evaluating if the particle crosses the boundaries of the box. If periodicity is enabledperiodic images on the opposite boundaries of the box are created, else the particle position and velocity vectors haveto be updated to mimic the bouncing back effect.

3.1.1 Two layered collision detection

For 𝑛 ellipsoids in the domain, the order of computational complexity would be 𝑂(𝑛2), since each ellipsoid in thedomain is checked for collision with every other ellipsoid. A two layered collision detection scheme is implementedto overcome this limitation. The outer layer uses an octree data structure to segregate the ellipsoids into sub-domains,this process is done recursively until there are only a few ellipsoids in each sub-domain. The inner layer consistsof bounding spheres hierarchy, wherein ellipsoids of each octree sub-domain are tested for collision only when theircorresponding bounding spheres overlap. This effectively reduces the number of collision checks and thus the orderof computational complexity to 𝑂(𝑛𝑙𝑜𝑔(𝑛)). The general framework of collision detection response systems with thetwo layer spatial partitioning data structures has the following features:

• Recursively decompose the given domain into sub-domains based on octree data structure.

• Perform collision test between bounding spheres of ellipsoids belonging to the same sub-domain.

• Test for ellipsoid overlap condition only if the bounding spheres overlap.

• Update the position and velocity vectors r and v based on collision response.

13

Page 18: kanapy Documentation

kanapy Documentation, Release 0.0.1

• Test for collision with simulation domain and create periodic images on the opposite boundaries (or) mimickthe bouncing against the wall effect.

Layer 1: Octree data structure

To ensure efficient collision checks an octree data structure is initialized on the simulation box. With pre-defined limitsfor octree sub-division and particle assignment, the octree trunk gets divided into sub-branches recursively. Thus, byonly performing collision checks between particles belonging to a particular sub-branch, the overall simulation timeis reduced.

Fig. 1: Figure: Simulation domain and its successive sub-branches on two levels, where particles are represented byred filled circles (left). Octree data structure depicting three levels of sub-divisions of the tree trunk (right).

Layer 2: Bounding sphere hierarchy

3.1.2 Overlap detection

Actual overlap of two static ellipsoids is determined by the algebraic separation condition developed by Wang (2001).Consider two ellipsoids 𝒜 : X𝑇AX = 0 and ℬ : X𝑇BX = 0 in R3, where X = [𝑥, 𝑦, 𝑧, 1]𝑇 , the characteristicequation is given as,

𝑓(𝜆) = 𝑑𝑒𝑡(𝜆A+B) = 0

Wang et al. have established that the equation has at least two negative roots and depending on the nature of theremaining two roots the separation conditions are given as,

• A and B are separated if 𝑓(𝜆) = 0 has two distinct positive roots.

• A and B touch externally if 𝑓(𝜆) = 0 has a positive double root.

• A and B overlap for all other cases.

14 Chapter 3. Modeling approach

Page 19: kanapy Documentation

kanapy Documentation, Release 0.0.1

Fig. 2: Figure: Upper layer consists of the octree sub-branch with particles (left) and lower layer is defined bybounding spheres for particles 𝑖, 𝑗 with radii 𝑎𝑖, 𝑎𝑗 respectively (right).

3.1.3 Particle (Ellipsoid) packing

User defined simulation box size and ellipsoid size distribution are used for creating simulation box and ellipsoids. Thesimulation begins by randomly placing ellipsoids of null volume inside the box and each ellipsoid is given a randomvelocity vector for movement. As the simulation proceeds the ellipsoids grow in size along their axes and also collidewith one another updating their position and velocities. The simulation terminates once all the ellipsoids have reachedtheir defined volumes, the process is depicted pictorially in the figure below.

Fig. 3: Figure: Ellipsoid packing simulation with partice interactions at three different timesteps.

Note: Since the application is microstructure generation, where all grains have a predefined tilt angle, the angularvelocity vector (w) is not considered for the ellipsoids and thus their orientations are constrained.

3.1. Method 15

Page 20: kanapy Documentation

kanapy Documentation, Release 0.0.1

3.2 Applications

3.2.1 Microstructure with equiaxed grains

Voronoi and Laguerre tessellations are the most popular methods for polycrystalline microstructure modeling. Theseapproaches require positions and weights as input parameters for generating tessellation cells that resemble grains ofa polycrystal. In this regard, the proposed particle packing approach can be used to generate the required information.Microstructure with equiaxed grains are best approximated by spheres and after obtaining the necessary packingfraction, positions and radii can be outputted.

Fig. 4: Figure: An example of sphere packing (left), radical voronoi tesselation (center) and FE tetrahedral mesh(right).

In this example, to obtain high packing fraction the box size is set as the volume sum of all the spheres. This definitionof the box size will inevitably result in overlap of spheres at the final stages of the simulation. This is because packingfraction of 100% is unachievable without the occurrence of overlaps. Reasonable amount of overlap is accepted, asthe input data obtained from EBSD analysis of grain size is also an approximation. Hence for further post-processing,it is suggested to choose the time step at which the spheres are tightly packed and there is least amount of overlap. Theremaining empty spaces will get assigned to the closest sphere when it is sent to the tessellation and meshing routine.Complete freedom in selecting the desired time step of the simulation to be sent for further processing is one of thehighlights of this approach.

Using the information obtained from sphere packing, polycrystal generation and meshing software Neper can constructthe radical Voronoi tessellations. And FE discretization of the tessellation cells by tetrahedral elements can also beperformed by Neper - Quey (2011) with assistance from FE mesh generating software Gmsh - Geuzaine (2009).

3.2.2 Microstructure with elongated grains

Microstructures generated through conventional manufacturing processes like rolling and state of the art processes likeadditively manufacturing (AM) consists of both elongated and equiaxed grains. In the context of AM, this is due tothe complex solidification process, which occurs as a result of constant re-heating and re-cooling of previously meltedlayers during the manufacturing. The morphology of the grains along with texture plays an important role in theresulting mechanical behavior. Hence, modeling such complex microstructures is vital and in this regard the proposedapproach of random ellipsoid packing is used.

The ellipsoid packing process is similar to that of sphere packing described earlier. Once the ellipsoids are tightlypacked with minimal acceptable overlaps, they are processed further for meshing. Since Voronoi tessellations cannotbe applied to anisotropic particles such as ellipsoids, a voxel based mesh generating routine that utilizes spatial parti-tioning data structure 𝑘-d tree for discretizing the RVE is employed. The voxelization (meshing) routine is made up

16 Chapter 3. Modeling approach

Page 21: kanapy Documentation

kanapy Documentation, Release 0.0.1

Fig. 5: Figure: An example of ellipsoidal packing (left), Voxelization - Initial assignment (center) and Final assign-ment (right).

of 2 stages. The number of voxels in the RVE has a direct influence on the FE solution and the FE simulation time,hence it must be meticulously chosen. The choice is not arbitrary, as it is constrained by how well the grains of theRVE are represented with respect to their geometry and the FEM simulation time.

3.2. Applications 17

Page 22: kanapy Documentation

kanapy Documentation, Release 0.0.1

18 Chapter 3. Modeling approach

Page 23: kanapy Documentation

CHAPTER 4

Code documentation

4.1 Module collision_detect_react

4.2 Module entities

4.3 Module input_output

4.4 Module packing

4.5 Module voxelization

19

Page 24: kanapy Documentation

kanapy Documentation, Release 0.0.1

20 Chapter 4. Code documentation

Page 25: kanapy Documentation

CHAPTER 5

Contributing

Contributions are welcome, and they are greatly appreciated! Every little bit helps, and credit will always be given.

You can contribute in many ways:

5.1 Types of Contributions

5.1.1 Report Bugs

Report bugs at https://github.com/mrgprasad/kanapy/issues.

If you are reporting a bug, please include:

• Your operating system name and version.

• Any details about your local setup that might be helpful in troubleshooting.

• Detailed steps to reproduce the bug.

5.1.2 Fix Bugs

Look through the GitHub issues for bugs. Anything tagged with “bug” and “help wanted” is open to whoever wantsto implement it.

5.1.3 Implement Features

Look through the GitHub issues for features. Anything tagged with “enhancement” and “help wanted” is open towhoever wants to implement it.

21

Page 26: kanapy Documentation

kanapy Documentation, Release 0.0.1

5.1.4 Write Documentation

kanapy could always use more documentation, whether as part of the official kanapy docs, in docstrings, or even onthe web in blog posts, articles, and such.

5.1.5 Submit Feedback

The best way to send feedback is to file an issue at https://github.com/mrgprasad/kanapy/issues.

If you are proposing a feature:

• Explain in detail how it would work.

• Keep the scope as narrow as possible, to make it easier to implement.

5.2 Get Started!

Ready to contribute? Here’s how to set up kanapy for local development.

Note: For a complete tutorial on forking, see https://help.github.com/en/articles/fork-a-repo

1. Fork the kanapy repo on GitHub.

2. Clone your fork locally:

$ git clone [email protected]:your_name_here/kanapy.git

3. Install your local copy into a virtual environment. Assuming you have anaconda installed, this is how you setup your fork for local development:

$ conda create -n myenv$ conda activate myenv$ cd kanapy/$ python setup.py develop

4. Create a branch for local development:

$ git checkout -b name-of-your-bugfix-or-feature

Now you can make your changes locally.

5. When you’re done making changes, check that your changes pass the tests:

$ py.test -v

6. Commit your changes and push your branch to GitHub:

$ git add .$ git commit -m "Your detailed description of your changes."$ git push origin name-of-your-bugfix-or-feature

7. Submit a pull request through the GitHub website.

22 Chapter 5. Contributing

Page 27: kanapy Documentation

kanapy Documentation, Release 0.0.1

5.3 Pull Request Guidelines

Before you submit a pull request, check that it meets these guidelines:

1. The pull request should include tests.

2. If the pull request adds functionality, the docs should be updated. Put your new functionality into a functionwith a docstring, and add the feature to the list in README.rst.

3. The pull request should work for Python >= 3.6. Make sure that the tests pass for all supported Python versions.

Note: For more on pull requests, see https://help.github.com/en/articles/about-pull-requests

5.4 Tips

To run a subset of tests:

$ py.test tests.test_entities

5.3. Pull Request Guidelines 23

Page 28: kanapy Documentation

kanapy Documentation, Release 0.0.1

24 Chapter 5. Contributing

Page 29: kanapy Documentation

CHAPTER 6

Credits

6.1 Developers

• Mahesh R.G Prasad <[email protected]>

• Napat Vajragupta <[email protected]>

• Alexander Hartmaier <[email protected]>

6.2 Contributors

None yet. Why not be the first?

25

Page 30: kanapy Documentation

kanapy Documentation, Release 0.0.1

26 Chapter 6. Credits

Page 31: kanapy Documentation

CHAPTER 7

History

7.1 0.0.1 (2019-07-01)

• First release on GitHub.

27

Page 32: kanapy Documentation

kanapy Documentation, Release 0.0.1

28 Chapter 7. History

Page 33: kanapy Documentation

CHAPTER 8

Indices and tables

• genindex

• modindex

• search

29