Hi Christoph!

Thanks for your post on the forums here. Is this system in any way related to your prior post for updating field points which had difficulty finding a solution? I am wondering if part of the issue with UPDATE has to do with something like Ray Aiming, which can take longer to update if you have the STOP at the rear of your system, if you have a really wide field of view, etc.

To improve the time to update your field points, would you be able to turn off Ray Aiming, at least until you then need to run the needed analyses? Of course, this assumes that you have Ray Aiming on in the first place, so if this doesn't work for you, please let us know! With this approach, you could at least modify your system with a reduced runtime, and only use that runtime when you are actually running the analyses.

Please let us know how these thoughts work out for you, and we can continue the discussion as needed. Thanks!

~ Angel

Hi Angel,

thank you for your post!

The Zemax design is actually the same as in my prior post. However, I think it is a different issue. In the prior post, the problem was this: Switching from Filed type 'angle' (which is the incidence angle) to 'real image hight' causes troubles because Zemax did seemingly not converge to the correct incidence angles for the given image positions. Or sometimes it did with large delay. It seems to be a specific problem in my design. And I was going to open a case and send the file. I still have to do this, didn't have the time so far. (Workaround is to work with type 'angle' and let the Merit function converge to the image field positions. This works w/o problems.)

Now, I am talking about another issue:

I only use type 'angle' (because of the issue above). Then I use ZPL to calculate the COM positions with the CENX,Y operants. I have to do this many hundred thousands of times (probably not a very usual case I guess. It is the basis for 'distortion maps'.)

This means I have to change the field all the time in the ZPL script, like this:

SETSYSTEMPROPERTY 102, Field_num, field_x

But Zemax applies this change only after an UPDATE command.

And what I am realizing is that ray tracing, even with sample_values like 20 x 20 rays is really fast. But the UPDATE takes a lot of time (about 8 seconds). I think this may be because not only the new field values are updated, but all settings. Right?

So I wonder if there is a faster way to update only  the field variables. I think one possibillity might be not to use CENX,Y at all but instead to use the raytrace statement directly in ZPL. Then I can define the fields with H_x, H_y and will not need the UPDATE. I will have to calculate the COM completely in ZPL. Do you think this can be faster? It is not my favourite, because it needs a lot of scripting.

Best, Christof.

Hi Christoph,

Thanks for your follow-up! I appreciate the detail -- I think I'm seeing what you mean now.

You are correct in that UPDATE will perform updates on the entire system, as it will recompute paraxial data, among other information, about your model. I did notice in our Help Files that we have the ability specify updating editors (with UPDATE EDITORS), but I am not sure if this will be a time-saver if it will still update all relevant information about the system.

Other than using the RAYTRACE keyword that you brought up, the only other suggestion I think I can make is to define as many field points as possible in batches. Depending on your license level, you will have the ability to define a certain number of field points (from the Help Files at 'The Setup Tab > System Group (the Setup Tab) > System Explorer > Fields > Field Data Editor'):

So, rather than update a single field point at a time, you could modify most (if not all) of your field points to a new portion of the range you're interested in. That way, you're reducing the number of times UPDATE is called and hopefully bringing some efficiency back into the ZPL code.

In the event that you ever look to something like the ZOS-API, we also have some resources on running a batch ray trace, which is a functionality that the ZPL does not offer. This would be analogous to looping through several RAYTRACE keywords and being able to access the entire batch of data after running the batch. The articles are as follows:

• ZOS-API using MATLAB


• Batch Processing of Ray Trace Data using ZOS-API in MATLAB or Python

Please let us know how these thoughts work out for you!

~ Angel

Hi Angel,

I like your idea to fill all the fields before updating. I think it is worth doing this modification of the script, although it is a bit like a workaround and I will need one more loop depth. I use the professional edition. I assume that 50 fields with one UPDATE will speed up things considerably.

I have a feeling that  ZOS-API would have been the better choice for me. I never worked with it and I am now working with a lot of ZPL scripts. The changeover to ZOS-API in a runing project can be quite a problem. But if I have the chance  to start a new project, I will very seriously thing about switching to this interface.

Thank you Angel, I think that you helped me really a lot!

Take care,

Christof.

The 50 fields version is running . In deed it causes a real speed boost by a factor of 8!

One thing is however to be considered: Seemingly, the 50 fields have to be created in the field editor in the GUI first. At first I was only using 10 fields. The pitfall is that the PDL script still runs without any complains and still produces results, but starting with field 11, they are wrong. I have no idea what is happening in this case.

If the 50 fields are generated first, then everything works correctly.

Thanks again Angel, this speed up is very helpful for me.

Hi Christoph,

Happy to hear that the macro is working more efficiently now! Regarding the fields not working correctly if the 50 fields aren't pre-defined, I think the omission there might be you are perhaps not updating your Field Data Editor from the ZPL with code 101:

I was able to update field points that weren't pre-defined in the GUI Field Data Editor, but I needed a ZPL line to define the necessary number of field points before I modified the points themselves. What might be happening is that if you're trying to pull field points from a 'row' that isn't defined in the FDE, it might be defaulting to an axial field or some other point. I haven't thoroughly tested the behavior myself, but of course you'll sidestep this problem by adding in another SYSP line to define all 50 points you'd like to modify.

And, for the future, you can always take a look at our ZOS-API Learning Path, which collects and organizes a lot of relevant Knowledgebase material to get you started using the API and getting some practice with examples. Just something to keep in mind if you ever want to take a closer look at it!

~ Angel

Right Angel, I actually did not define the number of fields at all. So probably I always hat those number which was currently defined in the field editor. Now, I added this in the script.

Thank you! Hope to meet you again.

Take care,

Christof.

PS Thanks for the ZOS-API link, I have bookmarked it.