I am a second-year undergraduate student pursuing a Bachelors degree (B.E.) in Computer Engineering at Thapar Institute of Engineering and Technology, India. I was introduced to programming about three years ago. I have taken courses in Higher Mathematics and physics including Linear Algebra, Discrete Mathematics, Engineering Mathematics - I, II & III, mechanics, thermo-fluids and solids, and structures as well as in Computer Science including Data Structures and Algorithms and operating systems. My major interest lies in the field of machine learning (especially neural nets).

• I work on Ubuntu 16.04 LTS machine with Atom as my primary text editor because of its user-friendliness.

• I have been programming for about 3 years and using C/C++ from then. I am also proficient in Python having 2 over 2 years of experience.

• I mostly have used python to do my personal projects. My GitHub contains all the projects I've taken up till now.

• I am familiar with Mercurial and Git as version control and use pdb for debugging.

I got introduced to SymPy in Dec 2017 and started contributing since then. Here is the list of all of my contributions along with their description in chronological order:

• (Merged) PR #13829 : Implementation of interpolating_spline for symbolic interpolation of B-splines. The function returns a spline of degree d for given X and Y values.

• (Merged) PR #13888 : Replaced <= operator with .is_nonpositive.

• (Merged) PR #13878 : Added _cdf method for some probability distributions which returned precomputed CDF. It made evaluation of cdf much faster as now there was no need to integrate pdf in order to obtain cdf.Fixed #13830

• (Merged) PR #13969 : Added _print_Relational method for PyhtonCodePrinter. Before this pycode gave error on printing realtional operators. _print_Piecewise was also improvised to generate an executable python code.

• (Merged) PR #13941 : Added _solve_trig2 helper function to solve trignometric equations which previously gave error. _solve_trig2 function gets called everytime the primary helper function (_solve_trig1) cant solve a equation. Fixed #13899

• (Merged) PR #14026 : increased number of iterations by one inside is_in used by has. Fixed #14025

• (Closed) PR #14054 : The issue was evaluation of conditions like (0 <= x) & Eq(x, 2*pi) to True without any constraint of Eq(x, 2*pi) which produced wrong evaluation of _intervals.

• (Merged) PR #14029 : changed **args argument of special and ortho polyomials to polys=False inside polys. Fixed #14028

• (Merged) PR #14104 : stringPict instance was replaced by prettyForms instance inside _print_DiracDelta. Fixed #14101

• (Open) PR #14121 : added few conditions to avoid wrapping of Tuple by a list which caused TypeError inside cse for Tuples containing matrices. Fixes #14118

• (Merged) PR #14003 : Implemented _print_Symbol for fcode. Fortran is a case-insensitive language and earlier symbols like X and x were printed without taking care of it by fcode. But after this PR fcode(exp(x_) + sin(x*y) + cos(X*Y)) returns exp(x_) + sin(x*y) + cos(X__*Y_).

• (Open) PR #14132 : Added a check and Piecewise for returns of gosper_sum in the cases when denominator of the Sum tends to zero. Fixes #14129

• (Merged) PR #14166 : changed \mathcal{O} to \big{O} inside _print_Order of LatexPrinter. Fixed #14163

• (Open) PR #14150 : output of cse should be of form (List(Symbol, expression), List(reduced_exprs)) but on some inputs the second list gave a Tuple of reduced_exprs instead of reduced expression themselves.

• (Merged) PR #14188 : removed newline before :members: and disabled autodoc_inherit_docstrings. Fixed #14187

• (Merged) PR #14225 : Changed isinstance(eq, bool) or eq.is_Atom to not isinstance(eq, Basic) or eq.is_Atom so that is_Atom property is used only on Basic instances . Fixed #14216

• (Open) PR #14207 : parenthesises non-evaluated Pow when exponent is -1. Earlier Mul(-2, u, Pow(Mul(a,a,evaluate=False), -1, evaluate=False), evaluate=False) gave -2*u/a*a. This PR corrects it to -2*u/(a*a). Fixes #14160

