BDSGeometryInterface.cc doesn't write quad strengths correctly.
The quadrupole strengths & a few other quantities are always written to the survey file as 0. They are currently commented out in BDSGeometryInterface.cc as a quick get-around but they need fixing properly.
Comments (5)
-
-
Yes, this seems sensible. The interface has required rewriting really since we have refactored much of the geometry construction this year (2015).
In future, it may be of utility to go down the route of having a magnet strengths class in the parser, much the way we have now done for tunnel models or cross-section biasing, that holds all multipolar strengths. This can be used by the survey writer as both the parser element and the BDSAcceleratorComponent are available at the same time. The parser lists are deleted after construction so this will not impact memory usage during the run.
I also propose we rename it to BDSSurvey. It's not really an interface to access geometrical parameters and only serves to write a survey. The full model (not always with interrogation) is stored in BDSAcceleratorModel.
We can also deprecate the BDSExecOptions --optics option.
Lastly, the --outline --outfile options are named inconsistently as compared to the other input options. We have
--file=inputfile.gmad --outfile=myresults
I propose:
--survey=mysurvey #extension added automatically
There's not really need for two options as there's only one possible output type (no optics, only survey). If this one exists then it's clear what's to happen.
-
-
assigned issue to
agreed to the proposed changes. assigning to myself
-
assigned issue to
-
this was slightly more involved than I had imagined since we sometimes have multiple BDSBeamlineElements per GMAD::Element (for SBends). But the issue is fixed now with the survey code in BDSDetectorConstruction.
-
- changed status to resolved
fix issue
#60: fix and move and writing of survey to BDSDetectorConstruction→ <<cset 346e296e96f1>>
- Log in to comment
The problem is that we don't need the magnet strengths anymore in BDSIM, so we don't save them after parsing. We can recalculate those, but how about moving the call to BDSGeometryInterface into BDSDetectorConstruction? That seems a natural place as we have the parser Element and the AcceleratorComponent at the same time. The interface of GeometryInterface might need to be changed a bit (writing per line, instead of a loop internally).