Use case: Simple local user

[denisri]

Summary: A non-developper user could launch analysis/preprocessing pipeline locally on local data.

Description: A simple user must be able to launch a software (like Brainvisa) with UI, to launch preprocessing pipelines (like in nuclear medicine toolbox) on local data. This pipeline would be run for one data at a time, with possibility to change pipeline parameters between each run, and be able to find results for each run. But also launching processings that have already been done do not create duplicate results files. Those results could be numeric data or preprocessed images.

Participants: Single user

Datasets: Local database of PET/MRI data, source and results in same DB.

Dataflow: N/A

Security: N/A

Workgroup(s): pipeline

Module name: bv_use_cases.simplest

[sapetnioc]

I implemented this use case using a separate process in the engine (another Python is launch to execute process). Discussion about this will be in Capsul but this raises a question. What should be the API to retrieve output values ? This is still missing in the use case. Even if the result is in the status of the process, it is a JSON serialization of the process parameters (input and output). It is possible to update the executable parameters by using

executable.import_json(final_status['parameters'])

I think we should provide some methods on CapsulEngine to make it implementation independent For instance:

capsul_engine.update_executable(executable, final_status)

[denisri]

So there is a new object named Capsul in the API. It apparently replaces the CapsulEngine.get_process_instance() method with Capsul.executable() and contains the CapsulEngine object we had before. Was it useful to separate it into 2 classes, which, with Settings, makes 3 "global" objects with a public API ? Doesn't it make it a bit difficult for a novice user (programmer) to start, where a single object would have gathered the main user API in a single place ?

[sapetnioc]

This is to be discussed. I made these choices without a written use case so it is not obvious that this is optimal. I put some explanation in the comments. The Capsul object is similar to application objects in web frameworks or Qt. Its main goal is to read all the configurations accessible to user : site level (e.g. on /etc/...), user level (e.g. on /home/...) and session level (e.g. environment variables). In this configurations, user may have access to several capsul engines, for instance local, triscotte and n4h. The separation allows to easily choose one of them for processings:

capsul = Capsul()
with capsul.engine('triscotte') as capsul_engine:
    # Do something on triscotte here via capsul_engine

I do not think we need a Settings objects here (configuration could be managed by Capsul API) but there are 3 still different concepts in this code:

• Capsul that exists only in user environment
• CapsulEngine that makes the link between user environment and execution environment
• Executable that exists in both environments. To date, it is just another name for Process instance to be able to clearly identify when we talk about a process (i.e. a kind of piece of code that needs parameters to run) from the executable that contains a process as well as all it needs to be executed (e.g. its parameter values).

[denisri]

OK we'd better have this discussion in the capsul project. Let's move to https://github.com/populse/capsul/issues/198.

[sapetnioc]

In my example, I tend to use enough details to be able to discuss internal details. But I keep in mind that we will probably provide some useful shortcut methods. For instance, the detailed example may easily be made compatible with the following code:

from capsul.api import capsul_engine

with capsul_engine('triscotte') as ce:
    executable = ce.run('bv_use_cases.simplest.list_directory')
    print(executable.result)