There is no denying that adding optiSLang as a controlling wrapper around the solver you are used to working with adds process layers and increases complexity. Your are used to direct interaction with the tool and now the contact becomes indirect. How many layers are there? From bottom up there are at least: solver, model branch in AEDT project, Electronics Desktop as hosting framework, Python scripting in AEDT, Python layer of the AEDT integration plugin, optiSLang's plugin interface, the algorithm, the hosting optiSLang project environment.
For new optiSLang users the first minutes of debugging experience may feel overwhelming. The secret is to break it down piece by piece, asking who exactly is causing the error? which node is it in optiSLang? what is missing or wrong? how far is the process going right? which parts in the optiSLang scenery are colored more green, which parts are more red? what's the content of a design folder? how does the content of the design folder match expectations? After breaking it down piece by piece, you will learn the logic quickly, and as you learn the logic of the structure, there is a direct benefit for your work: with your next project, you will be able to have a clear view right from the outset of what you want to achieve and how you can make the setup optimally powerful and convenient.
Here are a few experience-based suggestions of how to approach the task of breaking the logic down, tracing a problem back to the root cause and finding a solution to make the machinery run:
Begin with the first error, the one at the bottom of the optiSLang message log, the one that happened first.
Read error messages closely. Check also what comes directly before the error happens. Check the Actor column of the optiSLang message log. Make the connection between messages and the responsible nodes. Watch the appearance of nodes as it happens.
Go beyond the optiSLang user interface. Inspect design directory content. Inspect all log files. Check subdirectories as well.
Is the *.lock file still present? This would be a sign of a sudden crash of AEDT. Remove the lock, open the project, try to solve it manually.
No log file present? In run mode regular DSO with designs per process = N only every Nth design folder is a job-executing working directory.
Make sure you have seen that specific log file which contains the messages you are used to seeing in the message log of Electronics Desktop. If the error is there, you might be able to recognize it, or at least to reproduce it yourself working manually in Electronics Desktop.
Response object not obtained: Are CSV files present in the *.optiSLang subdirectory? If not, if no result data were exported from the AEDT project, then open the AEDT project in that folder and try to find out what's wrong with the reports.
Response object not obtained: If CSV files are indeed present, why could expected response objects not be gathered from the files? Are all expected files present? How does the content of the CSV files look like? Is there any difference in the CSV files as found in design directories as compared to the CSV files of the reference design? Are the column headers exactly the same? Response names are generated from file names and column header strings. If names are different at runtime, if they do not match the defined collection rule, that is definitely a cause of error. How can reports be set up so that stability of CSV file headers can be achieved? If units at the end of labels are the issue, then you may use the Output name truncation option to cut them off. This option may work for you if you find that CSV files exported at evaluation time keep stable units and if the odd units in the file headers in the reference project cache do not matter that much.
Watch processes in a tool capable of displaying tree representations of process hierarchies.
Switch off the no GUI option to see AEDT working in front of you.
Reset the system and try in a different run mode. Or copy the system instead of resetting, then you will have design folders to compare.
Conduct tests not only in a plain parametric system (weak test). Use a sensitivity or robustness system sampling a handful of random designs (strong test) and perhaps adding some special start designs.
If design 13 exhibits a strange error, open the AEDT project in the folder Design0013 yourself. Is it solved? Are the reports displaying result data? Can you solve the project now?
Was design 13 actually computed in folder Design0013? Or does it belong to a multi-design group job? Which one was the actual working directory? An active job-carrying folder can be recognized by the existence of log files from script executions.
If it gets tedious finding out what's going on in a cluttered folder Design0013, then create a new empty folder Design9999, copy only the *.aedt file from folder 13, not the *.aedtresults, try to solve it. Or copy the reference project, modify a parameter like optiSLang would try to do and solve it.
Maybe additional files have to be provided in your test folder Design9999to make it work? *.aedb missing? other circuit data missing? ROM data lacking? DLL or other library not found? environment variables?
Activate only the first node or the first few nodes while keeping the downstream part deactivated. Does that run? What is in a design folder then?
Repro system: Derive a new sensitivity system, switch off the dynamic sampling, import a (few) hand-picked successful design(s) and a (few) hand-picked failed design(s); reset and rerun this test system under different conditions/settings.
If test runs take long, take measures to accelerate the cycle: create a fast-runner setup for temporary debugging use.
Simplification: Copy a complex system, strip it of half the nodes for a test. Then add complexity again step by step.
Simplification: Switch solver functions and output collector functions off in all AEDT nodes. Does it run with only input integration active? Does this provide good starting conditions in design directories for the subsequently expected solve task? Can you manually solve an AEDT project in a design directory?
Simplification: replace cumbersome nodes in a complex setup with calculator or Python nodes forwarding dummy numbers or dummy signals.
Do not only passively inspect. Become a bold experimentalist. Manipulate. Break things deliberately.
Embrace debugging. Become the one among your colleagues for whom nothing is a problem. Become the one who can make run everything, the one who can automate anything. Help your team to master any electromagnetics design challenge.
And last but not least: give feedback. If you find that something is awkward and doesn't have to be, let it be known. Developers want to know. We want to improve our tools and make them more useful.