Message: Radioactive Decay module and Update Geometry issues. Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

Question Radioactive Decay module and Update Geometry issues. 

Forum: Geometry
Date: 03 Mar, 2011
From: L.G. Sarmiento <L.G. Sarmiento>

Dear forum people,

It looks like I pinned down a problem in a simulation and now I come to ask for your advice.

I have a hard-coded geometry developed i.e. not GDML or anything else, just CSG solids and boolean solids. The full geometry is this:
http://dl.dropbox.com/u/18580197/setup.png
and I am having some problems while comparing the simulated results with the experimental data.

Here is a figure to show my problem.
The white curve is the experiment and the red is the simulation using the 152Eu source from the database. The two curves are normalised in the full window i.e. 500-1500 keV. In turquoise I marked a few energies (keV) next to problematic peaks. You see the 563, 778 (!), 1212, 1298 peaks all overestimated while the transitions in between are well reproduced by the simulation. In addition you see the 1460 normal backround peak measured in the experiment as expected.
http://hypernews.slac.stanford.edu/HyperNews/geant4/get/AUX/2011/02/12/07.48-92026-152Eu.pdf

The situation is the following: Since 152Eu is a calibration source. I programmed the rod that holds the calibration source inside the chamber as something you can include or exclude by means of a DetectorMessenger i.e. you can place it or not via a macro file and it was not included by default.

Please follow the links and you will find the spectra, for the different scenarios, between 500keV and 1500keV (for direct comparison with the experimental data), and please pay special attention to the intensities of the peaks located at ~778keV, ~960keV.

If you let the source "hanging in the air" without placing the holder/rod the result are this:
http://dl.dropbox.com/u/18580197/152Eu_NO_holder.png
Never placing the "removing line" in the macro and the rod is not present by default
http://dl.dropbox.com/u/18580197/152Eu_macro_NO_holder.png
Removing the rod via Detector Messenger

You can notice that they are exactly the same between them since the rod was never there BUT the geometry gets recomputed anyway. Details below.
If you place the holder via the macro file now your results looks like this:
http://dl.dropbox.com/u/18580197/152Eu_macro_holder_2.png
You may notice that this is nothing but the original problem.

BUT(!), on the other hand, if you hard-code the rode from the beginning (holder_flag set to true in the details below), this is what you get:
http://dl.dropbox.com/u/18580197/152Eu_coded_holder.png
(and this is the desired result !!!! The agreement with the experiment is excellent, to say the least)

So, wrapping up: the problem comes to the fact that there is something wrong in the way I include the rod and here comes the part where I want to learn how to avoid/fix the situation properly.

The relevant parts of the code are the following:

G4LogicalVolume DetectorConstruction::Construct()
{
...
if(holder_flag) ConstructSampleHolder(); //holder_flag=false by default
...
}

void DetectorConstruction::ConstructSampleHolder()
{
...
... PhysicalVolume definition and placement of the rod inside the chamber
...
}

The relevant part from the DetectorMessenger is this:

if ( command == sampleHolderCmd )
{
 G4bool flag = sampleHolderCmd->GetNewBoolValue(newValue);
 detector->setHolder_flag(flag);
 detector->UpdateGeometry(); //Should I implement a RemoveDaughterVolume function?
}

And this is what the UpdateGeometry() method does:

void DetectorConstruction::UpdateGeometry()
{
  // Cleanup old geometry
  G4GeometryManager::GetInstance()->OpenGeometry();
  G4PhysicalVolumeStore::GetInstance()->Clean();
  G4LogicalVolumeStore::GetInstance()->Clean();
  G4SolidStore::GetInstance()->Clean();
  G4RunManager::GetRunManager()-> GeometryHasBeenModified();
  G4RunManager::GetRunManager()->DefineWorldVolume(Construct());
}


What am I doing wrong here? The volume looks ok in the visualization(!). Is it something related to the PhysicsList being initialized after the initial geometry and hence the new geometry messes up the Physics? Should I restart the PhysicsList as well when updating the geometry?

Many thanks in advance.


/Pico

 Add Message Add Message
to: "Radioactive Decay module and Update Geometry issues."

 Subscribe Subscribe

This site runs SLAC HyperNews version 1.11-slac-98, derived from the original HyperNews


[ Geant 4 Home | Geant 4 HyperNews | Search | Request New Forum | Feedback ]