Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

built-in routine for importing complex refractive index profile #1369

Open
oskooi opened this issue Sep 22, 2020 · 2 comments
Open

built-in routine for importing complex refractive index profile #1369

oskooi opened this issue Sep 22, 2020 · 2 comments

Comments

@oskooi
Copy link
Collaborator

oskooi commented Sep 22, 2020

Importing an arbitrary complex refractive index profile over a broad bandwidth (e.g., from ellipsometry measurements) has been an oft-requested feature over the years (see FAQ/How do I import n and k values into Meep?). With the availability of a broad and mature Python toolset for optimization, it would be useful to finally provide a no-fuss, built-in routine that performs a gradient-based minimization of the L2 norm of the error in the fit. This routine would have at least five input arguments: (1) a NumPy array of complex values for the refractive index, (2) a NumPy array of the frequencies, (3) an initial guess for the number of Lorentzian terms, (4) the threshold relative error used as termination criteria, as well as the (5) maximum number of function evaluations.

Since this problem amounts to designing an IIR filter which is known to require trial and error involving manual tuning of the fitting parameters, the challenge for the built-in routine will be to work across a large range of input parameters preferably with little to no user intervention. The built-in routine does not need to be perfect; it just needs to provide some way of automating the process of importing material data which does not currently exist.

(Since #398, which is a workaround, is a much more significant undertaking, fitting the refractive index profile to a sum of Lorentzians may still be worthwhile in the interim until #398 is ready.)

@stevengj
Copy link
Collaborator

Sure, with the caveat that using it will probably require a lot of babysitting.

@smartalecH
Copy link
Collaborator

Since #398, which is a workaround, is a much more significant undertaking

Note that #920 addresses #398.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants