Two important sections affecting the final work plan: Compulsory work and options. As the name imply, compulsory work is work that I have to do. Options are choices that I have to make.

Compulsory Works

Delivering BAMMfx-lite

The first order of 2006 is to complete BAMMfx-lite and deliver it to the user. BAMMfx-lite deliverables will be determined by BAMM development team.

Complete the publication of BAMMfx

This has been on-and-off for the past year or so and I really have to make the effort to write up a a publication of BAMMfx. My difficulty here is that I tend to think as a programmer while the targetted audience for the publication we have in mind are actually Neuroscientists. Thankfully, Dr Suckling is helpping me out here.

Move GenericFX/BrainFX/BAMMfx to a SVN repository

They had been archived as CVS repository. Upon completion of migration to Eclipse 3.1.1. A SVN repository to store them should be created in house. Standard SVN practice will be used, especially vendor branches for BrainFX and BAMMfx.

I decide to use SVN rather than CVS because I am more familiar with how to transfer data between two SVN repositories and not with CVS. I envisage that we will have two repositories: One that contains day-to-day update of the software and another only the release versions. The former will be hosted in house, the latter on sourceforge.net, when they begin to offer SVN repository.

Options Available

There is a need to prioritise the work here. Here are a few options available

Develop a new plug-in for BAMMfx to interact with WBIC and BCNC network directories structure

WBIC changed its directory structure to have separate places for user data, archived data and work area, BCNC's is also organized broadly on the same line.

Users are expected to do their work in the work area and transfer important data back to the archive. It is likely that storing data in the archived data area will be chargeable. In other words the onus on the end users to ensure only important data is properly archived. In reality, unless some form of mechanism is used, it is a heavy burden for users to have to manually select and transfer the appropriate data. Thus, there exists an opportunity to promote the use of BAMMfx by performing the transfer for the users.

The envisage scenario is a button which the user press to activate the transfer. When activated, it will transfer data from the work area to the archive area if there were any changes difference between the two. The crucial point here is that only preselected set data files are archived, the rest will be ignored. Ideally, it should perform version control as well.

This sounds like a job for SVN. In Eclipse Platform, I have a SVN interface that works. It is possible to adapt this to perform the stated service. SVN is preferred over CVS because SVN stores the difference between binary files (the predominent file type) while CVS will have to store the whole file again.

For the purpose of discussion this functionality will be known as the "archive" function.

Benefits

1. Promote the use of BAMMfx in WBIC/BCNC by reducing the overhead in management
2. Showing commitment to WBIC/BCNC and encourage the involvement and support of WBIC/BCNC personnals
3. Showcase BAMMfx's (hence GenericFX) adaptability to different situation.

Uncertainties

1. Is such a system beneficial? Or users will prefers to maintain exact copy between the archive and work area?

Enhance BAMMfx-lite to allow third party plug-ins. Allow Cinly Ooi to provide some common plug-ins independent of BAMM core development

The basic BAMMfx-lite structure assume that data is always in NifTI format and will provide a few ways of creating design matrices.

However, these may not fit the user needs completely. For example, they normally get their data in DICOM format and they have better ways to create design matrices.

For them, there may be expertise on site that can create new plug-ins to BAMMfx-lite to handle their specific needs. I believe we should provide this convenience.

Please note that I am not asking BAMM core development team to support additional facilities. I strongly believe that the decision that BAMM core development team should support the basic package as it is right now. Users will have to convert their data to suit the reference format used by BAMM before support is provided. For example, they must convert data from DICOM to NifTI first before we start talking about problems. However, I believe if thir party wants to provide BAMMfx-lite with ability to automatically convert from DICOM to NifTI, they should be able to do so.

I also believe that in the short run, providing UNC to Nifti, Analyze to Nifti converters are necessary. Therefore I propose that I host and maintain these converters independently from the core development team.

Another example is to allow creation of new buttons on the button panel of the Input Data Spreadsheet. This allows additional functions to be attached to the spreadsheet. One possible usage is the "archive" function above.

Benefits

1. Allow BAMMfx-lite to be customized by the users. Proper customization will encourage adoption by streamlining the user's workflow
2. Promote development of complementary technology (converters etc) around BAMMfx-lite.

Uncertainties

1. Need approval from BAMM core development team. If they say no, then this WILL be abandon.

Creating a Module Construction Interface

At present, a module is created by writing its XML description using a text editor. While this is adequate to create even the most complicated pipeline/modules, it is less than ideal because of the need to keep the XML text valid and the number of possible combinations available to create a module. A better way is to develop a module construction interface where developers create modules using a Graphical User Interface.

Benefits:

1. Creating modules become much easier and less error prone.
2. Make BrainFX more attractive to developers.

Uncertainties:

1. It might take some time to create such an interface as the pipeline interface is at present created for manipulation of pipelines, not module creation.

Create A Grid-based Engine

Create a Grid-based Engine to run batch job. It will be in a form that allows GenericFX to interface with existing Grid Engines such as the Sun Grid Engine. WBIC is using Sun Grid Engine to process data. Hence, hands-on expertise is available.

Benefits

1. Almost all other fMRI pipeline environment have support for grid engine. To provide one put us on par with them.
2. Support large processing work and better utilization of existing resources. At present, individual file server can become overworked while others remain idle. With grid computing, it is likely that our processing network will be more effective. I can work with the System Administrators to make the system fault tolerant. For example, in WBIC, some processors can be selectively shutdown when temperature increase. With Grid Computing, we might be able to migrate jobs from them to others before they shutdown.

Uncertainties

1. I have to do an audit to see whether using a Grid Engine will deliver better efficiency/performance, in other words, whether this make sense.

Final Words

Everything elsebeing equal, I will prefer to do the work in the following order:

1. Allow third party plugin to BAMMfx
2. "Archive" Function
3. Grid Engine
4. Module Creation Interface.