| T O P I C R E V I E W |
| bn14 |
Posted - Aug 07 2009 : 3:06:53 PM
Hello,
I'm getting the following unusual error from FSL:
/usr/local/fsl-4.1.4-centos4_64/bin/feat_model design
Can't open OUT_OCC_n5 for reading
I assume that this is a temp file that fsl creates.
I checked the '/tmp/feat_01izY8' directory on each node, and they each appear to contain thousands of files (e.g., feat_01izY8). I'm wondering if it is possible that I'm getting this error because the /tmp directory is full?
Thanks for any help,
Brandi |
| 11 L A T E S T R E P L I E S (Newest First) |
| petty |
Posted - Aug 17 2009 : 4:01:11 PM
assuming you've set your $FSLDIR to the newer install ... you can call $FSLDIR/bin/fsl or $FSLDIR/bin/Feat directly.
for most of their tools if you call the command line name, with a capitol letter, thats the interactive version. |
| petty |
Posted - Aug 11 2009 : 4:11:58 PM
yeah unfortunately setting the FSLDIR only affects the calls fsl makes within its own program, but does nothing to your search path.
|
| dvsmith |
Posted - Aug 11 2009 : 4:08:06 PM
Hmm... I believe I ran this test just by calling feat, which apparently is pointing to the wrong version even though I set FSLDIR to the proper directory, exported that variable, and then sourced the config file before I ran it (I guess it's not in the path). Nevertheless, if you look at the logs in that directory I uploaded, it looks like the correct version of FEAT was being called in both instances.
So, I just retested trying $FSLDIR/bin/feat design.fsf and feat design.fsf. Again, the calls to the programs are exactly the same (see the logs in the files I uploaded), so it's ostensibly using the same version. Yet, $FSLDIR/bin/feat seems to have worked while $FSLDIR/bin/feat produces the same error. Strange...
The lesson seems to be always call the programs using the whole path (i.e., $FSLDIR/bin/feat). I guess we should also mention that on the forum string that tells BIAC users how to use newer versions?
I'll test this on the real nodes tomorrow to make sure it's the problem. It definitely seems to be...
Thanks, Chris.
Cheers,
David
|
| petty |
Posted - Aug 11 2009 : 2:27:16 PM
it worked for me on both my machine and node4 ...
when you are calling feat .. are you pointing it to the full path of the feat executable ($FSLDIR/bin/feat)?
On the cluster this is key because there are multiple versions so people can use them, and the most current isn't actually the default. |
| dvsmith |
Posted - Aug 11 2009 : 1:46:46 PM
That would be great -- try downloading http://www.duke.edu/~dvs3/FEAT_test.zip
Basically, the idea is to use the confoundevs.txt file so that motion covariates can be used when running prestats and stats separately (see this thread for more details: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0907&L=FSL&P=R43281). In the newest version of FSL, there is an option to include additional confound evs, so you simply point to the confoundevs.txt file. this only works when when running through the GUI (on our system). but, you can take the same exact design.fsf that ran successfully through the GUI and run it on the command line and it fails (i.e., feat design.fsf) -- which is obviously inexplicable and very annoying. This error does not replicate on other systems (e.g., Mac).
Thanks again. |
| petty |
Posted - Aug 11 2009 : 1:15:22 PM
i have an equivalent version on my machine if you want me to try and test something. |
| dvsmith |
Posted - Aug 11 2009 : 11:31:13 AM
ok, thanks Chris.
The Mac version and the version on our cluster are unequivocally different (i.e., the former works while the latter is buggy). Unfortunately, I don't have the option of testing the exact version we have on the cluster on a different machine. |
| petty |
Posted - Aug 11 2009 : 11:16:37 AM
this was an issue with a path replacement not being executed when submitted .. that was a user variable name that never was substituted in the design.fsf
although, there's always the chance for small bugs in the release. however, whenever we do updates of fsl we always install the full release, not the patches. So currently we're running the latest distro. |
| dvsmith |
Posted - Aug 10 2009 : 11:28:48 PM
Chris,
Is it possible that the version of FSL we have on the cluster is simply a little buggy? Maybe there's something broken in the 64-bit Centos distribution of FSL, or maybe there's something odd with the cluster. Could we try putting latest release (full distribution, not the patch) on a node and see if that fixes it.
I've certainly ran across weird things like this before, and they can never be replicated on other systems. The most recent example is an issue with implementing the "add confound EVs" that was added in v4.1 (see https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0907&L=FSL&P=R28440). I've been going back and forth with Matthew Webster about this, and we're still not sure what to make of it.
Thanks,
David |
| bn14 |
Posted - Aug 07 2009 : 3:20:59 PM
The output directory isn't full. We've been trying this all day, and on all of the nodes, so the problem has been pretty persistent. Is anyone else having this problem? Any other ideas for things to check on?
Thanks!
brandi |
| petty |
Posted - Aug 07 2009 : 3:15:02 PM
all of those files are empty files that FSL creates, but apparently doesn't clean up.
/tmp is definitely not full ... when your jobs runs it should be writing to where you've set your out directory to be. there's a chance that could be full, or there was a network glitch at the time it was trying to access that file. |
