***  For details on how to be removed from this list visit the  ***
***          CCP4 home page http://www.ccp4.ac.uk         ***




Yes this is a bug

There is a fixed version at

ftp://ftp.mrc-lmb.cam.ac.uk/pub/pre/rebatch.f

also sent to ccp4

Phil



Jens T Kaiser writes:
 > 
 > Hi together,
 > After my last problem with mosflm dataset assignments (which seems to be 
 > connected to a problem in the mtz library and as far as I know there is 
 > no solution, yet.), I have another problem with dataset names/numbers.
 > I try to rename and rebatch several datasets. As far as I can tell, the 
 > rebatching works, but the dataset information gets corrupted. I.e. all 
 > datasets originating from one file are assigned to only one dataset. 
 > This also means that individual cell and wavelength information gets 
 > lost. Apparently, all batches expected are in the file, I just get 
 > uncomfortable as it may also be possible that the batch numbers get 
 > mangled (assigned to the wrong images).
 > A workaround I can think of would be to write individual files.
 > My question (in different wordings): Is this an evil bug (that's what I 
 > am thinking)? Is rebatch intended to be run only on mtz-files of single 
 > datasets (i.e. directly out of mosflm)? I'm using previously sorted 
 > mtz-files (containing 1 to 3 datasets) to try some different ways of 
 > processing and found it more convenient to start the rebatching from 
 > single files.
 > I paste the comfile and the beginning of the mtzdump below. The dump is 
 > from a file containing all intermediate files sorted together, but I 
 > confirmed that the problem exists already in the intermediate files. 
 > It's not sortmtz that screws things up.
 > 
 > Thanks,
 > 
 > Jens
 > 

Reply via email to