Choose a set of sub-pages to visit ...

Click here for AGDD_XmlFileBuilder pages.

Click here for SCT_AGDD_XmlFileBuilder pages.


From lester@hep.phy.cam.ac.uk Wed Sep 27 12:41:48 2000
Date: Mon, 25 Sep 2000 13:36:21 +0100 (GMT)
From: Christopher Lester <lester@hep.phy.cam.ac.uk>
To: Stan Bentvelsen <stanb@nikhef.nl>,
     LAPORTE Jean-Francois <laport@hep.saclay.cea.fr>,
     steven Goldfarb <steven.goldfarb@cern.ch>,
     Marc Virchaux <virchau@hep.saclay.cea.fr>,
     Andrea DellAcqua <Andrea.Dellacqua@cern.ch>,
     Christian Arnault <arnault@LAL.IN2P3.FR>,
     Julius Hrivnac <Julius.Hrivnac@cern.ch>,
     Jean-Francois Laporte <laporte@hep.saclay.cea.fr>,
     Katsuya Amako <Katsuya.Amako@kek.jp>, Tom LeCompte <lecompte@anl.gov>,
     Adele Rimoldi <adele.rimoldi@cern.ch>
Subject: Re: Workshop in Amsterdam: small and big topics
 
 

(Find small topics at the end ....)

The bigger topic:  SHAPE/VOLUME/MATERIAL distinction
----------------------------------------------------

(perhaps deserve a timetabled slot of its own?)

* Presently a box is both box shaped AND has a material (I will argue
this is not necessarily ideal)
* Boolean "solids" currently merge volumes rather than shapes. I
will also argue that I don't like that either, since this leads to
two problems:
  1) One boolean solid has its material specified in many different
parts of the XML file (bad!) all of which need to be changed when the
material needs to be updated.
  2) Presently, "higher order" syntax checking is required to ensure
that booleans only merge objects of identical material.

PROPOSAL:

(Notation - in the following, I use the terms "VOLUME" and "SHAPE" to
refer to objects respectively WITH or WITHOUT any solid-property
information connected with them)

I will propose that:

* SHAPES without materials or other solid properties should be
  introduced as new elements in the XML:
 <boxShape ... /><trdShape ... /> etc

* Existing elements: <box ... /><trd ... /> etc should be RETAINED,
  (and would continue to denote VOLUMES), but they should be
  considered only as short-hand forms for a new xml-element:

* The <materialize name=CDATA shape=IDREF solid_properties... />
  element.  This should become a new element whose job is to bestow
  solid properties (such as material) onto shapes.

* Boolean solids should become SHAPES not VOLUMES, and should only be
  permitted to combine other SHAPES together.  Boolean solids can
  be materialized into VOLUMES using the element above.

* This change is backward compatible, except for files which have
used boolean solids.  These files will need small to add
modifications.

Examples:

E.g.1: the following VOLUME ...

 <box name="myBox" X_Y_Z="1 2 3" material="silicon" />

... would be thought of as a shorthand for ...

 <boxShape name="myBoxShape" X_Y_Z="1 2 3" /> // SHAPE
 <materialize name="myBox"   // VOLUME
   shape="myBoxShape"
   material="silicon" />.

E.g.2: The following XML ...

 <boxShape name="part1" X_Y_Z="4 5 6" />  // SHAPE
 <boxShape name="part2" X_Y_Z="7 8 1" />  // SHAPE

 <union name="myUnionShape">  // STILL A SHAPE!
    <posXYZ volume="part1" /> //(may only position a shape)
    <posXYZ volume="part2" />
 </union>

... would replace the current way of using booleans, and if this
boolean was then ready for direct use ...

 <materialize  name="myUnionVolume" // NOW IT'S A VOLUME!
   shape="myUnionShape"
   material="cheese" />

... would be how the volume would be made.

--------------------------------------------------------------

Other small topics, that probably do not require their own slots in
the agenda, but which I hope to bring up include:

1)
Either: change status of all identifiers' "step" attributes to
IMPLIED rather than providing a default.
Or: invent two types of identifier (one with step and one without)

2)
Add "skipZero=(true|false),default false" attribute to all
identifiers for which the "step" attribute is valid, in the event
that people need +- symmetric ids: -3 -2 -1 +1 +2 +3

3)
Change (or augment!) the trd "inclination" attribute from an angle
based coordinate to the 2D displacement of the top
surface.  Advantages: no coordinate singularity (unlike
inclination="90 0") and more directly applicable in SOME
circumstances.

See you Wednesday/Thursday

Christopher Lester
 
 
 
 
 
 
 
 

From lester@hep.phy.cam.ac.uk Wed Sep 27 12:41:48 2000
Date: Mon, 25 Sep 2000 13:36:21 +0100 (GMT)
From: Christopher Lester <lester@hep.phy.cam.ac.uk>
To: Stan Bentvelsen <stanb@nikhef.nl>,
     LAPORTE Jean-Francois <laport@hep.saclay.cea.fr>,
     steven Goldfarb <steven.goldfarb@cern.ch>,
     Marc Virchaux <virchau@hep.saclay.cea.fr>,
     Andrea DellAcqua <Andrea.Dellacqua@cern.ch>,
     Christian Arnault <arnault@LAL.IN2P3.FR>,
     Julius Hrivnac <Julius.Hrivnac@cern.ch>,
     Jean-Francois Laporte <laporte@hep.saclay.cea.fr>,
     Katsuya Amako <Katsuya.Amako@kek.jp>, Tom LeCompte <lecompte@anl.gov>,
     Adele Rimoldi <adele.rimoldi@cern.ch>
Subject: Re: Workshop in Amsterdam: small and big topics
 
 

(Find small topics at the end ....)

The bigger topic:  SHAPE/VOLUME/MATERIAL distinction
----------------------------------------------------

(perhaps deserve a timetabled slot of its own?)

* Presently a box is both box shaped AND has a material (I will argue
this is not necessarily ideal)
* Boolean "solids" currently merge volumes rather than shapes. I
will also argue that I don't like that either, since this leads to
two problems:
  1) One boolean solid has its material specified in many different
parts of the XML file (bad!) all of which need to be changed when the
material needs to be updated.
  2) Presently, "higher order" syntax checking is required to ensure
that booleans only merge objects of identical material.

PROPOSAL:

(Notation - in the following, I use the terms "VOLUME" and "SHAPE" to
refer to objects respectively WITH or WITHOUT any solid-property
information connected with them)

I will propose that:

* SHAPES without materials or other solid properties should be
  introduced as new elements in the XML:
 <boxShape ... /><trdShape ... /> etc

* Existing elements: <box ... /><trd ... /> etc should be RETAINED,
  (and would continue to denote VOLUMES), but they should be
  considered only as short-hand forms for a new xml-element:

* The <materialize name=CDATA shape=IDREF solid_properties... />
  element.  This should become a new element whose job is to bestow
  solid properties (such as material) onto shapes.

* Boolean solids should become SHAPES not VOLUMES, and should only be
  permitted to combine other SHAPES together.  Boolean solids can
  be materialized into VOLUMES using the element above.

* This change is backward compatible, except for files which have
used boolean solids.  These files will need small to add
modifications.

Examples:

E.g.1: the following VOLUME ...

 <box name="myBox" X_Y_Z="1 2 3" material="silicon" />

... would be thought of as a shorthand for ...

 <boxShape name="myBoxShape" X_Y_Z="1 2 3" /> // SHAPE
 <materialize name="myBox"   // VOLUME
   shape="myBoxShape"
   material="silicon" />.

E.g.2: The following XML ...

 <boxShape name="part1" X_Y_Z="4 5 6" />  // SHAPE
 <boxShape name="part2" X_Y_Z="7 8 1" />  // SHAPE

 <union name="myUnionShape">  // STILL A SHAPE!
    <posXYZ volume="part1" /> //(may only position a shape)
    <posXYZ volume="part2" />
 </union>

... would replace the current way of using booleans, and if this
boolean was then ready for direct use ...

 <materialize  name="myUnionVolume" // NOW IT'S A VOLUME!
   shape="myUnionShape"
   material="cheese" />

... would be how the volume would be made.

--------------------------------------------------------------

Other small topics, that probably do not require their own slots in
the agenda, but which I hope to bring up include:

1)
Either: change status of all identifiers' "step" attributes to
IMPLIED rather than providing a default.
Or: invent two types of identifier (one with step and one without)

2)
Add "skipZero=(true|false),default false" attribute to all
identifiers for which the "step" attribute is valid, in the event
that people need +- symmetric ids: -3 -2 -1 +1 +2 +3

3)
Change (or augment!) the trd "inclination" attribute from an angle
based coordinate to the 2D displacement of the top
surface.  Advantages: no coordinate singularity (unlike
inclination="90 0") and more directly applicable in SOME
circumstances.

See you Wednesday/Thursday

Christopher Lester