Laboratory Management Guide (Draft)

Under construction.

Get as multiple pages

Arcade

The convension is that each database holds information for a single academic level from a single academic year.

The convension is also that a database has a three part name, with the parts separated by a hyphen. The first component is a two digit representation of the starting calendar year, the second component is a two digit representation of the ending calendar year and the third component a single digit representing the academic level; for example, the second year database for the 2009/2010 acedemic year would be named 09-10-2.

Convensions (Draft)

Database names

The convention is that course unit names use the Universty's short name for the course unit but without the COMP prefix. Where a module is a course unit component, a single character suffix is added to indicate the name of the component. The currently used suffixes are:

L

Laboratory

C

Coursework

S

Lecture attendance

T

In-course test

X

Examination

Student Database Copy (Draft)

/home/arcade/COPY-DATABASES

Recorded Marks (Draft)

Student marks for a piece of work may be followed by a number of different letter suffixes. The meaning of these are:

Estimated Grade (E)

The piece of work is expected but has not yet been submitted/given in. The estimate is 70% for early exercises or based on the students performance in previous exercises.

Demonstration Reqired (D)

The student has submitted some work via the submit command but has not yet taken the action needed to get it marked.

Marking Required (H)

The student has handed in a piece of work. However, this piece of work has not yet been marked. No action is reqired by the student.

Creating a new database

