This is a blog of the steps taken to restore ThreePi.V1 merging

Problem: ThreePi.283 refused to merge into The Big DB.

Symptoms: Looking into the log files, we see the following:

Starting script /home/panstarrs/ipp/psconfig//ipp-20101206.lin64/bin/minidvodb_merge.pl on ipp004

Can't find dvodb identifier /data/ipp004.0/gpc1/catdirs/ThreePi.V1 in DVO.CATDIR in site configuration, assuming filename

/home/panstarrs/ipp/psconfig/ipp-20101206.lin64/bin/addstar -resort -D CAMERA GPC1 -D CATDIR /data/ipp004.0/gpc1/catdirs/ThreePi.V1.Mini/ThreePi.283
addstar -resort time 458.000010251999
/home/panstarrs/ipp/psconfig/ipp-20101206.lin64/bin/relphot -averages -update -D CAMERA gpc1 -D CATDIR /data/ipp004.0/gpc1/catdirs/ThreePi.V1.Mini/ThreePi.283
update minidvodbProcessed set merge_order = 137 where minidvodb_id = 283137
*** stderr ***
Unable to find /data/ipp004.0/gpc1/catdirs/ThreePi.V1 within metadata.
 at /home/panstarrs/ipp/psconfig//ipp-20101206.lin64/bin/minidvodb_merge.pl line 80
Unable to perform relphot: 4 /data/ipp004.0/gpc1/catdirs/ThreePi.V1

programming error for: minidvodb_merge.pl --camera GPC1 --mergedvodb /data/ipp004.0/gpc1/catdirs/ThreePi.V1 --minidvodb /data/ipp004.0/gpc1/catdirs/ThreePi.V1.Mini/ThreePi.283 --minidvodb_group ThreePi --minidvodb_id 283 --dbname gpc1
job exit status: 4
job host: localhost
job dtime: 684.53569
job exit date: Wed Dec  8 18:07:47 2010

timeout for: addtool -checkminidvodbrunaddrun -state waiting -minidvodb_group ThreePi -dbname gpc1 -limit 32
job exit status: 0
job host: localhost
job dtime: 1.000142
job exit date: Thu Dec  9 08:34:25 2010

rerunning relphot by hand causes a segfault on ThreePi.283.

Is it relphot or is it ThreePi.283?

Running relphot on ThreePi.284 finishes with no errors.

I'm going to try to recreate ThreePi.283:

Step 1:

remove minidvodbProcessed for minidvodb_id 283

addtool -revertminidvodbprocessed -minidvodb_id 283 -dbname gpc1

update minidvodbRun (283) to state of 'active';

addtool -updateminidvodbrun -minidvodb_id 283 -set_state 'active' -dbname gpc1

update minidvodbRun (285) to state of 'to_be_merged';

addtool -updateminidvodbrun -minidvodb_id 285 -set_state 'to_be_merged' -dbname gpc1

Ok, now to set up the addRuns (this is terrifying):

update addRun join addProcessedExp using (add_id) set fault = '100' where minidvodb_name = 'ThreePi.283';
update addRun join addProcessedExp using (add_id) set state = 'new' where minidvodb_name = 'ThreePi.283';
delete from addProcessedExp where fault = 100 limit 326;

start up addstar: turn off minidvodb.merge minidvodb.merge.off add.minidvodb ThreePi THREEPI.V1.MINI THREEPI.V1 1 GPC1 add.label ThreePi

aaaand run! (after debugging errors in addstar.pro and addstar.pl)

Ok! ThreePi.283 is done. Copying the new version over (to ThreePi.283.redo), and attempting relphot. addstar is stopped.

addstar -resort -D CAMERA GPC1 -D CATDIR /data/ipp004.0/gpc1/catdirs/ThreePi.V1.Mini/ThreePi.283.redo/ThreePi.283

It works! set by hand state to 'to_be_merged' and turn on merging.

addtool -updateminidvodbrun -minidvodb_id 283 -set_state 'to_be_merged' -dbname gpc1

Then turn on survey task, once there is a new db to copy into. If the survey is turned on before there is a db, this will cause problems. Oh, except now I can't turn on the survey task, because there is no diskspace.

ThreePi Minidvodb Copy! Remember to remove the old 283, and set it so that it will redownload it (or just rsync it over). But right now it is turned off.