Project

General

Profile

Bug #5034

GDMLSchema directory not located in same area as geometry gdml file

Added by Brian Rebel over 5 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Geometry
Target version:
Start date:
12/03/2013
Due date:
% Done:

90%

Estimated time:
Occurs In:
Experiment:
-
Co-Assignees:
Duration:

Description

The experimental geometry files all point to a GDMLSchema file that is assumed to live in Geometry/gdml/GDMLSchema. One can copy that directory to the experiment specific location of the gdml files, i.e.

/uboone/app/users/brebel/mrb/localProducts_larsoft_v0_01_01_e2_debug/uboonecode/v0_00_01/gdml/Geometry/gdml/GDMLSchema/gdml.xsd

or we could put in a better path that looks to a more central location.

History

#1 Updated by Erica Snider over 5 years ago

  • Category set to Geometry
  • Target version set to v0_02_00

The first question is whether this file is still needed, since the later versions of the parser might know the schema. Brian will test this.

If the file is still required, we should define an environment variable that points to a central directory, since copying the schema to multiple places seems like a bad idea, and we have no control over the file search mechanism used by the gdml parser.

In this case, I would propose that we use $GDML_SCHEMA_PATH/xxx.xsd with the requirement that this gets set in the LArSoft setup. We can continue to install in the current location.

#2 Updated by Brian Rebel over 5 years ago

The files are unfortunately still needed. We should see if the GDML schema files exist as a product for download somewhere. I suspect that they do….

#3 Updated by Lynn Garren over 5 years ago

Looks like the schema are here:
http://lcgapp.cern.ch/project/simu/framework/GDML/gdmlschema.html

I'll see about making a product.

#4 Updated by Lynn Garren over 5 years ago

This tarball contains an exact match to larcore/Geometry/gdml/GDMLSchema:
http://service-spi.web.cern.ch/service-spi/app/releases/GDML/downloads/GDML_3_0_0.tar.gz
(Dec. 2008)

There is a newer tarball which is an exact match to the schema in geant4 v4_9_6_p01a:
http://service-spi.web.cern.ch/service-spi/app/releases/GDML/downloads/GDML_3_0_1.tar.gz
(Nov. 2011)

So there are two questions here.

First question, why not use the schema distributed with geant4? This does mean that you will get new schema files when you move to a new version of geant4. Would that be good, bad, or neutral?

Second question, if there is a reason to continue having a larsoft distribution of GDMLSchema, which distribution do you want? I presume you would want to update when you move to a newer geant4??

#5 Updated by Lynn Garren over 5 years ago

  • Assignee set to Lynn Garren

#6 Updated by Brian Rebel over 5 years ago

Let's see if we can make the version that ships with G4 work.

#7 Updated by Lynn Garren over 5 years ago

  • Status changed from New to Feedback

There is only 1 difference between larcore/Geometry/gdml/GDMLSchema and .../geant4/v4_9_6_p01a/source/geant4.9.6.p01a/source/persistency/gdml/schema:
gdml_materials.xsd has a new property in geant4 v4_9_6_p01a

I'm now waiting for a proposed solution from you. If you are going to use the geant4 gdml files, our build of geant4 needs to make sure they are always available and set some environmental variable.

#8 Updated by Brian Rebel over 5 years ago

I think this is a call for Rick. If we were to make our own ups product then we don't have to worry about checking each G4 build. On the other hand, if we rely on the G4 build then we will catch any changes to the schema automatically (i.e. things will just fail if something major changes).

#9 Updated by Erica Snider over 5 years ago

Since the schema is part of the geant4 product, and larcore already depends upon geant4 via root, I would prefer that we just use the schema that is in g4.

In order to maintain consistency with existing environment variable names and to avoid possible confusion (per Lynn's suggestion), we should use GDML_SCHEMA_DIR to point to the correct directory. This will need to be made part of the g4 packaging procedure. Since we can't make a new g4 before the next beta, however, we'll need to put this into the larcore table file for now.

#10 Updated by Lynn Garren over 5 years ago

  • Status changed from Feedback to Resolved
  • % Done changed from 0 to 100

larcore now explicitly sets up geant4 and defines GDML_SCHEMA_DIR. This is a temporary hack that will stay in place until larsoft uses a version of geant4 which defines GDML_SCHEMA_DIR.

The files in gdml/GDMLSchema are not installed and should be removed from the release, although I have not done that.

#11 Updated by Erica Snider over 5 years ago

  • Status changed from Resolved to Remission

The GDML_SCHEMA_DIR hack will not work because the GDML parser assumes that the schema directory is relative to the GDML file directory. Until we have a work-around for this problem, we will need to use the local installed version of the schema files.

Reverted larcore, and added the schema files with a local install for lbnecode and uboonecode, since both have gdml files.

#12 Updated by Erica Snider over 5 years ago

  • Target version changed from v0_02_00 to v0_02_02

Need to fully investigate getting the path correct. The schema files are opened and read by xerces_c. Can then implement the permanent solution and close the issue.

#13 Updated by Erica Snider over 5 years ago

  • % Done changed from 100 to 90

#14 Updated by Lynn Garren about 4 years ago

Discussion with Hans Wenzel.

All geant4 gdml examples contain http links to the schema files. We need to edit our gdml files to point to local schema files so internet access is not required.

For instance, in icarus.gdml:

<gdml xmlns:gdml="http://cern.ch/2001/Schemas/GDML" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xsi:noNamespaceSchemaLocation="GDMLSchema/gdml.xsd">

We are not sure if we can use environmental variables in the gdml files.

#15 Updated by Lynn Garren almost 4 years ago

  • Target version changed from v0_02_02 to develop/HEAD

#16 Updated by Erica Snider almost 3 years ago

  • Status changed from Remission to Rejected

This problem cannot be fixed with the current software, so we are closing the issue as "rejected".

#17 Updated by Erica Snider almost 3 years ago

  • Status changed from Rejected to Closed


Also available in: Atom PDF