Fluka2gdml conversion issue - compound materials - material not found

[mjpietrzak]

I get the following error while converting a Fluka .inp file to GDML.

File "/usr/local/lib/python3.10/dist-packages/pyg4ometry/fluka/fluka_registry.py", line 135, in getMaterial return self.materials[name] KeyError: 'M1001'

[stewartboogert]

@mjpietrzak Can you please upload the FLUKA file the creates this bug. It appears by the naming of the material, is it a FLUKA file created by a GDML2FLUKA conversion. If so then could you please let me know which files you used. Also can you say if it was on the main branch or v1.1 (the latest tag in git and released on pypi)

[mjpietrzak]

Yes, it happens on the main branch (v1.1). The file was created by Flair from an MCNP geometry file. The problem may be on the Flair side, not pyg4ometry. I'm not a Fluka user, so I don't even know whether this kind of naming scheme is acceptable in Fluka by default, namely, M1001 should be H-1, M8016 should be O-16, M8000 should be oxygen with a natural abundance of isotopes, etc.

My workaround is to define these materials by hand in the Fluka file (Flair does not define them during conversion). Below is a minimal example reproducing the error (the original file is too large to share). Below "GEOEND", there are two materials defined that are commented out if uncommented the conversion to GDML works (the workaround I mentioned).

TITLE
Testing root output
GLOBAL                                         1.0       1.0
DEFAULTS                                                              NEW-DEFA
BEAM           -10.0                                                  PROTON
BEAMPOS          0.0       0.0       0.1
GEOBEGIN                                                              COMBNAME
    0    0          Testing
* Black body
SPH blkbody    0.0 0.0 0.0 10000000.0
* Void sphere
SPH void       0.0 0.0 0.0 1000000.0
* Cylindrical target
RCC target     0.0 0.0 0.0 0.0 0.0 10.0 5.0
END
* Black hole
BLKBODY      5  +blkbody -void
* Void around
VOID         5  +void -target
* Target
TARGET       5  +target
END
GEOEND

*...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
*MATERIAL           1         1       1.0                              M1001
*MATERIAL           8                 1.0                              M8016

*LEAD:
MATERIAL          82                 1.0                              M1

*WATER:
MATERIAL                             1.0                              M2
COMPOUND   -0.111894     M1001 -0.888106     M8016                    M2

* ..+....1....+....2....+....3....+....4....+....5....+....6....+....7..
ASSIGNMA    BLCKHOLE   BLKBODY
ASSIGNMA      VACUUM      VOID
ASSIGNMA      COPPER    TARGET
USRICALL
USROCALL
USERDUMP       100.0      50.0       0.0                              dump
RANDOMIZ         1.0
START         1000.0
STOP

[stewartboogert]

Ok it really looks like the materials are not assigned to the regions. I've not used Flair MCNP loading, but I think GDML/MCNP etc loading in Flair are at best partial (although I would need to check more carefully). So

• assigning materials yourself is working ok?
• And the conversion to Geant4 is working?

Just to note, the FLUKA to Geant4 conversion in pyg4ometry isn't the greatest. I am working on a H-rep (infinite half-space representation MCNP and FLUKA) opposed to B-rep (boundary representation as used in Geant4) tracker for Geant4. This means the FLUKA/MCNP/PHITs geometry will be able run directly and at speed in Geant4. This is still a few months away from being finished.

If you are comfortable to email me (stewart.boogert@manchester.ac.uk) the MCNP file, this will accelerate my testing of the new code H-rep tracker and also test if the problem is in pyg4ometry or Flair. Otherwise please follow the g4fx repo in this GitHub organisation and you can see the progress.