What(): std::bad_alloc

Hi!
I want to run the following script:

void box_1e5_h2()
{
gSystem->Load(“libGeom”);
TGeoManager *geom = new TGeoManager(“world”,“IES geometry”);

//— define some materials
TGeoMaterial *matUHV = new TGeoMaterial(“UHV”, 0,0,0);
TGeoMaterial *matSi = new TGeoMaterial(“Si”,26.98,13,2.7);

//— define some media
TGeoMedium *UHV = new TGeoMedium(“UHV”,1, matUHV);
TGeoMedium *Si = new TGeoMedium(“Si”,1, matSi);

//— make the top container volume
TGeoVolume *world = geom->MakeBox(“World”, UHV, 5000., 5000., 5000.);
world->SetVisibility(kFALSE);
geom->SetTopVolume(world);

//make the substrate
TGeoVolume *subs = geom->MakeBox(“substrate”, Si, 5000., 5000., 2500.);
subs->SetVisibility(kYellow);

//assemble the geometry
//world->AddNode(subs, 0, new TGeoTranslation(0, 0, -2500));

TGeoShape *shape = new TGeoBBox(0.5, 0.5, 0.5);
TGeoVolume *vol = new TGeoVolume(“Box”, shape, Si);

for(double i=0; i < 100; i += 1 ) {
for(double j=0; j < 100; j += 1) {
for(double m=0; m<10; m += 1) {
world->AddNode(vol, k++, new TGeoTranslation(i, j, m+0.5));

                                 }
                               }
                             }

geom->CloseGeometry();

geom->SetVisLevel(4);
world->Draw(“ogle”);

geom->Export(“box_1e5_h2.root”);
}

But I get still the following error message:

terminate called after throwing an instance of 'std::bad_alloc’
what(): std::bad_alloc

Can anybody help me? It seems there is no enough memory, but there are only
10to5 nodes that need to be added and my PC has 64bit 4GB physicall memory.

How Can I use AddNodeOffset() with positioning volumes in top volume? AddNodeOffset() doesnt have the option for the Volume Positioning. If I use above AddNodeOffset, then I can add 10to6 10to7 Nodes but all of them are not postioned.

I think your problem is 64-bit system specific.

On a 32-bit system (Ubuntu 10.04.4 LTS, i686), your script eats up to 72MB RAM (VIRT) in the “for” loops, when doing “world->AddNode(vol, k++, …)”. Afterwards, the “geom->CloseGeometry();” step immediately eats about 2.4GB RAM (VIRT and RES). However, I was able to execute your macro without problems (i.e. the “box_1e5_h2.root” file was created). Once your macro is finished, the RAM usage stays at about 140MB (VIRT).

On a 64-bit system (CentOS 6.3, x86_64), your script eats twice as much RAM in the “for” loops (up to 133MB VIRT RAM). Afterwards, in the "geom->CloseGeometry(); step, it dies: Info in <TGeoManager::CheckGeometry>: Fixing runtime shapes... Info in <TGeoManager::CheckGeometry>: ...Nothing to fix Info in <TGeoManager::CloseGeometry>: Counting nodes... Info in <TGeoManager::Voxelize>: Voxelizing... terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Well, I have 6GB RAM in that machine, but apparently it’s not enough.
Try maybe to find a machine which has something like 20GB RAM …

Note: your macro is missing something like “int k = 0;” (i.e. before all the “for” loops).

BTW. Try to change the “Subject:” -> e.g. put “TGeoManager” explicitly in the “Subject”, otherwise people who are interested in geometry problems may not read it at all.

Is there anybody out there, who’s “responsible” for the “geometry package” in ROOT?
I really think that the enormous RAM usage needs explanation (e.g. I personally use a 32-bit system, but I am considering moving to a 64-bit one … I don’t want to hit the wall on my 4 GB RAM laptop).

Hi,
This was already clarified here:
https://savannah.cern.ch/bugs/?98091

The issue on 64 bits is related to the different size of the word used for voxels allocation.

Regards,
Andrei

[quote=“agheata”]The issue on 64 bits is related to the different size of the word used for voxels allocation.[/quote] Thanks for pointing me to the “bug #98091”. I understand that, in that particular case, the problem was solved for the original author (he modified his source code which creates his geometry).

However, there are many cases in which one is not able / allowed to modify the provided source code.

Well, maybe it would be a good idea to fix it in the ROOT source code then?
So that, regardless whether one uses a 32 or a 64 bit system, the “word size” would be the same and so the RAM consumption would be equal.