Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
F
finesse3
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 81
    • Issues 81
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 5
    • Merge Requests 5
  • Requirements
    • Requirements
    • List
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
  • finesse
  • finesse3
  • Issues
  • #169

Closed
Open
Opened Aug 25, 2020 by Samuel Rowlinson@samuel.rowlinsonDeveloper

Astigmatic surfaces - separate components?

Currently Mirror and Beamsplitter components have both Rcx, Rcy model parameters for the RoCs in each plane. The Lens just has f (no separation of the focal length into the two planes) for now but we'll want to have support for astigmatic lenses too (easy to do).

I was wondering recently whether we want to keep these surfaces as being generic, with the option of them being astigmatic, or do we want to have separate components for the astigmatic versions? e.g. Mirror would just have Rc as a model parameter whilst AstigmaticMirror would have Rcx and Rcy.

This separation could be quite neat in my opinion as it would get around some of the (essentially) user-interface problems referenced in #133 (closed). I think the majority of the time people use non-astigmatic surfaces so having specialised component versions for these could remove any confusion about planes and setting up references when scanning RoCs.

The only disadvantage I can think of here is that there would be a bit of code duplication I imagine. But this could be solved in principle by having, using mirrors as an example, a MirrorBase abstract class from which Mirror and AstigmaticMirror both derive.

Any thoughts?

Edited Aug 25, 2020 by Samuel Rowlinson
To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
Alpha 1
Milestone
Alpha 1
Assign milestone
Time tracking
None
Due date
None
Reference: finesse/finesse3#169