• (Merged) PR #14180 : Added _print_log that allows custom printing of logarithmic functions by accepting ln_notation as a boolean (default=False) keyword argument. Fixed #14175

• (Merged) PR #14248 : Earlier expression containing MatrixSymbol were printed like (-1)*B + (-1)*A*B + A, -B + -A⋅B + A and '-1 B + -1 A B + A' by str, pretty and latex printers respectively. After this PR, outputs changed to -B - A*B + A, -B -A⋅B + A and '-B - A B + A'. Fixed #14237

• (Merged) PR #14317 : Earlier latex printed Poly as an Expr instance (poly.as_expr) which made monomials of Poly to have a different order when printed. Fixed #14316

• (Open) PR #14308 : Improves pretty printing of vectors having fractional scalars. Fixes #12675

• (Merged) PR #14342 : Instead of wrapping negative nodes with ast.UnaryOp(), this PR wrapped the negative terms with a Call instance of Mul having -1 as one of its argument. Earlier sympify('2*2 - 2*2 ', evaluate=False) gave -4 + 2*2. Now it is -2*2 + 2*2. Fixed #11095

• (Open) PR #14446 : slope and deflection functions of continuum_mechanics now returns a partially evaluated value rather than a wrong one.

• (Open) PR #14453 : Added more beam deflection problems in continuum_mechanics documentation.

• (Merged) PR #14455 : ConditionSet(f, symbol, domain) was changed to ConditionSet(symbol, Eq(f, 0), domain).

• (Merged) PR #14458 : Raises NotImplementedError whenever limit approaches zoo. Fixed #14456

• (Merged) PR #14535 : _solve_trig was modified to return a better solution(if exists) instead of ConditionSet. Also, _solve_trig2 was made capable of handling a corner case.

• (Open) PR #14551 : _solve_trig was modified to return a better solution(if exists) instead of ConditionSet. Also, _solve_trig2 was made capable of handling a corner case.

In GSoc 2016 continuum_mechanics module was implemented using SingularityFunction. I was first introduced to this module a few months back, when I used this for solving some beam problems in my tutorial sheets as I am having a course of Solids and Structures(UES010) at my university this semester. The simplicity and cleanness in the logic implemented in this module increases my likeliness towards it. My proposal aims at making the current continuum_mechanics module more robust and increasing its capabilities to solve different type of beam systems. As I have just completed this section from my course, I am familiar with required theory and also have gone through a variety of beam problems. My primary motivation for this project is my liking towards the field of mechanics in general. A blog was maintained last time when this project was introduced and honestly it helped me alot to know ins and outs of this module in less time. I would love to create a blog continuing from there, so that it can be easier for others to expand this module.

I would like to work in a systematic way by focussing different aspects of project one at a time. So, I have planned to divide my work into four stages. Each stage serves a general purpose

• stage 1 : This would mainly focus on improving beam solving capabilitiesthe of the module. Also, some necessary and missing functions would be implemented.

• stage 2 : This would aim at the implementation of new type of beam problems which earlier were unsolvable(Along with implementation of Support class which would make the system more neat and robust).

• stage 3 : Implementation of 3Dbeam class.

• stage 4 : Plotting.

Beginning of each stage would be marked by creation of a Pull Request with some sub-tasks in it. After completion of each stage we will have code that can be merged with the codebase, after the tests pass, and used right away.

A strucure in which the laws of statics are not sufficient to determine all the unknown forces or moments is said to be Statically indeterminate. Current Beam class only uses static equilibrium equations to solve the unknown reactions. So, Statically indeterminate beam problems in beam class cant solve for reaction forces.

                          12 KN
  \\\\|                    ||
  \\\\|                    \/
  \\\\|________________________________
  \\\\|________________________________|                              
  \\\\|          :          :         oo
  \\\\|----------|----------|----------|  

          2.0 m      2.0 m      2.0 m

