DEBUGS - #209

Two questions:

1. What is the significance of tagging a stream as "diagnostic"?

2. Your modification to aamod_secondlevel_model includes the first use of spm_print I've seen in the code. Should we start using this instead of saveas or print? What are the advantages?

Ad 1.: Diagnostic streams are not deleted by garbagecollection after execution, and therefore, they are available for report generation.

Ad 2.: I am not sure. I used spm_print, because I created image on the SPM Graphics, and thought it would be saved more 'properly' with using spm_print.

HI Tibor,

So I've been testing your PR -- having some trouble with domain wildcarding. (I realize this is not new to this PR, but I forgot that it has never worked for us).

For example, the current version of aamod_norm_write has a domain='*' which I have to change back to domain='session' to get the module to run.

Is there something we need to set up or change for this?

Cheers,
Mike

PS: Everything else with the PR seems to be working fine...

What is not working? Does it throw you an error? In general, '*' domain is substituted based on the domain of the input or the module providing input.

With domain='*', the scheduler is trying to run aamod_norm_write as 'subject'. Here is currenttask passed in:

`K>> aap.tasklist.currenttask

ans =

struct with fields:

      epiprefix: []
extraparameters: [1×1 struct]
       settings: [1×1 struct]
   inputstreams: [1×1 struct]
  outputstreams: [1×1 struct]
           name: 'aamod_norm_write_00001'
          index: 1
   modulenumber: 8
         domain: 'subject'
       modality: 'MRI'

aamod_norm_write then crashes on line 87 by trying to load stream_epi_outputfrom_aamod_norm_write_00001.txt

That seems wrong. Why is it trying to load an outputfrom stream?

What is the module right before aamod_norm_write? I suspect it is aamod_realign, which is on subject level; which makes aamod_norm_write also subject level. It try to load the epi stream output from the module, because it cannot find the input into it.

I am not sure about your pipeline, but aamod_norm_write is generally preceded by aamod_coreg_extended_2epi (see example), which is on session level.

You are correct. Here is the complete pipeline up to the crash:

aamod_structuralfromnifti
aamod_reorienttomiddle_structural
aamod_epifromnifti</module
aamod_reorienttomiddle_epi
aamod_realign
aamod_coreg_extended
aamod_segment8_multichan
aamod_norm_write

Is this not a valid pipeline? It worked before aamod_norm_write was modified to use domain wildcarding.

The recommended version would be:

aamod_structuralfromnifti
aamod_reorienttomiddle_structural
aamod_epifromnifti
aamod_reorienttomiddle_epi
aamod_realign
aamod_coreg_extended_1
aamod_segment8_multichan
aamod_coreg_extended_2epi
aamod_norm_write

Couldn't we simply add a session domain header alias for aamod_norm_write (call it something like "aamod_norm_write_epi.xml")?

I'm still trying to understand whether domain wildcarding was added for convenience or added to fix a problem.

Yes, we can.

However, domain wildcarding was added to avoid aliases.

Another fix for your issue can be to write a (generic) function to specify/change domain for modules.

However, domain wildcarding was added to avoid aliases.

That's a reasonable design philosophy.

A competing philosophy is to ask: "what makes aa easier to use?" Clearly-named alias headers are self-documenting and help a user -- particularly a new user -- have confidence in designing a proper pipeline. When the behavior of a module is determined by the other modules that appear in a pipeline (or ordering thereof), this is a potential source of confusion. A confused user is an angry user.

M

PS: I'll reiterate this issue is not related to this PR, which as I mentioned passed my testing* aside from the wildcarding issue. So this PR can be merged as far as I am concerned (* the full aa_test suite still doesn't run under OS X, which we have a student looking into, who is currently out for winter break).

I think this discussion would be more suitable for a separate thread, then.

The aim to "make aa easier to use" was mine, too. And there was an agenda to reduce redundancy across modules.

I agree that some of my simplifying changes may not be intuitive for other but me (because I have deveopped them independently); however, the were introduced according to the 'best practice' we had agreed upon.

Finished testing this PR at WUSTL and everything ran as expected. Looks like it's good to merge.