Print

Print


Hi,

I have implemented a few changes related to these issues that should make lcsim compatible now with the LCIO C++ trunk.

The momentumAtEndpoint reading/writing is implemented now in lcsim and methods were added to the appropriate interfaces.

I've also updated the internal version of lcsim LCIO in lcsim to 2.7 which should match the current version from the standalone project.

You should see these updates in the current 3.7-SNAPSHOT of lcsim, and I tested that the momentum at endpoint is available in data I generated using a SLIC DEV build (that is using LCIO trunk).

> There is a potential additional issue with using the v02-06 version, in that this will not contain the fix needed to read LCIO that was written by our JAVA code.

We can move on to using v02-07 if we want.

Are we still using the 'collection_type_fix' branch for this particular fix?  I think we are stuck using the branch until we can convince Frank to merge your changes into the trunk.

I can always update the branch if you want by merging from current LCIO trunk if you need those updates (please let me know exactly what you want to do here).

--Jeremy

-----Original Message-----
From: Maurik Holtrop [mailto:[log in to unmask]] 
Sent: Wednesday, July 20, 2016 11:18 AM
To: McCormick, Jeremy I.
Cc: hps-software
Subject: Re: LCIO issue

Hello Jeremy,

I am surprised that this happened one sided in the C++ version. Does the LCIO data format have a version tag, or some way to identify what version is being read?  Without such a tag, I would say it should be forbidden to change the data format. With such a tag, any changes to the data format should be written in such a way that older data is still readable, by checking the version first. In either case the JAVA version should be made compatible with the C++ version.

I don’t know who is in charge of the LCIO data format, by I would push them to either made the two implementation compatible, or to formally revert that change from the trunk. 

There is a potential additional issue with using the v02-06 version, in that this will not contain the fix needed to read LCIO that was written by our JAVA code. 

Best,
	Maurik


> On Jul 13, 2016, at 9:16 PM, McCormick, Jeremy I. <[log in to unmask]> wrote:
> 
> Hi,
> 
> I think that I may have found a pretty severe bug in LCIO, or at least a mismatch between the Java implementation and the C++.
> 
> It seems that in the C++ implementation now has an extra data field in  MCParticle to store the endpoint momentum which is present in the 2.7 releases and the trunk.  This seems to make simulation files unreadable in our Java code when these versions are used to simulate the data!
> 
> So I would suggest instead of changing our Java LCIO implementation (which I am reluctant to do right now), we standardize on an older known good LCIO release and do not use the 2.7 releases or the trunk (these do not have any updates in them that we need anyways).
> 
> I am using the 'v02-06' tag and it seems to not have this problem.
> 
> You can check it out using....
> 
> svn co svn://svn.freehep.org/lcio/tags/v02-06
> 
> For the recent fix to the collection types (discussed on this list and on JIRA) I forked this tag into the branches directory instead of using the trunk.
> 
> Long term, I am going to look at getting our LCIO implementation up to date with the C++ implementation, but for now this should fix the issue.
> 
> I hope that makes sense.  Let me know if you have any questions/comments.
> 
> --Jeremy
> 
> ########################################################################
> Use REPLY-ALL to reply to list
> 
> To unsubscribe from the HPS-SOFTWARE list, click the following link:
> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1


########################################################################
Use REPLY-ALL to reply to list

To unsubscribe from the HPS-SOFTWARE list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1