for the above example:

In  [] : E,I,M,V, V2 = symbols('E I M V V2')

In  [] : b = Beam(6, E, I)

In  [] : b.apply_load(V, 0, -1)

In  [] : b.apply_load(M, 0, -2)

In  [] : b.apply_load(12, 4, -1)

In  [] : b.apply_load(V2, 6, -1)

In  [] : b.solve_for_reaction_loads(V, M, V2)

In  [] : b.load

Out [] :
          -1                 -1                  -2             -1
V₂⋅<x - 6>   + (-V₂ - 12)⋅<x>   + (6⋅V₂ + 48)⋅<x>   + 12⋅<x - 4>  

Clearly V and V2 are still present in the load. But SingularityFunction can be used to solve this problem.

Another example is any system having more than two supports(or one fixed support). Therefore inability to solve statically indeterminate beams also prevents us using more than two supports in any beam system.

But SingularityFunction can be used to solve this problem. As explained in this course vedio, such structures are analyzed by writing the appropriate equations of static equilibrium and additional equations pertaining to the deformation and constraints known as compatibility condition.

So, we can use boundary_conditions to compute slope and deflection in term of reactions, thus obtaining required number of compatibility condition.

So the pseudo code should look like

Compute static indeterminacy of the beam
If  static indeterminacy not equals zero
	If  static indeterminacy ==  boundary_conditions
		Compute  slope or deflection(or both) using them
		Solve the system of equations and find reactions
else 
	return unevaluated reactions

In case of a non-prismatic beam, the flexural rigidity EI is variable and till now we were considering second moment is constant throughout the length of beam and Material of the beam is homogenous and isotropic (Constant E).

Beam examples with variable cross-section(or elastic modulus) are not very uncommon. Like consider this example

Currently we compute slope as

which is correct as I and E are constant and thus can betaken outside of integral. But when any of them is a function of length of beam, the situatuion change. Therefore we would handle such problems in the following way

1. shear_force and bending_moment are evaulated in the similar way we find them in normal beams

2. Check if I is the function of x

3. If it is, then find slope using

Note : M(x) is wriiten in terms of SingularityFunction, so in these cases we will have to rewrite M(x) in terms of Piecewise and then integrate.

4. Then compute deflection(as usual)

Point of Contraflexure is the point where Bending moment diagram changes its sign from +ve to -ve or vice-versa (or where value of bending moment is zero). In other words we can say, it gives details of location where the beam transits form Sagging to Hogging phase of bending and Vice-Versa.

     - point_cflexure() : returns point of contraflexure.

Position and value of maximum deflection in a beam can be of interest. For simply supported beams, the maximum deflection occurs where the slope is zero. Thus the position of maximum deflection is found out by equating the slope equation zero.

while for Cantilever Beam, this occurs at the free support end. In case of single/double overhanging beams, we can compare both: the point where slope becomes zero and the overhanging end. We can have a similar method for the max bending moment (would occur at the point of zero shear force), maximum shear force and finding point where Pure bending occurs can be implemented.

    - `max_delfection()` : returns point of maximum deflection along with its 
                           value as a dictionary.

    - `max_bmoment()`    : returns point at which maximum bending moment occurs  
                           along with its value as a dictionary.

    - `max_shearforce()` : returns point of maximum shear force along with its 
                           value as a dictionary.

    - `pure_bending()`   : returns point of zero shear force.

I myself have faced this problem many times. While solving beam problems if you miss-type a load value or just simply want to remove a load, you will have to instantiate whole Beam from scratch again. There is no abstract way to remove a load once applied and moreover it's as simple as:

