microsoft
More examples
Examples are an obvious first point of reference for a lot of people checking out the package, so it'd be good to get the page up to date. I can think of three things at the moment, which I'll list in order of ascending difficulty.
- Rendering the example images in high resolution (using xvfb-run -s "-screen 0 3840×2160x24") and fixing their size in the markdown file.
- Adding new examples, such as an optical system with an eye model (#43).
- Fixing the Zoom Lens example [optical engineering experience required].
The source files to look at are examples.md and Examples.jl.
With regard to the zoom lens example: The first problem seems to be the reference to the discontinued SFL4 glass. The replacement glass should be N_SF4. Right after that hovewer the example visualization code generates this error
ERROR: AssertionError: zero(T) <= sinθₜ
Stacktrace:
[1] snell(surfacenormal::StaticArrays.SVector{3, Float64}, raydirection::StaticArrays.SVector{3, Float64}, nᵢ::Float64, nₜ::Float64)
@ OpticSim ~/.julia/dev/OpticSim.jl/src/Optical/Fresnel.jl:49
which can be traced back to the NIKON.LLF6 glass, which has NaNs in its a4 and a5 coefficients. When crosschecking with the Zemax glass catalog, the other coefficients seem fine. So there seems to be an error in the glass catalogs or the parsing of the downloaded file.
Just looked at the AGF, the problem is that there are newlines breaking the CD line which we assume is a single line for parsing
CD 2.326858000E+000 -2.496168000E-002 2.979231000E-003 3.164392000E-003
-3.498773000E-004 1.777229000E-005 0.000000000E+000 0.000000000E+000
0.000000000E+000 0.000000000E+000
@alfredclwong This will likely mean we have to add a bit of complexity to our parsing code to deal with this kind of thing...
I'm not massively familiar with the parsing code as I just copied it over blindly from the old code, but I'd be happy to have a look. I'll probably change it over to use regex for robustness. Is there a reference for the AGF file format somewhere?
Not that I'm aware of - the basic principle is that the two characters at the start of each line tell you what information is on the line, then the line contains a list of " " separated items, usually numbers. The trouble is that 'lines' can be split across multiple lines in the file. Probably just checking if the first element in the line is two characters and matches one of the codes would be enough, and otherwise assuming a split line. This will just need a bit of state compared with the very simplistic method used currently (assuming each file line is a 'line' of information).