Skip to Content.
Sympa Menu

opal - Re: [Opal] [bug?] Probe data is not always saved

opal AT

Subject: The OPAL Discussion Forum

List archive

Re: [Opal] [bug?] Probe data is not always saved

Chronological Thread 
  • From: "Adelmann Andreas (PSI)" <andreas.adelmann AT>
  • To: "Opal AT" <Opal AT>
  • Subject: Re: [Opal] [bug?] Probe data is not always saved
  • Date: Wed, 14 Jun 2017 06:32:29 +0000
  • Accept-language: en-US, de-CH

Hi James, this should be fixed in the next release (1.6.0). At the moment we
are waiting
with the release until a root problem is fixed. However you can always
checkout and build from
the source if time is an issue.
Cheers Andreas
Dr. sc. math. Andreas (Andy) Adelmann
Staff Scientist
Paul Scherrer Institut WBBA/219 CH-5232 Villigen PSI
Phone Office: xx41 56 310 42 33 Fax: xx41 56 310 31 91
Phone Home: xx41 62 891 91 44
Friday: ETH CAB F37 or HPK G 28 +41 44 632 75 22
The more exotic, the more abstract the knowledge,
the more profound will be its consequences.
Leon Lederman

> On 14 Jun 2017, at 01:16, Daniel Winklehner <Winklehn AT> wrote:
> Hi James,
> This is a known bug in 1.4 and has been brought up a few weeks ago by
> someone else too. Back then I commented that it is fixed in the master but
> I don't know if that was propagated back through previous versions.
> Andreas should be able to comment.
> Cheers,
> Daniel
>> On Jun 13, 2017, at 17:47, James Gerity <jgerity AT> wrote:
>> All,
>> It seems that any tracker error raised in the
>> ParallelCyclotronTracker will prevent the finalization of probes in
>> ParallelCyclotronTracker::execute().
>> This function calls one of several Tracker_*() functions that may
>> throw an error and when this is the case, the end of execute() is
>> skipped, so that finalise() is not called for each element in the
>> selected beamline, including any probes that might have stored data.
>> I've locally modified my working copy of OPAL (1.4.0-rc3, but at a
>> glance the execute() function looks similar in the development
>> version) to catch the thrown OpalException, finalise() the entire
>> beamline, and re-throw the exception. For the simulations I'm running,
>> it is most convenient to track particles until they are "lost" rather
>> than a particular duration, and it seems to me that the general
>> end-user would expect the probes to output events seen before the
>> error, rather than discarding all of this data.
>> Thanks,
>> James

Archive powered by MHonArc 2.6.19.

Top of Page