GDML
GDML copied to clipboard
KeithSloan
Elliptical Cuts
Greetings! When i press the cut button, i have following prompt:
[<SelectionObject>,<SelectionObject>] Boolean Cut
but nothing happened. What could it be? With part workbench it runs fine meanwhile.
FreeCAD 0.20.2 GDML - last Release
Actually i figure out what is happening: when i cut two objects, one of them are pulled out from cut base property and falling under element tree. Then, when its to be sticked again we just need to recompute object to see it properly.
Is that the cut button in the GDML workbench or the Part workbench?
The Boolean operations in the GDML workbench assume that there is one GDML object per Part/(Volume) and you select the two Parts for the boolean operation.
From you last comment, I will check if there is a missing recompute following the Cut.
Okay checked the code and a GDML boolean operation creates a new Object for which a recompute was performed, but not for the Tool and Base Object that get removed. Have push an update that will now do a Document recompute for GDML booleans. Interested to know if this fixes the issue you are seeing.
And there is one more: as you can see at Bool_Cut object, when i do cuts with y axis translations, it is not saving the object in good manner. Even after editing, saving and reopen it states on the brocken place. May be it also couldn't work with x-translation, i didn't test it.
https://github.com/KeithSloan/GDML/issues/108#issuecomment-1490401375 Hm, interesting behavior!
Okay I am trying to recreate. If I create the two Ellipitical Tubes and Cut I get
AfterCut-worldVOL.gdml.txt BeforeCut.FCStd.txt AfterCut.FCStd.txt
The translation that at issue is
At what point are you applying the y translation? Is it being applied to the GDML Object ElTube_007 or the Part that contains the ElTube_007 before the Cut?
BeforeCutObjPlacement.FCStd.txt BeforeCutPartPlacement.FCStd.txt
If the translation is applied to the Part before the boolean, for me it seems to be okay. If the translation is applied to the GDMLObject before the boolean, the translation is lost.
Is this what you are also seeing.
Have pushed a fix for Boolean Cut Placement.Bases
Rotations not yet handled and needs to be applied to booleans other than Cut.
Would appreciate if you could test, so that can at least apply to other booleans.
Now it works good with thanslations. But still in bool cut operation base property not filled out. I still should do it by myself.
And one more I found wondering: when you point, for example, dz for box or tube, it means full length along z, but for ELTube it says a half width along z axis. Shouldn't it be full length, since its not a radius?
"Now it works good with thanslations. But still in bool cut operation base property not filled out. I still should do it by myself"
There have been a number of updates to the code, please could you check this is with latest code
This is what I am seeing with test files, one where change of Placement is in Part and the other in GDMLElTube
Base seems to be set to me.
BeforeCutObjPlacement.FCStd.txt
BeforeCutPartPlacement.FCStd.txt
Manual says
3.4.4 Elliptical Tube The GDML Elliptical Tube is formed using 3 dimensions: dx x semi axis dy y semi axis dz z semi axis
You are correct, what is implemented, z is treated as full length.
Need to check which is correct.
ElTube looks correct in Geant4, so assume there is an error in the manaul and I need to change the description in the GDML ElTube property description.
I do a bit different cut, when one object included in another:
and i get
But your method works perfectly.
I do a bit different cut, when one object included in another:
Okay - Now able to reproduce the problem you are seeing, will see what we can do.
Booleans should be between objects that have a SHAPE. App::Parts really should not be used as the base and tool of boolean operations, even if they some times seem to work. So the items in the last figure that should be selected for cutting are the GMLElTube and GDMLElTube001 and not the Parts they are in.
Booleans should be between objects that have a SHAPE. App::Parts really should not be used as the base and tool of boolean operations, even if they some times seem to work. So the items in the last figure that should be selected for cutting are the GMLElTube and GDMLElTube001 and not the Parts they are in.
Note: That is not how it is currently coded. The selection is checking for a part.
If I switch to using selecting of GDMLobjects, what should happen about the Placement of the Part of the second Object? Ignore? or find parent?
I would check for shape, not GDMLObject (hasattr(obj, 'Shape')). I believe the current code (that I fixed!) takes into account BOTH placements, but I will double check.
But it could have a Shape and not be a GDML Object.
"The code you fixed" Is that in your repro?
Yes, that's the hole point. The user should be able to do booleans with any solid, not just GDML objects. One should think of GDMLobjects as new specialized solids, but boolean operations should operate on any solid, not just the specialized solid.
The last branch I pushed and that you already merged into Main already has the code to to take into account the placement of both tool abd base Parts. Check the code in BooleanCutFeature.
"Yes, that's the hole point. The user should be able to do booleans with any solid, not just GDML objects. One should think of GDMLobjects as new specialized solids, but boolean operations should operate on any solid, not just the specialized solid."
But when the Non GDML object with a Shape gets exported, how is that handled? surely better to have a GDMLBoolean that will only allow booleans of GDMLObjects.
Things can have Shapes, that have no GDML equivalent,
Under the Part workbench if you try a cut with a Part that has sub parts:
You get the error
09:02:12 Traceback (most recent call last):
File "
and the following is produced
Now our current code only selects the first of the to objects and would work. Should discuss this offline before deciding on best approach.
@KeithSloan
We do export non GDML objects and booleans thereof and have been for a very long time. Extrusions, Revolutions, ... etc.
"We do export non GDML objects and booleans thereof and have been for a very long time. Extrusions, Revolutions, ... etc."
So the export code will handle a boolean of a GDML object and Extrusion or Revolution?
But there is nothing to stop the user creating a non supported Shape will the export code just ignore, report the issue?
Yes, the export code does handle booleans of GDML and non GDML objects, as long as there is an exporter for that particular solid. At present if there is no exporter, the solid will be skipped. We should add a message to that effect. Check your email.
Yes, we currently do support export of booleans of GDML and (supported) non-GDML solids:
In case it is hard to see, above is a cut between a GDMLBox and a sphere (Part sphere, not GDMLSphere). Export works fine.
I do a bit different cut, when one object included in another:
Doing a boolean operation between a volume and one of its descendants is really a little strange. If you do the operation under the Part workbench, you will get a result, but even there, the Part workbench complains:
15:54:13 Traceback (most recent call last):
File "
Best have the operands of the boolean operation on the same level, not one contained within the other
Actually, export to gdml far from ideal. Some details should be tuned after saving to gdml, but i fine with it. More crucial, there is objects that permanently lose their position, etc. For example GEARS.gdml.zip For now ELTube110 and Box098 has y position translation on -70 mm and -140 mm accordingly. Whereas initially Box099 had +70 mm translation through the y axis. After editing of placement, there is no changes occurs.
Actually, export to gdml far from ideal. Some details should be tuned after saving to gdml, but i fine with it. More crucial, there is objects that permanently lose their position, etc. For example GEARS.gdml.zip For now ELTube110 and Box098 has y position translation on -70 mm and -140 mm accordingly. Whereas initially Box099 had +70 mm translation through the y axis. After editing of placement, there is no changes occurs.
Please could you supply the FreeCAD file for GEARS that you are exporting - Thanks
Actually, export to gdml far from ideal. Some details should be tuned after saving to gdml, but i fine with it. More crucial, there is objects that permanently lose their position, etc. For example GEARS.gdml.zip For now ELTube110 and Box098 has y position translation on -70 mm and -140 mm accordingly. Whereas initially Box099 had +70 mm translation through the y axis. After editing of placement, there is no changes occurs.
Please could you supply the FreeCAD file for GEARS that you are exporting - Thanks
ger.FCStd.txt As you can verify, there are two types of fails: N250 is possible to be tuned, and N10, N614 as unchangeable objects.
@Alex2671
Could you please check if the attached file works. There seems to be a problem (on our side) of exporting two different solids but with the same name. I have changed the name of the base solid in N1 from GDMLElTube_GDMLElTube to GDMLElTube_GDMLElTube000.
With my version of geant (geant4.10.07) I get display artifact when the cutting solid has a matching surface with the solid being cut, so I increased the z-dimension of the cutting solid to avoid that distracting artifact. That should have no effect on the simulation.
We will work on fixing the naming roblem.
I don't know what you mean "N10, N614 as unchangeable objects".