Fastr 1.2.0 release

[Hakim Achterberg]

We just released Fastr 1.2.0, this update bring a lot of new features regarding batch processing and inspection of the result of a workflow. There are also many smaller features and bugfixes added. The full changelog can be found at: https://fastr.readthedocs.io/en/stable/static/changelog.html

The packages just uploaded to pypi, so installing should be as simple as pip install fastr==1.2.0 or pip install --upgrade fastr==1.2.0 to upgrade.

If you experience any problems or would like to request features for future version, please post to the discussion group.

[Marcel Zwiers]

pip install --upgrade fastr==1.2.0
worked successfully (it seems at least) but gave two warnings:

[...]
  Found existing installation: psutil 5.0.1
    DEPRECATION: Uninstalling a distutils installed project (psutil) has been deprecated and will be removed in a future version. This is due to the fact that uninstalling a distutils project will only partially uninstall the project.
    Uninstalling psutil-5.0.1:
      Successfully uninstalled psutil-5.0.1
[...]
  Found existing installation: lxml 3.7.2
    DEPRECATION: Uninstalling a distutils installed project (lxml) has been deprecated and will be removed in a future version. This is due to the fact that uninstalling a distutils project will only partially uninstall the project.
    Uninstalling lxml-3.7.2:
      Successfully uninstalled lxml-3.7.2
[...]

Op woensdag 15 maart 2017 14:30:11 UTC+1 schreef Hakim Achterberg:

[Hakim Achterberg]

I think the warnings are from pip and do not really have to do with Fastr itself, so I'm just going to ignore them. ;-)

[Marcel Zwiers]

Maybe fastr can be a bit smarter when it comes to resolving the datatype of the sources (and constants and sinks I guess). For instance, when I do a simple 'Divide' using the shorthand notation I get this error:

fastr.toollist['Divide']
Out[47]:
Tool Divide v0.1 (Divide two numbers)
       Inputs          |       Outputs      
---------------------------------------------
left_hand  (Number)    |  result   (Number)  
right_hand (Number)    |                    

network = fastr.Network(id_='example')
divide_node = network.create_node('Divide', id_='divide_example')
[1] >> divide_node.inputs['left_hand']

[INFO]   network:0130 >> Changing fastr.current network to "example"
[WARNING]      link:0652 >> Cannot match datatypes <TypeGroup: Number class [Loaded]> and <TypeGroup: Number class [Loaded]> or not preferred datatype is set! Abort linking fastr:///networks/example/nodelist/const_divide_example_left_hand_0/outputs/output to fastr:///networks/example/nodelist/divide_example/inputs/left_hand!
Out[46]:
Link link_0 (network: example):
   fastr:///networks/example/nodelist/const_divide_example_left_hand_0/outputs/output ==> fastr:///networks/example/nodelist/divide_example/inputs/left_hand/0

More or less the same also holds for other sources, except that the type of which can only be resolved at runtime (i.e. when the network is executed)

Op woensdag 15 maart 2017 14:30:11 UTC+1 schreef Hakim Achterberg:

We just released Fastr 1.2.0, this update bring a lot of new features regarding batch processing and inspection of the result of a workflow. There are also many smaller features and bugfixes added. The full changelog can be found at: https://fastr.readthedocs.io/en/stable/static/changelog.html

[Hakim Achterberg]

Hi Marcel,

I think on the Network create time I should indeed not see this as an error, but how to treat this on run-time I am not sure about yet. Shall we discuss this the next time we meet? The question is basically if we want to assume preferences in datatypes or not. We could for example have a preferences in type groups, which should solve this problem. But I am not sure the preference would always be the same in all circumstances...

Cheers,
Hakim

[Marcel Zwiers]

Here's another feature request :-)

Suppose I have only 1 output that is automatic, how can I resolve the location? I would like for something like this to be possible i.e. use

output.directory

instead of

out.some_id_that_does_not_exist_in_this_usecase[0].directory

So the whole thing looks like this:

    <outputs>
      <output id="report" name="Summary report of the segmentation results" datatype="Directory"
              automatic="True" location="{output.directory}/slicesdir" method="path" cardinality="1"/>
    </outputs>

Instead of e.g.:

    <outputs>
      <output id="dummy" datatype="FilePrefix"/>
      <output id="report" name="Summary report of the segmentation results" datatype="Directory"
              automatic="True" location="{output.dummy[0].directory}/slicesdir" method="path" cardinality="1"/>
    </outputs>

Op woensdag 15 maart 2017 14:30:11 UTC+1 schreef Hakim Achterberg:

We just released Fastr 1.2.0, this update bring a lot of new features regarding batch processing and inspection of the result of a workflow. There are also many smaller features and bugfixes added. The full changelog can be found at: https://fastr.readthedocs.io/en/stable/static/changelog.html

[Marcel Zwiers]

Oops, I think

{output.directory[0]}

(thus with the extra [0]) should do the job, right?


Op maandag 10 april 2017 13:26:31 UTC+2 schreef Marcel Zwiers:

[Marcel Zwiers]

It should, but I'm getting this error message (in __fastr_stdout__.txt):

[CRITICAL] executionscript:0102 >> Execution script encountered errors: Traceback (most recent call last):
in execute_job
    job.execute()
  File "/home/mrphys/marzwi/.conda/envs/fastr/lib/python2.7/site-packages/fastr/execution/job.py", line 739, in execute
    result = tool.execute(payload)
  File "/home/mrphys/marzwi/.conda/envs/fastr/lib/python2.7/site-packages/fastr/core/tool.py", line 321, in execute
    result = self.interface.execute(target, payload)
interface.py", line 404, in execute
    self.collect_results(result)
interface.py", line 507, in collect_results
    collector.collect_results(self, output, result)
interface.py", line 126, in collect_results
    self._collect_results(interface, output, result)
ollector.py", line 127, in _collect_results
    output_parts=outputs)
AttributeError: 'tuple' object has no attribute 'directory'

I suppose this is caused by:

    <outputs>
      <output id="report" name="Summary report of the segmentation results" datatype="Directory"

              automatic="True" location="{output.directory[0]}/slicesdir" method="path" cardinality="1"/>
    </outputs>

Op maandag 10 april 2017 13:51:47 UTC+2 schreef Marcel Zwiers:

[Hakim Achterberg]

I added a new field {specials.workdir} that should have the desired effect. We need to test this and then we can include it in the next point release.