Universal 1-D and ZOS-API

  • 19 February 2020
  • 4 replies
  • 162 views

I'm trying to use the Matlab ZOS-API to extract data from a plot generated in the Universal 1-D tool.  



After I generate the results the tool tips for matlab show the following data properties:

DataGrids: 1x1 IAR_DataGrid[]

NumberofDataGrids: 0



I have also looked through the topic on output data types for Universal Plot 1-D and all the types (DataGrid, DataSeries, DataScatter, etc) are all false .



1.  Am I missing something about how the Universal 1-D creates data as DataGrid and using that in matlab?  Should I be expecting NumberofDataGrids >0 and just have something wrong in the code?

If not:

2.  Do I need to save files at .txt files then upload into Matlab and extract the numeric data adding an additional step?

3.  If 2. is true. Is there any other in the ZOS-API that can quickly cycle system parameters (independent variables) and extract values from the merit function editor? Essentially doing the same thing as Universal-1D but not needing the steps to search for the text files and upload those?

 

4 replies

Hi Robert,



You are right with your reasoning. If the analysis GetResults() function doesn't retrieve sensible data, that means this analysis probably doesn't support direct output of data to MATLAB yet. Instead, you should use the GetTextFile(String Filename) from your result interface (IAR_). Then, you should be able to parse this new text file with MATLAB.



In summary, for point 1. you don't seem to be missing anything, its normal to have NumberofDataGrids: 0. For point 2. It is also correct.



Finally for point 3. it depends a little bit on the kind of values you want to get. To be general, I can say that you have access to the Merit Function editor with the ZOS-API, and there is a handy function called GetOperandValue, which can be used to evaluate any operand, even if not present in the Merit Function editor.



Here is a small example for you:

TheApplication = MATLABZOSConnection;
TheSystem = TheApplication.PrimarySystem;
TheMFE = TheSystem.MFE;
TheMFE.GetOperandValue(ZOSAPI.Editors.MFE.MeritOperandType.REAY, 6, 1, 0, 0, 0, 0.7, 0, 0)
TheApplication.CloseApplication;

If you use it on our Double Gauss 28 degree field.ZMX sample file, it'll return:



ans =



     6.959771787962447e+00



Exactly as if you would have manually setup REAY at Surface 6, Wavenumber 1, and Py = 0.7.



Does that answer your question?



Kind regards,





David

Thanks David,

 This does answer the question for 1 and 2. 



For part 3.  what I am really wondering is if there is a different way through the ZOS-API to access the Universal 1-D algorithms, in that it seems that that function creates a copy of the system and runs through values efficiently .



For example, I want to look at a object distance vs rms spot size for finite conjugate system.  I can operate a for loop in Matlab that controls

the object thickness but every time it has update the system to recalculate a merit function like RSRE.  I think I'm looking for a way to efficiently control the calculation and dump the values directly into matlab instead of saving a .txt file and parsing it.  It's not an issue to do that and it may be helpful to have the .txt file but curious if there is a different way. 



 
My pleasure Robert,



The reason why the Universal 1-D algorithm is so efficient is because it is a native analysis that is complied.



In this regard, processing large loops in MATLAB can be slow, but it doesn't necessarily means that OpticStudio is the cause of it. I suggest having a look at the following article by my colleague Michael who is discussing batch processing of ray traces with MATLAB:



https://my.zemax.com/en-US/Knowledge-Base/kb-article/?ka=KA-01651



As for your example, you do not need to update the whole Merit Function to read the value of RSRE, you can simply change the object thickness and run RSRE using the code snippet I presented in my previous reply. All you need to do is replace REAY with RSRE and the parameters you like for this operand. GetOperandValue will compute RSRE without the need to update the Merit Function. Does that make sense?



Lastly, if you are concerned by speed. I suggest that after you've prototyped your analysis with MATLAB, you move on to compiled programming languages such as C++ or C#. Those will certainly be faster than MATLAB and Python.



Kind regards,





David

Hi,  David Nguyen, 

I have a problem about ZOS-API in Matlab.

Could we transform a MFE operator like 'REAY' in the type String to  ZOSAPI.Editors.MFE.MeritOperandType.REAY in Matalb? 


The following is the code for C#


 MeritOperandType mfOP;

 mfOP = (MeritOperandType)Enum.Parse(typeof(MeritOperandType), 'REAY', true);

Reply