<PREV><INDEX> <NEXT>
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
att Harrison (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
<PREV><INDEX> <NEXT>