User Tools

Site Tools


contact

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
contact [2020/12/10 19:14]
marijn.nijenhuis
contact [2021/01/05 11:22] (current)
marijn.nijenhuis
Line 13: Line 13:
 ==== In SPACAR ==== ==== In SPACAR ====
  
-This simulation is tricky because it involves iterations to get the system in the right state. We currently have no clear rationale for picking the values of ''stiffn'' of the fictitious force (or the precise mathematical form of this force, for that matter). Also, it's best to do these iterations within one single Spacar call, seeing as each new SPACAR Light call would make the system start from the undeformed configuration again. The current interface for doing a custom force within Spacar is by means of the usersig interface. This interface hasn't been implemented in SPACAR Light properly, but here are some pointers to get a simulation up and running nevertheless. It's currently not elegant and for more details, you're encouraged to read up on the dat-filethe command ''iterstep'', ''xf'', ''delxf'', as these all come into play under the hood.+This simulation is tricky because it involves iterations to get the system in the right state. We currently have no clear rationale for picking the values of ''stiffn'' of the fictitious force (or the precise mathematical form of this force, for that matter). Also, it's best to do these iterations within one single Spacar call, seeing as each new SPACAR Light call would make the system start from the undeformed configuration again. The current interface for doing a custom force within Spacar is by means of the usersig interface. This interface hasn't been implemented in SPACAR Light properly, but here are some pointers to get a simulation up and running nevertheless. It's currently not elegant and for more details, you're encouraged to read up on the dat-file and the commands ''iterstep'', ''xf'', ''delxf'', as these all come into play under the hood. Also see the [[manuals|manuals]].
  
   * Get the development version of SPACAR Light that supports the ''opt.customdyn'' field. See the [[https://github.com/precision-utwente/spalight/tree/contact|development branch on GitHub]].   * Get the development version of SPACAR Light that supports the ''opt.customdyn'' field. See the [[https://github.com/precision-utwente/spalight/tree/contact|development branch on GitHub]].
-  * Use ''opt.customdyn = 'usersig PUSHSIG';'' to have Spacar call the m-file PUSHSIG.m (all of this is case-sensitive) +  * Use ''opt.customdyn = 'usersig PUSHSIG';'' to have Spacar call the m-file PUSHSIG.m (all of this is case-sensitive). This file should be in the same folder as the main SPACAR Light script. 
-  * This m-file will be called repeatedly, depending on the number of ''opt.loadsteps''. This file contains a function with very specific input and output requirements. If you deviate from the template, you'll very quickly run into errors. Within this function, you'll have available the ''x''-vector, which contains the current positions of all nodes. Unfortunately, the node numbering in Spacar (full) is different from SPACAR Light. This is actually by design, and something you usually shouldn't have to come across. Here, you do, though. The conversion is simple and detailed in the file. Note that this simple conversion may not work whenever you use multiple elements per beam with ''eprops(i).nbeams'' > 1. (The .dat-file actually shows you what the conversion should be in all cases.)+  * This m-file will be called repeatedly, depending on the number of ''opt.loadsteps''. This file contains a function with very specific input and output requirements. If you deviate from the template, you'll very quickly run into errors. Within this function, you'll have available the ''x''-vector, which contains the current positions of all nodes. This information can be used to create custom force profiles. Unfortunately, the node numbering in Spacar (full) is different from SPACAR Light. This is actually by design, and something you usually shouldn't have to deal with. Here, though, you do. The conversion is simple and detailed in the file. Note that this simple conversion may not work whenever you use multiple elements per beam with ''eprops(i).nbeams'' > 1. (The .dat-file shows what the actual conversion should be in all cases.)
  
 <code matlab PUSHSIG.m> <code matlab PUSHSIG.m>
Line 69: Line 69:
 The script with the SPACAR Light model looks like this.  The script with the SPACAR Light model looks like this. 
  
-<code matlab>+<code matlab contact.m>
 % EXAMPLE SCRIPT FOR RUNNING SPACAR LIGHT % EXAMPLE SCRIPT FOR RUNNING SPACAR LIGHT
 % This example simulates a simple cross flexure rotating due to an applied moment % This example simulates a simple cross flexure rotating due to an applied moment
Line 133: Line 133:
  
 Some more notes: Some more notes:
-  * The number of loadsteps matters, and probably in relation to the value of the fictitious stiffness. The contact force is applied using the ''opt.customdyn'' line, whereas the actuation force is applied using the ''nprops(3).force'' line. Note the differences between ''nprops.force'' and ''nprops.force_initial''. The latter probably won't work because SPACAR Light will ignore the ''opt.loadsteps'' (which you do need when using ''usersig'') when there is no ''nprops.force'' present, it seems.+  * The number of load steps matters, and probably in relation to the value of the fictitious stiffness. The contact force is applied using the ''opt.customdyn'' line, whereas the actuation force is applied using the ''nprops(3).force'' line. Note the differences between ''nprops.force'' and ''nprops.force_initial''. The latter probably won't work because SPACAR Light will ignore the ''opt.loadsteps'' (which you do need when using ''usersig'') when there is no ''nprops.force'' present, it seems.
   * When there is some error with the usersig interface or the particular m-file, debugging can be hard, because you only get the general SPACAR Light error. The log-file will provide some details. For more details, it can be helpful to do a manual Spacar call and see what the error then is: in the command window, do ''spacar(-10,'contact')''.   * When there is some error with the usersig interface or the particular m-file, debugging can be hard, because you only get the general SPACAR Light error. The log-file will provide some details. For more details, it can be helpful to do a manual Spacar call and see what the error then is: in the command window, do ''spacar(-10,'contact')''.
-  * The input and output variables of the usersig m-file is strict. If you need additional variables in the usersig m-file, a workaround is to use MATLAB's global variables.+  * The input and output variables of the usersig m-file are strict and cannot be deviated from. If you need additional variables in the usersig m-file, a workaround is to use MATLAB's global variables
 +  * Multiple forces can be specified with a single usersig file. Each row in the ''f''-vector specifies a nodal force. Nodal forces specified with usersig may overwrite any forces specified with SPACAR Light force command, such as ''nprops(i).force''.
contact.1607624050.txt.gz · Last modified: 2020/12/10 19:14 by marijn.nijenhuis