21-765 Slide 2

Grading, Projects, Problems - Software Package

Grading is based on three components:

Class attendance (30%)
Merits of the final project (50%)
Take-home test and/or in-class short quizzes (20%)

Homework will be assigned after most lectures. Submitting solutions, interesting approaches, and comments is not mandatory, but can be a plus for grading. The purpose of the homework is to help develop practical skills and get used with the computing environment. The homework is recommended for students auditing the lectures as well.

Take-home test and in-class short quizzes contain questions from a list of Python video tutorials. These tutorials are available for free for CMU affiliates on LinkedIn Learning https://www.cmu.edu/web/training/linkedin-learning.html (check if you have access):

Python Essential Training by Ryan Mitchell, Chap 1-6 (quizz: week 3)
Python Essential Training by Ryan Mitchell, Chap 7-11 (quizz: week 4)
pandas Essential Training by Jonathan Fernandes (take-home test: week 5 to week 6)
NumPy Essential Training: 1 Foundations of NumPy by Terezija Semenski (recommended: week 7)
Python Statistics Essential Training by Michele Vallisneri (optional)
Python for Data Science Essential Training Part 1 and 2 by Lillian Pierson (optional)

Students will need to pick a final project no later than the third week of the semester and to deliver milestones every other week. A project consists in developing a (simple) software package or module that have a defined practical purpose. Students are welcome to discuss with the instructor projects close to their scientific interests, or to request a project idea.

The students are expected to produce a polished piece of software (referred below as the project) that solves a certain problem. The software will be developed during the semester in the following steps:

Clearly establish the problem and discuss it with the instructor -- (by week 3)

Isolate a class of algorithms that can be used, identify new research on them, pick the algorithm of choice -- (by week 5)

Design a modular implementation of the software -- (by week 7)

Write the modules in C with documentation and clear interface specifications -- (permanent after week 7)
Create and maintain various documents and a web page as the project evolves -- (permanent)

Pick several non-trivial examples to demonstrate the software (general principles and particularities) -- (permanent after week 7)

Do debugging, fine tuning, and polishing of the software and documentation -- (permanent after week 7)

Create a parallelized version of the software -- (after week 11)

Students can work in teams of maximum three at the same software package. Every other week, by Friday at noon, each team is supposed to issue a new version of the work with a brief journal documenting the progress, and a "ToDo" list kept by EVERY member of the team separately. Numbering of the versions should be determined by the stage of the work. Teams can split and fork the project development during the semester.

When finished, the project is supposed to contain:

the readable and properly commented code and makefiles

self-consistent documentation for skilled users (man pages or other type of docs), the sysamin (how to compile and install, platforms), and the developer (description of the algorithm, how to continue and extend the work, technicalities)

various files containing licensing terms, history of the development, credits, discussion of possible security issues, etc.
working non-trivial test examples

a webpage advertising the software project

Merits of the final project considered for grading are:

how well is the program structured such that it will allow easy further development, easy debugging (diagram of modules and APIs)
the quality (and not the length) of the documentation
how functional, efficient, and/or innovative is the numerical algorithm (tested on the provided examples)

The code can be one of the following:

part of the student's research work
a project suggested by the student or provided the instructor

The problem to be solved is supposed to be simple enough, such that the emphasis is on the completeness of the implementation and on the quality of the software package.

Software Project

Problem to be solved
Core group of programmers: dynamic, commit changes, impose programming paradigms, decide features/evolution, contributors
Software: modular, versions, timelines, audit/debugging, development cycles, examples, tests
Documentation: user, sysadmin, developer, statements, credits
Copyright/license: commercial, GPL, BSD
Distribution: web advertising, presentation, repository, downloads
Testbed/user base

Modular Design

Functional partitioning of the problem: different solutions depending on the problem
Modules + interaction API (Application Programming Interface)
Kernel = command center
Modules vs subroutine/function/procedure
Communication -> kernel
Modules can have modular structure

Real life example of modular diagram:

Examples of past projects

Parallelize a linear regression with a nonlinear transfer function
Computation of molecular energies at equilibrium and bond energies
Find an optimal path between departure and destination
Implementation of weighted singular value decomposition
Calculation of dG values from thermodynamic integration of alchemical absolute binding free energy