Project

General

Profile

Feature #24269

Explore splitting out WebEVD as a standalone product

Added by Christopher Backhouse 7 months ago. Updated 5 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
04/03/2020
Due date:
% Done:

100%

Estimated time:
Spent time:
Experiment:
LArSoft
Duration:

Description

Upgrading this from an email thread with Erica into an issue.

What would it take to make my WebEVD event display a "top level" ups product? Or is there some existing lar* project it fits neatly in?

My goal is for people to be able to use it as easily as setup webevd, or to develop it with mrb g webevd.

I assume this would be basically giving it a repository within larsoft on github, and copying the structure of one of the existing ones? What causes it to get build with the rest of the release?

I would need to go through and do a careful accounting of the dependencies, but essentially they will be on all of the larsoft data products, and the Geometry and DetectorInfo services, but not on any of the simulation / reconstruction algorithms, nor on the individual experiment repositories. The only "external" dependency is to the THREE.js javascript library, and I currently just have a link to a frozen copy of that on a CDN rather than importing it into my source tree.

The display currently works with SP DUNE FD and ProtoDUNE. I have ambitions for dual phase, the SBN experiments, and hopefully also DUNE ND.

The code exists in a feature branch of dunetpc at the moment. That location is arbitrary. The pain of checking out and building dunetpc is part of what I want to get away from.
https://cdcvs.fnal.gov/redmine/projects/dunetpc/repository?utf8=%E2%9C%93&rev=feature%2Fbckhouse_evd

Thanks - Chris

History

#1 Updated by Lynn Garren 7 months ago

A quick note here. The product could easily be called webevd. We would build it when making a larsoft distribution, however the larsoft product would not setup webevd. Instead, anyone wanting to use the product would set it up themselves. This will be discussed by the SciSoft team on Monday.

#2 Updated by Kyle Knoepfel 7 months ago

  • Assignee set to Lynn Garren
  • Status changed from New to Assigned

#3 Updated by Lynn Garren 7 months ago

  • Status changed from Assigned to Feedback
  • Co-Assignees Christopher Backhouse added

Chris, we suggest a product named webevd. The easiest way forward is for you to develop this initially in your own githup repository. Once it is ready to go, it can be added to the LArSoft github project. Does that work for you?

You will need to be careful about dependencies. You can start with a dependency on larsoft, but I presume that you will only need to depend on one or two of the larsoft products (maybe larrecodnn and larwirecell, but I'm guessing).

The "mrb p webevd" command will generate a skeleton product for you, but please update cetbuildtools to v7_15_01.

#4 Updated by Christopher Backhouse 7 months ago

I have an initial version of this in the develop branch at https://github.com/cjbackhouse/webevd . To my surprise it all builds and works, and I managed to figure out how to import my history.

For now I'm taking a dependency on all of larsoft. I figure I can make that more fine-grained later. The ups and build files could probably do with an expert taking a look to tidy things up.

I think the biggest problem is that currently one needs to setup dunetpc (which I don't declare as a dependency) to build. The reason is that I use dune/ArtSupport/ArtServiceHelper.h. I don't believe there's anything there that is dune-specific. Seems like it should be moved to some much more fundamental location.

#5 Updated by Christopher Backhouse 7 months ago

OK, I've resolved the ArtSupport problem for now by just directly copying the (short) source files I need. We should probably start a conversation with David Adams about a better fix.

The dependencies otherwise all boil down to lardata and its transitive dependencies, so that ended up fairly simple. If someone could sanity check my github repository I think we're about ready to go.

#6 Updated by Lynn Garren 7 months ago

I've asked Kyle to take a look.

#7 Updated by Kyle Knoepfel 7 months ago

Chris, as the WebEVD application really only requires the LArSoft providers, it should be possible to change the dependency from lardata to lardataalg. I understand, however, that easily creating the providers can be a complication. I'd like to suggest some possible solutions. Are you available sometime this week for a Zoom meeting to discuss options?

#8 Updated by Christopher Backhouse 7 months ago

Yes, I picked lardata just because I have an include of lardata/DetectorInfoServices/DetectorPropertiesService.h I immediately convert that to the provider in any case, but do I not need the whole thing in order to be able to instantiate the ServiceHandle?

I'm reasonably available. Please suggest a meeting time.

#9 Updated by Kyle Knoepfel 7 months ago

Okay, how about 9 am CDT on Friday (4/10)? I'll send out an Exchange invitation if that works.

Regarding service handles: yes, you would need the service system to be able to create one. My argument is that for this application, it is not necessary to create/access a provider through a service handle; it can be done in a different way. We can talk about it in the meeting.

#10 Updated by Christopher Backhouse 7 months ago

Sounds good.

#11 Updated by Kyle Knoepfel 7 months ago

  • % Done changed from 0 to 50

The art developers have met to discuss this, followed by a separate meeting between Chris Backhouse and Kyle. The proposal is:

  • In the short-term, modify the ArtServiceHelper to use a supported (although discouraged) function for now (see https://github.com/cjbackhouse/webevd/pull/1).
  • The longer-term solution is that the required providers should become tools that can be dynamically loaded, without involving art's service system. This will require changes in both LArSoft and art, and it will be discussed by the SciSoft team.

#12 Updated by Lynn Garren 6 months ago

  • % Done changed from 50 to 0

I see that the PR has been merged. Kyle, would you take another look?

#13 Updated by Kyle Knoepfel 6 months ago

Not sure what you want me to look at, Lynn. The repository now looks like what I would expect it to following the merge.

#14 Updated by Christopher Backhouse 6 months ago

I think the question is, is everyone happy to clone the repository as it stands into the larsoft github?

#15 Updated by Lynn Garren 6 months ago

Chris, this needs a bit of work to build with c7. There are unused variables, and an ambiguous use of operator '<<'.

#16 Updated by Christopher Backhouse 6 months ago

I don't have access to a mac, but if you send the logs it sounds like it should be easy enough to fix up blind.

#17 Updated by Lynn Garren 6 months ago

Chris, you can build with c7 on SLF7. Just make this change to ups/product_deps:

diff --git a/ups/product_deps b/ups/product_deps
index 7189601..924b803 100644
--- a/ups/product_deps
+++ b/ups/product_deps
@@ -44,6 +44,8 @@ end_product_list
 qualifier      lardata       gallery     notes
 e19:debug      e19:debug     e19:debug
 e19:prof       e19:prof      e19:prof
+c7:debug      c7:debug     c7:debug
+c7:prof       c7:prof      c7:prof
 end_qualifier_list

 # Preserve tabs and formatting in emacs and vi / vim:

Then

source .../webevd/ups/setup_for_development -p c7

#18 Updated by Christopher Backhouse 6 months ago

OK, I just pushed fixes for both issues.

The operator<< one puzzles me, since the "wrong" overload should have failed a static_assert and therefore not been picked. But it's almost certainly the fault of my understanding of SFINAE rather than of clang.

#19 Updated by Lynn Garren 6 months ago

  • % Done changed from 0 to 50
  • Status changed from Feedback to Assigned

Thanks - looking good now.

#20 Updated by Lynn Garren 6 months ago

  • % Done changed from 50 to 100
  • Status changed from Assigned to Resolved

https://github.com/LArSoft/webevd will be part of the next larsoft distribution.

#21 Updated by Kyle Knoepfel 5 months ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF