Linear Collider Forum



Home » Analysis and Reconstruction » Tracking & Vertexing » Inconsistencies with "Transience Flag"
Inconsistencies with "Transience Flag" [message #2093] Fri, 19 November 2010 02:18 Go to next message
rosemann
Messages: 41
Registered: March 2009
Location: hamburg.de
Hi everyone,

I noticed some slight confusion and unfortunately also plain errors/bugs concerning the usually common processor parameter of whether the output collection is to be stored (e.g. in a file) or not.

The currently common name is "SetOutputTransient". Due to historic reasons these are sometimes still integers. Even worse, sometimes the logic is turned around, so only when you set this parameter to true/non-zero, the collection will be saved.

So I will change this in every processor that I can find to the right logic. But besides this, it might be easier to understand -- in reading and writing -- to call this parameter "SetOutputPersistent" or even something like "CommitOutputToStorage".

This will of course lead to a change in the "interface", or rather a change in all the existing steering files.

Opinions? Objections?

Cheers,
Christoph


When you have eliminated the impossible, whatever remains, however improbable, must be the truth. (Sir A.C. Doyle in Sign of Four)
Re: Inconsistencies with "Transience Flag" [message #2094 is a reply to message #2093] Fri, 19 November 2010 02:44 Go to previous messageGo to next message
killenberg
Messages: 125
Registered: July 2005
Location: CERN
In principle we could skip this flag at all. The LCIOOutputProcessor is able to drop or preserve collections, either by type or by name.

But I found it convenient to have this flag with the processor. I agree that the name is not very easy to understand, but I think the logic is good: Normally a collection is written, unless specified otherwise.
The parameters you propose have the inverse logic: The parameter has to be set for the collection to be written, and is true by default. Would this not cause more confusion, now that some users are already used to the current scheme?

How about changing the comment lines so people are aware what transient means:
A collection is NOT written to disk if the transient flag is true (default: false. The collection is written to disk).


In terms of backward compatibility: A new parameter does not necessarily have to be in the steering file. We just have to make sure it has a reasonable default value. I don't know if a parameter (the old one) is in the steering file but was removed from the processor. We cannot leave both (for backward compatibility) because their use is mutually exclusive. And we cannot give precedence to one. This would lead to strange bugs if both or the 'wrong' one is used/modified in the steering file.

So we could change the parameter without causing too much trouble. But I vote for clarifying the usage of SetOutputTransient and making it consistent.

Cheers

Martin

[Updated on: Fri, 19 November 2010 02:45]


Martin Killenberg

CERN
martin.killenberg@cern.ch
Re: Inconsistencies with "Transience Flag" [message #2095 is a reply to message #2094] Fri, 19 November 2010 03:11 Go to previous messageGo to next message
rosemann
Messages: 41
Registered: March 2009
Location: hamburg.de
Hi Martin,

I'm all in favour for simplicity. A comment needs to be read and understood, which is a complication. If the parameter is called "WriteOutputToStorage", then there is no misunderstanding about software concepts, and no double-negation ("i don't want to not store the output") is needed to achieve the same effect.

I've collected five votes so far, (hopefully without biasing the voters) and all are in favour of the inverted logic w.r.t. what we have now.


Cheers,
Christoph

If we are voting anyhow, the here's the preliminary count:
six votes for "WriteOutputToStorage" (default true)
one vote for "SetOutputTransient" (default false)

[Updated on: Fri, 19 November 2010 03:52]


When you have eliminated the impossible, whatever remains, however improbable, must be the truth. (Sir A.C. Doyle in Sign of Four)
Re: Inconsistencies with "Transience Flag" [message #2096 is a reply to message #2095] Fri, 19 November 2010 04:19 Go to previous messageGo to next message
killenberg
Messages: 125
Registered: July 2005
Location: CERN
Hello Christoph,

you are right. I always thought about "I set transient true in order not to write the output." But "I set transient false to prevent the data from not being written" is not so good. We should change this.
I think it historically came from the fact that the lcio::collection has this transient flag, which we just repeated for the processor.

So you have another vote for "WriteOutputToStorage"

Cheers

Martin


Martin Killenberg

CERN
martin.killenberg@cern.ch
Re: Inconsistencies with "Transience Flag" [message #2097 is a reply to message #2093] Fri, 19 November 2010 10:44 Go to previous message
jabernathy
Messages: 78
Registered: March 2006
Location: University of Victoria
That sounds like a good change.
Previous Topic:Recent Changes in MarlinTPC trunk
Next Topic:Problem in track reconstruction
Goto Forum:
  

[ PDF ]

Current Time: Sun Feb 23 21:02:33 Pacific Standard Time 2020
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.1.
Copyright ©2001-2010 FUDforum Bulletin Board Software