Learning Forum

[JBelleville]

Hello,

I have a python script which sequentially does the following with an FDTD session (called fdtd here), using lumapi:

1. Load in a previously defined GDS file into the Lumerical session (creates an imported geometry).
2. Sets the material properties of the imported geometry to the desired values (using fdtd.set).
3. Saves index monitor outputs to a matrix object "data_set" in the script workplace (i.e. saves permittivities as a function of x, y, z, f, etc.)
4. Retrieves the index monitor outputs from the Lumerical script workplace, into the python script (using lumapi.getVar(fdtd.handle, "data_set"))

This works most of the time and gives me the correct results. However, on occasion, the first time I poll for "data_set", I get the permittivity values PRIOR to the material properties being updated (i.e. the same results as if I had omitted step 2). I then have to execute steps 3 & 4 again to get the correct results.

I suspect that this is because the lumapi functions will return prior to the scripting functions completing in Lumerical. I'm looking for some way to block my python script before step 3, until step 2 has completed. Is this functionality provided anywhere in lumapi?

Thank you! Any suggestions are much appreciated.

[Taylor Robertson]

Thanks for the question. So from my understanding in 3. you are saving the index monitor results to a data set in the lumerical workspace. Are you doing this by evaluating a string argument as lsf code. For example.
fdtd.eval("A = getresult('index monitor','index');")
Python basically treats the Lumerical GUI environment as a client. Once it passes this code to be evaluated it will move on, since it is not expecting any results to be returned. Lumerical may still be evaluating the code when you are trying to get the results? Not entirely sure about the sequence of events here, but in this case it may be be better to return the results directly to Python using
A = fdtd.getresult('index monitor','index')
This will return a dictionary with the same structure as the lumerical dataset see - Passing Data - Python API
Also the index monitor returns a number of results; some of which are available in layout mode, but the more accurate datasets will require the simulation to be meshed. It may be that the index preview was generated before before updating the material and it failed to update the results when the material data was changed? If you wanted the most accurate results, that take into account the advanced meshing refinement options, I would suggest meshing the structure after updating the material properties. There is a hidden way of doing this without having to run the simulation.
fdtd.addjob("myFileName.fsp", "FDTD", "-mesh-only");
Then you can use assignment in python or get the variable from the script workspace if you like. One note the syntax you are using to pass variables to python is deprecated. I would suggest
A = fdtd.getv('index_matrix')
The simplest possible thing may to just build in a bit of a time buffer. To do this I use python time module.
import time
.
.
#Update material data
time.sleep(15) #wait for 15 seconds before moving on
.


I hope this helps.
Best Regards

[JBelleville]

Thank you for the very thorough response! It's good to get the confirmation that python treats the GUI environment like a client. I was retrieving the results with fdtd.eval as you suspected. I've tried with fdtd.getresult instead, but I see the same behaviour (where the first function call sometimes receives the wrong output, but the second retrieves the correct value).
I'm setting the material properties by selecting the GDS and then running fdtd.set('material', materialName). I suspect that this is the call which fails to complete before my attempt to retrieve the results (that is, I think that Lumerical is still in process of setting the material when I call either fdtd.getresult or lumapi.getVar).
I previously used a time buffer, but because the time required was variable from computer to computer, I was hoping for more robust solution (for example, a way to verify that the fdtd.set command has completed). Do you know of any way to do that? My current solution is to poll the index results at time intervals until the permittivities are roughly as expected (then allowing the script to proceed). If there's no way to check the completion of a command, I might stick with that.
Thank you for the tips on fdtd.addjob and fdtd.getv , those are great to know about and I'll be sure to use them!
Best,