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.
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!):
- Show size:
moCacheFile Check
- Delete files not used for 3 months:
moCacheFile Retire
- Delete all cache files:
moCacheFile Delete $all
- Limit cache size to X giga bytes:
moCacheFile('Limit', X)
This delete older cache files at first.
- These commands are available in the context menu, which opens after a
right-click on the Cache trials button of the MoMoG dialog.
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.
The self-test of MoMo performs a bunch of tests:
- Same base methods of MoMo are checked:
moVersion,
momoPrefs, dependencies to toolbox and filter functions.
- The productive model scripts (this means all models known by
moModelManager) are checked with momoCheckModel.
- A list of sessions is processed, e.g. all known sessions or all
sessions inside a specified path:
momoSelfTest exhaust and
momoSelfTest('exhaust', '<TestPath>').
- One session is processed with a variety of input arguments:
momoSelfTest deep.
- The deep test includes starting MoMoG, playing around with
callbacks of the sheets, the self test of
ShowC4D and checking ShowC3D.
In addition user-defined color styles are applied and norm data created, if
the corresponding data are available.
- The unit-test functions inside the folder <MFiles>\MoMo\ are
started.
- Unfortunately not all functions of MoMo are called during an exhaustive
self-test.
A successful self-test is needed for a new
certification.
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:
- a new Matlab version is installed,
- a model script is added or modified,
- any user-related functions have been changed,
- a patch of MoMo or the GL-toolbox was sent from the author,
- the local MoMo-administrator has a really good reason to edit the
source code personally.
Then the following steps are the standard procedure applied for programming MoMo:
- 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.
- 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.
- Send a complete description to the author.
- 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.
- 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.
- 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.
- Run the unit-tests for all functions:
addunittest; UnitTest.
- Run MoMo's self-test and control the output manually:
momoSelfTest.
- 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.
- 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.
- 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.
- If your are not sure, send the changed files to the author of MoMo and asks
for a new certificate.
- 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!
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:
PutASC inserts the lab's name in the header line of ASCII
files. This name is inserted automatically in the file PutASC.m during the
creation of a MoMo release:
DefaultLocation = 'Jan Simon'; % @:{STRING=LAB_NAME}
Then the string 'Jan Simon' can be modified by:
LocalizeSource('PutASC', 'String', 'LAB_NAME', 'TheLabName').- With similar keys lines or blocks of lines can be defined, which can be
commented or deleted according to certain conditions:
Data.PatientKey = 'Patient '; % @:{LINE:SESSION=GaitlabHD}
%Data.PatientKey = 'Subject '; % @:{LINE:SESSION=UNSWBiomechLab}
or
% @:{BLOCK:LANGUAGE=German}
Reply.Dynamics = {'PelvicTilt', 'Becken Kippung'};
% @:{BLOCK:END}
% @:{BLOCK:LANGUAGE=English}
%.@Reply.Dynamics = {'PelvicTilt', 'Pelvic tilt'};
% @:{BLOCK:END}
Then these lines or blocks can be commented with the following commands:
LocalizeSource('$user', 'SwitchLine', 'SESSION', 'GaitlabHD')
LocalizeSource('$user', 'SwitchBlock', 'LANGUAGE', 'German')
Here '$user' accesses all M-files in user-defined folders in Matlab's path,
see GetMFiles.
The commands 'CropLine' and 'CropBlock' deletes the corresponding line or block.
So do not get confused by comments with the magic sequence
"@:{...}". Just ignore them or use
LocalizeSource
to control them.
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:
- Find touched source files:
JRev check $user
- Update the version line and create a copy of the new files in
<MFiles>\Archive\Updated<current_date>:
JRev udpate $user
- Find source files, which have been modified since the last certification
of MoMo:
momo cert
The function
MaskPassword enciphers and deciphers passwords,
such that they can be sent securely in emails to other MoMo users. Usage:
- Choose a secure password: 8 to 17 characters, 2 or more special
characters, no allowed: space, ', ", \, ` (char [0:32, 34, 39, 92, 96]).
- Encrypt the data with this password, e.g. with WinZIP, WinRAR.
- Start MaskPassword and type in the plain text password.
- After hitting return, the enciphered password is calculated and can be sent
over insecure internet channels.
- 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.
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