Skip to content

gvolume design #5

@maureeungaro

Description

@maureeungaro

Hello Mauri,

Good to get started on this right away.

OK to start with the GVolume class, since that is needed for everything else. I think this is actually not quite a trivial class. This class is actually very important, because this is where you will have most of your interaction when defining your geometry. It thus needs to have all the “bells and whistles” to make such an interaction as flexible as possible.

Here is my philosophy on such an object:

Since the object is essentially a “container” for information (in this case the geometry information), it should behave like one, i.e. the following constructs should work.
gvolume[‘pos’] should return the 3 vector for position and the associated dimensions in 2 lists (or tuples).
gvolume.get(‘pos’) does the same.
gvolume.set(‘pos’,’1mm 2.cm 1.3inch’) # This means we DO need string/unit parsing and conversion.
gvolume.set([1.,2.,1.3],([“mm”,”cm”,”inch”]) # this should do the same, so we use overloading.
gvolume[‘pos’] = ([1.,2.,1.3],([“mm”,”cm”,”inch”]) # This we may need to look at. I don’t know if = can be overloaded.
It also needs to be possible to create the object from a simple string, or from a set of arguments:
gvolume(“name | mother | description | '’1
mm 2.cm 1.3inch’ | …..)
gvolume(name=“name”,mother=“mother”,description=“This is a volume”,pos = ’1*mm 2.cm 1.3inch’, ….)
Again, items like “pos”, and “dims” need to be flexible in how you define them, so it can also be pos=[1.,2.,1.3],pos_units=[“mm”,”cm”,”inch”]
The object must know how to present itself for inspection.
Define the str() method, so you can print the object and see what it contains. The output of this string can either be the GEMC txt format, or something more verbose.
The class uses the correct formatting so that Python help(gvolume) gives very useful and meaningful output.
More pedantic documentation is written in a Python notebook, which GitHub is happy to render for you to pdf if you don’t have Jupyter installed.

My current implementation has some, but not all of this. I also had the class itself know how to translate to different formats (i.e. it had a write_sql() to put out an SQL string), which I think in our rewrite we could leave to a separate library, i.e. a MySQL input/output class.

As you can see, I think this class does need to ability to convert units. You would want to store the data in consistent units (whatever is the Gemc standard), but you may want to input an object using inches. Translations between the standard length units and angle units are not complicated, and I have already implemented something we can adapt.

I don’t see how you want incorporate CLHEP into this project. Do you mean to use Geant4Py? (http://geant4.web.cern.ch/geant4/UserDocumentation/UsersGuides/ForApplicationDeveloper/BackupVersions/V9.3/html/apas08.html)
I have not used this, but it could be useful for this project. Using this we can replace all of Gemc with Python :-)

I would prefer to keep the core library as free of non standard Python as possible. For instance, the ROOT code should only be in the ROOT module, so that if ROOT is not installed, everything else is still fully functional. We can argue whether Numpy or Scipy are sufficiently standard, but I would hesitate having a CLHEP or G4 Python binding as a pre-requirement for all this to work.

Note: How do we move this discussion to GitHub so it is archived? Is the current correct location for this project gemc/api/python?

Best,
Maurik

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions