MoMo R5.1: Admin

1. Contents
2. Setup
3. Preferences
4. Sessions
5. Command line
6. Models
7. Visualize C3D
8. Administration:8.1Log files
8.2Trial cache files
8.4MoMo's self-test
8.5Editing MoMo's sources
8.6Localize sources
8.9 Disclaimer of warranty
9. Changes

8.1 Log files

During processing a session, MoMo writes its output to the command window and to the file "momoLog.txt" in the session folder. The level of details in this output can be controlled with the command Debug. New log files replace older ones.
The contents of the log file in a session folder is displayed, when the status button of MoMoG dialog is pressed.
In addition the status and the date of processing are added to the fields MOMO_SUCC and MOMO_PROC in the session-ENF. Here you can find the last model, which computed the sessions with success and the information about the last (successful or failing) processing. If these fields are inserted in the ENI file, you can check the status from Vicon-WorkStation also.
Besides the logs in the session folder, any access of MoMo is stored in log file with the date, computer, MoMo issue, session folder and applied model script. The name of the user is not included in this list except for events concerning an installation.
This log files is written to <MoMoData>\Logs and if the file size exceeds 200kB, the current date is appended to the file name and a new file is created.
The command momo runlog (see: RunLog) displays this log file (and the older logfiles, see popup-menu on the left bottom), e.g. to clear the questions, if a session has been processed successfully before, which MoMo issues are in use, when an error occurred the first time etc.

8.2 Trial cache files

The trial-cache files contains pre-parsed copies of the C3D and ENF files of each processed session. They are written to the local Temp directory. This saves a lot of time by avoiding network traffic and the complex work of GetC3D. Deleting the cache files does not destroy any original data.
Former versions of MoMo preferred to write cache files in each session folder. But it is faster and safer to store them locally on each network client. Even when working on the local computer it's nicer not to write redundant data into the session folders.
The size of this cache files can be controlled with (case of argument matters!):

8.3 Unit-testing

Following Turing and Gödel, the correct working of a function cannot be proved completely. Nevertheless, the working in specified limits can be shown by comparing the reactions to a certain set of inputs with expectations. A meaningful test must contain invalid inputs also: bad number, bad type, bad size, bad shape, empty data. In such cases stopping with an error message is the most secure choice, because wrong results must be strictly avoided.
For MoMo and the GL-toolbox such tests are performed by so-called unit-tests. The corresponding functions are stored in subfolders called "UnitTests_", which are included in the Matlab path by the command addunittest. These test functions can be called alltogether by the function UnitTest or manually. Especially if the environment has changed, a complete test is strongly recommended: new Matlab version, new toolbox functions, new compiler, new operating system, new processor...
Some of the test functions perform speed tests, which can be suppressed by an input argument: Test<FuncName>(false) or UnitTest('nospeed') respectively.
Unfortunately the unit-testing is not available for older functions of the GL-toolbox. If a test exists, the help section of a function contains the line:
"% Tested: ... [UnitTest]"
To add new test functions, search or create the folder "UnitTests_" in the parent folder of your function. Create the function "Test<YourFcnName>", which accepts a logical scalar as optional first argument to trigger speed-tests. If the tests fail, the test should stop with a unique error message.
To measure the execution speed, do not perform a fixed number of loops, but run a loop for a specified time > 1 sec. Then the test runs on a 75MHz Pentium 4 and a 3GHz Core 2 Duo. See TestCStrCatStr for an example.
A successful unit-test is obligatory for a new certification!

8.4 MoMo's selftest

The self-test of MoMo performs a bunch of tests: A successful self-test is needed for a new certification.

8.5 Editing MoMo's sources

