Back to the main page.
Bug 1441 - openmeeg test scripts are not executed
| Status | CLOSED FIXED |
| Reported | 2012-04-19 18:05:00 +0200 |
| Modified | 2012-06-20 15:03:22 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P3 normal |
| Assigned to: | Boris Reuderink |
| URL: | |
| Tags: | |
| Depends on: | 1457 |
| Blocks: | 1264 |
| See also: |
Robert Oostenveld - 2012-04-19 18:05:26 +0200
These should be executed whenever a change is made to the relevant code. I do notice that the testOpenMEEGeeg function does not include the "TEST" trigger points. Another section of test scripts that might have gone untested due to the recent changes in the test framework is external/mne/test/test_ex_compute_inverse.m external/mne/test/test_ex_read_epochs.m external/mne/test/test_ex_read_raw.m external/mne/test/test_read_forward.m these also have to be checked on correct execution and should be auto-executed at the appropriate times.
Boris Reuderink - 2012-04-23 14:05:50 +0200
So far only scripts in $FIELDTRIP-ROOT/test were run. Additional dirs that seem to contain tests are: $ for d in `find -type d -name "*test*"`; do echo $d: `ls $d | wc -l` ; done ./preproc/test: 0 ./external/mne/test: 5 ./external/simbio/test: 4 ./external/simbio/vgrid1.3.1/program/test: 17 ./inverse/test: 0 ./plotting/test: 15 ./connectivity/test: 0 ./specest/test: 0 ./fileio/test: 4 ./contrib/spike/test: 13 ./realtime/buffer/test: 55 ./realtime/buffer/cpp/tests: 1 ./test: 163 ./forward/test: 25 I can enable all test*.m files in all subdirs for automated testing. But should we run test scripts in external packages by default? Exceptional dirs (that is, no subdir names 'test') that contain test*.m files are: $ find . -name "test*.m" | xargs -n1 dirname | sort | uniq | grep -v test ./external/openmeeg ./fileio/@uint64
Alexandre Gramfort - 2012-04-23 14:22:57 +0200
boris, I think you should run tests of external packages otherwise you will keep breaking other people's code. I can do whatever I can to make sure MNE tests and OpenMEEG tests pass on your buildbot. Feel free to rename my OpenMEEG functions to match the Fieldtrip test triggers. Alex
Boris Reuderink - 2012-04-25 13:33:21 +0200
(In reply to comment #2) Ok, good point. I am not completely familiar how Fieldtip's OpenMEEG is updated with an upstream version; if I rename the test scripts, would that complicate keeping FT's OpenMEEG up to date?
Alexandre Gramfort - 2012-04-25 14:18:07 +0200
> Ok, good point. I am not completely familiar how Fieldtip's OpenMEEG is updated > with an upstream version; most OpenMEEG users use the last released version. So no need to update OpenMEEG on a nightly basis. can you run the tests yourself? > if I rename the test scripts, would that complicate keeping FT's OpenMEEG up to date? no go ahead. Let me know when you do so I can try. can you run the tests yourself? Alex
Boris Reuderink - 2012-04-25 15:03:28 +0200
I just tried running testOpenMEEGeeg in the external/openmeeg dir, and it complains that it cannot find OpenMEEG. I'll ask Cristiano if he knows more.
Alexandre Gramfort - 2012-04-25 15:05:11 +0200
do you have openmeeg installed? can you do: system('om_assemble') ? if it complains about not finding some libraries make sure the the lib folder is in LD_LIBRARY_PATH on linux or in DYLD_LIBRARY_PATH on mac. Alex
Boris Reuderink - 2012-04-25 15:26:35 +0200
(In reply to comment #6) Hmm, my mistake. I was under the impression that OpenMEEG was packaged with FT, since it is in the external dir; but apparently I had to install it. On Windows (can't access the Linux cluster right now), I can now run testOpenMEEGeeg --- at least it now fails much later: --- Warning: The input units are unknown for points and S/unknown for conductivity > In forward\private\warning_once at 81 In ft_compute_leadfield at 531 In testOpenMEEGeeg>run_bem_computation at 88 In testOpenMEEGeeg at 15 RDMs: 0.019963 0.019962 0.10695 MAGs: 0.84467 0.84469 0.83892 ??? Undefined function or method 'assertElementsAlmostEqual' for input arguments of type 'double'. Error in ==> testOpenMEEGeeg at 16 assertElementsAlmostEqual(rdms, [0.019963 0.019962 0.10754], 'absolute', 1e-3) --- Do you know where it is defined?
Alexandre Gramfort - 2012-04-25 15:34:33 +0200
assertElementsAlmostEqual comes from the mtest package : http://www.mathworks.com/matlabcentral/fileexchange/22846-matlab-xunit-test-framework feel free to rewrite this test without this dependency if needed. You just need the equivalent of from numpy.testing import assert_array_almost_equal # in python if you have errors at the 3 decimal feel free to increase the threshold. Alex
Boris Reuderink - 2012-05-01 11:46:30 +0200
Thanks. The test scripts now run successfully. It is not yet reflected in the test dashboard [1] (the openMEEG installation needs to be completed on the cluster). [1] http://fieldtrip.fcdonders.nl/development/dashboard
Alexandre Gramfort - 2012-05-01 17:59:19 +0200
excellent ! thanks for taking care of this. Alex
Boris Reuderink - 2012-05-23 12:52:37 +0200
The openmeeg indeed show up in the dashboard; and most test pass. I close this issue.