Problem 24 - G4Polyhedra gives Exceptions for legal parameters
Summary: G4Polyhedra gives Exceptions for legal parameters
Status: CLOSED FIXED
Alias: None
Product: Geant4
Classification: Unclassified
Component: geometry (show other problems)
Version: 0.1
Hardware: PC Linux
: P2 normal
Assignee: Gabriele Cosmo
URL:
Depends on:
Blocks:
 
Reported: 1999-10-26 08:19 CEST by Ivana.Hrivnacova
Modified: 2012-02-15 04:20 CET (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this problem.
Description Ivana.Hrivnacova 1999-10-26 08:19:06 CEST
Polygone parameters that are legal in G3:
// PGON params
// 10.3429 360 35 2 -56.85 37.7 40 -58.35 37.7 40
result in "Illegal input parameters" exception in G4:

G4Polyhedra (Solid): Illegal input parameters: R/Z values must be specified cloc
kwise
*** G4Exception: Aborting execution ***

I have put in /afs/cern.ch/user/i/ivana/public/g4bug
the modified ExN02DetectorConstruction and the output.
Comment 1 Gabriele Cosmo 1999-11-10 08:22:59 CET
Problem reported to author.
Comment 2 Gabriele Cosmo 1999-11-26 04:45:59 CET
Problem is fixed in tag geometry-V00-01-02.
Fixes will be included in release Geant4 1.0.
-----------------
Original messages by D.Williams (davidw@scipp.ucsc.edu):

Wed, 10 Nov 1999
----------------
The problem with G4Polyhedra is that, using the G3 style
constructor, it requires the z planes in such simple polyhedras
to be in accending order.
This funny quirk actually has a reason: it is possible to use z
values that are not strickly monotonically increasing in order
to define more complex solids.

In this case it seems a bit of a liability, though. I'll put
together a reasonable fix and submit it to the repository as
fast as I can test it.

Wed, 10 Nov 1999
----------------
I've submitted the following to the G4 repository:

CSG/include/G4ReduciblePolygon.hh    rev 1.4
CSG/src/G4ReduciblePolygon.cc        rev 1.4
CSG/src/G4Polyhedra.cc               rev 1.8
CSG/src/G4Polycone.cc                rev 1.6

These should fix the bug reported.

New code is only invoked at the point were there used to be
an exception. I therefore don't expect this change to have
much of an impact on already working code.