Personal tools
You are here: Home / cm / Wiki / Summary Notes on Failed cm Tests
Navigation
Log in


Forgot your password?
 

Summary Notes on Failed cm Tests

This represents a summary of the status of the cm tests that are currently failing, together with notes on the suspected or possible reasons for the failure and who might be responsible.

Please edit when the information is inaccurate, when you have more information on the reason for the problem, and especially when the reason for the failure has been resolved.

(These issues could be represented as many different bugs in the tracker, but I haven't worked out how to indicate interdependencies or groups within the tracker, the description in view mode renders poorly under khtml, and it is easier to paste them into one page.)

Tests that Stopped Succeeding in 2005

  • "e32: Male torso - with salu":http://cmiss.bioeng.auckland.ac.nz/development/examples/e/e3/e32/index.html

    Broke when the testing of cmo_irix shifted from esu8 to esu20 between 21 and 27 August 2005. The difference is in a binary signal file that is not checked for any of the other versions.

    Someone who can interpret the binary signal files needs to determine whether the difference in output is significant. If the difference is acceptable then the comparison method needs to be changed to accept such differences (or someone needs to check the differences by hand and update answers every time they change).

    There is a .ipsign file that presumably contains the same information as the .signal file. Is there any need to test the binary file?

    Leo: It it necessary to test the binary files to ensure the files are of the appropriate format. One solution is to convert the binsig files to ipsign files as part of the test and only compare those.

    To test writing binary files perhaps a fixed solution that it not affected by roundoff error in numerical calculation could be used.

  • "5d3: Active contraction of LV wedge (Gauss point based)":http://cmiss.bioeng.auckland.ac.nz/development/examples/5/5d/5d3/index.html

    Between 3 and 6 July. This example is not tested with any debug versions.

  • "5d2: The old (Gauss point based) approach to active tension modelling":http://cmiss.bioeng.auckland.ac.nz/development/examples/5/5d/5d2/index.html

    Apparently due to changes by Jae between 30 June and 1 July 2005

    There are two issues:

    • The deformed_fibres fields in deformed_0.exnode are NaN for cm-debug-clear-malloc and cm-debug-clear-malloc7. This may indicate that the values have not been initialized.

      At activation_level greater than 0, the fields contain small non-NaN values. What has caused the values to be updated?

    • At activation level zero there is apparently no stress and the data for gauss_stress_0.exdata contains values smaller than 1e-99. These are output in the file without the 'E' to separate the mantissa and exponent.

      Either the output format needs to be changed to allow exponents less than -99 or a zero needs to be output instead.

  • "b361: Noble 98 - HMT 2D sheet with varying fibre orientation":http://cmiss.bioeng.auckland.ac.nz/development/examples/b/b3/b36/b361/index.html

    "b362: Noble 98 - HMT 2D sheet with infarct & SAC's":http://cmiss.bioeng.auckland.ac.nz/development/examples/b/b3/b36/b362/index.html

    cm_n32_clear_malloc and cm_n32_clear_malloc7 between 27 June and 1 July

  1. Jae?

    Similar deformed_fibres issues to 5d2, but the values are NaN at all time steps. Is there a command to update these values?

this example now gives unreasonable results.

rs6000-aix/cm-debug has a negative pressure and so tries to divide by "elastic

wall const kappa" which is zero. The pressure may not be meant to be negative so the invalid kappa is probably not the real problem. On hpc2 a SIGTERM signal was generated, but on esu20 the example appears to run indefinitely. This may be just a very long time due to floating point exceptions.

Kelly is checking whether instability is the problem and whether different

time steps would resolve this.

changed when our AIX system changed from a p690 to a p595 (March to May 2005).

Someone who can interpret the binary signal files needs to determine whether the difference in output is significant. If the difference is acceptable

then the comparison method needs to be changed to accept such differences (or someone needs to check the differences by hand and update answers every time they change).

on Linux (25 Jan 2005).

The output differs before the optimise command is used. It looks like it may be happening in the "adjusted dipole" phase.

Compiling ddot.f with O2 instead of O0 makes the answers the same as the reference answers but the O0 answers may in fact be better (smaller error reported).

valgrind did not show up anything that could cause the initial differences.

Examples that are private to the electrical imaging group:

  • eab: Event Detection of Signals

    The unemap library is no longer available. It was once generated as part of cmgui, but no one knows why it is no longer generated.

    Leo: Something wrong with the Makefiles on either the cmgui or cm side? Possibly occured during the hpc SAN shift.

  • e919: Creating 3 Types of Transfer Matrices with Generic Male Torso

    cm_linux_debug

    (Leo: cannot find /hpc/cmiss/cm/bin/i686-linux/cm-debug, I guess this is a static debug version which is no longer built)

  • e924: Small zeroxing activation example

    cm_linux_debug

  • e923: Zeroxing activation

    cm_linux_debug and all rs6000-aix

Examples that have been broken for a long time

Apparently no one cares that these examples are not working. Is it because they have been obsoleted by different methods? If so the the examples should be removed. If not then shouldn't the example be updated to test what is expected to work and document what doesn't?

Examples for which at least one test has never worked.