*** For details on how to be removed from this list visit the ***
*** CCP4 home page http://www.ccp4.ac.uk ***
There is definitely a bug, which I will investigate. It's an unfortunate
interaction between reassigning batches to datasets and renumbering them,
so I think the work-around is to separate out these operations into
different runs of rebatch. The program will certainly cope with files with
multiple batches.
I don't quite see what you are trying to do, but if you split the jobs, eg
below I think it will work
Phil
rebatch hklin F5_2_sorted.mtz \
hklout temp.mtz <<+
batch 1 to 270 pname lm xname merge dname f05p
batch 1000 to 1270 pname lm xname merge dname f05r
+
rebatch hklin temp.mtz \
hklout F05-f05.mtz <<+
batch 1 to 90 add 2000
batch 181 to 270 add 3000
batch 1001 to 1090 add 4000
batch 1181 to 1270 add 5000
+
--On 12 June 2006 11:38:12 -0700 Jens T Kaiser <[EMAIL PROTECTED]> wrote:
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
