[Halld-offline] Offline Software Meeting Minutes, January 26, 2018
marki at jlab.org
Fri Jan 26 15:26:44 EST 2018
Please find the minutes below and at
GlueX Offline Meeting, January 26, 2018, Minutes
* *CMU *: Naomi Jarvis
* *FSU *: Sean Dobbs
* *JLab: *: Alex Austregesilo, Thomas Britton, Eugene Chudakov, Mark
Ito (chair), Beni Zihlmann
There is a recording of this meeting <https://bluejeans.com/s/Ai90E/> on
the BlueJeans site. Use your JLab credentials to access it.
1. New sim-recon release, version 2.21.0
This is the first release that has Simon's new track matching code.
2. New version of CCDB: v1.06.06
Contains all changes since last July. Does not include features from
the 1.07 development branch.
3. New release of RCDB: v0.02.01
Contains changes to the Python routines. The C++ API is the same as
in v0.02. On a related topic, the website
<https://halldweb.jlab.org/rcdb> is still running a very old version
(pre-GitHub era). Mark did update the alias.py there however, giving
us access to the "is_2018production" query.
4. New version set 2.25 has new sim-recon (and more)
This version set includes the releases of sim-recon, CCDB, and RCDB
Review of Minutes from the Last Meeting
We went over the [[GlueX Offline Meeting, January 10,
2018#Minutes|minutes from January 10. We did review disk usage on cache,
work, and volatile. There was no other significant discussion.
New RCDB version with SQLite capability
Mark went over his recent email message
describing the changes needed to bring on the new RCDB version. This
will restore access to the SQLite version of the database and thus
enable running on the OSG. There are two issues he has encountered since
sending the message:
1. HDGeant4, via inclusion of the level 1 trigger library of sim-recon,
has a dependence on RCDB. Its makefile therefore needs modification
to search the new SQLiteCpp library. This has been done; the results
are on the sqlitecpp_standalone branch of the HDGeant4 Git repository.
2. The new SQLiteCpp library needs a version of the SQLite library
greater than or equal to 3.7.x The default SQLite (provided via
RPMs) on RHEL6 and CentOS6 is 3.6.x. To build on these platforms, a
more recent version of SQLite needs to be installed. At JLab, there
is an SQLite 3.13.0 available on the /apps partition. A solution
using this installation is underway.
Mark's proposal from the email was:
I've not yet merged any of these changes onto any of the master
branches. My proposal is to prepare public versions of RCDB,
SQLiteCpp, and build_scripts [and also HDGeant4] at JLab, and then
submit a pull request for the change to sim-recon. When that gets
merged I can create a tagged version and build that with the
appropriate version set (version.xml).
Collaborators that are uninterested in these changes can continue on
with older version sets. However, after this change, any update of the
master branch of sim-recon will require an update of RCDB and HDGeant
and installation of SQLiteCpp *at the same time*.
At present, the only technical difficulty standing in the way of this
proposal is the SQLite version problem on RHEL6 and CentOS6. These
platforms are not heavily used at JLab for offline processing and the
pieces for a solution at JLab are at hand. The real problem will come
for folks running CentOS6 off-site; each system admin will have to come
up with a local solution. Note that SQLite version 3.7.0 was released on
July 21, 2010, over seven years ago, so there are likely solutions out
We came to a consensus on going ahead with implementation of the proposal.
Release Management Thoughts
As reflected in the title of the agenda item, Sean has been thinking. He
has identified a need for more formal control of our version sets. For a
given run period there may be multiple reconstruction passes and for
each reconstruction pass, there may be multiple iterations of the
simulation software. In additions there are changing version of the
GlueX Root Analysis (GRA) package. The correct combination of versions
for a particular task can get complicated. He outlined the situation in
We discussed various approaches.
* Thomas pointed out that part of the complication is because
simulation and reconstruction are bundled together in the same
package. If they were separate packages, version control would be
simpler. Mark mentioned that having HDGeant4 in a separate
repository goes a long way toward sim/recon independence, but other
important components remain bundled, most importantly mcsmear.
* Alex remarked that GRA version control is often usefully left to the
individual analyzer. Often the master branch is used. Mark pointed
out that often collaborators are not interested in making this
choice; they would rather have a compatible version set-up for them
* Mark suggested that a meta-version XML file could identify version
sets appropriate for each task, e. g.,
<activity type="reconstruction" version_set="recon_2018-01_ver03.xml"/>
<activity type="simulation" version_set="recon_2018-01_ver03-sim.xml"/>
<activity type="analysis" version_set="recon_2018-01_ver03-ana.xml"/>
The group was generally in favor of a more formal system. We decided to
take the topic offline for now---more thinking.
Review of Recent Pull Requests
We reviewed them
No significant comments.
Review of Recent Discussion on the GlueX Software Help List
We reviewed recent discussion
* This page was last modified on 26 January 2018, at 15:22.
Mark Ito, marki at jlab.org, (757)269-5295
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Halld-offline