Comments (14)
Yeah the code in sbnanalysis needs to be ported to the new structure. For now, I think it'd be ok to just comment out building (e.g.) SBNOscReco.
from sbncode.
We can probably just remove the sbnanalysis code from the develop branch -- it's going to be ported into the new CAF file stuff anyway.
A bigger problem is the data products which are still defined in sbndcode/icaruscode. I believe it is mostly the CRT data products. The SBN-CAF file maker needs access to these data products to work. So I believe they need to be moved out of sbndocde/icaruscode into something like sbn-obj.
from sbncode.
Where is the CAF stuff envisioned to live?
from sbncode.
from sbncode.
Currently it's on the feature/sbncaf branch in the sbncode/ directory. At some point it should just be merged onto develop.
from sbncode.
Ah, you mean that CAF will remain part of sbncode, and absorb whatever functionality sbnanalysis currently has, but rewriting it in such a way that it no longer has explicit dependencies on sbndcode/icaruscode, so that it's safe to remain as part of the re-located sbncode?
from sbncode.
I think a situation of NH sbncode, but the CAF development branch remaining IH for a while sounds extremely confusing. Can we try and synchronize those fixes, or merge CAF into develop before the switch?
from sbncode.
Opened issue #10 to create sbnobj
.
from sbncode.
Yeah Chris I agree that we should try to merge the SBN CAF changes into develop before doing the switch. I don't know if there are still issues with merging onto develop (@FernandaPsihas ?).
Once it's on develop, we can work out what changes need to be made. I think(?) it should mostly just be putting the necessary data products in an sbn-obj repo.
from sbncode.
I am hitting this as well now.
I don't understand which is the envisioned solution, but it appears to me that sbnanalysis
is going to keep its dependency on icaruscode
, since it seems to use detector geometry via geo::GeometryCore
.
Other headers that are required: sbndcode/OpDetSim/sbndPDMapAlg.h
, icaruscode/CRT/CRTProducts/CRTChannelData.h
. These are not scheduled for move in sbncode
/sbnobj
as of now.
(edit) In fact, icaruscode/CRT/CRTProducts/CRTChannelData.h
does not exist in icaruscode
develop
branch, and the header closest to sbndcode/OpDetSim/sbndPDMapAlg.h
in sbndcode
is actually called sbndPDMapAlg.hh
. (.hh
instead of .h
).
from sbncode.
OK, not that this is urgent, but I want to ping on this. Can we get a time estimate for when we need this?
from sbncode.
@gputnam : this is now well obsolete, yes? If so can you close this issue?
from sbncode.
@PetrilloAtWork @FernandaPsihas @miquelnebot
Is this obselete? Would be good to close.
from sbncode.
I'm closing.
from sbncode.
Related Issues (20)
- Split CAFMaker into record-making and CAF-making parts HOT 1
- Ability to create CAF-precursor art files HOT 2
- CAF-precursor to CAF, including additional weights
- GENIE reweights configuration HOT 1
- Getting (Pandora) Nu Score BDT inputs from Pandora into CAF files HOT 6
- Getting (Pandora) Nu Score BDT inputs from Pandora into CAF files #229
- Clean up binary locations
- Implement filter module based on run/subrun/event HOT 4
- Break CAFMaker out into its own package HOT 2
- CRTT0Matching libraries have the same name HOT 5
- Make optical flash information filling detector-agnostic HOT 6
- Genie v3_02_00 update HOT 2
- Flash matching time definition in CAF differs for data and MC HOT 4
- BNBRetriever module needs to be decoupled from ICARUS trigger fragment HOT 3
- Refashion the supera integration for more standard production release
- CAFMaker blinding random stream uses the same random numbers as the "fake" reconstruction HOT 5
- Add reconstructed time to CAF particle record HOT 4
- Possible error in TrackCaloSkimmer HOT 2
- Discrepancies on the expected Branching Ratios for HNL decays in MeVPrtl module
- rec.slc.reco.pfp.shw.start and other pfp variables not being pushed to flat caf tree
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sbncode.