[WIP] CAD beampipe implementation

[aciarma]

BEGINRELEASENOTES
Imported beampipe from CAD model, including:

• AlBeMet beampipe ±1.2m from the IP (central + trapezoidal chamber)
• Copper beampipe from ±1.2m to ±6.0m, including SR mask shape (not filled yet)
• Copper cooling manifolds in the trapezoidal chamber
• Gold layer
• Paraffin cooling in the central section
• Water cooling in the trapezoidal chamber

Added in a separated folder FCCee/CAD_beampipe as it is independent from the detector.

Added a dedicated .xml file to visualise it (i.e. geoDisplay) but the beampipe files should be included in the main .xml of the detectors.

-- A more complete description, with bellows/remote vacuum connection/flanges etc will come --

ENDRELEASENOTES

[andresailer]

Why ±2.5m AlBeMet, when it should only be ±1.19 m (1.28m?), as far as I understand our note.

[aciarma]

Yes, according to the beampipe is AlBeMet only up to the bellows (±1.2) and after that copper.

The CAD with the right design exists, but for the moment I have a single CAD file for the beampipe down to ±2.5m to reach also the separation region, and for technical reasons the volume can be given only one material.

After completing this first implementation I will add the complete one, also because some small adjustments are still ongoing in particular on the bellow/remote vacuum connection area.

I add this note to the description above anyway, thanks for noticing

[aciarma]

@andresailer is LiquidNDecane the material to use for the paraffin?

[andresailer]

Yes @aciarma , that name is more precise than Paraffin.

[aciarma]

@andresailer for the moment I added all the volumes for the beampipe description, so to me this PR is ready.

The realistic part from the bellows on (1.2~2.5m) will be added once the remote vacuum connection and BPM designs will be completed.

I've checked with checkOverlaps and looked at few key points along the pipe with g4MaterialScan. The implementation seems to be working correctly both for geometry and material. Few very small air gaps O(~0.1mm) between layers are due to the tessellation of the volumes.

Are there some other checks that needs to be done?

[andresailer]

Could you please fill the RELEASENOTES like in the other PRs here?

[BrieucF]

Thanks!

Can you add a compact file with everything needed to have the beampipe "complete" (i.e. including both Beampipe_onlylegs.xml and Beampipe_CADimport.xml), named e.g. Beampipe_o1_v01.xml + a test running with this compact file? See e.g. https://github.com/key4hep/k4geo/blob/master/lcgeoTests/CMakeLists.txt#L57-L60

[BrieucF]

Do I understand correctly that both files should be included to have a 'complete' beampipe? Can you say a word why the beampipe is 'split' into two compact files?

[aciarma]

now only one .xml file for the beampipe

[BrieucF]

This README is very similar to the one in FCCee/CAD_beampipe/, should it be updated? Are they both needed?

[aciarma]

I removed it, it was a leftover duplicate of an old version

[BrieucF]

Shall we remove from this file all constants that are not relevant to the beampipe and rename the file FCCee_BeampipeDimensions.xml @andresailer ?

[aciarma]

As now all the geometries are imported directly from CAD (so they are not parametric) there is no need for a FCCee_BeampipeDimensions.xml file.

[BrieucF]

The current folder structure (Pipe_17032023 and Pipe_18072023) suggests that they are two versions of the beampipe. But both are actually needed. I would propose to merge Pipe_17032023 and Pipe_18072023 into one folder or to rename them according to their content.

[aciarma]

I removed the old Pipe_xxxxxx folders as they had some issues in the design, and am now left with only the latest one. In the future when other versions (with different designs or more details) will be added, every folder will contain all the necessary files, and if they are duplicated from old versions a symlink can be used, as we discussed the other day

[BrieucF]

I see only the CAD part of the beampipe here, should'nt there be also the part with DD4hep_Beampipe_o1_v01?

[BrieucF]

I still believe it would be better to append o1_v01 to this filename

[aciarma]

Now everything is CAD, also the legs (it was easier to just extend directly the model instead that trying to match the two volumes). No DD4hep volumes anymore. I will add the o1_v01 and change the file names

[BrieucF]

Is it possible to remove the 'id' there or is it crashing? It may conflict with id defined in other detectors when importing this xml...

[aciarma]

done for all

[BrieucF]

Same here

[BrieucF]

Same here

[BrieucF]

Same here

[BrieucF]

Same here

[BrieucF]

And here

[BrieucF]

Thanks Andrea! Except for the file test_g4mat.sh which should be moved to e.g. FCCee/CAD_beampipe/scripts It looks good to me! Note: some of the materials will also probably have to be ported in the materials.xml of the detectors when we will include the new beampipe but I propose we do that in those future PR's.

[aciarma]

Thank you, test_g4mat.sh may also be removed if not strictly necessary, but I can make a script folder. About the material I agree with you, I had these here just to make the standalone version readable. Maybe a common material list can be shared by all detectors?

[BrieucF]

Thank you, test_g4mat.sh may also be removed if not strictly necessary, but I can make a script folder. About the material I agree with you, I had these here just to make the standalone version readable. Maybe a common material list can be shared by all detectors?

I think it is useful to have this script there, other people may be interested in studying the beampipe material budget and starting with an example is always easier. Also, I guess that the Gaudi based MaterialScan will not work due to the CAD import.

About the materials.xml shared across detectors, it is something we could indeed discuss, but not for this PR.

All good to me @andresailer !

[aciarma]

Today/monday I will also add the tungsten SR mask (simple template as the real design does not exist yet). I am waiting for the CAD model to be ready so I can import it. After that to me it is good.

[BrieucF]

Hi @aciarma, is this PR ready on your side?

[aciarma]

Hi @BrieucF, the geometry models are there and are displayed correctly with geoDisplay/jsroot, but the tests are failing so I'll try to understand what is wrong.

[atolosadelgado]

Hi,

The test can not run because the relative paths only seem to work when the working directory is the compact directory. Since it is just for a test, the option to run the test inside that directory can be added by modifying the line 93 of the file lcgeoTests/CMakeLists.txt

SET_TESTS_PROPERTIES( t_${test_name} PROPERTIES FAIL_REGULAR_EXPRESSION  "Exception;EXCEPTION;ERROR;Error" WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/../FCCee/CAD_beampipe/compact")

The warnings I found when running ddsim appear if the facet is smaller than the surface thickness 1e-9 mm, so nothing to worry about.

[atolosadelgado]

Hi,

The number of vertices is quite high, and I think it is related to the high level of detail (there are vertices 1e-16 cm apart). Is this level of detail really needed? If not, would be it possible to get rid of some vertices easily?

Thank you for your time.
Alvaro

[atolosadelgado]

This will make the ddsim run,

Suggested change

	ddsim --compactFile=${CMAKE_CURRENT_SOURCE_DIR}/../FCCee/CAD_beampipe/compact/testBeampipe_CADimport_o1_v01.xml --runType=batch -G -N=1 --outputFile=testBeampipe_CADimport_o1_v01.slcio )
	ddsim --compactFile=${CMAKE_CURRENT_SOURCE_DIR}/../FCCee/CAD_beampipe/compact/testBeampipe_CADimport_o1_v01.xml --runType=batch -G -N=1 --outputFile=testBeampipe_CADimport_o1_v01.slcio --part.userParticleHandler= )

[atolosadelgado]

Suggested change

	SET_TESTS_PROPERTIES( t_${test_name} PROPERTIES FAIL_REGULAR_EXPRESSION "Exception;EXCEPTION;ERROR;Error" )
	SET_TESTS_PROPERTIES( t_${test_name} PROPERTIES FAIL_REGULAR_EXPRESSION "ERROR;Error" )

Could you please remove Exception;EXCEPTION from the list of Regular expresion?
3 facets are too small, and probably trigger this error when closing the geometry

14: -------- WWWW ------- G4Exception-START -------- WWWW -------
14: *** G4Exception : GeomSolids1001
14:       issued by : G4TessellatedSolid::SetSolidClosed()
14: Defects in solid: ASCII_shape_0x30e3ac0 - some facets have wrong orientation!
14: *** This is just a warning message. ***
14: -------- WWWW -------- G4Exception-END --------- WWWW -------
14: 
14: 
14: -------- WWWW ------- G4Exception-START -------- WWWW -------
14: *** G4Exception : GeomSolids1001
14:       issued by : G4TessellatedSolid::SetSolidClosed()
14: Defects in solid: ASCII_shape_0x30e3ac0 - there are holes in the surface!
14: *** This is just a warning message. ***
14: -------- WWWW -------- G4Exception-END --------- WWWW -------

[atolosadelgado]

Hi,

When Geant4 builds the CAD design, it finds the following errors:

1. It looks that the following three messages are caused by existence of very narrow triangles:
   • Facet is too small or too narrow.
   • Attempt to add facet not properly defined.
   • Defects in solid: ASCII_shape_0x1f41a000 - there are holes in the surface!

The interpretation is the following:
* First a narrow triangle is marked as a not properly defined facet by G4TriangularFacet (1st message)
* Then G4TesselatedSolid refuses to take it (2nd message),
* and finally a hole is detected during the check of the structure (3rd message).

Changing line #84 in G4TriangularFacet.cc to G4double delta = 0.; could make these messages to disapear.

2. The message:
   Defects in solid: ASCII_shape_0x1f41a000 - some facets have wrong orientation!

means that the tessellated solids contains a pair of edges which have the same directions. Тhe reason for this needs to be investigated. Possibly, some parts of the solid touch each other.

[atolosadelgado]

Hi,

When Geant4 builds the CAD design, it finds the following errors:

1. It looks that the following three messages are caused by existence of very narrow triangles:
   
   * Facet is too small or too narrow.
   * Attempt to add facet not properly defined.
   * Defects in solid: ASCII_shape_0x1f41a000 - there are holes in the surface!

The interpretation is the following: * First a narrow triangle is marked as a not properly defined facet by G4TriangularFacet (1st message) * Then G4TesselatedSolid refuses to take it (2nd message), * and finally a hole is detected during the check of the structure (3rd message).

Changing line #84 in G4TriangularFacet.cc to G4double delta = 0.; could make these messages to disapear.

2. The message:
   `Defects in solid: ASCII_shape_0x1f41a000 - some facets have wrong orientation!`

means that the tessellated solids contains a pair of edges which have the same directions. Тhe reason for this needs to be investigated. Possibly, some parts of the solid touch each other.

In the previous message I just listed the errors, but no solutions. I am not expert in CAD, so I do not know exactly how this can be tackled, but I would propose:

1. Keep the geometrical resolution above 1 nm. If vertexes are closer than 1nm, the corresponding facets are rejected by Geant4, leaving a hole, and lead to undefined behavior during the simulation. The navigation performance inside a tessellated solid in Geant4 depends on the number of vertexes squared, o(n**2), so it is a another idea to keep in mind when creating the mesh to be used in simulations.
2. In order to avoid the second error, if a shape is defined in CAD as union of simple shapes that are just touching along a line, it would be better to define those shapes as separated or place them in such a way they touch on a surface rather than a pair of points. Debugging CAD geometry seems to be extremely challenging, if the source of the second error is something else, I have no clue.

No longer relevant

[aciarma]

I think I should close this other PR right? it is old and outdated by #344

[BrieucF]

Yes you can close this one