For a larger data set, you may be able to use this method: How to read a static data file into a user-defined surface – Knowledgebase (zemax.com)

Dear Jeff, 

thank you very much for your quick reply! Would the use of the additional “Data” surface(s) require a modification of the UDS DLL (FIXED_DATA4 UDS DLL structure)? The UDS comes with labeled column headers in the EDE but the data surface does not if placed immediately before. How can the entries in the data surface be linked to the specific column headers of the UDS?  

Best regards,

Mario

Dear Allie, 

thank you very much for your quick reply! I will discuss your suggestion with our programmers, since I am lacking of the required programming skills. Would this approach allow to change the underlying data sets somehow on the fly (without re-programming) to analyze different design modifications rapidly?

Best regards, 

Mario

Hi Mario,

I’ve actually never written a custom user-defined surface DLL that utilizes extra data from a Data surface, but a quick review of the sample program “us_datasurface.c” shows that this program simply takes the extra data from one Data surface (240 values from columns Par 13 to Par 252, which are labeled Extra Data 1 to Extra Data 240) and copies the values into the corresponding extra data cells of the UDS.  This only happens when the UDS is initially loaded (corresponding to Case 7 in the switch statement).

It’s just a demo program.  There is no fundamental reason why the columns of the two surfaces should be linked.

The FIXED_DATA4 structure should work okay as is.  With this structure, it appears that the UDS itself provides 242 extra data values which are accessible using the “xdata” array, while each Data surface (located immediately above the UDS in the Lens Data Editor) provides 240 extra data values which are accessible using the “datasurf_values” array.  Since up to 20 Data surfaces are allowed, the “datasurf_values” array can hold up to a maximum of 4800 elements.

The extra data values defined this way allow for interaction within the model by using solves (e.g., variables, pick-ups, etc.).  If all you need to do is load 500 fixed values that define a surface, and the values remain static (at least for one realization of your model), then it may be easier and more efficient to utilize the method that Allie mentioned.

Regards,

Jeff

Hi Jeff, 

thank you very for your detailed response. We are now working on a revision of the UDS DLL to include the FIXED_DATA4 structure. It appears that this will resolve our limitation issues. 

Best regards, 

Mario  

Hi @Mario.Gerlach - sorry about the late response - I was attending Photonics West. To answer your question: the data set is not dynamic and requires you to remove the DLL from the LDE before updating the data. Here’s an excerpt from that KBA:

The data is only unloaded from memory when the DLL is unloaded from OpticStudio, e.g. when the program is closed or the surface type is changed. At this point the DLL_PROCESS_DETACH step is initiated, during which the memory allocated for the global variables is released. If the DLL is then re-loaded into OpticStudio, data from the file will again need to be read in, but only once. If data in the file has changed and needs to be read back into OpticStudio, you can therefore unload the DLL (by changing the surface type) and then reload it, and the new data will be read in.

So this may not work for what you are after. Although, I’m happy to hear you were able to find a path forward!