COMP 523.002 · Team C · Fall 2026
Optical Design Tool Frontend
View the frontend prototype →A cross-platform front-end for LieOptics that lets optical engineers, researchers, and students interactively design lens systems, run analytical aberration analysis, and visualize results without writing code.
Project introduction
Cross-platform interactive GUI for analytical optical lens design and aberration analysis.
This project is a front-end for an optical lens design tool. The backend, LieOptics, is a lightweight Python package we've already built that computes optical aberration coefficients analytically, using Lie group and Hamiltonian methods instead of traditional ray tracing. That approach makes it dramatically faster. It has over 1000x speedup on a simple camera lens in our benchmarks, and it makes principled lens design accessible. Designers can dig into aberration pattern analysis that no other tool offers, giving them real guidance during design instead of the trial-and-error process most lens design still relies on. What's missing is a way to actually see and use any of this. That's why we are looking forward to an front-end.
The backend is still a prototype, but it covers the essential APIs: defining lens systems (radius, thickness, glass index per element), analyzing how rays focus through them, running optimization (e.g., differential evolution over lens parameters) to improve performance, and generating spot diagrams that any optics engineer can read.
Right now, a designer has to write code to run any of these functionalities. The goal of this project is a cross-platform application that lets an end user, such as an optical engineer, researcher, or student, interactively define a multi-element lens system, run aberration analysis and optimization, and visualize the results (spot diagrams, aberration coefficients, phase-space plots) without touching code. We're picturing an Electron or browser-based app with a form/canvas-style UI for building lens systems, talking to the existing Python backend through an API layer, and rendering interactive plots of the results, though we're open to a better framework for bridging the two if one fits better.
The target users are researchers and students in optics who want a lightweight, open-source alternative to commercial tools like Zemax or CODE V for exploratory lens design, with access to performance insights that only our model provides. The team's job is the front-end and a thin API layer connecting to the existing backend. We will provide the backend's core computational code, in a stable state. The team does not need to modify the backend.
Interactive Lens System Builder
Define multi-element lens systems with curvature radius, thickness, and glass index per element via an intuitive form/canvas interface.
Analytical Aberration Analysis
Generate spot diagrams and analytical aberration coefficients backed by LieOptics with >1000x speedup over ray tracing.
Optimization & Visualization
Run differential evolution optimization over lens parameters and inspect phase-space plots and performance insights without touching code.
Team roles
Every member writes code. These roles mark where each person carries additional responsibility.
Contact
One click reaches the entire development team.
Email the entire development team
sarathy@unc.edu, avipatel@unc.edu, lganesha@unc.edu, psushant@unc.edu
Development team
| Name | Role | |
|---|---|---|
| Sarathy Selvam | Software Engineer | sarathy@unc.edu |
| Avi Patel | Software Engineer | avipatel@unc.edu |
| Lakshin Ganesha | Software Engineer | lganesha@unc.edu |
| Sushant Potu | Software Engineer | psushant@unc.edu |
Client
| Name | Title | Organization | |
|---|---|---|---|
| Haosheng Shi | Client & Optical Researcher | LieOptics | Via the Client Manager |
Consultants and instructors
| Name | Title | Organization | |
|---|---|---|---|
| Paul Stotts | Instructor, COMP 523 | UNC Department of Computer Science | stotts@cs.unc.edu |
| TODO: Manager Name | Faculty Manager | UNC Department of Computer Science | todo@cs.unc.edu |
Schedule
Regular meetings with the team, the client, and the faculty manager, plus the dates that matter most this semester.
| Meeting | Who | Cadence | Time | Location |
|---|---|---|---|---|
| Team working meeting | All team members | Weekly, Mondays | TODO: 5:00–6:30 PM ET | TODO: Sitterson Hall, Room TBD |
| Team standup | All team members | Weekly, Thursdays | TODO: 8:00–8:20 PM ET | TODO: Video call (link in team channel) |
| Client meeting | Client Manager, Project Manager, client | Biweekly, Wednesdays | TODO: 3:00–4:00 PM ET | TODO: Video call (link in team channel) |
| Manager / professor meeting | All team members, faculty manager | Weekly, Fridays | TODO: 2:00–2:30 PM ET | TODO: Sitterson Hall, Room TBD |
| TA meeting | All team members, course TA | Every two weeks (Zoom) | TODO: confirm slot with TA | Video call (link provided by the TA) |
| Weekly progress report (PPP) | All team members | Weekly, by 11:59 PM the day before the TA meeting slot | 11:59 PM ET deadline | Posted on this site, with a confirmation email to the TA |
Key dates
| Date | Event |
|---|---|
| September 15, 2026 | Requirements sign-off Agreed scope with the client: a frontend plus a thin API layer over the existing LieOptics Python backend. The team does not modify the backend itself. |
| September 26, 2026 | Platform selection, user stories, and team rules due TypeScript/React/Electron over the Python LieOptics backend; user stories and the course-required team rules (Gitflow, pre-commit hooks, Kanban) posted. |
| September 30, 2026 | Architecture diagram and system metaphor due Client-server diagram: Electron/React UI and a thin API layer (ours) in front of the unmodified LieOptics backend (the client's). |
| October 1, 2026 | Frontend prototype published First-draft lens builder, aberration table, spot diagram, and mock optimization run, published as its own repository for the team to evaluate. |
| October 5, 2026 | Midterm talks begin Midterm talks run 10/5 to 10/12. |
| October 15, 2026 | Fall break No team meetings 10/15-10/16, per the course calendar. |
| October 18, 2026 | Lens builder wired to the real LieOptics backend (target) Swap the current mock API for a thin service calling the real Python package, so results in the UI stop being placeholder data. |
| October 20, 2026 | Midpoint demo Demonstrate lens definition through real aberration analysis and a real spot diagram, end to end. |
| October 21, 2026 | Ethics assignment due |
| November 8, 2026 | Layout visualization, save/load, and error handling (target) Canvas-based lens visualization, reliable save/load, and backend errors surfaced in the UI instead of failing silently. |
| November 15, 2026 | Optimization UI, phase-space plots, and tests (target) Real differential-evolution controls (bounds, constraints, progress) and the start of an automated test suite. |
| November 17, 2026 | Client acceptance testing |
| November 25, 2026 | Thanksgiving break No team meetings 11/25-11/27, per the course calendar. |
| December 5, 2026 | Final presentation and hand-off Electron installers, client acceptance-testing feedback folded in, and the client hand-off plan complete. |
Team rules
The working agreements every member of this team has committed to.
Show up, or say so early
Attend every scheduled team, client, and manager meeting. If you cannot make one, tell the team in the group channel at least 24 hours ahead and read the meeting journal entry afterward.
Respond within 24 hours
Any direct question in the team channel gets a reply within 24 hours, even if the reply is only "seen, working on it." Silence blocks other people.
Communicate blockers immediately
If you are stuck for more than an hour, post about it. Asking early is not a failure; going quiet until the deadline is.
All work goes through pull requests
No one pushes directly to the main branch. Every change is a pull request reviewed and approved by at least one other team member before merging.
Finish what you claim
Only take an action item you expect to finish before the next meeting. If your estimate slips, say so at the next standup rather than at the deadline.
Decisions are recorded
Any decision that affects the team gets written into the meeting journal on this site the same day, so it does not get relitigated later.
Follow Gitflow and enforce checks with hooks
We use the Gitflow branching workflow. Pre-commit hooks check commit message style and code formatting (linting) on every commit, so broken style never reaches a pull request.
Small commits in Conventional Commits style
Each commit covers one task and follows the Conventional Commits format. We never commit secrets such as API keys or passwords.
Track work on a Kanban board
Every task lives on our Kanban board (GitHub Projects) and moves through To Do, In Progress, Review, and Done, so anyone can see what is blocked.
Weekly progress report
Every week, by 11:59 PM the day before our TA meeting slot, we post Progress, Plans, and Problems on this site, including what we tried and failed at, and email the TA the link.
Use AI tools, and review what they produce
We use AI tools for coding help, but review every suggestion instead of copy-pasting it. Written deliverables get significant human revision, and no sensitive information goes into an AI tool.
Respect client confidentiality
Nothing the client shares in confidence — data, documents, screenshots, credentials, participant information — appears on this public site, in the public repository, or in any public channel.
Disagree in the meeting, commit after it
Raise objections while the decision is being made. Once the team decides, everyone works with the decision until there is new information worth reopening it.
Escalate as a team
If a conflict or workload imbalance is not resolved within the team after one honest conversation, the Project Manager raises it with the faculty manager before it affects a deliverable.