I’m trying to modify object properties in a group by a script. The script changes a user property in a group. But I notice that the actual change in the size of the object inside the group does not happen until the script is finished. In the example script you can see that the property “wg_width” is modified to 1u (from original 0.5u) but the actual width of the WG is still 0.5u. But when the script is finished the actual WG width becomes 1u.
Is this a bug or it’s the way it is suppose to work? Is there a way to modify the actual sizes of objects in a group within a script?
Please see the attached example
The structure group enclosing parameters such as gap, height, wg_width, etc. (in Properties tab) and script command lines (in Script tab) enables user to easily build up the objects inside the structure group by adjusting the parameters inside it in a controlled way. If you check the “construction group” as below image, you cannot modify the objects outside the structure group via script command.
In your case you unchecked the “construction group”, it seems like you can modify the inside structure. But in this structure group system with parameters and a script just as Primitives Structure Groups, you can only access to the inside object without any effects on it. Thus, you are only allowed to modify the object (WG_1) through the design parameters in Properties tab.
Here is the some alternative way to control the objects inside the structure group. After take apart the WG structure group (mouse right click - Break groups), and select both objects - WG_1 and WG_2. Make the new structure group named WG2 (mouse right click - Add to new group) without an inside script contents. Then, you are able to adjust the width of the “WG_1” (y span) using some script commands as following.
set(“y span”, 1e-6);
You can refer to the more information on construction group in detail following a KX page.
Thanks @isawjsy for the input. It is true that we cannot directly change the parameters of the object inside the structure group (with “construction group” checked) but will need to go through the parameters defined in the Properties tab. It is because the structure group Script will be run each time you “touch” it. This is also explains why the it may sometimes feel slower when you are editing the Script that involves a large number of objects.
I think the point @eugene.ivanov was trying to make is that the Script Prompt is not showing the desired “y span” the first time try.lsf is run. I believe this is a minor GUI bug. In fact, the correct “y span” will show the second time you run the script again. More importantly, the “y span” should be already updated the first time you run the script (you can verify this by editing the rectangle named WG_1, or measure the rectangle length using the Ruler function). So this minor bug should not affect your simulation results. I will show this to a developer tomorrow.
<<More importantly, the “y span” should be already updated the first time you run the script (you can verify this by editing the rectangle named WG_1, or measure the rectangle length using the Ruler function). So this minor bug should not affect your simulation results. <<
No, in my example script I modify the wg_width and them read it back from the actual object by “get” command and it is still showing the original value of 1u, not the modified value. I also saw this problem in another scenario: I was trying to make a script to create an array of structures in loop and then stream them out to GDSII but I found that even though I try to modify the “wg_width” parameter in the loop the actual WG width in the GDSII file did not change.
I think you are right. Although the CAD (eg xy view) shows the change in the first time, the changed parameter don’t seem to get properly updated until you run the script again. I added an index monitor to this example and it shows that geometry parameter is updated when you hit the “Run Script” button the second time. I think this is a bug and will file a bug report for you.
So a simple workaround here is to run the script twice…
We revisited this issue and we found that this is not actually a bug but is intentional. The issue is that we deliberately don’t retrigger setup scripts every single time a property is changed. The problem is that we could trigger a cascading series of setup scripts that would make scripts take too long to run. For example, if you had a script that took 10 seconds to run, and it had 10 input properties, we would take 10x10=100seconds to run if we used 10 setnamed commands to set each property and, after each property was set we retriggered the entire setup script.
The setup scripts will all be run if a file is saved or when an FDTD simulation is launched, so we are sure that everything will be up to date.
The workaround is that to use the “runsetup” script command. This is in fact why we added this command. It will force the setup scripts to run and ensure that all children of a group are correctly refreshed. Place a “runsetup;” command immediately after the “setnamed” and everything works fine. See https://kb.lumerical.com/en/index.html?ref_scripts_runsetup.html