Check the Google module allocation spreadsheet, and if the Master schedule to see what size modules need to be loaded for the next couple of experiments. The Google spreadsheet is updated daily by a script, if the experiment is not listed it is because the schedule isn't yet ready, so look at a previous experiment for an idea of the data space required.

Make a note of the modules allocated to each experiment on the Google Spreadsheet as hbobserver. The staff at Ke and Yg check the spreadsheet and will also list the modules they have allocated.

On a separate tab on the Google sheet is an inventory list which should give some indication of the module stock at each station.

R4's at Ke and Yg must go on a module by themselves, as they get shipped directly to Washington. R1's should also go on a module alone.

By keeping the rapid R1 and R4's separate we maintain a population of high turnover modules that can be deleted and reused within a period of a few weeks.

At Hobart the next number R1 experiment, usually on a Tuesday can go on the same module as the preceding R4 experiment recorded on Friday/Saturday e.g. r4783hb is recorded, followed by R1784hb on the same module.

It can be useful to make a note on the Handover Notes page for the experiment of which module to use, so the observer is reminded. You may wish to send the starting observer an email also.

Place a red sticker on the module when it has been recorded to, and label the experiment name clearly.

Modules from Yg and Ke are posted to Hobart, except for R4 experiments, shipped directly to Washington.

When Yg Ke modules first arrive in Hobart they are to be loaded into a spare Mark5, to be transferred from module disk-pack to a local storage location. A Hb Ho experiment can be transferred to local storage immediately post experiment especially rapid R1 and R4. The Local Transfers page shows which experiments have been, or are currently uploading from module to local storage.

The data is then uploaded from the local storage to Bonn or Washington. See the Transfers page for information on the details of this process.

Only when an experiment has been correlated (search IVS email, or use the useful scripts below) can the data be deleted from module. With Dimino running, ensure that the module only contains the correlated experiment data. The labels may be incomplete and not always to be trusted. On the Mark5 command line use

 DirList | less 

to scroll through the list of scans on the disk to check before you delete. When you are sure, double check yoiu have the correct module and start tstDIMino at the command line, turn off the data safety with

 protect=off 

and then

 reset=erase 

to clear the data from the module. Check free space and vsn OK with

 rtime?  

and

 vsn?  

. Take the red sticker and experiment label off the module, ready for re-use.

Some utility scripts are available on ops1hb. list_correlation.py scans the master schedules pages for the last few years and looks for a correlation date on experiments involving our stations. It writes a list of correlated experiments to correlated.txt on ops1hb. If an experiment appears in this list e.g.

 cat correlated.txt | grep -i r1758 

then the data can be erased from the module.

Also on ops1hb is data_summary.py which daily reads the master schedule, finds upcoming scheduled experiments with summary files, finds the data size for each station and writes this information to the Google module allocation spreadsheet.