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

Feature tidy up #189

Merged
merged 12 commits into from
Oct 31, 2024
Merged

Feature tidy up #189

merged 12 commits into from
Oct 31, 2024

Conversation

EdAtkin
Copy link
Contributor

@EdAtkin EdAtkin commented Oct 28, 2024

Pull request description

Mainly tidying up some bits of code especially the FarDetectorStruct class. Removing allocation of lots of arrays on the heap to use std::vectors instead. Also a general bit of tidy up here and there.

Changes or fixes

Rename of FDMC struct to FarDetectorStruct. Also moving many of the members of this struct to be vectors. Small clean up of splineFDBase class.

Examples

e.g. int* modes = new int[nEvents]; -> std::vector modes; modes.resize(nEvents);

@github-actions github-actions bot added Nu Osc/Xsec Related with neutrino interactions or oscialtions Samples labels Oct 28, 2024
Comment on lines +46 to +58

bool *isNC;

// histo pdf bins
Copy link
Member

Choose a reason for hiding this comment

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

Why is it raw pointer while everyhitng else is vector?

Copy link
Contributor

@luketpickering luketpickering Oct 28, 2024

Choose a reason for hiding this comment

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

Read about std::vector bool, it doesn't behave like other std::vector objects, or just try printing the address of the first three entries of auto myvecbool = std::vector bool {true,true,false};

Copy link
Member

Choose a reason for hiding this comment

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

I feel dumb for not knowing this...

In this case there should be a destructor?

Copy link
Contributor

Choose a reason for hiding this comment

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

Probably there should be a default constructor:

FarDetectorCoreInfo() : isNC{nullptr} {}
~FarDetectorCoreInfo(){delete [] isNC;}

@@ -2,7 +2,7 @@ set(HEADERS
samplePDFBase.h
samplePDFFDBase.h
Structs.h
FDMCStruct.h
FarDetectorCoreInfoStruct.h
Copy link
Contributor

Choose a reason for hiding this comment

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

I know its minor, but I'd remove struct from the file name, its very common to have a file named after the class it is defining. And having 'struct' in the name of a class/struct is just noise. (I also think 'Core' is noise here, and FarDetData or something is a cleaner name, but your name is absolutely fine and we don't need to argue forever about names)

@@ -785,7 +782,7 @@ void samplePDFFDBase::SetupNormParameters(){
//A way to check whether a normalisation parameter applies to an event or not
void samplePDFFDBase::CalcXsecNormsBins(int iSample){

fdmc_base *fdobj = &MCSamples[iSample];
FarDetectorCoreInfo *fdobj = &MCSamples[iSample];
Copy link
Contributor

Choose a reason for hiding this comment

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

Its up to you, it really is minor, but weaning people off using pointers when they don't need to, you might consider:

FarDetectorCoreInfo &fdobj = MCSamples[iSample];

//...
fdobj.someprop = something;

Copy link
Contributor

Choose a reason for hiding this comment

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

but it depends on how people feel about reference/pointer/copy semantics. You do have to be careful and confident... maybe taking pointers is clearer that it isn't a copy, as if someone misses that ampersand then it doesn't do what you expect. (you could delete the copy/move constructors of FarDetectorCoreInfo to elide this

struct FarDetectorCoreInfo{
  FarDetectorCoreInfo(FarDetectorCoreInfo const &other) = delete;
  FarDetectorCoreInfo(FarDetectorCoreInfo &&other) = delete;
  FarDetectorCoreInfo& operator=(FarDetectorCoreInfo const &other) = delete;
  FarDetectorCoreInfo& operator=(FarDetectorCoreInfo &&other) = delete;
}

Copy link
Contributor

Choose a reason for hiding this comment

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

I'd maybe do this anyway and see if you do copy/move anywhere. If you always construct in place with emplace_back or resize, then I think its fine/best to not have copy constructors/assignment

@@ -785,7 +782,7 @@ void samplePDFFDBase::SetupNormParameters(){
//A way to check whether a normalisation parameter applies to an event or not
void samplePDFFDBase::CalcXsecNormsBins(int iSample){

fdmc_base *fdobj = &MCSamples[iSample];
FarDetectorCoreInfo *fdobj = &MCSamples[iSample];

for(int iEvent=0; iEvent < fdobj->nEvents; ++iEvent){
std::list< int > XsecBins = {};
Copy link
Contributor

Choose a reason for hiding this comment

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

I really don't see why we use a list here, should be a vector

fdobj->mode.resize(nEvents, &fdobj->Unity_Int);
fdobj->nxsec_norm_pointers.resize(nEvents);
fdobj->xsec_norm_pointers.resize(nEvents);
fdobj->xsec_norms_bins = new std::list< int >[nEvents];
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think we should manually manage the memory of an STL container designed to obviate manual memory management. Also it should just be a vector

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, this might actually be a find/replace issue, I don't even think the syntax is correct.

fdobj->total_weight_pointers.resize(nEvents);
fdobj->Target.resize(nEvents, 0);
#ifdef _LOW_MEMORY_STRUCTS_
fdobj->osc_w_pointer.resize(nEvents, &fdobj->Unity_F);
Copy link
Contributor

Choose a reason for hiding this comment

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

we should just have a single fdobj->Unity data member with the type changing based upon this define. My 'tidy up' PR will make this trivial, so don't need to change yet, just a comment for future.


fdobj->x_var[iEvent] = &fdobj->Unity;
fdobj->y_var[iEvent] = &fdobj->Unity;
for(int iEvent = 0 ; iEvent < fdobj->nEvents ; ++iEvent){
Copy link
Contributor

Choose a reason for hiding this comment

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

std::fill_n(fdobj->isNC, fdobj->nEvents, false);

@luketpickering luketpickering marked this pull request as ready for review October 31, 2024 13:37
@luketpickering luketpickering merged commit 8846589 into develop Oct 31, 2024
11 checks passed
@luketpickering luketpickering deleted the feature_TidyUp branch October 31, 2024 13:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Nu Osc/Xsec Related with neutrino interactions or oscialtions Samples
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants