Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HF shower library interface vers03 #8358

Closed
wants to merge 1 commit into from

Conversation

lveldere
Copy link
Contributor

I open this pr to enable a discussion.
A proper description will follow later.

<< "," << cos(momDir.phi()) << ", " << sin(momDir.theta())
<< "," << cos(momDir.theta());
#endif

std::vector<HFShowerLibrary::Hit> hit;
ok = false;
if (parCode == pi0PDG || parCode == etaPDG || parCode == nuePDG ||
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Vlandr57

move the parCode condition to the fillHits function,
this allows you to remove the parCode condition from
FastHFShowerLibrary

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code for particles in FullSim is initiated with initRun(G4ParticleTable * theParticleTable) function,
so for FastSim need to write some interface for this case.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right.

@civanch, can we give the *PDG variabels proper values inside the constructor of HFShowerLibrary?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@civanch , is there anything against initialising the *PDG variables in the constructor to the usual PDG codes?
@Vlandr57 , could you take care of that?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lveldere , @Vlandr57, of course it is correct to move these lines to the constructor. If later we will need to use pdg codes from Geant4, then I would say Geant4 particle types are static, so if one access whatever Geant4 particle type it is already defined.

@cmsbuild
Copy link
Contributor

A new Pull Request was created by @lveldere for CMSSW_7_5_X.

HF shower library interface vers03

It involves the following packages:

FastSimulation/Calorimetry
FastSimulation/ShowerDevelopment
SimG4CMS/Calo

@ssekmen, @nclopezo, @lveldere, @civanch, @mdhildreth, @cmsbuild can you please review it and eventually sign? Thanks.
@Martin-Grunewald, @matt-komm, @makortel this is something you requested to watch as well.
You can sign-off by replying to this message having '+1' in the first line of your reply.
You can reject by replying to this message having '-1' in the first line of your reply.
If you are a L2 or a release manager you can ask for tests by saying 'please test' in the first line of a comment.
@nclopezo you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.


protected:
std::vector<HFShowerLibrary::Hit> getHits(G4ThreeVector & p, G4ThreeVector & v,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Vlandr57

when you move the parCode condition into HFShowerLibrary::fillHits,
the parcode condition can be removed from FastHFShowerLibrary::getHits.

The 2 remaining lines of code inside this function better move to FastHFShowerLibrary::recoHFShowerLibrary, so that this function can be removed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. it is possible to remove FastHFShowerLibrary::getHits function

@civanch
Copy link
Contributor

civanch commented Mar 17, 2015

@lveldere , @Vlandr57 , in FullSim the default SL file is for run-1 (in this PR - for run-2); in general, this PR seems to be OK for FullSim.

@lveldere
Copy link
Contributor Author

Hi Vladimir

Vladimir Andreev has implemented such that for run1 we use GFLASH, as
before,
while for run2 the run2 SL is used. This is fine for now.
It might be that we get rid of GFLASH for run1 at a later stage, then we
have to keep this in mind.

Lukas

On Tue, Mar 17, 2015 at 7:39 PM, Vladimir Ivantchenko <
notifications@github.com> wrote:

@lveldere https://github.com/lveldere , @Vlandr57
https://github.com/Vlandr57 , in FullSim the default SL file is for
run-1 (in this PR - for run-2); in general, this PR seems to be OK for
FullSim.


Reply to this email directly or view it on GitHub
#8358 (comment).

@cmsbuild
Copy link
Contributor

@cmsbuild
Copy link
Contributor

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-8358/3557/summary.html
There are some workflows for which there are errors in the baseline:
401.0 step 1
The results for the comparisons for these workflows could be incomplete
This means most likely that the IB is having errors in the relvals

@lveldere
Copy link
Contributor Author

moves to #8591

@lveldere lveldere closed this Mar 31, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants