NPPS Leadership Team

[Torre Wenaus <wenaus AT gmail.com>]

Thanks Brett, it’s good to have your assessment. Do you have an example of “right way” geometry?

  Torre

On Fri, Nov 22, 2019 at 1:51 PM Brett Viren <bv AT bnl.gov> wrote:

A few comments, in case any might be useful:

- The format of the document kind of encourages "us vs them" but even
  with that there is a lot of bad faith statements.  They clearly
  demonstrate very unhealthy "collaboration".

  I also sense that a lot of the statements in blue come from a place of
  not really understanding the fun4all's design.  I can't say I do, but
  looking through a few of the linked files it's clear to me that ROOT
  .C scripts are used as configuration files while blue text seems to
  see them as application code.

  This confusion may be in part due to some lacking in fun4all docs
  (which we discussed today deserve some attention).  At the same time,
  the blue text writer (I assume) is a deep expert in software
  development so should be able to glean what I did after a few minutes
  of browsing the code.

- I note that fun4all is used in experiments beyond just PHENIX/sPHENIX
  (eg SeaQuest at least).

- g4e does have bad code "smell" (I mean this in the term of art way).
  Lack of consistent indentation, a lot of commented-out vestigial code
  instead of simple removal, giant "#if 0" blocks leaving cruft around.
  The string comparisons in the stepper are indeed real and not even
  done in some way that exploits a generalized naming convention, just
  miles of string comparison.  I stopped there because I detest GitLab's
  web interface.

- As a past contributor to the project, I wouldn't list VGM as such a
  major benefit.  It's more of a hindrance (sorry to say).

- For "geometry parameters", again it seems clear that the ROOT scripts
  are not being seen as configuration files but application code.
  (otoh, g4e literally hard-codes the geometry, so, pot/kettle)

  [My opinion: both approaches are wrong.  I think the "right" way to
  handle geometry is to abstract the description of the geometry into
  some independent, high level model and from that model develop
  compilers that can generate GDML, G4 C++, interpreters of the model
  that directly produce G4 C++ objects, generators of reference
  documentation, visualization forms, and whatever other forms might be
  useful.  Such modeling can likely be used for as-built geometry.]


All in all, it's a very angry table.

-Brett.

Torre Wenaus via Phys-npps-mgmt-l <phys-npps-mgmt-l AT lists.bnl.gov>
writes:

> EIC simu table
> https://docs.google.com/document/d/1T-lGz_AtJt5ZkwUQaUCouFqrr6RNykPdA8FsUD7QmsM/edit#heading=h.ln6z26ycplzg
>
>
> On Fri, Nov 22, 2019 at 9:36 AM Torre Wenaus <wenaus AT gmail.com> wrote:
>
>  Leadership team meeting following the group meeting
>    Torre
>
> _______________________________________________
> Phys-npps-mgmt-l mailing list
> Phys-npps-mgmt-l AT lists.bnl.gov
> https://lists.bnl.gov/mailman/listinfo/phys-npps-mgmt-l