The first questions aiming at most often encountered issues are again: Is the plugin trying the project inquiry with a suitable AEDT path or version? Is the project still locked? Could there be other reasons why AEDT cannot load the project, maybe due to missing modules? Next steps consist in digging deeper into log files, and to understand the log files, it is useful to understand the context of processes producing the logs.
Whenever listings of parametrizable slots or objects are demanded, and when the needed info cannot be recalled from cached project inquiry results which are valid and up to date, then a project walker script is triggered for the purpose of project inquiry and to generate a cache folder with inquiry results. This trigger can happen when you are starting the solver wizard for AEDT or when you use the edit dialog for configuring an AEDT or AEDT-LSDSO integration node. There are two Python scripting layers involved – the one of optiSLang's integration plugin and whenever a script-driven AEDT subprocess is spawned from there, then there is a separate second Python environment, the IronPython layer in AEDT. Keeping this context in mind, the following troubleshooting hints may be helpful:
The plugin Python layer is able to generate standard or error type messages which optiSLang can directly display in its message queues. The first effort should therefore be spent on sifting through the messages displayed by optiSLang. Both errors and normal messages should be checked.
Every integration plugin node has its own message display in the lower part of the edit dialog.
During solver wizard use parametrization page has its own message display in very similar manner.
A check of the main message queue in the main window should not be forgotten.
After the glance at message displays, the look should go towards log files.
However, not only log files are of interest. In the case of the AEDT integration, also project inquiry cache files are worthwhile to be inspected. The project inquiry cache of a reference project ABC.aedt is located in a folder ABC.optislang showing up right beside the reference project.
The two log files of the two involved Python layers are also appearing right next to the reference project. Given a file ABC.aedt:
the integration plugin log is written into ABC_AEDT_Manager.log,
the AEDT IronPython layer, where the project walker script is run, writes its log into ABC_AEDT2_script_project_walker.log.
The
stdoutandstderrof the AEDT subprocess are funnelled into two separate log files in the same place.All files of non-zero kilobyte size can be of potential interest and should be checked in search for error explanations.
The project walker script stores its investigation results in the cache folder ABC.optislang, and of particular importance are the project_info.json and the result reports exported to CSV files. It's always worthwhile to check how old these files are and how far the project walker got in the latest trial.
The .optislang cache folder and all log files the AEDT integration plugin produces next to the .aedt file can be safely removed, and then you can see them being newly created when the project inquiry is triggered the next time.
The spawning of the AEDT subprocess and its associated licensing client, if it takes place, can be observed in a tool able to visualize the process trees on your machine.
