Invoke CreateGeometry() from StBFChain

[plexoos]

• Add function CreateGeometry() to StarGeometry library
  The code from StarDb/AgMLGeometry/CreateGeometry.h is copied to

  StarVMC/StarGeometry/CreateGeometry.cxx
  StarVMC/StarGeometry/CreateGeometry.h
  

• StBFChain: Call compiled CreateGeometry()

[genevb]

No objection.

[plexoos]

No objection.

No objection to merging this failing code? Hm... interesting 🤔 😄

[veprbl]

I suppose, we might want to remove the macro files, if they are not used anymore?

[klendathu2k]

The StarDb/AgMLGeometry macros are still required. Any maker in the chain can request the geometry through GetDatabase("VmcGeometry") at any point in the lifetime of the application (during or after StChain::Init()). When that call is made, the DB looks for macros under StarDb/AgMLGeometry (or AgiGeometry depending on alias settings...).

The initialization of the geometry in StBFChain is only performed when certain makers are in the chain (see line 1015).

[veprbl]

dlopen error: /star-sw/.sl79_gcc485/LIB/libStarGeometry.so: undefined symbol: chain

Looks like we've never landed the 205f44a.

[plexoos]

Ah, yes! I think that is the reason why half of the tests crashed

[veprbl]

Now ROOT5 seems to not handle the extern *chain in bfc.C.

[klendathu2k]

CreateGeometry will not be found if the agml libraries are not loaded, e.g. if the AgML chain option is not specified. We switched to using AgML for the geometry description ~ 2012. Prior to that the geometry was supported from macros translated directly from the AgSTAR geometries (StarDb/AgiGeometry/). Thpse macros also depend on "CreateGeometry"... albeit a much simpler macro.

[genevb]

Maybe this is already known to @klendathu2k and @plexoos , but I figured I would document that I see that the current method of this in DEV does create some (not large) lost memory, according to valgrind in tests I was doing for something else:

==15423== 4 bytes in 1 blocks are definitely lost in loss record 15,244 of 312,718
==15423== at 0x4029885: operator new(unsigned int) (vg_replace_malloc.c:328)
==15423== by 0x150EDEC5: G__StarGeo_Cint_558_0_2(G__value*, char const*, G__param*, int) (StarGeo_Cint.cxx:544)
...
==15423== by 0x4284B0F: TCint::Calc(char const*, TInterpreter::EErrorCode*) (TCint.cxx:655)
==15423== by 0x1113149E: StBFChain::Init() (StBFChain.cxx:1039)

Where StBFChain.cxx:1039 is the call to CreateGeometry:

        LOG_INFO << "StBFChain::Init force load of " << file << endm;
        TString command = ".L "; command += file;
        gInterpreter->ProcessLine(command);
        gInterpreter->Calc("CreateTable()");             // <-- LINE 1039
        command.ReplaceAll(".L ",".U ");
        gInterpreter->ProcessLine(command);

Which is clear because the following is the only "force load of" in the output of the job:

BFC:INFO - StBFChain::Init force load of /afs/rhic.bnl.gov/star/packages/DEV/StarDb/AgMLGeometry/Geometry.y2021a.C

[genevb]

Actually it's a larger amount of "definitely lost memory" than I noted in my previous message as I see now several other such messages in the valgrind output, culminating in this biggest definite loss. I guess it may not be a big deal if the loss occurs after the geometry objects are done being used?

==15423== 107,204 (84,100 direct, 23,104 indirect) bytes in 725 blocks are definitely lost in loss record 312,478 of 312,718
==15423== at 0x4029885: operator new(unsigned int) (vg_replace_malloc.c:328)
==15423== by 0x4254E6E: TStorage::ObjectAlloc(unsigned int) (TStorage.cxx:325)
==15423== by 0x808DF26: TObject::operator new(unsigned int) (TObject.h:156)
==15423== by 0x13A0D2AC: AgPosition::rotation() (AgPosition.cxx:146)
==15423== by 0x13A0D5EA: AgPosition::matrix() (AgPosition.cxx:190)
==15423== by 0x13A356FC: StarTGeoStacker::Position(AgBlock*, AgPosition) (StarTGeoStacker.cxx:1208)
==15423== by 0x1551353E: WCALGEO1::WMOD::Block(AgCreate) (WcalGeo1.cxx:206)
==15423== by 0x139F4531: AgBlock::Create(char const*) (AgBlock.cxx:79)
==15423== by 0x1551673E: WCALGEO1::WcalGeo1::ConstructGeometry(char const*) (WcalGeo1.cxx:828)
==15423== by 0x149EB69C: WCAL::WCALv1::construct() (FcsmConfig.cxx:104)
==15423== by 0x14FEE8E2: y2021a::construct(std::map<std::string, int, std::lessstd::string, std::allocator<std::pair<std::string const, int> > >) (StarGeo.cxx:1700)
==15423== by 0x150E643D: StarGeometry::Construct(char const*) (StarGeo.cxx:19972)
==15423== by 0x150F0784: Geometry::ConstructGeometry(char const*) (StarGeo.h:1005)
...
==15423== by 0x4284B0F: TCint::Calc(char const*, TInterpreter::EErrorCode*) (TCint.cxx:655)
==15423== by 0x1113149E: StBFChain::Init() (StBFChain.cxx:1039)

[veprbl]

star-sw/StarVMC/StarAgmlLib/AgPosition.cxx

Lines 144 to 146 in fd34a52

	TGeoMatrix *AgPosition::rotation()
	{
	TGeoRotation *rot = new TGeoRotation();

star-sw/StarVMC/StarAgmlLib/AgPosition.cxx

Lines 165 to 168 in fd34a52

	TGeoMatrix *AgPosition::translation()
	{
	TGeoTranslation *tran = new TGeoTranslation();

star-sw/StarVMC/StarAgmlLib/AgPosition.cxx

Lines 190 to 198 in fd34a52

	TGeoRotation *R = (TGeoRotation *)rotation();
	TGeoTranslation *T = (TGeoTranslation *)translation();
	// R->SetTitle( "geometry file" );
	// T->SetTitle( "geometry file" );
	TGeoCombiTrans *C = new TGeoCombiTrans( *T, *R );
	C->SetTitle( R->GetTitle() );
	return C;