I have some geometry code to build a stainless steel tank with rounded ends and a pipe coming out the top. I use G4Polycone for this, rather than a mess of booleans to reduce memory, computation, and visualization problems. My debugging output prints the list of (r,z) corners used, CDMSPolyconeMaker[Polycone] 34 (r,z) corners (0,-460) (450,-460) (462.941,-458.296) (475,-453.301) (485.355,-445.355) (493.301,-435) (498.296,-422.941) (500,-410) (500,410) (498.296,422.941) (493.301,435) (485.355,445.355) (475,453.301) (462.941,458.296) (450,460) (114.3,460) (114.3,960) (107.95,960) (107.95,447.3) (450,447.3) (459.654,446.029) (468.65,442.303) (476.375,436.375) (482.303,428.65) (486.029,419.654) (487.3,410) (487.3,-410) (486.029,-419.654) (482.303,-428.65) (476.375,-436.375) (468.65,-442.303) (459.654,-446.029) (450,-447.3) (0,-447.3) These are actually passed to G4Polycone as the usual r[] and z[] arrays, via a statement like tankS = new G4Polycone("ETank", 0, twopi, 34, rlist, zlist); In 9.6, I get exactly the shape desired, shown in the first attachment. In both 10.0.p03 and 10.1, the pipe stem is replaced by a cone extending from part of the upper curved rim out to where the pipe should end; this is shown in the second attachment. I dumped the GDML version of my geometry in the 9.6 and 10.0 tests to compare the actual constructed solids. In 9.6, I got a set of 17 (rmax,rmin,z) planes (attachment 3 [details]), which is consistent with what I'd expect from my construction above, but some of them don't look right. In particular, all of the planes have rmax <= rmin, and there are three "point" planes with rmax==rmin. In 10.0, I get a set of _thirty_ (rmax,rmin,z) planes (attachment 4 [details]), which I guess are trying to deal with my approximated curved rims better. These planes all have sensible rmax>=rmin values, and there's just one "point plane at (0,0) down at the bottom of the tank. But some of the steps don't look right, especially in the transition near the bottom of the attachment, from the tank to the pipe stem, where the radii don't match my shape. Looking carefully, I'm not actually sure _either_ of the GDML outputs are "correct" (in the sense of reproducing the (r,z) corners I original provided). Even the 9.6 version seems to have incorrect planes, as I noted above. However, the solid as visualized in 9.6 is correct, while in the 10 series it is wrong.
Created attachment 304 [details] Etank (upside-down) as built in 9.6.p03
Created attachment 305 [details] Etank (upside-down) as built in 10.0.p03 and 10.1
Created attachment 306 [details] Extract from GDML dump of Etank in 9.6.p03
Created attachment 307 [details] Extract from GDML dump of Etank in 10.0.p03
Dear Michael, Thank you for reporting this problem and for very detailled report. I could reproduce it very easily. When user constructs G4Polycone by using corners(r,z) internaly on the construction time polycone is transformed to a polycone with (rmin,rmax,z) planes when it is possible. It seems that the values of (rmin,rmax,z) are wrongly calculated. I'm working on the fix. Best Regards, Tatiana
Hi again, Tatiana. I took a close look at G4Polycone in 9.6 vs. 10.0, and I think I see the problem. In 10.0, somebody changed the restrictions on the (r,z) corner inputs. In 9.6, that constructor could handle any arbitrary sequence of corners, including Z changing direction. With 10.0, the constructor was changed to only allow users to provide a monotonically increasing (not even decreasing!) set of Z values. It looks like the original form of G4Polycone has been moved to G4GenericPolycone. Of course, that means that any user applications which utilize this feature got broken in 10.0, including CDMS :-( By itself, this wouldn't be a problem, but it means that user apps with this feature cannot be used with both older and newer releases of G4. I think this means there isn't a "bug" per se, but rather an interface change which I got burned by. I would request, if it isn't too much work, that you add a "sanity check" to the G4Polycone constructor: If the z[] array is not monotonically increasing, throw an exception with text telling the user they must use G4GenericPolycone instead. If you can do it, it would be nice to backport to 10.0 and 10.1.
Hi Mike, Thank you for your comments. In 9.6. and earlier versions in GDML Generic Polycone constructor was not supported. If user was calling G4Polycone with (r,z) corners internally G4Polycone was setting (rmin,rmax,z) planes, but is not always possible.It was decided to add GenericPolycone and a conversion from (r,z) constructor to (zmin,zmax,z) constructor when it is possible. But here I made a mistake in conversion, I'm working on it, and I will look how to back port this change to 9.6.. Best Regards, Tatiana
Created attachment 317 [details] Fix for SetOriginalParameters Fix for conversion from (r,z) constructor to (rmin,rmax,z) constructor.
Dear Mike, The fix for error in conversion(SetOriginalParameters) is ready, you can try it with 10.1 version. I will have a look how it can be used for 9.6 version. Best Regards, Tatiana
Created attachment 318 [details] Cutaway of E-tank built against G4 development tree with G4Polycone.cc patch. The code fix worked for my application. Attachment #6 [details] shows my geometry (here in cutaway) drawn against the latest G4 development tree including the modified G4Polycone.cc from attachment #5 [details].
