TAGGED: fdtd, geometry, Lumerical-FDTD, lumerical-script, parameters, variables
-
-
April 24, 2025 at 4:00 am
axelmagana8
SubscriberHello,
I'm encountering an issue while attempting to run a parameter sweep in Lumerical (Lumerical v 2024r1) in an FDTD simulation. Specifically, we are using a script with the ‘setnamed’ command to vary geometric parameters via a model object. The script is designed to loop through seven parameters, each with over five values, making manual updates impractical. We plan to scale this further with more parameters, so automation is essential.
Issue: When the script runs, the variable list in the model object under Model > Edit updates successfully before or after the simulation is run (never during). However, the actual geometries in the object tree do not reflect these updated values. The GUI also fails to visually update to reflect the changes unless manual intervention occurs.
To test this, we:
1. Let the script run through the first iteration (which works fine).
2. During the second iteration, we quit and did not save.
3. Navigated to the geometric parameters expecting an update, but nothing changed.
4. Opened Model > Edit and confirmed that the updated values are reflected in the variable list.
5. Pressed Cancel — no change in geometry.
4. Repeated step 4, but this time hit OK before exiting — surprisingly, this did update the geometries.We've also tried forcing a GUI refresh using ‘redrawmode’ and ‘redrawon’, but the interface still doesn’t update unless we manually press OK in the Edit Model dialog.
To be clear, we are not attempting to change model parameters during a running simulation. All model updates occur before or after a simulation run via scripting.
Question: Is there a step we’re missing to ensure that the geometry in the object tree updates automatically with the new model variable values during scripting? Is there a way to programmatically “press OK” on the Edit Model interface, or another method to force the geometry to reflect the variable changes mid-script?
Please let me know if any additional information is required from my end. Thank you for your time and help!
Best regards,
Axel -
April 24, 2025 at 8:23 pm
Kirill
Forum ModeratorDear Axel,
Thank you for the detailed explanation.
Are you using Lumerical’s built-in sweep tool or a custom scripted sweep? Also, do you switch to Layout Mode to update the geometry?
Would you be able to set up a minimal geometry or simulation (not necessarily meaningful) that reproduces the issue, and share the corresponding screenshots and scripts? That would be very helpful for investigating the problem.Best regards,
Kirill -
April 24, 2025 at 9:47 pm
axelmagana8
SubscriberDear Kirill,
Thank you for your message.
We are not using Lumerical’s built-in sweep tool—instead, we’ve implemented a custom scripted sweep. We do switch to Layout Mode in order to update the geometry.
I will set up a minimal simulation to reproduce the issue and will share the relevant screenshots and scripts with you shortly. I’ll follow up again once that’s ready.
Best regards,
Axel -
May 5, 2025 at 5:06 am
axelmagana8
SubscriberHello Kirill,
Before minimizing the simulation, we attempted several debugging steps—none of which resolved the issue:
- Iteration Delay Test: We added a five-second delay per iteration to see if allowing extra time would help the model "catch up" in cases where it wasn’t updating correctly with respect to the expected time window.
- Syntax Isolation: We copied the syntax, specifically the setnamed lines that reflect changes in the model, into the file running the iterations.
- Script Adjustments: We modified parts of the model script related to mesh gap settings, but the simulation still failed to update as intended.
To simplify and minimize the simulation:
We significantly reduced the code complexity. Instead of varying over 10 parameters as in our full working model, we focused only on the gap. This allowed us to cut down on setnamed lines, reduce the number of files being called, and narrow the scope of variable changes.
Despite these efforts, we encountered the same issue: the data output still did not match our expectations.We’re running this on a computing cluster (256 GB RAM across 64 cores), and each simulation takes approximately 2 minutes to complete.
To attach all relevant pictures and scripts, could you provide me with an email?
Best regards,
Axel -
May 6, 2025 at 5:52 pm
Kirill
Forum ModeratorDear Axel,
According to the Guidelines for Posting on Ansys Learning Forum, we do not share email addresses and are also unable to download shared files.
Would you be able to post your model script, the sweep script, and any relevant screenshots directly here?
Best regards,
Kirill -
May 6, 2025 at 8:32 pm
axelmagana8
SubscriberHi Kirill,
Thank you for your response!
To mitigate the issues, I've created three docs that contain the scripts and the pictures. These are links to google docs where you can copy paste from, and no downloading is required to access the relevant information:
Model Script
Relevant Sweep Scripts - The main run file is RRLib_Cp.lsf
Relevant Pictures
If this approach does not work, then I will copy and paste all the informaiton in this post as replies.
Let me know if anything else is needed from my end.
Thank you,
Axel -
May 13, 2025 at 5:35 am
axelmagana8
SubscriberHi Kirill,
I hope that you're doing well!
I just wanted to follow up on my last message and see if you had any updates.
Best,
Axel -
May 15, 2025 at 3:17 am
Kirill
Forum ModeratorDear Axel,
In your case, it appears to be just an artifact of the Classic viewport, as the actual values are changing according to the script. So hopefuly this should not affect your simulation results.
Try checking whether the geometry updates correctly in the Modern viewport, and consider updating to the latest Lumerical version. I ran tests with 2025 R1, and the geometry was updating as expected.If you’re still seeing the issue, please try using a minimal script that demonstrates the problem with an unmodified application example file.
If I can reproduce the issue, I’ll be able to escalate it to the development team and/or report it as a bug.
Try using something like:switchtolayout;
setnamed("::model", "gap", 2.5e-6);
?getnamed("::model", "gap");
run;
switchtolayout;
setnamed("::model", "gap", 1.4e-6);
?getnamed("::model", "gap");
run;
Best regards,
Kirill
-
- You must be logged in to reply to this topic.
-
3492
-
1057
-
1051
-
965
-
942
© 2025 Copyright ANSYS, Inc. All rights reserved.