Closed manuegrx closed 7 months ago
Wrapping MATLAB in Mia is not an option.
Nipype provides tools for this. I wonder if Capsul also allows to do this directly? @denisri , am I wrong?
Using MATLAB (with licence) is an interesting option. However, I think we should also (or even mainly) offer an alternative with MCR. I believe the GIN has a MATLAB compiler. It would be worth exploring this possibility, even if we can already see some foreseeable difficulties (version of MCR compared with that of the SPM standalone, management of different OS, etc.).
I guess in capsul, matlab.executable is the matlab non-MCR program: if it is configured (with a correct path) then it should mean that a "full" matlab is available. In the requirements of a process, we need to require it to be non-empty. Let's see:
from capsul.api import Process, capsul_engine
class Papa(Process):
def requirements(self):
return {'matlab': 'executable != ""'}
ce = capsul_engine()
pr = ce.get_process_instance(Papa)
pr.check_requirements()
results in requirements not met: requirement: capsul.engine.module.matlab : executable != "" not met in Papa
and None
is returned. Now if:
with ce.settings as settings:
conf = settings.new_config('matlab', 'global', {'executable': '/opt/bin/matlab'})
pr.check_requirements()
now returns:
{'capsul_engine': {'uses': {'capsul.engine.module.matlab': 'executable != ""'}},
'capsul.engine.module.matlab': {'config_id': 'd3d34fc1-b555-4d6d-b32f-a3055a542da2',
'config_environment': 'global',
'executable': '/opt/bin/matlab'}}
To actually run it, using nipype as you are doing is perhaps a good solution. Otherwise we would need to add a matlab module in capsul.in_context
, which has not been done because we did not have this use case up to now.
I think it's a very good thing to be able to use MATLAB code directly, for example if it's large code, to avoid having to spend time translating it into python in certain situations.
Indeed, as @manuegrx suggests, using nipype can be an interesting alternative to adding a matlab module to capsul.in_context (which could be considered later if necessary).
This is a very good thing.
However, I think we should also look into the possibility of using MCR. One of the advantages of Mia is we don't need MATLAB (license). Most SPM calculations are available with the standalone version, so it's a shame to have to install a MATLAB license because, for example, a brick only needs the licensed version. However, having to install the license is always better than nothing...
In short, the need for a quick and easy way to wrap MATLAB is real, and the need for MCR is at least as great!
I've just tested the branch.
Yes, this method works. It's just a shame to have to search the stdout
to find the result (we'll have to play with the RegEx!). That said, we often want to work on files in a brick, so we should rarely have to retrieve a value from the brick's output.
Until now, the check of requirements at initialisation time has not been designed for this specific case. We check whether matlab or MCR is present (so far, we haven't needed the case where we particularly, and exclusively, need the Matlab license -> ['capsul_engine']['capsul.engine.module.matlab']['executable']).
Once this method has been fully validated, we'll need to make the necessary changes to requirements check at initialisation time.
For the moment, I think this does not prevent operation in developer mode.
A final word on the subject: a long time ago, we ran a few tests, which if I remember correctly worked, to launch a matlab script directly in Mia (without nipype or module in capsul).
Since the idea here is to finally run a matlab script, maybe that would work too (so we know exactly what's being done - sometimes nipype is a bit of a black box ... -)
As it looks like we already have a solution for wrapping a Matlab code (without MRC) (and in order to not keep an unused branch), I removed the branch "matlab_module"
If we need to wrap Matlab code using Nipype, I keep the code here :
To take full advantage of this opportunity, I think it would be best to add this ComputeBrainVolume
brick to the mia_processes library, with documentation mentioning that it requires an exclusive Matlab license, is provided as a proof of concept for developers and in the absence of a better solution (with MCR), this is the one that can be envisaged from now on.
That way, we can always draw inspiration from it.
@manuegrx can you do it? (it's mainly the doc that's going to take time)
@servoz done with this commit https://github.com/populse/mia_processes/commit/acefdf7c06c31300fd3f8b73eb7e6d66cfd79c85 !
Perfect, thanks.
I think this ticket can now be closed.
We discussed a while ago that it might be useful to be able to wrap a MATLAB script in a mia processes brick, so I tried with a simple Matlab script.
My test is in the following branch (not to merge, as it is only a test and the matlab script is not a useful one): https://github.com/populse/mia_processes/tree/matlab_module
I created a brick that runs a specific matlab script. For now, the brick is in brick/preprocess/matlab and the matlab script is in brick/preprocess/matlab/scripts folder The steps in the "run_process_mia" part are as follows:
MatlabCommand
There are questions and things to be explored before continuing:
About the requirements: from what I know, run a matlab script only works with Matlab and not with Matlab standalone (MCR), so we need to check in the brick's requirements that Matlab (and not MCR) is available. However, currently when we uses
matlab
in theself.requirement
of the brick, it only check that matlab is available (standalone or not). → see how to check this information and make the brick available only if it is okayAbout the configuration: I configured the matlab path in the "run_process_mia" part but I think it should be done at a higher level and not directly in the brick (for Nipype we need to set "MATLABCMD" with
os.environ
).In my test the matlab script are stored in brick/preprocess/matlab/scripts folder, I do not now if it is a good idea or not. Same for the folder brick/preprocess/matlab/ , maybe a other name will be more appropriate but right now I have no idea
Once we have progressed a little further I could try to wrap a more useful (and complicated) matlab script (maybe the one used to convert physio file in AMIGO)