def remove_load(self, value, start, order, end=None):
    x = self.variable
    value = sympify(value)
    start = sympify(start)
    order = sympify(order)

    if value*SingularityFunction(x, start, order) in self._load.args:
        self._load -= value*SingularityFunction(x, start, order)

        if end:
            if order == 0:
                self._load += value*SingularityFunction(x, end, order)

            elif order.is_positive:
                self._load += value*SingularityFunction(x, end, order) 
                                  + value*SingularityFunction(x, end, 0)

            else:
                raise ValueError("""Order of the load should be positive.""")

Singularity functions can be elegantly used to overcome discontinuities in the various loads acting on the entire beam, but they cannot blaze the various loads for the entire beam when the beam has one or more discontinuities in its slope when the loads are applied to act on it. In fact, singularity functions cannot be above the rules of mathematics that require a function to have continuous slopes in a domain if it is to be integrated or differentiated in that domain (in our case its beam).

If a beam is composed of two or more segments that are connected, say for example, by hinges (e.g., a Gerber beam), then the beam has discontinuous slopes at the hinge connections when loads are applied to act on it. In such a case, the deflections and any statically indeterminate reactions must be analyzed by dividing the beam into segments, each of which must have no discontinuity in slope. Otherwise, erroneous results will be reached.

Current Beam class can't solve such systems because it misses out the above fact (along with the absence of a way to represent connected beams). We can break the implementation of this in two steps:

After going through some books I found following three type of connections were common to occur in beam problems

Type Of Connection	Figure	Number Of Reactions	Boundary Conditions
Hinged Connection		2 (No moment)	M=0
Fixed Connection(along the axis)		3	**No need**
Fixed Connection(at 90 degrees)		3	dΘ = 0

So as we can see in the above table, each type of connection has some Boundary_conditions which can help us in making these systems solvable.

Now each type of composite beam system is solved differently

After finding reactions on the composite system as a whole, all we have to do is to split the system at a hinge. As moment due to hinge is 0, only one reaction force perpendicular to each sub-beam which would be equal and opposite. So the above system gets decomposed/solved as shown in the figure.

So for the first sub-beam bending_moment, slope and deflection equations are as follow

Deflection at hinge(for boundary_condition of next sub-beam):

let x2(later would be substituted by x - 7 when combining both sub-beams) represent length of scond sub-beam.

Second beam

Thus any equation for the entire system would be sum of corresponding equations of both the sub-beams. Hence, delfection for above beam system woul look like

⎧             3                        4                3                 4         
⎪ - 4.16⋅x  +  83.93⋅x  + 1.25⋅<x - 2>  -  11.67⋅<x - 5>  -  1.25⋅<x - 5>          
⎪ ─────────────────────────────────────────────────────────────────────────   for x <7
⎪                                   E⋅I                                          
⎨                                                                             
⎪                                   3               2                           
⎪         50.45⋅x  -  0.4165⋅(x - 7)  + 3.65⋅(x - 7)  -  426.05                  
⎪  ───────────────────────────────────────────────────────────────────────   for x <10
⎩                                   E⋅I                                          

This would be another cake walk for our Beam class as we can consider the whole system as a single beam but variable E and I values. So equation for slope of our deflected beam(L being the total length of system) becomes:

Let's talk about an example similar to discussed here(in our case beams would have negligible thickness). The approach would be to solve the system as two independent beams. But there is a catch here that when we will break the perpendicular fixed join, we would be needing another equation to solve for internal reactions/unknowns. The another equation would be obtained from the fact as connection cannot rotate, the angle between slope of two beams would remain same, that is:

So there would be new join function which would take two attributes:

    - `Beam` : a `Beam` class object.
    - `Type_of_connection` : `fixed` or `hinged`. Default set to `Fixed`.
    - `angled` : `True` when both beams are perpendicular. Default set to `False`

So to join Beam b2 to b1 the code would be:

In  [] : E1, I1, E2 ,I2 = symbols('E1 I1 E2 I2')

In  [] : b1 = Beam(6, E1, I1)

In  [] : b2 = Beam(4, E2, I2)

In  [] : b.join(b2, fixed, angle=False)

