JuliaPhysics/SolidStateDetectors.jl

Update config file format

fhagemann opened this issue · 8 comments

fhagemann commented

Based on the clarification of impurity and charge densities (#65), the redefinition of primitives (#84), the implementation of transformations (#62) and the refactoring of the CSG (#110), we need to update the config file format.

For this, we should decide on a long-term supported format, such that the user will have to update the config file format once (ideally with the help of conversion functions that SSD will provide).

lmh91 commented

At the end, so after the changes you mentioned, we should also have a look regarding the simulation of multiple detectors.
This not only concerns the config file but maybe also mutable struct Simulation.
Just to keep this in mind.

  • 👍1
fhagemann commented

Also, parameters of the charge drift model should be part of the general config file (preferably with splitted config files), rather than being stored separately in a folder that no one will find.

fhagemann commented

I gathered all comments in PR regarding the new structure of config files to gather them here:

PR #122 in a comment from @lmh91 about the general definition of VolumePrimitives

Instead of

type: "tube"
r: 
  from: 0.1
  to: 0.5
phi: 
  from: 0.0
  to: 360.0
h: 1.0

define the whole thing as tube instead of having a `type: "tube"`` inside the definition:

tube:
  r: 
   from: 0.1
   to: 0.5
  phi:
   from: 0.0
   to: 360.0
  h: 1.0

PR #84 in a comment from @fhagemann about the general definition of CSGTransformations

Instead of making transformations part of the objects, i.e.

type: "tube"
r: 
  from: 0.1
  to: 0.5
h: 1.0
translate:
  z: 1.0

give the object the name of the transformation and pass it the values needed for its definition, i.e.

translate:
  z: 1.0  # defines the translation
  tube:   # primitive that is translated
    r: 
      from: 0.1
      to: 0.5
    h: 1.0

PR #84 in a comment from @lmh91 on the general definition of CSGRotations

Rotations should be either defined by angles around specific axes or as a general rotation matrix:

rotate: XYZ = [90, 0, 45] # first rotate around X, than, Y, than Z
rotate: ZX = [-45, 10] # first rotate around Z, than X
rotate: M = [1, 0, 0, 0, 0, 1, 0, 1, 0] # Vector of length 9 (if matrix notation is supported by yaml/json)

This requires the respective parsing functions for each of the cases.

PR #84 in a comment from @fhagemann about updating config files

The new version v0.6 should be equipped with two methods: one to convert old config files to the new format, and one to convert geometries created in code from the primitive constructors to a respective config file. First work can be found in the comment mentioned in the title of this subsection.

PR #104 and #144 on splitted config files and ChargeDriftModels

The config files for detector geometries and ADLChargeDriftModels are spread all over the package and should be merged.
Now with splitted config files, this would keep the config files short, clear and well structured. It would be nice to merge all config files together to avoid double defintions (material and temperature) and keep geometric input (like phi110 for ADLChargeDriftModel) next to the definition of the detector itself.
With this comes the idea to parse an arbitrary crystal orientation to ADLChargeDriftModel (#67) that should follow the same syntax as rotations in general.

fhagemann commented

Before closing this issue, we still have to decide on:

  • How (and where) to include ChargeDriftModel in the general detector config files (preferably using splitted config files) (#162).
    This can then also include how to parse arbitrary crystal orientations to the ADLChargeDriftModel (#161).
  • How to choose the config format such that multiple detectors can be defined. This also comes with a change in the source code of the Simulation struct.
fhagemann commented

As #110 implies that we need to have a final discussion about the config file format, this is the issue to clarify!

lmh91 commented

As we discussed offline we see the format as fixed.
We will add some features to it but those should not break old config files.

fhagemann commented

@lmh91: What is the default config file we would like the user to have?

  • json or ỳaml?
  • surroundings as part of the detector or outside?
  • origin / translate ?

Then, I can update the script to convert old config files to new config files and force the new config files to have the format that we would recommend.

lmh91 commented

I would use yaml. It can be written more compact and one can add comments.

I think we agreed that both is possible. I would put it outside in the example files.

Even though I think origin is much better inside the primitives defintion you can use translate there.