The OPAL Discussion Forum

["Adelmann Andreas (PSI)" <andreas.adelmann AT psi.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 mit.edu> 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 tamu.edu> 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