This repository has been archived by the owner on Oct 23, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 40
Allow for surface type extensibility in AxisymmetricOpticalSystem #179
Merged
Merged
Changes from 12 commits
Commits
Show all changes
14 commits
Select commit
Hold shift + click to select a range
93c66f6
move exports
alfredclwong ca0be78
formatting
alfredclwong 5cc4664
style improvements for AxisymmetricOpticalSystem constructor
alfredclwong 7e065c9
switch from symbols to strings
alfredclwong 021c856
add basic dataframe validation
alfredclwong 3cd72d4
update examples
alfredclwong 019a50d
add Parameter column and Aspheric surface type
alfredclwong 245ae39
improve dataframe validation
alfredclwong d0027e1
fix aspherics to conform with new Parameter column
alfredclwong 73463dd
v0.5.0-DEV -> v0.5.0 (release ready)
alfredclwong 7cd6b3d
remove Optimize* columns from core AxisymmetricOpticalSystem
alfredclwong fcf139a
use kvps in Parameter column
alfredclwong 2f311f4
Merge branch 'main' into alfred/asos-surfaces
alfredclwong 80afa24
Revert "v0.5.0-DEV -> v0.5.0 (release ready)"
alfredclwong File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not quite a dictionary, but I think Pairs here are more expressive than tuples regarding our intended usage. This will easily convert to a Dict if needed later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think there is a better way to do this still eg where surface type is the actual type name allowing you to get the constructor for the surface dynamically and then you could pass the parameter dict as keyword args. This is a pretty fundamental change and might mean modifying the surface constructors too (ughh) but would mean that new surface types would be supported directly and there wouldn’t be any need for hard coding stuff when setting up axisymmetric systems.
Anyway this seems reasonable for now, but I think there is a better solution there that might be easiest to achieve by starting almost from scratch on the design of AxisymmetricOpticalSystem
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see what you mean - got the wrong idea earlier!
It'll definitely require a lot of changes, and it'll get mixed up with some other discussions we're having now about prescription DataFrames for non-axisymmetric systems... (although this also means it's a good time for a rewrite). Let's go with this for now - in the short term, all I want is to add support for Zernike surfaces. I'll factor this into our discussions and work towards something smoother in the future.
side note: i'd still like to stick with Vector{Pair} for coefficients