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;

---

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);

---