Hi @Jonasz,

I think this is a task that is better addressed in sequential mode, but if it is simply an exercise. Then, I’d say you could use the Merit Function. In non-sequential mode, you’d have to have three operands (so you can’t simply use the method: GetOperandValue). One NSDD to clear all detectors, one NSTR to perform the raytrace, and one last NSDD to read say the angular RMS value. Something like so:

Then, with the ZOS-API, you can simply write:

# This forces the calculation of the whole Merit Function
mf_value = TheSystem.MFE.CalculateMeritFunction()

# Print the value of your NSDDD which is setup to give your RMS angle
print(TheSystem.MFE.GetOperandAt(3).Value)

Please note the warning about CalculateMeritFunction:

If you want, you could even setup the operands through the ZOS-API.

Hope this helps.

PS: I’m assuming you know all that stuff in the user-interface and you’re asking specifically about the ZOS-API. Please let me know otherwise and I can give more explanation. To run your optimization, you could have a Weight of 1.0 for the last NSDD operand, and it will target the RMS angular radius to 0.0 (collimated beam).

Take care,

David

Hi David,

Thank you for your input! Strictly speaking this is not just an exercise, but a strippped down version of the problem I wanted to solve. I am iterating over the parameters of a system and each iteration requires me to optimise the position of the lens for collimation. Therefore being able to extract the angular information from the rectangle detector would be useful. If there is not a straighforward way to do it, I will try with the merit function.

What does asynchronous mean in this context? It is calculated everytime I run the ray trace? Or everytime the merit function is evaluated it runs its own ray trace through NSTR?

Yes, I am familiar with how to run the optimisation through the GUI. I appreciate your effort. Thank you!

Hi @Jonasz,

I see, is there a particular reason you can’t do it in sequential mode?

I’m not a software programmer but asynchronous means that the method is called to start a process but quickly returns to continue the code execution while the process is still happening in the background. In this case, CalculateMeritFunction is not asynchronous. That means, once you call CalculateMeritFunction, the program will hang until the Merit Function is actually calculated, and this can take some time depending on the complexity of your Merit Function. I found this explanation on this website:

Asynchronous is a non-blocking architecture, so the execution of one task isn’t dependent on another. Tasks can run simultaneously.

Synchronous is a blocking architecture, so the execution of each operation is dependent on the completion of the one before it. Each task requires an answer before moving on to the next iteration.

Everytime you need to evaluate NSDD, you need the previous call to NSTR, similar to what is described in the help file, therefore you need a call to CalculateMeritFunction:

A typical merit function would consist of three groups of operands:

First, NSDD operands would be used to clear the data in the current detectors. Use NSDD with the detector number set to zero to clear all energy in all detectors. Usually a single NSDD at the top of the merit function is all that is needed. NSDD returns a value of zero and has no effect on the merit function value when used to clear detectors.

Second, NSTR operands are used to trace rays from NSC sources. NSTR i traces analysis rays from source i; NSTR 0 traces all analysis rays from all sources. Note the number of analysis rays on the NSC editor determines how many rays are traced and how long the evaluation of the NSTR operand will take. NSTR always returns a value of zero and has no effect on the merit function value. The NSTR operand supports options to split, scatter, and use polarization.

Third, a new group of NSDC, NSDD, NSDE, or NSDP operands are used to read out the detector data.  NSDD has four arguments: surface, detector, pixel, and data. Surface is the surface number of the NSC group (use 1 if the program mode is non-sequential). Detector is the object number of the detector. Both detector objects and faceted detectors may be used as detectors. If pixel is an integer greater than zero, the flux, flux/area, or flux/solid angle is returned for that pixel. Which of the three is determined by the data argument, which should be 0, 1, or 2 for flux, irradiance, or intensity, respectively. If pixel is 0, the sum of all the flux or flux/area in the detector is returned. The units of the returned data is determined by the system units, see “Analysis Units”.  To compute other data with NSDD, see the Pix# and Data# assignments for the NSDD operand in the table below.

That is a limitation of the non-sequential mode though. Which is why I’m suggesting a sequential model, where you can evaluate the RMS angular radius with a single operand such as RSCE, and this operand requires a minimum number of rays to be traced (it will likely be quicker) thanks to the Gaussian quadrature.

Does that make more sense?

Take care,

David 

Yes, i´m design an illumination system involving a polarising beam splitter, which requires non-sequential mode. I´ll play a bit with the merit function within ZOS-API. Thank you for your input, it has been very helpful!