Current Beam class has Length, Young's Modulus, Moment of Inertia, load, bc_slope and bc_deflection as attributes. We initialize a beam like Beam(length, E, I) where E and I are Young's Modulus and Moment of Inertia respectively and length is a Symbol(or a number).

The above API works fine but it also crushes any possibility to solve a system having non-horizontal beams or any system having loads which are not perpendicular to beam.

To overcome all these issues, I will allow the following attributes to be more than just a Symbol:

      - `length` : Length can now be a `vector` or a Symbol.
                   If `length` is not a vector, x-axis(horizontal) would be taken 
                   as default direction.
      
      - `load` :  Load can now be a `vector` or a Symbol.
                  If `length` is not a vector, y-axis(vertical) would be taken 
                  as default direction.

This Modifies API without any conflict with the older one as a beam with symbolic/numeric length would never get affected by this change.

If any of length or load is a vector then take the component of load perpendicular to the length of beam. Suppose A is the length vector of beam and B is the load applied then

So after finding the projection of load perpendicular to the beam, we can simply use all the functions of our class by using its magnitude.

Suppose we have to solve a problem in which beam of length l is supported at an angle of theta with the horizontal and a point load is applied at the end of the beam along negative y-axis. The output API of this system would look like:

In  [] : from sympy.vector import CoordSys3D

In  [] : N = CoordSys3D('N')

In  [] : length = l*cos(theta)*N.i + l*cos(theta)*N.j

In  [] : b = Beam(length, E, I)

In  [] : b.apply_load(3, l*cos(pi/6), -1)   # As default direction is set 
                                            # along y-axis

A beam has to be supported by support structures at least at two points in order to remain static. Each support structure applies reaction forces on the object in particular directions.

Type Of Support	Figure	Number Of Reactions	Boundary Conditions
Pinned		2	y=0
clamed		3	Θ=0 y=0
Roller		1	y=0

Now in the present Beam class, we ourselves have to consider the reaction forces(and their order) and apply them using apply_load function. And also for each support structure, there are some pre-defined boundary conditions for slope(Θ) and deflection(y). The Support class would have all this information for each support type. Some of its attributes and methods are

 - type : can be `clamped`, `hing` or `roller`
 - show_reactions() : will return a Dictionary with `Reaction` as 
                      a key for evaluated `value`

apply_support method would be added to beam class which would internally add all reactions and boundary conditions due to that support structure.

The output API would look like

In  [] : s1 = Support(`clamped`)

In  [] : s1.show_reaction()

Out [] : 
{M:M, R:R}             # unsolved reactions

In  [] : b = Beam(6, E, I)

In  [] : b.apply_support(s1, 0) # compare this with b.apply_load(R, 0, -1)
                                #                   b.apply_load(M, 0, -2)
                                #                   b.bc_deflection = [(0, 0)]
                                #                   b.bc_slope = [(0, 0)]

In  [] : b.apply_load(12, 6, -1)

In  [] : b.solve_for_reaction_loads()     # will solve for all support reactions
                                          # (if no argument passed) 

In  [] : b.reaction_loads

Out [] :
{s1: {M: 72, R: -12}} 
 
In  [] : b.deflection()       # no need to write boundary conditions because 
                              # of support

Out [] :
      2        3            3
36⋅<x>  - 2⋅<x>  + 2⋅<x - 6> 
─────────────────────────────
             E⋅I                  

Each Support instance can be applied to Beam using apply_support method. So, in nutshell benefits of Support class are:

• This would make instantiating of a beam system easier as for every support in the system, previously we had to apply nearly two reaction forces and at least one Boundary condition. Missing any of this information returned incomplete solution and thus increasing chances of error.

• Old way to solve beam systems can also be used for non-conventional support structures.

• This thus also ensures equal number of boundary conditions would be added, due to support structure, for every reaction introduced. Hence, ensuring we can solve for reactions everytime if our system becomes statically indeterminate here.

