GoLint VS prysm

Actually in the early days of Go, devs were stuck to camalCase/PascalCase on variable naming. But VScode Go plugin managed by Microsoft at that time , and they suggested ID over id/ID, XML over xml/ Xml. Because VScode is free, it attached many users and using uppercase for abbreviations/ initialisms became a standard. Andhttps://github.com/golang/lint/issues/124 finalized it. But , still I think it is a wrong decision.

As for linting, go vet and [staticcheck](staticcheck.io) are the recommended tools, according to the now deprecated golint repository.

golint is deprecated, and it’s no longer required to comment every exported variable/function/struct, etc.

not found error (go tools not found issue explained below), can also check here

about Initialisms; Personally I still prefer simple initial conventions (lowerCamelCase, UpperCamelCase, UPPERCASE) Go followed before VSCODE/Microsoft suggested ID or Id (ex. https://github.com/golang/lint/issues/124). Following one pattern everywhere is the best. In Go, a name is exported if it begins with a capital letter. ex URL; if any unexported var/const start with "URL", what do you do?

My current concept is to just combine zernike polynomials with a random factor and calculate the PSF from that, which can be somewhat easily be done with the prysm library. These PSFs can then be convolved with circular and gaussian kernels for modelling additional defocus and accounting for other stuff like the AA filter. Then I'd add chromatic aberration by offseting/scaling the PSFs for each channel. Some generated kernels already look pretty good when comparing them to stars in astrophotography images, but others not so much.

https://github.com/brandondube/prysm (caveat emptor: mine)

You can trace about 1 billion raysurfaces per second in pure python with CuPy, or a few million raysurfaces per second on CPU.

New paper from /u/BDube_Lensman using prysm to model NASA's Roman Coronagraph

This free book is what this free code is based on

Prysm Originally for diffraction type optics but seems to able to handle...everything? Performance as a priamary concern, GPU acceleration, proven JPL heritage :) Raytracing is however still experimental and without docs, generally whilst the library looks excellent if you're an optics person already I think I lack a bit of the base fundamental knowledge to really use it powerfully from just the API reference. I can see BDube has some raytracing example code in some of the issues I could probably adapt and muddle my way through at least. No guis is mildly annoying for a noob like myself, but I can work my way around matplotlib-ing just fine instead i'm sure.

You may want to steal my shim set since it lets you hot swap Numpy<-->cupy at runtime

I do computational diffraction with large manycore servers and GPUs at a FFRDC. The difference between MKL and not MKL is the difference between hitting enter and getting a result in an hour or two vs tomorrow.