To create a new database move to the root directory that contains all databases (e.g. /home/arcade/DATABASES/. Use the command:

Answer the qustions generated as follows:

• Database name: xx-yy-l
• Size registration numbers: 7
• Name list format: Manchester
• Default study year: l
• Default owner: admin2
• Default student domain: can leave blank
• Name allocation algorithm: 2
• Final fixed character: d
• Start day date: d
• Start month: d
• Start year: dddd
• Module name: blank
• Import name list: boolean (for 2nd and 3rd year databases, probably yes)
• If yes to previous, previous database: database name

The start date needs to be a Saturday.

ss optionally

ss

Edit Privileges (Draft)

Having created the database, there are some additional configuration that need to be completed. To do these, move into the database directory (which has the database name). The first change is to setup the users who have various roles. The command do do this is:

This opens the priviledges file in your default editor. Change the LabManager entry to the user name of the laboratory manager. If there is more than one manager, these lines can be duplicated and edited for each of the manager user names. Change the DataEntry to the user name of the person who does data entry; it is likely that this line needs duplicating and setting to donaldg, wardr and jeand. The YearTutor and HeadOfUg (graham)will also need to be edited

Arcade Configuration (Draft)

Student Information

Information about the students present in the database and their course unit choices (referred to as name list information) needs to be setup and maintained. The process to do this transforms information from Campus Solutions and combines it with locally added information.

Initial Setup

Creating the initial version of student information is a two stage process. The first stage uses the script:

db/JTL/create-initial-name-list

This transforms information from Campus Solutions into a form that can be used by the Arcade system. To generate the name list used within Arcade use the command:

name-list-update

Local Information (Draft)

To customise the process ... TBC

Automated(ish) Maintenance

As with the initial setup of student information, the automated maintenance of information is a two stage process. The first stage uses the script:

db/JTL/get-students-from-compost

Again, this only transforms the Campus Solutions information into a form that can be used by the Arcade system. To generate the name list used within Arcade use the command:

name-list-update

When run, this command displays the differences between the current name list and the updated one and there is then a chance up confirm (copy) or abort the update.

Local Information (Draft)

The student information obtained from Campus Solutions can be modified by altering the db/JTL/get-students-from-compost script. Typical changes are:

• deleting course units
• rwa students

Manual Name Maintenance (Draft)

To manually modify a name list entry. Copy current name list, make edit in copy then update active list by name-list-edit -i edited-file Delete edited file as subsequent automated updates will not be applied to it. This process is only appropriate for locally created information, e.g. username.

Data Location (Draft)

Student information is stored in the directory db/STUDENT_DATABASE. The main files are:

students

Transformed information from Campus Solutions combined with local information that gives the name, year and degree programme for each registration id.

courses

Campus Solutions information transformed and combined with local information that gives the level and short code of course units taken by a registation id; the format is one unit per line, so the same registation id may occur on multiple lines.

tutor-list

c.

name-list

Information about a student used within Arcade. This includes their Arcade id, name, registation id, degree programme and registered course units.

The name-list is created/updated using the command name-list-update which uses information from the students and courses files. Previous versions of these files may be present with a date stamp appended to the name.

There are also some supplementary files that may appear in this directory, these include

differences

The results of a comparison between the current name-list and that which results from an update using the current information in students and courses files.

problems

Problems detected whist running name-list-update.

Controlling Mark Predictions (Draft)

Arcade predicts values for marks that are currently unknown. These marks occur when a student has not submitted work, a student has submitted work but not yet had it marked and when a tutor has not yet returned a mark. By using various flag files, it is possible to control how Arcade calculates the preditions for these unknown marks.

Mark Predictions for Unsubmitted Work

Normally Arcade will predict a non-zero mark for work that a student has not yet submitted. This mark will have an Estimated (E) flag appended. Initially a prediction of 70% is used. Once a student has submitted some work for a course unit, the average of the previous work submitted to the course unit is used.

This behaviour can be altered by creating the flag file db/CONFIGURATION/ZERO-PREDICTION. When this file is present, Arcade will predict a mark of zero for any piece of work that the student has not submitted. This file also effects unknown tutor marks, see below.

Mark Predictions for Submitted but Unmarked Work

When a student submits a piece of work that has not yet been marked, Arcade will normally predict a non-zero mark for the piece of work. Initially this prediction is 70%; once the student has some marks for the course unit, the prediction will be the average of the existing marks for the course unit.

For exercises where the student electronically submits their work, the predicted mark will have either a Demonstration Required (D) or Offline Marking Required (H) flag appended. Arcade assumes that any exercise configured with a CS attribute is electronically submitted. The type of flag appended is controlled for a course unit or an individual exercise by flag file(s). If the file ~/ARCHIVE/year/courseUnit/DEMO-WANTED exists the Demonstration Required flag is used for all exercises of the course unit; whereas, the existance of the file ~/ARCHIVE/year/courseUnit/exercise/DEMO-WANTED will set the Demonstration Required flag only for a single exercise.

When face-to-face marking is used (Demonstration Required) and it is felt that students have had sufficient time to get their work marked, it is possible change predicted marks to zero. As with the demonstration required configuration, this can be done for individual exercises or all of the exercises of a course unit. The existance of the file ~/ARCHIVE/year/courseUnit/DEMO-MISSED will make the predicted mark for all unmarked work for all exercises of the course unit zero; whereas, the existance of the file ~/ARCHIVE/year/courseUnit/exercise/DEMO-MISSED will zero the predicted mark only for a single exercise. Besides setting the predicted mark to zero, this configuration also changes the flag appended to the mark from a Demonstration Required one to a Demonstration Missed (d) one. Although the demonstration missed flag is set, it does not prevent the student from getting their work marked.

Mark Predictions for Work Submitted Late (Draft)

The mark for any work submitted late without an excuse will have a Late (L) flag appended. The Late flag will have its standard effect, see ?. For exercises where the student submits their work electronically and the work has not yet been marked, D or H (see ?).

It is also possible to configure a date after which it is considered too late for any work submitted to be marked. This is done using the configuration file ~/ARCHIVE/year/ARCHIVE-CLOSED.The contents of this file give the cut off date after which submitted work will not be marked. Once this date is reached, any work submitted will automatically have the Demonstration Missed (d) flag appended and.

Mark Predictions for Unonown Tutor Marks (Draft)

Background Processes (Draft)

Setup/Change

To setup/change the background processs that should be run use the command:

This opens the control file for the current user and database in an editor. The first time that a user runs the command in a database, a control file with a default set of processes to be run will be created. A comment at the head of the file expalins the format of the file.

Creating the control file only defines what processes should be run, it does not cause them to the run. To actually run the configured processes, use the command:

Although this command can be run manually, it is normally run once a day as a cron job. As current database name is a parameter to the command, the crontab entry requires editing every year.

Typical Processes (Draft)

The processes that are typically run are:

Attendance Data to Admin

Command: attendance

Attendance information is sent to owners of the database. Only information that has not been previously sent is forwarded. It is also only sent for course unit groups that have no blank data in the attendance field.

Activity Data

Command: (progress; due) | mail user

ss

Student Registration Changes

Command: mail-name-list | fgrep -v "same as last time"

sss

Student Timetable Changes

Command: mail-sessions-table | fgrep -v "same as last time"

sssss

Missing Data

Command: JTL/send-blank

Data Location

Information on the jobs to be run is stored in the file DB/CONFIGURATION/remote-jobs-user. A comment at the head of the file describes the format used in the file.

Arcade Data Entry (Draft)

Manual

To indicate that a student has done a piece of work (but at on unknown time), an N can be entered into the date field; to indicate that a student has not done a piece of work, an X can be entered into the date field.

The standard excuse (E) for a piece of work has an expiry date. If the student completes after this date, the work will be marked late. There is also a non-expiring, special, excuse (S) that can be set by those with sufficient privilege. To enter it go to the expiring excuse that is to be changed and type Control-S (^S). Two other values possible values for date fields are an expiring excuse that has been manually expired (e) and non-expiring excuse that has been manually expired (s).

In addition to marks, possible indicators that can be enetered into the marks field are average of other work (A), demonstration still required (D) and demonstation missed (d). When wishing to awarding an average mark to a student, it may be necessary to avoid a late flag being attached to the piece of work; to do this an N in the date field and excuses may be required.

In the case of suspected collusion, a mark can have a C appended; this causes the mark to be treated as zero. If the outcome of any investigation into collusion is that a mark should be reduced, then the reduced mark can be entered but should have c appended to indicate that the original mark has been reduced. For marks automatically transferred from an external system, Control-T (^T) can be used to cycle though the sequence none, collusion (C) and demo missed (d). Whenever collusion is suspected, details of evidence (Q) and penalty (A) should be put into the Q/A fields (accessible via Control-C); for example:

Q: Copied/Collaborated:-todorov9-angelok9
A: Zeroed

Electronic transfer from Assessment 21 (Draft)

By convension, the raw csv files downloaded from Assessment 21, by those responsible for a course unit, are placed into the directory DATA/ELECTRONIC-MARKS. The filename should have the structure: moduleName-sessionName.abc.csv.

Before importing the file make sure that it is a Unix style text file; if necessary run dos2unix on it. The import is performed using command:

../LOCAL-EXECUTABLES/save-data-from-abc filename

Where the filename can be just the same of the file or the relative path to the file.

Arcade Data Storage (Draft)

Plagiarism Reports (Draft)

Use the command

../LOCAL-EXECUTABLES/plagiarism-report

Campus Solutions mark transfer

Before starting spreadsheets for the individual components must be obtained and saved in the db/CAMPUS-SOLUTIONS directory. Currently, Jennie obtains these and emails them to those involved in running Arcade.

The generation process will produce the populated spreadsheets in the db/CAMPUS-SOLUTIONS/NEW directory.

The process of transferring marks happens on a copy of the information stored in the Arcade.

./make-final-marks

This copy is created in the directory ./FINAL-MARKS. Each time the final marks are made, a new copy is created in this directory. By convension, only copies that have been used to send marks to SSO for entry into Campus Solutions are kept.

It is possible to compare two versions of the final marks using

./final-diff

Generating Spreadsheets for All Course Unit Elements

The spreadsheets for all courses can be generated using the command

../LOCAL-EXECUTABLES/create-composte-sheets

Note, this command assumes that any name alignment required has been setup in the AFC/latest-final-marks file as described in the section on individual course units.

Generating Spreadsheet for Individual Course Unit Element

In the following, element is assumed to be all or a major part of a course unit (e.g. the laboratory, coursework or examination component); it does not equate to an individual activity.

Can check that have all that expect for an element using:

./outstanding element

For some course units, this will show outstanding for students who have never attempted an exercise. These can be detected by x in the completed by deadline field, E-xxx in the extension field. Can remove them from outstanding list by putting X in date field.

The names used in Campus Solutions and those used in Arcade can be aligned by inserting entries into the AFC/latest-final-marks file. Once the name configuration has been completed, it is possible to populate the spreadsheets using:

./AFC/latest-final-marks -list | ../LOCAL-EXECUTABLES/load-marks-into-Campus-Solutions-XLS.pl -f CAMPUS-SOLUTIONS/element -a element

Note by this stage, the element has the COMP prefix.

Messages about no Arcade marks for a student often mean that they have left after the spreadsheets were generated. This can be confirmed by asking someone with Campus Solutions access to check.

Spreadsheet Transfer

The generated spreadsheets need to be sent to Jennie. All new spreadsheets can be sent using the command:

../LOCAL-EXECUTABLES/send-composte-sheets

As well as sending the spreadsheets to Jennie, this will also move them from the db/CAMPUS-SOLUTIONS/NEW directory to the db/CAMPUS-SOLUTIONS/SENT directory.

If a spresdsheet has already been sent, a message indicating this will be displayed followed by any differences between the new spreadsheet file and the one previousl sent. This means that in the summer, for first semester course units, it is necessary to (re)move the February versions before the updated ones can be sent. By convension, the db/CAMPUS-SOLUTIONS/SENT directory is renamed to db/CAMPUS-SOLUTIONS/SENT-FEBRUARY.

Checking Transferred Marks

A check for differences between the marks in Arcade and those send to Jennie can be performed using:

../LOCAL-EXECUTABLES/compare-latest-final-marks-with-sent-to-composte

Staff Information (Draft)

Resit Students (Draft)

Submit (Draft)

Getting marking tokens (Draft)

On a linux machine run the command:

This will prompt for the course details that it requires

To successfully run this program you must already be authorised as a responsible person for the course unit.

Manual generation (Draft)

Arcade Server/Client (Draft)

Access to records (Draft)

Client access to the Arcade records can be blocked by putting a username in the file /home/arcade/COPY-DATABASES/debtors. There are a variety of reasons why this may be necessary, they include being in debit to the University and not completing compulsory zero credit units (e.g. plagirism).

Client Authentication (Draft)

Archiving (Draft)

Emailing students with personalised messages (Draft)

./mail-report report-file

Where the report-file has a one line entry per student. The format is a space terminated username followed by information.

Getting a username list for a module (Draft)