We will have the DUNE General computing meeting:
Heidi Schellman is inviting you to a scheduled Zoom meeting.
Topic: General DUNE Computing meeting
Time: This is a recurring meeting Meet anytime
Join Zoom Meeting
https://fnal.zoom.us/j/162652254
One tap mobile
+16699006833,,162652254# US (San Jose)
+16465588656,,162652254# US (New York)
Dial by your location
+1 669 900 6833 US (San Jose)
+1 646 558 8656 US (New York)
Meeting ID: 162 652 254
Find your local number: https://zoom.us/u/acoyhG3WuF
FInal decision on BNL workshop this week
Doing dual phase MC for the data challenge
ProtoDUNE MC/reco in the works - small test sample exists
Need to get a campaign tag for this new production. Suggestions in the production slack channel
Elisabetta needs space on EOS for DP. Steve and Robert are working Start massive transfer tests to make certain they work.
DIRAC/rucio work coming out of a workshop in London two weeks ago. Roger will report on RAL efforts next week.
Discussion of longer term strategy for DIRAC + rucio testing. Need to do security review before we can run DiRAC jobs through FNAL.
Discussion of code management issues for external packages
Two classes
external codes, unmodified - HDF5, CAFE
external codes, modified - how do you separate them?
need some forum for discussion of external packages - which ones should we use ?
DUNE DAQ Consortium is going to update its interface document with the new geographically-split data file format and associated issues (trigger, metadata, non-TPC data, etc) and would like the offline computing people to review.
Here's a question Kevin Ewart asked on Thursday in #larsoft_beginners channel on the DUNE Slack system:
----------------------
What is the collaboration/LArSOFT/Art's position on copying from open source libraries? Specifically, I want to use a function released under LGPL 3.0 that I have modified, but left all the original inline documentation and author information, as well as my name and modification date
----------------------
(no answer yet)
This sort of thing has come up twice in the last week. Here's the other instance:
Jeremy Hewes wants central maintenance of HighFive, a header-only package that
provides convenices interfaces to HDF5. HighFive is a project by a small group
of people called BlueBrain and they put it on GitHub:
https://github.com/BlueBrain/HighFive
Jeremy has copied HighFive headers into his own personal test release and likes them but wants to push his code,
and would like central management of HighFive. I asked Lynn and the SciSoft team about this and they mentioned they
could do the initial setup but that DUNE would be in charge of maintenance. There is an HDF5 product in the larsoft
CVMFS area. Naturally there are worries here: if BlueBrain abandons HighFive and HDF5 evolves, we may end up
with dead code. HDF5 may have some interest in preserving compatibility. Another scenario is that the compiler evolves
and HighFive no longer compiles, or BlueBrain develops faster than we do and the new version of HighFive has
some incompatibiltiy with DUNE software. I told Jeremy that we would look into installing it as its own UPS product
in the DUNE CVMFS space, but if it breaks anything in a way that
cannot be solved with a simple update, we'll disable code that depends on it. I should have also mentioned that
we do not plan on providing tutorials on HighFive either (I found out about its existence last week).
Another wrinkle: Chris Green and Marc Paterno are working on a C++ wrapper to HDF5, and integrate with the HDF5
group.
https://www.hdfgroup.org/2019/01/register-for-the-hdf5-cpp-webinar/
----------------------------------
Back to Kevin's question. I don't mind if the licensing arrangements are met and it isn't a bigger burden
to carry around than user code, but the fact that Kevin has modified the code causes some worry. The worry
is that the method(s) with the same names can crop up elsewhere and Kevin's modified version can clobber
someone else's desired use of an unmodified version. That, and keeping the code maintained with new
compilers and possibly changing external dependencies is the usual chore. A suggestion to Kevin: if he has
modified some code, he should give his modified version new names.
Your thoughts?
I might include this as a discussion item in my talk at the upcoming LArSoft workshop.
Tom