Script variable not properly registered in Lumerical's workspace

MikeSMikeS Member Posts: 5


I am using a script to create the geometry I want to simulate and another script to save the geometry / simulation parameters in a .txt file. The idea is the following:


parameter1 = 1e-6;
adduserprop("Parameter 1",2,parameter1);
set("script", Custom script using parameter 1);


write("Info.txt", "Parameter 1 = " + num2str(parameter1));

Then I use script to create and run the job with a workflow like this:



The problem is that when the Geometry_info script is called, I get the error that parameter1 is not defined. I have tried saving the file and typing the missing parameter (?parameter1 = 1e-6) to populate the workspace before calling the Geometry_info script but it didn't solve the problem. I searched for a command to update the workspace but I didn't find anything. However, after the Run_Simulation.lsf stops execution (due to the missing variable), I can see and print the variable in the workspace. As a side note, when the variable is printed from within the script I get the following:


Somehow the value is registered but not the name, or this is what I understand. However the values of a different script that contains only values assignments (does not change anything in the model) seem to be properly registered, but I haven't fully checked on that.

Any idea what is going on?


Best Answer


  • gsungsun Posts: 751Ansys Employee

    This is an interesting problem. As you know, all the script files in the GUI of one simulation file share the same work space. Therefore in principle, all the variables should be there, except that one script file uses "clear" to dis-register existing parameters. Therefore, the first step is to check if any script files use "clear" other than the main script file.

    The other way to find the cause of the problem may be to execute the script line by line, and at the same time you check the workspace. Then you can know when the specific variable is created and when it disappears.

    If you could not find the root cause, please share the information of software version and your computer operation system version so we can test .

  • MikeSMikeS Posts: 15Member

    Thanks @gsun for the reply.

    I'll do as you suggest and I will post an update.

  • MikeSMikeS Posts: 15Member

    Here is the update:

    I think I found the issue, and in the end it is not related to the work-space but to the working directory. My method is the following:

    I have a repository of scripts that I copy to the folder where I run the simulations. I assumed that when a script is run, the working directory changes to where the script is located, but this seems not to be the case. My explanation is that I was running a different script from the one opened in the script editor window (that is why line-by-line execution was running). I assume that when the run button is pressed, Lumerical searches in the working directory for a script with the given name and runs it, so if a script with the same name would be opened from a different location, many unexpected things can happen. It would be better if that was confirmed though (@gsun highly appreciated), because if it doesn't hold, I need to find another explanation!

    Still, that does not explain how the variables were available after break of execution

    However, after the Run_Simulation.lsf stops execution (due to the missing variable), I can see and print the variable in the workspace.

    but if indeed a different script than the intended was run, I cannot backtrack what could have happened.

    So, I would update my question to how can I set the working directory to correspond to the location of the script being executed? Also, when the save command is issued the file is saved at the current working directory? If the save path is explicitly given, does the working directory changes to location where the simulation file is saved?

    I could open a new discussion topic related to managing the working directory if it would be better.


  • MikeSMikeS Posts: 15Member

    Hello and thanks again for the reply @gsun !

    I have concluded the following: While I was using the GUI to run the script, my working directory was misset and the actual script that was run either had a "clear" command somewhere, the command order was different, or something like that. Any debugging attempt didn't have any impact since I was modifying and running different scripts, so I can no longer support the claims in my initial post. When I use the terminal / command line with the option:

    path_to_executables/mode-solutions -run path_to_script/script_to_be_executed.lsf

    the working directory is automatically set to path_to_script and the scripts run normally. So, yes, the variables are there (work-space) and are accessible.

    Making sure that the working directory is set to the directory you're working is more important than it sounds. Anyway, I would find it useful if the working directory was automatically updated when a script / file was loaded through the GUI. And even better, if the script editor allowed opening multiple files at once.


  • gsungsun Posts: 751Ansys Employee

    Thank you again for the new updates!

    In the GUI, you should be able to open more than one script files in the "script window", either in Windows or in Linux. But using command may open different window. To run script files in other directory, you can use script path+script file name to open and run it inside the main script file. But the working directory should be the one in the main script. Please try.

  • MikeSMikeS Posts: 15Member

    Thank you for the suggestions,

    They do work, now the script runs without problem.

    What I meant when I said

    ...if the script editor allowed opening multiple files at once.

    is to be able to ctr select multiple files when you click on the open script button of the script editor window, and open all of them in one go.


  • gsungsun Posts: 751Ansys Employee

    This will be a feature request. Please submit your suggestions here

    Thank you!

Sign In or Register to comment.