The full version of MoMo is delivered with the source codes, because in the opinion of the author effective scientific working is possible only, if the algorithms can be observed completely. Because a computer program cannot be free of errors, a scientist needs the ability to control the source of errors as far as possible. It is worth to learn from the bugs the authors has left in the program.
Nevertheless, if a customer of MoMo does not just learn from errors, but fixes them, a serious problem occurs: in general changes in the program can influence the following program execution in an unpredictable way ever. In consequence a supposed fixed bug can be the source of further bugs, which can invalidate the results of MoMo in the worst case.
Therefore customers are not allowed to change the source code of MoMo and any of the used functions. Independent from the individual license conditions, the author does not answer questions to problems and does not grant any support, if any function of MoMo has been modified in any way.
There are some function thought for user-modifications: user defined color schemes (created from template UserColorTemplate_), StudyStaffList, moModelManager to insert pointers to new models, and new model itself. Although the author tried to encapsulate these functions from the core of MoMo, no guarantee can be given concerning potential negative effects coming from these functions.
Note:  Do not modify the source code of MoMo and its subroutines!
In case of problems create a qualified report with BugReport and call the author.
After these explicit disclaimers and warnings, the author's strategy to control the integrity and reliability of MoMo is described here. It is strongly recommended to follow this strategy if: Then the following steps are the standard procedure applied for programming MoMo:
  1. Do not create new bugs! Never redefine an existing variable. Do not write complex IF-statements with short-circuiting and side-effects. No global variables. Use SuError and SuWarn for messages.
  2. Insert exhaustive comments in the source code and in the header section of the function (the "% History:" part) including date, name and description of the solved problem.
  3. Send a complete description to the author.
  4. Do not create files in MoMo's folders except for the folders Models_Safe and Models_User, because updates of MoMo can overwrite these files otherwise.
  5. Let Matlab assess the integrity of the code. Use MLINT in Matlab 7. If you have access to Matlab 6.5, check the functions with: CheckSyntax $user force+detail. Clean the source code until no errors and warnings appear anymore.
  6. Check for stricter syntax rules: CheckMLines $user. This function of the GL-toolbox warns for statements without a trailing semicolon, also e.g. "return" does not really need one. Nevertheless, a strict programming style allows for an easier location of typing errors.
  7. Run the unit-tests for all functions: addunittest; UnitTest.
  8. Run MoMo's self-test and control the output manually: momoSelfTest.
  9. Keep a copy of the new and the old version of files, such that the exact status of MoMo's source can be reconstructed to reproduce results. See versioning.
  10. MoMo can cleanup its resources automatically, e.g. the contents files, dates of changes and the list of input arguments in the documentations: momo cleanup. The user needs at least temporary privilegs for the administration of MoMo (this does not mean the administration of the local computer) - ask the author how to get them.
  11. If and only if the source code passed all these tests, the certificate of the new or changed functions can be updated: momoCert $create. As for the cleanup (previous point), MoMo administration privilegs are needed.
  12. If your are not sure, send the changed files to the author of MoMo and asks for a new certificate.
  13. Even with a valid certificate and after testing MoMo for years, bugs can influence the created output. So if a human locomotion system is assessed with MoMo, compare the results of MoMo with other sources as video-tapes, clinical examinations and visual impressions. Find a scientific explanation, if any discrepancies occur. If you are in doubt, do not trust the output of MoMo!

8.6 Localize sources

The source code of MoMo can be adjusted to the environments of different laboratories autoamtically by the function LocalizeSource. Therefore the magic key "@:{...}" is inserted as comment in the source code. Inside the curly braces different commands and conditions modify the program text directly. This results in tighter source code than with creating local preferences data for values, which are never changed. In addition the automatic source code modification is safer than the manual editing if dozens of files and conditions must be taken into account.
Examples: So do not get confused by comments with the magic sequence "@:{...}". Just ignore them or use LocalizeSource to control them.

8.7 Versioning

Large programming projects as MoMo need a versioning system, e.g. CVS, SourceSafe or SubVersion. Although these established tools are very powerful, they cannot be integrated in Matlab and MoMo satisfactorily due to restrictions of the internet connection from the Orthopedic Clinic in Heidelberg. Therefore the simple functions JRev and JBuild are responsible for the version management. While JBuild is most likely not useful for customers of MoMo (and not included in the distributions), JRev can be helpful to control and protocol changes in the source files.
The source files, which are managed by JRev, contain a line with a version number and the date of the last modification. A second line stores the file name relative to the <MFiles> folder. Example:
% $JRev: R5.02t V:024 Sum:A77A6E43 Date:26-Jan-2009 20:51:50 $
% $File: MoMo\R5.0\MomoSuper5.02\momoCleanUp.m $
Some commands to check the status of source files:

8.8 Encryption

The function MaskPassword enciphers and deciphers passwords, such that they can be sent securely in emails to other MoMo users. Usage:
  1. Choose a secure password: 8 to 17 characters, 2 or more special characters, no allowed: space, ', ", \, ` (char [0:32, 34, 39, 92, 96]).
  2. Encrypt the data with this password, e.g. with WinZIP, WinRAR.
  3. Start MaskPassword and type in the plain text password.
  4. After hitting return, the enciphered password is calculated and can be sent over insecure internet channels.
  5. Any other MoMo user can decipher the password again by inserting it in the Cipher field of MaskPassword.
Note: Random salt is added to the clear text password before enciphering. Therefore different cipher strings are replied for the same input. A large number of 128 bit AES encryptions are performed to slow down brute force attacks.
A future version of this tool will perform the encryption and compression of files internally.

8.9 Disclaimer of warranty

Covered code is provided under this license on an "as is" basis, without warranty of any kind, either expressed or implied, including, without limitation, warranties that the covered code is free of defects, merchantable, fit for a particular purpose or non-infringing. The entire risk as to the quality and performance of the covered code is with you. Should any covered code prove defective in any respect, you (not the initial developer or any other contributor) assume the cost of any necessary servicing, repair or correction. This disclaimer of warranty constitutes an essential part of the license agreement. No use of any covered code is authorized hereunder except under this disclaimer.
See also: momo licensedoc
Author: © Jan Simon, Imprint / Impressum   File: Help/momo_5.1/admin.html    24-Nov-2018   MoMo: 5.1.34