Testing for dax about dax HOT 6 CLOSED

On a smilar note can we add - - writeonly to dax launch? I really like it in dax_manager

Sent from my Verizon Wireless 4G LTE smartphone

-------- Original message --------
From: Benjamin Yvernault [email protected]
Date: 3/2/2016 9:12 AM (GMT-06:00)
To: VUIIS/dax [email protected]
Subject: [dax] Testing for dax (#53)

Hi,

We talked about this (Steve, Brian and I) and we agreed that we need to have something to test the processors/modules/settings/spiders etc...

This issue is just to remember that we need to work on that.

Two points:

1. We need to implement an options to limit the number of assessor when testing a processor on a new project/dataset, something like --limit 10 for processors where dax_build generates 10 assessors that will run and if we like the outputs, we can remove the limit and it will run on everything.

2. Create a way to test the code in different files (processors/modules/spiders/settings).

3. spiders: probably straightforward, add a local variable that will not run the finish() function or something like --skip_finish.

4. processors: probably something like an executable where you give a processor file and a project ID from XNAT. From there, it will run dax_build on a project but for just few sessions (2-5), run dax_launch and print the .pbs file to see that everything is fine.
   E.G: dax_test -p TEST --processor /Users/byvernault/Processor_GIF_Parcellation.py

5. modules run dax_build on a project ID from XNAT but for just few sessions (2-5)
   E.G: dax_test -p TEST --module /Users/byvernault/Module_dcm2nii.py

6. settings: display all informations from the settings that will be used by dax in a way that help the user to check that everything if fine.
   E.G: dax_test --settings /Users/byvernault/Settings_VUIIS.py

What do you think?

Cheers,

Ben

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/53.

from dax.

Good Idea. We write the pbs but skip the qsub.

Ben

On Mar 2, 2016, at 15:14, Stephen Damon [email protected] wrote:

On a smilar note can we add - - writeonly to dax launch? I really like it in dax_manager

Sent from my Verizon Wireless 4G LTE smartphone

-------- Original message --------
From: Benjamin Yvernault [email protected]
Date: 3/2/2016 9:12 AM (GMT-06:00)
To: VUIIS/dax [email protected]
Subject: [dax] Testing for dax (#53)

Hi,

We talked about this (Steve, Brian and I) and we agreed that we need to have something to test the processors/modules/settings/spiders etc...

This issue is just to remember that we need to work on that.

Two points:

1. We need to implement an options to limit the number of assessor when testing a processor on a new project/dataset, something like --limit 10 for processors where dax_build generates 10 assessors that will run and if we like the outputs, we can remove the limit and it will run on everything.

2. Create a way to test the code in different files (processors/modules/spiders/settings).

3. spiders: probably straightforward, add a local variable that will not run the finish() function or something like --skip_finish.

4. processors: probably something like an executable where you give a processor file and a project ID from XNAT. From there, it will run dax_build on a project but for just few sessions (2-5), run dax_launch and print the .pbs file to see that everything is fine.
   E.G: dax_test -p TEST --processor /Users/byvernault/Processor_GIF_Parcellation.py

5. modules run dax_build on a project ID from XNAT but for just few sessions (2-5)
   E.G: dax_test -p TEST --module /Users/byvernault/Module_dcm2nii.py

6. settings: display all informations from the settings that will be used by dax in a way that help the user to check that everything if fine.
   E.G: dax_test --settings /Users/byvernault/Settings_VUIIS.py

What do you think?

Cheers,

Ben

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/53.
—
Reply to this email directly or view it on GitHub.

from dax.

Just to clarify something, this will once again involve making a change to
EVERY spider, right? I'd just like to point this out as another opportunity
to say that we should really consider a more generic spider that has these
functions like --skip-finish built in as an option? I'd just like to point
out that my spider class has this function already built in.

On Wed, Mar 2, 2016 at 7:16 AM Benjamin Yvernault [email protected]
wrote:

Good Idea. We write the pbs but skip the qsub.

Ben

On Mar 2, 2016, at 15:14, Stephen Damon [email protected]
wrote:

On a smilar note can we add - - writeonly to dax launch? I really like
it in dax_manager

Sent from my Verizon Wireless 4G LTE smartphone

-------- Original message --------
From: Benjamin Yvernault [email protected]
Date: 3/2/2016 9:12 AM (GMT-06:00)
To: VUIIS/dax [email protected]
Subject: [dax] Testing for dax (#53)

Hi,

We talked about this (Steve, Brian and I) and we agreed that we need to
have something to test the processors/modules/settings/spiders etc...

This issue is just to remember that we need to work on that.

Two points:

1. We need to implement an options to limit the number of assessor when
   testing a processor on a new project/dataset, something like --limit 10 for
   processors where dax_build generates 10 assessors that will run and if we
   like the outputs, we can remove the limit and it will run on everything.

2. Create a way to test the code in different files
   (processors/modules/spiders/settings).

3. spiders: probably straightforward, add a local variable that will not
   run the finish() function or something like --skip_finish.

4. processors: probably something like an executable where you give a
   processor file and a project ID from XNAT. From there, it will run
   dax_build on a project but for just few sessions (2-5), run dax_launch and
   print the .pbs file to see that everything is fine.
   E.G: dax_test -p TEST --processor
   /Users/byvernault/Processor_GIF_Parcellation.py

5. modules run dax_build on a project ID from XNAT but for just few
   sessions (2-5)
   E.G: dax_test -p TEST --module /Users/byvernault/Module_dcm2nii.py

6. settings: display all informations from the settings that will be
   used by dax in a way that help the user to check that everything if fine.
   E.G: dax_test --settings /Users/byvernault/Settings_VUIIS.py

What do you think?

Cheers,

Ben

—
Reply to this email directly or view it on GitHub<
https://github.com/VUIIS/dax/issues/53>.
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#53 (comment).

from dax.

There is a spider class build in dax now (spiders.py).

So for the spiders using the class, it wouldn't need any changes but it's
true that most spiders from VUIIS aren't using those classes so it might
not be added to the spiders. If it uses the spider class, it will just be
an options available for the user. If it's an old spider, we don't need to
add it for now since they have been tested. It will be available for the
new one.

On Wed, Mar 2, 2016 at 3:20 PM, aplassard [email protected] wrote:

Just to clarify something, this will once again involve making a change to
EVERY spider, right? I'd just like to point this out as another opportunity
to say that we should really consider a more generic spider that has these
functions like --skip-finish built in as an option? I'd just like to point
out that my spider class has this function already built in.

On Wed, Mar 2, 2016 at 7:16 AM Benjamin Yvernault <
[email protected]>
wrote:

Good Idea. We write the pbs but skip the qsub.

Ben

On Mar 2, 2016, at 15:14, Stephen Damon [email protected]
wrote:

On a smilar note can we add - - writeonly to dax launch? I really like
it in dax_manager

Sent from my Verizon Wireless 4G LTE smartphone

-------- Original message --------
From: Benjamin Yvernault [email protected]
Date: 3/2/2016 9:12 AM (GMT-06:00)
To: VUIIS/dax [email protected]
Subject: [dax] Testing for dax (#53)

Hi,

We talked about this (Steve, Brian and I) and we agreed that we need to
have something to test the processors/modules/settings/spiders etc...

This issue is just to remember that we need to work on that.

Two points:

1. We need to implement an options to limit the number of assessor when
   testing a processor on a new project/dataset, something like --limit 10
   for
   processors where dax_build generates 10 assessors that will run and if we
   like the outputs, we can remove the limit and it will run on everything.

2. Create a way to test the code in different files
   (processors/modules/spiders/settings).

3. spiders: probably straightforward, add a local variable that will
   not
   run the finish() function or something like --skip_finish.

4. processors: probably something like an executable where you give a
   processor file and a project ID from XNAT. From there, it will run
   dax_build on a project but for just few sessions (2-5), run dax_launch
   and
   print the .pbs file to see that everything is fine.
   E.G: dax_test -p TEST --processor
   /Users/byvernault/Processor_GIF_Parcellation.py

5. modules run dax_build on a project ID from XNAT but for just few
   sessions (2-5)
   E.G: dax_test -p TEST --module /Users/byvernault/Module_dcm2nii.py

6. settings: display all informations from the settings that will be
   used by dax in a way that help the user to check that everything if fine.
   E.G: dax_test --settings /Users/byvernault/Settings_VUIIS.py

What do you think?

Cheers,

Ben

—
Reply to this email directly or view it on GitHub<
https://github.com/VUIIS/dax/issues/53>.
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#53 (comment).

—
Reply to this email directly or view it on GitHub
#53 (comment).

from dax.

I'm going to start testing this now. One thing I noticed looking at the code is that I think we should include a lot more prints since this will be used for testing. That way it will be easier to trace what is going on. Also a couple methods used here are already done in XnatUtils. I'll make some commits to address these concerns. Thanks for getting this going, though. This has been a longstanding issue that needed to be closed IMO.

from dax.

I'm good with this

from dax.