Giter Club home page Giter Club logo

Comments (7)

chrisgorgo avatar chrisgorgo commented on June 11, 2024 1

I would suggest a different approach. After running the workflow that exits with errors

  • crawl the crashfile directory and identify all crashfiles belonging to each subject analyzed in this run (you might need additional daytime restrictions to avoid capturing crashfiles from historical runs)
  • append error information to corresponding subject specific HTML reports report

This way we will be able to capture all errors (not only those coming from Report Capable interfaces). It will also avoid having to deal with the problematic case of a failed node that populates error reportlet that should be send to a datasink (what @oesteban mentioned in #66 (comment)).

from fmriprep.

chrisgorgo avatar chrisgorgo commented on June 11, 2024 1

Actually, the problem of confusing crash files from different subjects and historical runs could be solved, by using a unique temporary crashfile directory for every subject/run.

from fmriprep.

oesteban avatar oesteban commented on June 11, 2024

I think this is currently well covered with the new reports.

from fmriprep.

oesteban avatar oesteban commented on June 11, 2024

Yep, the problem is that the out_report output trait is never populated: the node fails and, even though a reportlet is generated, the nipype engine will not consider it.

from fmriprep.

chrisgorgo avatar chrisgorgo commented on June 11, 2024

The reports should include the content of all generated crashfiles. Here's the code for reading crashfiles: https://github.com/nipy/nipype/blob/master/nipype/scripts/crash_files.py (could be easily adapted with mocking print).

We briefly discussed adding optional plain text crashfiles to nipype (see nipy/nipype#1184), but I doubt this can happen before the next nipype release (rc1 was just released).

from fmriprep.

rwblair avatar rwblair commented on June 11, 2024

In niworkflows for the definition of ReportCapableInterface there is check to see if the interface ran successfully and if not to call _generate_error_report: https://github.com/poldracklab/niworkflows/blob/master/niworkflows/common/report.py#L59

I'm looking into writing the crash information out to the reportlet here. That being said in the reports that we have on afterhours I'm not seeing any instances of the html from _generate_error_report.

from fmriprep.

chrisgorgo avatar chrisgorgo commented on June 11, 2024

Closed by #298

from fmriprep.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.