Core dumped while running sensitive detector

Hello everyone !
I am facing difficulty in running my detector after introducing sensitive detector in it. Here is the code

 void DetectorConstruction::ConstructSDandField()
{
auto sdManager = G4SDManager::GetSDMpointer();
  G4String SDname;

  MySensitiveDetector* sensDet = new MySensitiveDetector(SDname="/sensDet");
  sdManager->AddNewDetector(sensDet);
  logicDetector->SetSensitiveDetector(sensDet);
  }

The last line is creating some issue because when I comment it out, it runs but I am not able to implement sensitive detector part in it. Kindly help !

Where is logicDetector filled? Is it a data member of your DetectorConstruction class? If it is not properly filled with a valid G4LogicalVolume pointer, then you’re dereferencing an invalid pointer and of course your job crashes.

Also, you probably don’t want to instantiate and register a new SD object every time. If you ever run a job with multiple run, that will cause errors. What you should do instead is initialize SDname with the name string first, then query the sdManager to get a pointer to the SD. If that get request fails, then create a new SD and register it into sdManager.

Logic detector is filled in following way in detector construction header file.

private:
//virtual void ConstructSDandField();
G4Box *solidWorld;
G4LogicalVolume *logicWorld, *logicDetector, *Reflector,* logicScintillator,* logicPhotocathode,* logicPMTWindow;
G4VPhysicalVolume *physWorld, *physDetector,* physiPhotocathode,* physiScintillator,* physiReflector,* physiPMTWindow;
G4Material* NaI , *worldMat, *AluR, *Lucite, *Quartz, *K2CsSb;
G4Tubs*solidPMTWindow, * solidScintillator, * solidPhotocathode,* solidReflector,* solidDetector;

virtual void ConstructSDandField();
void DefineMaterial();

};

I initialise sd name string first but still the core is dumped. Can you please check this out ?

this is not where it is filled, this is where it is defined. the filling should look similar to

logicDetector = new G4LogicalVolume(..., ..., "...");

It is filled inside G4VPhysicalVolume DetectorConstruction::Construct()* class

G4Tubs* solidDetector = new G4Tubs("Detector",0.*cm,5*cm, 0.5*cm, 0*deg, 360*deg);			   
        G4LogicalVolume* logicDetector = new G4LogicalVolume(solidDetector, worldMat, "logicDetector");


        G4ThreeVector positionDetector = G4ThreeVector(0.*cm,0.*cm,10.5*cm);
         G4VPhysicalVolume* physDetector = new G4PVPlacement(0,positionDetector, logicDetector, "physDetector", logicWorld, false, 0, true);
   
   
      return physWorld;

this must read

G4Tubs* solidDetector = new G4Tubs("Detector",0.*cm,5*cm, 0.5*cm, 0*deg, 360*deg);			   
logicDetector = new G4LogicalVolume(solidDetector, worldMat, "logicDetector");

and you are good to go. Otherwise you create a local “logicDetector” that shadows the class member logicDetector (should be one of the compiler warnings btw).

Thank you so much for your response sir. But segmentation fault is still there. What should I do ?

maybe you forgot other volumes with the same issue?

Usually there is no need to define them in your header file as data members of your detector construction class. The you would not have this problem,

Is there a particular reason for defining them in the header file?

Try using the ConstructSDandField() after you defined your detector as a physical volume:

    G4VPhysicalVolume* physDetector = new G4PVPlacement(0,positionDetector, logicDetector, "physDetector", logicWorld, false, 0, true);
    ConstructSDandField();

No. Do not do this. ConstructSDandField() is called separately by the worker threads. If you do that in the master thread, you will have problems. The correct thing to do, as @weller wrote, is to make sure you’re filling the data members, and not creating (and then discarding) a local variable with the same name.

Hi, John. The reason for doing this is so that the created volume pointers can be referenced later, when the worker threads call ConstructSDandField(). Otherwise, the user would need to hardcode the volume names and search through the geometry store to get the pointers. We do the same thing in our simulation.

The issue is resolved. Thank you so much everyone for your responses. I carefully checked the code and called define materials function in detection constructions class. The fault vanished.
Screenshot from 2023-01-12 16-36-29

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.