CSR Meeting 201041

We will meet Thursday in WH2SE Comitium on 4/1 from 1-2:30pm.


  • Define what it means to be a computer science research group. * Learn how this fits into the work plans for the year. * Define target areas of interest and begin to establish a scope and direction for computer science research work. * Better understand the process of getting involved and moving forward.

Draft Agenda:

  • Make a short, prioritized list of areas and projects that we want to be involved. The items on the list must be aligned with Fermilab's strategic goals. * What is the process of getting involved? * What groups that we might be able to work with? * What is the strategy and the plan fort we will use to move forward? * Make sure that the things listed in the goals are at least vaguely understood by all.

Slide Material



The message is that we need to be moving towards external funding in order to do more interesting projects. We will have about 10% +- 10% over the next three months to start putting together skeleton plans for projects or programs that we could do. It is important to justify the particular program and supply Fermilab context for work suggested. It is also important to work as a secondary player until we establish some sort of presence.

What about the problem that groups or people at Fermilab might not have the vision to see usefulness to a suggested project? This is where rationale or justification statement come in - many things will not be thought about or accepted until there is a first demonstration of applicability.

We will have a follow-up meeting in two weeks, where we will come up with a record progress on project ideas and a place to put comments and documents about a subject. We will also determine the initial work that needs to be
completed (where to look for grant calls, who is doing interesting work in the fields of interest for example).


Panagiotis and Jim A. have work that we, as a group, can help with regarding multi-threading and accelerator modeling code.

The slides point out the things we discussed.

Jim A. wants us to help with writing the INCITE proposal for using the blue gene machine at Argonne for accelerator modeling.

up and coming things: parallel I/O, reliability of computations on supercomputing, improving quality of software (design / construction), improve maintainability of code.

example: We regards to supercomputing tools - people want to study how to know something is wrong in the application (runtime) due to hardware failures and be able to recover and not lose all the completed work.

Jim A. suggested doing something concrete instead of a broad, abstract category of thing.

There were not many ideas given during the meeting.

SBIR should be the last resort. NSF is difficult to directly obtain money. DOE is probably best.

Talk to PGS first, before talking with anyone else.

Ideas given

C++ class

binary rewriting - change the underlying stream of instructions for optimization / parallelization purposes. There is an LQCD MIT group doing some of this work. Northeastern also has done some simple work on this in Geant4.

C++ language improvements - reflection capabilities directly in the language, advancing units.

Tools and programming techniques or libraries to aid in creating better code or simplifying the writing of code that is more robust or testable, or better expresses the problem that is being solved. This includes exploring new or different languages (Chappel and opencl were mentioned).

Program Transformations (source to source translation)

  • non parallel to parallel * hardware optimization on different platforms * examination and analysis for robustness * changes to better utilize multicore

Here are specific project ideas

  • refactoring - copied code to a single function for example * "autopar" in ROSE (automatic parallelization), expanding and moving forward on this * object persistence for C++ (including output to things like HDF or other parallel I/O facilities) * adding testing code to functions to assess changes to inputs/outputs of functions after code changes are made to address the lack of testing problem