《ZEMAX中文说明3[1]》由会员分享，可在线阅读，更多相关《ZEMAX中文说明3[1]（143页珍藏版）》请在金锄头文库上搜索。
1、关于数据域编号需要直到一个非常重要的事情。如果它的值为零，则执行宏指令，得到OPTRETURN 0 中的值。然而，如果数据域编号不是零，那么不执行宏指令，而代替使用前面调用该宏指令时储存的数值。这种约定有着实质性的好处。如果宏指令计算了许多数值，它们所有都需要被优化，则这个宏指令只要调用一次，而多次使用ZPLM 操作数就可以得到这个数据。这比多次调用宏指令有效得多。例如，假设名为ZPL11.ZPL 计算三个数值，它们三个都需要优化。在这个宏指令中将使用OPTRETURN 来储存这三个数据：OPTRETURN 0=xOPTRETURN 1=yOPTRETURN 2=z那么在评价函数中用三个ZPL
2、M 操作数来摘录这个数据，仅调用一次这个宏指令来执行优化：ZPLM 11 0ZPLM 11 1ZPLM 11 2仅在ZPLM 11 0 中调用宏指令ZPL11.ZPL。注意，仅当Int2 的值为零时，可以使用Hx、Hy、Px、和Py 的值，因为仅在这种情况下，宏指令才被求值。最后，在宏指令执行过程中镜头数据不能有任何改变，这一点十分重要。这些改变将涉及到后面其他操作数求值。ZEMAX 不能将已经求值的镜头数据恢复到对ZPLM 指定的宏指令求值之前的状态。同样，ZPLM 也不应用在默认评价函数的中间，而应该放在ZEMAX 默认定义的那部分评价函数的前面或后面。如果在宏指令操作的过程中镜头数据被改
3、变了，ZEMAX 将无法知道哪个数据被改变了，而且不能不能将镜头数据恢复到没改变时的原始状态。只允许ZPL 宏指令执行对镜头数据的拷贝数据进行优化，而不是对实际数据进行优化，这样可以避免出现上述情况，然而这个功能当前不被支持。其原因是有时候宏指令在对后面的操作数进行求值之前需要改变镜头数据。在这种情况下，应执行两个宏指令。第一个应按要求修改数据，第二个应将数据恢复到原始条件。这两个宏指令，和执行改变镜头数据的插入操作数一起，都可以在评价函数编辑界面中列出。使用外部编译的程序的优化创建一个用户自定义操作数（UDO）的第二种方法是编写一个外部窗口程序来计算数据，然后使用动态数据交换（DDE）来将数
4、据输入ZEMAX 中或从ZEMAX 中输出。DDE 界面在“ZEMAX 扩展”一章中进行说明。那里介绍的内容在这里不再复述；这里的说明是在假定已理解那一章的内容的前提下进行的。操作数UDOP 被用来从评价函数内部调用一个外部客户程序。客户程序可能通过制造多个联系到ZEMAX 服务器的DDE 调用来执行要求的计算，然后使用DDE 界面将结果返回到ZEMAX。然后将计算得出的数据放在评价函数编辑界面中的“值”栏中，这样才可能以通常的方法被优化。UDOP 是很容易使用的。Int1 和Int2 的值分别用来指定客户程序编号和数据域编号。客户程序编号指出了哪个客户程序将被执行，而数据域编号则指出了由客户
5、程序计算的哪个值将被优化。客户程序编号必须是0 到99 之间的整数。例如，如果一个UDOP操作数的Int1 的值被设为17，那么客户程序编号为17，被执行的客户程序必须被命名为UDO17.EXE。客户程序名必须始终使用与客户程序编号相对应的一个两位数。如果客户程序编号为6，那么要被执行的客户程序应该是UDO06.EXE。客户程序文件必须放在ZEMAX主目录下的UDO 目录中。当到达一个其数据域编号为零的UDOP 操作数，ZEMAX 将调用这个客户程序。假设客户程序编号为17，客户程序将以如下的语法结构被调用：UDO17.EXE 缓冲器代码 Hx Hy Px Py这缓冲器代码是由ZEMAX 提供
6、给客户程序的一个整数值，它是唯一能识别正确镜头的标识符。因为ZEMAX 能够同时对多个镜头进行求值，缓冲器代码被用作一个标识符，以便于当客户程序申请或返回数据时，它和正确的镜头相联系。注意在优化时，ZEMAX 将同时对许多镜头进行求值，将计算出输出的细微差异，这个优化将继续下去。客户程序必须计算指定镜头的数据。一旦客户程序开始执行，客户程序必须执行一下一个关键的步骤：1） 建立与ZEMAX 服务程序相连的DDE 链。2） 将正确的镜头数据加载到ZEMAX 服务程序的存储器中。3） 计算要求的数据。4） 将数据传输回ZEMAX。5） 清除ZEMAX 服务程序的存储器中的内容。6） 终止DDE 链
7、，并退出。具有代表性的是，DDE 链是由ZCLIENT 编码维持的，这在DDE一章中介绍（当然如果愿意的话，用户自己可以自由编写它们）。ZCLIENT 调用了用户定义的用户函数来计算操作数数据。为了将正确的镜头数据加载到ZEMAX 服务程序的存储器中，必须发送一个单个的名为GetUDOSystem 项目到ZEMAX服务程序中。其语法结构为“GetUDOSystem，缓冲器代码”。这将使ZEMAX 从系统存储器中重新得到这个正确的镜头数据，并且后面所有的DDE调用都是对这个镜头的操作（如光线追迹）。然后通过随意使用在DDE 一章中定义的任意一个DDE 项目调用来计算数据。一旦数据被计算完毕，最多
8、有51 个值可以被放在一个长格式的字符串中。使用项目SetUDOData 将数据传送回服务程序，最后回到ZEMAX 内的优化程序。其语法结构为“SetUDOData，缓冲器代码，data0，data1，data2，data3，data50”。任何一个省略的数据项被认为是零。所有的数据必须是自由格式的整数、指数、和浮点数。关键的是客户程序要用SetUDOData 返回一个字符串，即使它只包括一个缓冲器代码，而其余都是空的。ZEMAX 将等着客户程序返回这个字符串。因为ZEMAX 无法知道计算将用多长的时间，所以ZEMAX 将一直“暂停”，直到它得到这个数据。如果客户程序计算失败了，或者没有返回这
9、个数据，ZEMAX 将不能完成这个操作数的执行，或者将永远暂停。在ZEMAX 内部按下ESC 键将会“中断”求值，使ZEMAX 跳过对这个操作数求值。可以通过客户程序的用户函数将控制返回到ZCLIENT 来终止DDE 链。一个计算3个数据项，分别被称为a，b，c，的范例编码可以阅读如下：void UserFunction(char *szCommandLine)double a, b, c;char szBuffer500,szSub256;int buffer_code;/*得到识别镜头的缓冲器代码*/buffer_code = atoi(GerString(szCommandLine, 0
10、, szSub);/*将正确的镜头数据设置到服务程序储存器中*/sprintf(szBuffer, “GetUDOSystem,%i”,buffer_code);PostRequestMessage(szBuffer, szBuffer);/* 这里是计算数据的地方，这些行省略了*/* 现在得到标记为0，1，2 的数据*/* 如果行的总长度超出255 个字符，则不要使用SetUDOData，*/* 而使用SetUDOItem。详细内容可参见有关ZEMAX 扩展的章节。 */sprintf(szBuffer,“SetUDOData,%I,%.7f,%.7f,%.7f”,buffer_code,a
11、,b,c);PostRequestMessage(szBuffer, szBuffer);注意，对客户程序的一个简单调用可以得到多个数据。这是数据域编号用来摆放的地方。数据域编号可以是0 和50 之间的数字，包括这两个数。这个编号指出了数据在与存储器中的镜头相对应的全局数组中位置。在客户程序的执行过程中， 客户DDE项目“SetUDOData 用来得到一个有51 个数的长字符串（或者少一点；空格和省略值被认为是零）。这些数据必须是数值，被存放在镜头缓冲器中，以供后面的UDOP 使用。在实际应用中，DDE 项目名限制在255 字符之内，这限制了SetUDOData 只能传送远小于51 项的数据；
12、但是DDE 项目“SetUDOItem”通过一次传回一个数据可以在这个限制附近工作。对于任意一个DDE 项目名有一个255 个字符的限制；因此SetUDOData 被限制只能通过少量的数值。为了在这个限制附近工作，可以使用SetUDOItem，这在“ZEMAX 扩展”中说明。总共有51 个不同的数据域，因此一个客户程序调用可以用来同时优化51 个不同的值。这个数据域编号值指出了哪个得到的数值将被放在那个UDOP 操作数的“值”栏中。UDOP 也允许使用Hx，Hy，Px，和Py 数据域。这些数据也可以被客户程序读取，因为它们在命令行中跟在缓冲器代码后面被传送过去。有一个非常重要的事是要知道数据域
13、编号。如果它为零，则执行客户程序，并且将从数据位置0 得到的值放到值栏中。然而，如果数据域编号不为零，则不执行客户程序，由客户程序的一个前面的调用储存的先前值将被代替使用。这个约定的优点是它的实用性。如果客户程序要计算许多数值，这些数值都需要被优化，则客户程序仅需要调用一次，只要用多个的UDOP 操作数就可以得到这些数据。这比多次调用客户程序有效得多。例如，假设一个名为UDO25.EXE 的客户程序计算了三个数值，它们都需要优化。在这个客户程序中，通过使用“SetUDOData，buffercode，x，y，z”将这些数值传送回去。然后只调用一次客户程序，评价函数中的三个UDOP 操作数就可以
14、记录这些数据，并执行优化，这三个操作数是：UDOP 25 0UDOP 25 1UDOP 25 2仅在操作数UDOP 25 0 的求值过程中调用客户程序UDO25.EXE。注意，仅当数据域值为零时，才使用数值Hx，Hy，Px，和Py，因为仅在这种情况下客户程序才被求值。与ZPL 宏指令的使用不同的是，UDO 在求值过程中可以随意改变镜头数据，这个因为所有的DDE 命令都是针对镜头数据的一个复制本执行的，而不是针对正在被执行的实际镜头数据。有一个被称为UDO_DEMO.C 的范例UDO 源代码文件，它可以由ZCLIENT 编译和连接。这个可执行的文件需要被重命名为UDOxx.EXE，这里xx 是一
15、个两位数的整数。这个UDO 范例得到6个值：Hx，Hy，Px，Py，和两个虚拟常数，分别放在编号为0 到5的数据位置中。使用建议在初期设计过程中，优化时很少需要对每个视场的所有波长的所有光线进行追迹。因此，可以通过在优化时限制使用的视场和波长的数目来大大减少执行的时间。如果选择的视场和波长的权重被设为零，则在构建评价函数时默认评价函数运算法则将跳过这些零权重的视场或波长。其结果是追迹的光线少了许多，加快了执行速度。例如，如果一个镜头在五个视场点被求值，则评价函数中仅包含第一、第三、和第五视场是可行的。当然，在设计的后期，需要包括所有的光线，默认评价函数需要被重新构建。由一些技巧可以用来改善执行
16、结果。除非优化方案坚持用不实际的设计，否则不要对变量设置边界操作数。边界操作数增加了计算的难度。只要可能，尽量使用求解来代替明确的操作数。例如，如果可能的话，则用曲率求解来控制焦距，而不用操作数。优化与现代镜头设计的技术是不可分的，而且，只有实践才能是设计者精通使用优化法则。那些精通其他软件优化法则的使用者可能会发现ZEMAX 更易于使用，而且只要少量经验，界面使用的技巧容易掌握，设计者可以专心于设计本身。如果你刚刚接触计算机化的镜头优化，则没有比实际操作更好的方法来学习它了。全局最佳方案这个产生评价函数的最小可能值的设计被称为是“全局”最佳方案，是最好的可能设计的定义。然而，没有已知的优化法则对于一个任意的设计问题都普遍可以发现其全局最佳方案，除非你想“直接找到”一个优化法则（换句话说，就是试验所有的无数可