A separate class for solving beam system in three dimensions would be implemented. In the 2D beams, height of the cross-section was ignored hence shear deformations were of little importance due to high value of shear modulus G .

But in a Quasistatic Timoshenko beam we have a finite G (shear modulus) value, hence shear deformations are not negligible and cant be ignored. Let u be continuous displacement field and w and θ be position and rotation vectors of a beam respectively. Therefore,

After manipulations on above equation (reference), for a general Timoshenko beam (beams in which cross-section remains plane during deformation), the axial deformation is governed by the equation

whereas bending deformation in the y-direction is defined by the coupled equations

Similarly, the flexural deformations in the z-directions are determined by

where

• G is shear modulus

• A is cross-sectional area

• A_y and A_z are shear areas

• θ_z is roatation vector components in y and z directions respectively

NOTE : As we can see, these system of equation contain alot of variables and is messy to solve for.Thatswhy Generic Timoshenko beam would only be implemented if rest of four Stages are completed well before the deadline.

So, We would take a special case of Timoshenko beam, known as Bernoulli-Euler beam, which is alot more simpler and cleaner to solve (also aligns with rest of our module in terms of assuming high value of G)

So when that is the cross-sections remains orthogonal to beam axis during deformation(Bernoulli-Euler beam), we get a special case which uncouples completely into following differential equations for determination of w_x, w_y and w_z :

Solving each equation will give us required parameters in a particular plane.

NOTE : The above system of eqautions is similar to one we solve to get deflection in 2D. The only difference is addition/subtraction of derivative of moment in the another plane w.r.t length of beam. So all methods would have a logic somewhat simialr to beam class.

The 3dbeam class would inherit from Beam class and would have following overloaded/addition methods:

class 3dbeam(Beam):

       `shear modulus` : Defines shear modulus of beam(Timoshenko beams).
                         default set to` None`(Bernoulli-Euler Beam).

       `apply_load` : method for applying load (only as a vector).

       `bc_moment` : set boundary conditions on `bending_moment`

       `bc_slope` : set boundary conditions on `slope`

       `bc_deflection`: set boundary conditions on `deflection`

       `shear_force` : overloaded method to compute shear force in a 3d beam

       `bending_moment` : overloaded method to compute bending moment in a 3d beam
   
       `deflection` : overloaded method to compute deflection in a 3d beam

The output API would look like

In  [] : from sympy.vector import CoordSys3D

In  [] : N = CoordSys3D('N')

In  [] : b = Beam(6, E, I)

In  [] : load = N.i + 2*N.j - N.k  # This just a way to input load.
                                   # Internally every component would
                                   # be treated as a separate force

In  [] : b.apply_load(load, 3, -1)

visualization is an important important aspect when it comes to beam delfection problems. SymPy has a Plotting Module which can be used as our backend.

As SymPy plotting module supports dynamic positioning of co-ordinates, getting value of any qauntity by just hoverig cursor over it is an added advantage.

So we would have following methods in this module

     `plot_load` : plots load applied on the beam(returns error if system cant be solved)

     `plot_shear` : plots Shear Force Diagram (SFD)

     `plot_moment` : plots Bending Moment Diagram (BMD)

     `plot_slope` : plots slope of elastic curve of deflected beam

     `plot_deflection` : plots the curvature of deflected beam

     `plot_internals` : plots `shear_force` and `bending_moment` on a single graph

     `plot_all` : plots `shear_force`, `bending_moment` and `deflection` due to them on a single graph

The output API would look like

In  [] : b.plot_deflection()
Out []:
<sympy.plotting.plot.Plot object at 0x7f58462c88d0>

Following is the rough idea how the plots would look like(plot_internals and plot_all)

where red plot represents variation of shear force

and blue plot represents variation of bending_moment

where green represents variation of shear force

blue represents variation of bending_moment

and red represents deflected beam

I am interested in making the indivisual plots more visually appealing, anything close to this should work.

