LS-DSO jobs are based on submitting specific Optimetrics tables with design variations, but the standard AEDT integration node generally applies the Analyze All command on the level of the project.

Result files from LS-DSO jobs are also CSV files, but they come in a special format and a special folder structure so they must be treated with a dedicated result reading subroutine

The ability offered by the standard integration node to flexibly combine various run modes with different scheduler submission modes cannot be expanded to include LS-DSO in an equally simple way. LS-DSO jobs are handled by Remote Solve Manager (RSM) and the Desktopjob executable, but the framework does not represent a queuing system as all LS-DSO jobs are started instantly by RSM and the Desktopjob executable. For job submission to Desktopjob using the command oDesktop.SubmitJob, it looks like LS-DSO fits into the framework of other scheduler submission modes, but considering the special output format and other aspects, there are also strong arguments for considering it as a run mode.

Validate for Large-Scale DSO: The models in your AEDT project can be checked by creating simple variation tables under the Optimetrics section in each model, right-click the table, and select Validate for Large-Scale DSO from the context menu. This useful context menu function is a time saver, it can help finding setup discrepancies immediately, greatly reducing the trial-error loops.

Submit Job dialog box: Next, right-click a simple Optimetrics variation table and select Submit Job from the context menu. Adjust HPC settings and perform a test run using LS-DSO. Use the Export button at the bottom of the dialog box to store a proven set of settings as an AREG file for use with your optiSLang setup.

Step 1 in optiSLang: Create a sensitivity system and add one or two AEDT-LSDSO nodes into it, two if you would like to have a separate output collector node (best practice). Link both nodes with your AEDT project.

Node edit dialogs: Register parameters, adjust execution settings, and define response collection rules.

Multiple designs per process: It is important to set multiple designs per process as desired, often this means matching the number of tasks choice of the LS-DSO job settings stored in the AREG file or taking a multiple.

Perform a test run of the simple sensitivity system: Check or observe the LS-DSO jobs, for example, by watching process trees, looking at log files, opening RSM result folders, and checking them for result CSV files. Such test runs can be upscaled in stepwise manner, for example, first only on localhost before addressing other network machines.

Upscaling for productive use: use functions like copy, paste, morph into parametric system, and algorithm wizards or manual graphical programming work to derive systems for productive use. Revise execution settings (including AREG file content). Consider matching HPC settings with algorithm settings, for example 240 samples instead of 250 if you have 48 cores, or adjusting the population size of an evolutionary algorithm.

AEDT projects with multiple model branches require a sequence of LS-DSO jobs, one for each model. The Electronics Desktop scripting interface properly supports such a sequence of multiple job submission commands only for version 2021 R2. With older AEDT versions, the AEDT-LSDSO node will issue a warning message and optiSLang will not be able to receive any result data except from the first job.

In AEDT version 2020 R2 there exists a known bug with a known workaround. The format of AREG files was updated, but the script command oDesktop.SubmitJob kept requiring the old format. With 2021 R1 the SubmitJob command gained the ability to interpret the new format AREG files and the bug was fixed. 2020 R2 can be used for scripted LS-DSO (and its exploitation by an LSDSO integration node) nevertheless, simply by providing AREG files generated with a previous AEDT version as workaround.