Re: [Brahms-dev-l] makefile installation

Hi all, 

On Mon, 2004-09-13 at 19:55 -0400, flemming videbaek wrote:
> I just want to make you aware of a potential problem with brat and the
> installation makefiles.
> The mult calibrations are basically asciit text files. A a few times
> the format has been changed, and files deleted
> from the CVS repositiry. This will of course also ensure that files
> are deleted from your 'local' brat directory but NOT
> from the install directory. A specific case
> is /opt/brahms/new/share/brat/mult where old incompatible files were
> kept.
> Thus the reason for some reconstruction mishaps. Morale, deletion of
> files in CVS can be a problem if they are not
> code/library files. This hole issue could of course have been avoided
> had the mult calib been in the DB and not in files.

It could also be prevented by doing 

	make uninstall 

_before_ updating your BRAT working directory.  

However, I agree that the SMA and TMA calibrations should go into the
MySQL database ASAP.   The main difficulty is that much of the meaning
of the calibration numbers is carried by the code - that is, certain
conditions are hard-coded into the various modules, which makes it a
non-trivial task to reformat the data to something that fits in the
database paradigm.  

This is not a weakness in the database paradigm as such, but rather a
challenge to it.   

Although the task of importing the ASCII files to the database is non-
trivial, it is definitely doable by someone who has an intimate
understanding of how the calibrations was done, and what they mean. 

On a related issue: 

There's been some concern whether BRAHMS would over populate the MySQL
server.  Please note, that tables can get pretty big in MySQL, and the
2GB file limit in Linux 2.2 shouldn't be a problem, see [1].

Also, some have voiced concerns over the calibration revision selection,
in situations like 


	|-------- 0: Bad Calibration --------------------------------|    

	|- 1: Good Calibration --|        |- 2: Good Calibration ----|

	                           ^
                                   |
                           Selected start of period


The concern is, that you may end up with calibration 0, even though this
is a bad calibration, and you'd like to get calibration 1.  Now, the
quality of a calibration is not something the database software in it
selve can deduce - that has to come from human input, one way or the
other.  

Note, that the situation above could very well make sense.  Suppose we
do calibration 0, which is good for an extended time.  Now, later down
the line, you figure out, that in the period covered by 1, something was
a miss, so you go back and redo the calibration for only that period,
hence overridding the otherwise good calibration 0.  That is a perfectly
reasonable scenario.  

Now, to come back to the case where 0 is indeed bad.   First off, it
shouldn't have been committed with such a long duration in the first
place.   A duration of one or two runs should generally be used.   

If, however, contrary to what has been said numerous times that a long
bad calibration was added to the database, there's is no need to delete
that calibration.   There's two options to remedy the situation: 

      * Fill in a copy of calibration 1 to cover the missing piece, so
        you'd end up with 



	|-------- 0: Bad Calibration --------------------------------|    

	|- 1: Good Calibration --|        |- 2: Good Calibration ----|
				 |- copy1 |

      * Change the revisionType of calibration 0 to something that's
        non-default, for example `bad'.  Normally, the DB software only
        looks for the revisions with revisionType == 0 (or what ever the
        default one is), so reclassifying it as something else would
        mean that the DB software would not automatically pick up that
        revision.  

I would prefer the later, even if it requires some hand tuning. 

Yours,

-- 
 ___  |  Christian Holm Christensen 
  |_| |  -------------------------------------------------------------
    | |  Address: Sankt Hansgade 23, 1. th.  Phone:  (+45) 35 35 96 91
     _|           DK-2200 Copenhagen N       Cell:   (+45) 24 61 85 91
    _|            Denmark                    Office: (+45) 353  25 404
 ____|   Email:   cholm@nbi.dk               Web:    www.nbi.dk/~cholm
 | |

[1] http://dev.mysql.com/doc/mysql/en/Table_size.html#IDX40


_______________________________________________
Brahms-dev-l mailing list
Brahms-dev-l@lists.bnl.gov
http://lists.bnl.gov/mailman/listinfo/brahms-dev-l