Ctrl+K

1.3  Key notions in SDT architecture

1.3  Key notions in SDT architecture#

functions, commands#

To limit the number of functions SDT heavily relies on the use of string commands. Functions group related commands (feutil for mesh manipulation, iiplot for curve visualization, ...). Within each functions commands (for example iicom ImWrite), are listed with their options.

command string and structure options (CAM,Cam,RO)#

Most SDT functions accept inputs of the form function('command',data, ...).

Command options can be specified within the command (parsed from the string). iicom('ch+5') is thus parsed to ask for a step of +5 channels. See commode for conventions linked to parsed commands (case insensitive, ...).

When reading SDT source code, look for the CAM (original command) and Cam (lower case version of the command). Section 7.17 gives more details on SDT coding style.

While command parsing is very often convenient, it many become difficult to use in graphical user interfaces or when to many options are required. SDT thus typically supports a mechanism to provide options using either commands options, or option values as a data structure typically called RO (for Run Options but any variable name is acceptable). Support for both string and structure options is documented and is being generalized to many commands. 

% Equivalent command an structure calls
figure(1);plot(sin(1:10));title('Test');legend('sin');
cd(sdtdef('tempdir')); % Use SDT temp dir

% Give options in string
comgui('ImWrite -NoCrop Test.png')
% Give options as structure (here allows dynamic generation of title)
RO=struct('NoCrop',1,'FileName',{{pwd,'@Title','@legend','.png'}});
comgui('ImWrite',RO);

Stack#

When extensible and possibly large lists of mixed data are needed, SDT uses .Stack fields which are N by 3 cell arrays with each row of the form {'type','name',val}. The purpose of these cell arrays is to deal with unordered sets of data entries which can be classified by type and name.

stack_get, stack_set and stack_rm are low level functions used to get/set/remove single or multiple entries from stacks.

Higher level pointer access to stacks stored in iiplot (curve stacks) and feplot (model and case stacks) are described in section 2.1.2 and section 4.5.3.

GUI Graphical User Interfaces#

GUI functions automatically generate views of data and associated parameters. The main GUI in SDT are

  • iiplot and the associated iicom (commands to edit plots) to view frequency and time responses defined at multiple channels.
  • feplot and the associated fecom (commands to edit plots) to view 3D FEM and test meshes and responses.
  • idcom for experimental modal analysis.
  • ii_mac for test/analysis correlation.
  • sdtroot for project handling, parameter editing.

Graphically supported operations (interactions between the user and plots/ menus/mouse movements/key pressed) are documented under iimouse.

The policy of the GUI layer is to let the user free to perform his own operations at any point. Significant efforts are made to ensure that this does not conflict with the continued use of GUI functions. But it is accepted that it may exceptionally do so, since command line and script access is a key to the flexibility of SDT. In most such cases, clearing the figure (using clf) or in the worst case closing it (use close or delete) and replotting will solve the problem.

pointers (and global variables)#

Common data is preferably stored in the userdata of graphical objects. SDT provides two object types to ease the use of userdata for information that the user is likely to modify

For example in a feplot figure, cf=feplot(5) retrieves the SDT handle object associated with the figure, while cf.mdl is a SDT handle method that retrieves the v_handle object where the model data structure is stored.

global variables are no longer used by SDT, since that can easily be source of errors. The only exceptions are upcom which will use the global variable Up if a model is not provided as argument and the femesh user interface for finite element mesh handling (feutilimplements the same commands without use of global variables), which uses the global variables shown below


FEnodemain set of nodes (also used by feplot)
FEn0selected set of nodes
FEn1alternate set of nodes
FEeltmain finite element model description matrix
FEel0selected finite element model description matrix
FEel1alternate finite element model description matrix

By default, femesh automatically use base workspace definitions of the standard global variables: base workspace variables with the correct name are transformed to global variables even if you did not dot it initially. When using the standard global variables within functions, you should always declare them as global at the beginning of your function. If you don't declare them as global modifications that you perform will not be taken into account, unless you call femesh, ... from your function which will declare the variables as global there too. The only thing that you should avoid is to use clear and not clear global within a function and then reinitialize the variable to something non-zero. In such cases the global variable is used and a warning is passed.

Contents