Notes on what need to be upgraded in the next
	releases of RIVM

=====================================================================

1) Camera coalignment	V3.2		DONE BJL  Sept 17, 1998
					ABCOAL_3.2.PRO
					CALTRANS_3.2.pro

	There is a question of how well ABCOAL works.
The observer does repoint the data camera steering mirror every
morning, so a longterm database is not useful.  Perhaps
a special observation of the disk center granulation or of the limbs
would get this for the day.

2) Destretch / deblur	V3.2

	We should do the shifts accurately before doing the deblur.
We need a quantitative measure of how hard to try.

3) Messages     V3.2			DONE BJL  Sept 1998
					RIVM_V3.2.PRO

        Many of the procedures were written to be run interactively.
That is not reasonable when we need to do batch reductions.
A search for the MESSAGE procedure locates a number of stops in the
code.


4) Nomenclature        V3.2		DONE BJL  Sept 18, 1998
                                        RIVM_3.2.PRO

        The rivm_ file with the record of the reduction should have
the data file name, not the current date.

5) File formats        V3.2		DONE BJL  Sept 18, 1998
                                        RIVM_3.2.PRO

        The blur_ file should have only the final tile coefficients,
not the coarse ones, so it can be processed more easily.

6) Platform independence V3.2

	On PC platforms the raw files appear byte-swapped.  Many
parts of RIVM handle this automatically, using IVM_RD_HEAD and 
IVM_GT_DARK.  The flats, cals, and data need work.

=======================================================================

1) Velocities	V4.0
	
	We should work to get the vector velocity field from 
the Doppler and destretch data.  Line of sight velocities are important
for the magnetic field measurement.  Doppler velocities in the 
Q, U, V data are also interesting.

2) Magnetic field	V4.0

	The derivative method saturates in big spots.
The fitting program is sensitive to noise and may try too hard
on noisy data.

3) Time series	V4.0

	We need to design the code for handling whole days of data.
The cals should be done first as a block.  The grams can be sorted 
according to which cals they use.
When the etalon is adjusted, the cals (flats) change
and cannot be used on the immediately preceding grams, for example.

4) Cal processing	V4.0

	A better method for the flats is desirable and possible,
fitting for the line center and removing that part of the 
intensity gradient.

	The cals also need attention.  They have large gradients
over the field - why?

5) Computing model	V4.0

	The whole intermediate file structure is an artifact of the
memory limitations of the generation of processors.  That limitation
no longer exists and the code should be cleaned of all the ASSOC
statements.  Holding the arrays in core is fine - virtual memory
should handle the large arrays more efficiently.

6) Computing model, part 2	V4.0

	The basic problem is that we look at things from an atomic level -
each image treated in isolation.  We should think about the whole
gram, as a cube rather than a stack of separate images.
Why does the polarization bias appear, and why does it vary so
much?

=====================================================================

     Last modified: Wed Jan 20 15:47:08 HST 1999