An important TODO would be plotting of non-horizontal beams which I would have implemented in previous week.

The following timeline aligns with what has been mentioned in Implementation plan.

Goal : Community Bonding and few improvements

• The goal is to get to know my mentor and other organisation members.
• Also, due to familiarity with SymPy for about 4 months, I would commence to code in community Bondig Period itself, if all prior discussions with the mentors are completed.
• But still, my main focus would be to solve more and more beam problems to look for any possible bug.

Goal : Complete and merge PR created for Stage 1

• algorithm helping to solve statically indeterminate beams would be implemented inside solve_for_reaction_loads function.

• slope and deflection functions will be updated to handle Non-Prismatic Beams(beams with variable moment or elastic modulus).

• Implementation of point_cflexure method.

• Implementation of max_delfection, max_bmoment, max_shearforce and pure_bending method.

• remove_load function would be implemented to remove applied load.

Goal : Implementation to solve multiple beam system and non-horizontal beams(Stage 2)

• join method to connect two beams would be introduced. There would be three type of connections, namely hinge, fixed and fixed at right angle.

• Each connection involves slightly different type of constraints, so algorithm to solve each type would be implemetnted indivisually.

• Changes to the Beam class and implementation of logic to handle non-horizontal beams will be done.

Goal : implementation of Support class and merging PR created for stage 2. Addition of documentation/tutorials for implemented functionalities.

• Support class will be implemented along with slight changes in the way Beam class handles reaction forces.

• It will be ensured that Stage 2 PR is ready to get merged.

• I I will add documents for each and every functionalities implemented till now.

As per above schedule, i will have completed algorithms to solve statically indeterminate beams, to solve beams with variable moment, to solve composite beam systems and non-horizontal beams along with implementation of max_delfection, max_slope, remove_load methods and Support class. I will also make sure to add the test cases and complete the documentation.

Goal : implementation of 3dbeam class (Stage 3)

• the class would have shear_modulus as a new attribute which decides which set of equations would be used to solve the system.

• bc_moment, bc_slope and bc_deflection will be implemented.

• shear_force and bending_moment for the representation internal stresses will be implemented.

• slope and deflection method will be introduced too.

Goal : completing the PR created in previous week along with addition of documentation/tutorials for 3dbeam class

• Any leftover work of Stage 3 PR will be completed.

• Addition of documents added functionalities of 3dbeam class.

Goal : implementation of Plotting for continuum_mechanics (Stage 4)

• Implementation of plot_load, plot_shear, plot_moment` methods will be done.

• plot_slope and plot_deflection will also be implemented.

• plot_internals and plot_all will also be included.

• Required changes would be dont to make plots more visually appealing, readable and useful.

Goal: Buffer Period and Wrap Up

• Documentation for the plotting of beams would be added

• The last week would be used for any kind of left over tasks and ensuring that all PR of all stages are now merged.

• I would submit a report showing all the work done by me this summer and what more can be done.

• I would be having my End Semester Examination in mid of May (would end by 21st), so it can overlap with my first coding week. But this won't affect my work as I would prepare code for that week beforehand. After that I would be able to devote 40 - 50 hours a week during the project, since I have no other big commitments other than GSoC.

• My next semester would start by late end of July, so summer break covers nearly whole coding period, allowing me to focus on my project to the fullest.

• If I miss a particular alloted slot in some week, I will make sure to inform my mentor in advance, and would also surely make up for the time, by devoting extra time the following weeks.

• I will continue to contribute in SymPy by fixing bugs and reviewing pull requests and would love to engage myself more in the world of SymPy and open-source.

• I would implement more topics in continuum_mechanics module after the summers, so that it can be used for all beam related topics in a general Solid-Structures course.

• Discussion with Mentors in mailing list

• Beam Deflections by Discontinuity Functions

• SymPy Continuum Mechanics documentation

• Sampad Saha Blog

• Deflections due to Bending

• Elastic Beams in Three Dimensions