Hall D Meeting Report, July 24, 2017

  • new release
    • build custom version of python
  • website re-design
  • preparation for next simulation launch
  • computing round table committee
  • New work disk purchase: 44 TB, non-Lustre, ready by September




Talking with Sandy and Paul about More Cores for Hall D

  • new multi-core queue will be put up: 12 core qualifier, 4 jobs max
  • 30 new nodes (16 cores each) coming in to farm from LQCD as loan payback. Will be part of multi-core queue.
  • 50 of the 100 nodes currently in the exclusive queue moving to the multi-core queue.
  • Most of the exclusive nodes are running at load 10 on 24-core, 48-hyperthreaded machines currently in the exclusive queue. This motivated the changes above.


Drop in Number of halld Group Members

Cron <gluex@jlabl1> /home/gluex/bin/ccdb_update_users.sh

jobs run at midnight
• 10/01: 179 -> 179, no change, earliest message in Trash folder
• 11/17: 179 -> 185
• 11/25: 185 -> 186
• 12/04: 186 -> 187
• 12/05: 187 -> 175
• $CCDB_HOME/scripts/users_create/group_parse.pl gives 174+1 = 175 group members on 12/5
• no record before 10/01, AFAIK
• see 202 users in ccdb database

Update, 12/7:

Dmitry doesn’t know why this happened. Sent message to Helpdesk.


Rebaseline tweaking needed

A message from Eugene on  June 14, 2013

> Hi,
> We need to revisit some rebaseline items:
> a) Provide steps wherever needed

How do we know if steps are needed? At what level are steps appropriate?

For now, ignore this directive, go on to the next one.

> b) Treat the “red flags” in the progress schedule, which indicate
>    that an activity is late and pushing something else beyond
> milestones.
>    The cause might be a wrong predecessor-successor logic, unclaimed
>    progress or a real problem.

Red flags are defined below. In what sense are they to be treated?
Looked at the red flags. Assume that these are the literally red items marked “critical remaining work”. None for TOF, start counter, or target.

> c) Initiate the FY13 procurements

One interpretation: identify procurements that have not been initiated
in FY13, but should have been, and start buying stuff. Is that

> I copied various new files to
> http://www.jlab.org/Hall-D/halld_secure/rebaseline/

What follows is a list of files to be found there.

> 12_GeV_Hall_D_May_Rebaseline_Progress_3_June_13_PMK.pdf
> a progress schedule file from Phil, which shows the “red flags”

See above.

> 12_GEV_UPGRD_REBASELINE_Post_May_2013_Progress_Chudakov_modif.xls
> the May post-progress file, which contains both the progress % and the
> dates. It is the place to change the actual dates if needed.

What does post-progress mean? Which dates? Sounds as if we are to
review each of them to determine if they need changing.

Since there are no red flags for areas of responsibility, perhaps
nothing needs to be done here.

> stat_rebaseline_spend_2_2013_May.xlsx
> A table of the activities with the % done and a summary info on the
> associated procurements

> stat_rebaseline_spend_8_2013_May.txt
> A table of the activities with a detailed history of the associate
> procurements

Is there an action item associated with this file?

> rebaseline_4_progr.xlsx
> Updated rebaseline file. This is the place to add steps (find some
> examples in the file) and to tweak the predecessor-successor
> logic. The file contains the latest progress numbers.
> Thanks,
> Eugene